Isletim Sistemi Buyuk Surum Yukseltmesi: Riskli Ama Kacinilmaz

İşletim Sistemi Büyük Sürüm Yükseltmesi: Riskli Ama Kaçınılmaz

Sunucunuzdaki işletim sistemi sürümünün desteği bitiyor. Güvenlik güncellemeleri kesilecek ve yeni paketler artık o sürüm için yayımlanmayacak. Yükseltme gerekiyor ama tek bir komutla yapılacak bir iş değil — çünkü büyük sürüm geçişi, alışık olduğunuz yamalamaya benzemez.

Bu yazı, büyük sürüm geçişini planlamayı ele alıyor.

Yamadan Farkı

Birinci satır en çok sürpriz üreten farktır: büyük sürüm geçişinde yalnızca sürüm numaraları değil varsayılan ayarlar da değişir — daha önce açık olan bir özellik kapalı gelebilir ve uygulamanız hiçbir kod değişikliği olmadan farklı davranmaya başlar.

Bu değişiklikler sürüm notlarında yazar.

Ama çoğu kişi bu notları okumaz.

Üçüncü satır ise planlamanın neden kritik olduğunu açıklar.

İki Yöntem

• Yerinde yükseltme.
• Yeni sunucu kurup taşıma.

İkinci yöntem çoğu durumda daha güvenlidir: yeni sürümle temiz bir sunucu kurup uygulamayı oraya taşımak, geri dönüş imkânını sonuna kadar korur — eski sunucu çalışmaya devam eder ve bir sorun çıkarsa trafiği geri almak dakikalar sürer.

Yerinde yükseltmede geri dönüş yedekten geri yükleme gerektirir.

Bu işlem saatler sürebilir.

Bulut ve sanal ortamlarda yeni sunucu maliyeti düşüktür.

Yükseltme Öncesi

1. Tam yedek alın ve doğrulayın.
2. Kurulu paketleri listeleyin.
3. Özel yapılandırmaları not edin.
4. Sürüm notlarını okuyun.

Birinci maddedeki doğrulama vurgusu önemlidir: yükseltme öncesi alınan yedek, geri yüklenebildiği kanıtlanmadıysa yedek sayılmaz — ve bunu öğrenmek için en kötü an, yükseltme başarısız olduktan sonradır.

Sanal ortamlarda anlık görüntü almak en hızlı güvencedir.

İkinci madde ise kaynak dışı kurulan yazılımları ortaya çıkarır.

Bu paketler geçişte en çok sorun çıkaranlardır.

Depo Dışı Paketler

İkinci satır geçişi durdurabilir: kullandığınız üçüncü taraf deponun yeni işletim sistemi sürümü için paketi yoksa yükseltme yarıda kalır veya o yazılım çalışmaz hâle gelir — bu kontrol yükseltmeden önce yapılmalıdır.

Veritabanı ve web sunucusu depoları bu gruba girer.

Üçüncü satır ise elle kurulan araçları kapsar.

Bunların kurulum adımları belgelenmiş olmalıdır.

Yapılandırma Çakışmaları

• Değiştirdiğiniz dosyalar sorulur.
• Yeni sürüm mü, sizinki mi?
• Karar dikkat ister.

Üçüncü madde acele edilmemesi gereken andır: yükseltme sırasında kendi yapılandırmanızı korumayı seçmek, yeni sürümün gerektirdiği ayarları kaçırmanıza yol açabilir — yeni dosyayı almak ise sizin özel ayarlarınızı siler.

Doğru yaklaşım, farkları tek tek incelemektir.

Bu inceleme zaman alır ama sonradan saatler kazandırır.

Yapılandırmaları sürüm kontrolünde tutmak bu işi kolaylaştırır.

Uygulama Uyumluluğu

1. Çalışma zamanı sürümü değişir.
2. Kütüphane sürümleri değişir.
3. Kod uyarlanması gerekebilir.

Birinci madde en büyük riski taşır: işletim sistemi yükseltmesi çoğu zaman dil çalışma zamanının da büyük sürüm atlamasına yol açar — uygulamanız yeni sürümde çalışmıyorsa sunucu ayakta olsa bile site açılmaz.

Bu nedenle uygulama önce test ortamında denenmelidir.

Test ortamı, hedef sürümle kurulmalıdır.

Üçüncü madde ise geçişin gerçek iş yükünü belirler.

Önce Provası

Üçüncü satır iletişim açısından değerlidir: provada ölçülen süre, müşterilere duyurulacak kesinti penceresini gerçekçi kılar — tahmine dayalı süreler neredeyse her zaman aşılır ve güven kaybı yaratır.

Prova, üretim verisinin kopyasıyla yapılmalıdır.

Boş bir sistemde yapılan deneme yanıltıcıdır.

Veri hacmi süreyi belirgin biçimde etkiler.

Yükseltme Sonrası

• Servislerin açılışta geldiğini doğrulayın.
• Günlükleri hata için tarayın.
• Performansı karşılaştırın.

Birinci madde sık atlanan bir kontroldür: yükseltme sırasında bazı servislerin açılışta başlama ayarı sıfırlanabilir — sistem çalışıyor görünür ama bir sonraki yeniden başlatmada o servis gelmez.

Bu sorun haftalar sonra ortaya çıkar.

Yükseltme sonrası bir kez yeniden başlatıp doğrulamak en güvenli yoldur.

Üçüncü madde ise beklenmedik yavaşlamaları yakalar.

Yeni varsayılanlar performansı değiştirebilir.

Yükseltme provası için ikinci bir sunucuyu kısa süreliğine kullanmak en güvenli yoldur; VDS altyapı paketleri ile geçiş sürecini kesintisiz planlayabilirsiniz.

Sonuç

Büyük sürüm geçişi yamalamaya benzemez: yalnızca sürüm numaraları değil varsayılan ayarlar da değişir ve uygulamanız kod değişmeden farklı davranabilir. Mümkünse yeni sunucu kurup taşıyın — geri dönüş imkânını korur. Üçüncü taraf depoları önceden kontrol edin, provayı üretim verisiyle yapın ve yükseltme sonrası bir kez yeniden başlatıp servislerin açılışta geldiğini doğrulayın.

Sıkça Sorulan Sorular (SSS)

Büyük sürüm geçişi neden riskli?

Yalnızca sürüm numaraları değil varsayılan ayarlar da değişir; daha önce açık olan bir özellik kapalı gelebilir ve uygulamanız hiçbir kod değişikliği olmadan farklı davranmaya başlar. Ayrıca geri almak, yamalamanın aksine zordur.

Yerinde mi yükseltmeli, yeni sunucu mu kurmalı?

Mümkünse yeni sunucu. Temiz kurulum yapıp uygulamayı taşımak geri dönüş imkânını sonuna kadar korur; eski sunucu çalışmaya devam eder ve sorun çıkarsa trafiği geri almak dakikalar sürer. Yerinde yükseltmede geri dönüş yedekten geri yükleme gerektirir.

Üçüncü taraf depoları neden kontrol etmeliyim?

Kullandığınız deponun yeni işletim sistemi sürümü için paketi yoksa yükseltme yarıda kalır veya o yazılım çalışmaz hâle gelir. Veritabanı ve web sunucusu depoları bu gruba girer; kontrolü yükseltmeden önce yapın.

Yükseltme sonrası neyi doğrulamalıyım?

Önce servislerin açılışta geldiğini. Yükseltme sırasında bazı servislerin açılış ayarı sıfırlanabilir; sistem çalışıyor görünür ama bir sonraki yeniden başlatmada o servis gelmez ve sorun haftalar sonra ortaya çıkar. Bir kez yeniden başlatıp doğrulayın.