Değişiklik Öncesi Etki Analizi
Linux sunucuda çekirdek, paket veya kritik servis güncellemesi yapmadan önce kapsamı, beklenen kesintiyi ve olası kullanıcı etkisini belirleyin. Üretim ortamında doğrudan denemek yerine mümkünse aynı işletim sistemi, paket ve uygulama sürümlerini içeren bir test sunucusunda doğrulama yapın.
Kontrol listesi:
Yedekleme ve Geri Dönüş Planı
Güncelleme öncesi yedek alınması tek başına yeterli değildir; yedeğin okunabildiği ve gerektiğinde geri yüklenebileceği doğrulanmalıdır. Veritabanlarında uygulamaya uygun, tutarlı yedekleme yöntemi kullanın. Dosya kopyası, disk snapshot'ı ve veritabanı yedeğinin aynı amaca hizmet etmediğini unutmayın.
İşlemden önce:
İşlemi yalnızca tek bir SSH oturumuna bağlamayın. Bağlantı kopsa bile sürecin izlenebilmesi için güvenilir bir oturum yöneticisi, sağlayıcı konsolu veya alternatif yönetim kanalı kullanın. Paket yöneticisinde bekleyen kilit, yarım kalmış işlem veya bozuk bağımlılık bulunmadığını doğrulamadan yeni bir güncelleme başlatmayın.
Komutları dağıtımınızın ve servis sağlayıcınızın dokümantasyonuna göre uyarlayın. Üretimde doğrulamadan kopyala-yapıştır komut çalıştırmayın; özellikle disk, ağ, güvenlik duvarı ve önyükleme yapılandırmasını değiştiren işlemlerde önce etkisini inceleyin.
Yeniden başlatmadan önce aktif bağlantıları, kuyrukları ve uzun süren işlemleri değerlendirin. Veritabanı veya dosya yazma işlemleri sürerken zorla kapatma veri bozulmasına yol açabilir. Gerekirse trafiği azaltın, görevleri duraklatın ve servisleri bağımlılık sırasına göre kontrollü biçimde kapatın.
Yeniden Başlatma Sonrası Doğrulama
Sunucunun açılması bakımın tamamlandığı anlamına gelmez. Önce temel sistem durumunu, ardından servis ve uygulama katmanını doğrulayın.
Sorun Durumunda Geri Dönüş
Servis başlamıyor, performans belirgin biçimde düşüyor veya kritik veri işlemleri başarısız oluyorsa art arda yeniden başlatmak ya da rastgele dosya silmek yerine geri dönüş planını uygulayın. Önce etkilenen düğümü trafikten çıkarın, hata kayıtlarını koruyun ve kapsamı sınırlayın.
Gerekirse doğrulanmış önceki paket sürümüne, snapshot'a veya yedeğe dönün. Geri dönüş sonrasında sağlık kontrollerini yeniden çalıştırın; veri kaybı ihtimali varsa yedeği kaynak sistemin üzerine yazmadan önce olayın kapsamını belirleyin. Kök neden incelenmeden aynı güncellemeyi tekrar uygulamayın.
Bakım kaydına uygulanan sürümleri, başlangıç ve bitiş zamanlarını, gözlenen hataları, alınan kararları ve geri dönüş sonucunu ekleyin. Böylece sonraki operasyon kişisel hafızaya değil, güvenli ve tekrarlanabilir bir prosedüre dayanır.
Linux sunucuda çekirdek, paket veya kritik servis güncellemesi yapmadan önce kapsamı, beklenen kesintiyi ve olası kullanıcı etkisini belirleyin. Üretim ortamında doğrudan denemek yerine mümkünse aynı işletim sistemi, paket ve uygulama sürümlerini içeren bir test sunucusunda doğrulama yapın.
Kontrol listesi:
- Çalışan servisleri, bağımlılıkları, açık portları ve kritik trafik saatlerini belirleyin.
- SSH erişiminin yanı sıra sağlayıcının web konsolu, rescue veya out-of-band erişiminin çalıştığını test edin.
- İşletim sistemi, çekirdek, paket ve uygulama sürümlerini kaydedin.
- Bakım penceresini, beklenen kesinti süresini ve geri dönüş kararını yazılı hâle getirin.
- İzleme, alarm ve sağlık kontrolü uçlarının güncel olduğundan emin olun.
Yedekleme ve Geri Dönüş Planı
Güncelleme öncesi yedek alınması tek başına yeterli değildir; yedeğin okunabildiği ve gerektiğinde geri yüklenebileceği doğrulanmalıdır. Veritabanlarında uygulamaya uygun, tutarlı yedekleme yöntemi kullanın. Dosya kopyası, disk snapshot'ı ve veritabanı yedeğinin aynı amaca hizmet etmediğini unutmayın.
İşlemden önce:
- Dosyaları, veritabanını ve kritik yapılandırmaları ayrı ve erişilebilir bir konuma yedekleyin.
- Bulut disk snapshot'ının uygulama tutarlılığı açısından uygun olup olmadığını değerlendirin; snapshot tek başına her zaman yeterli değildir.
- Geri dönüşte kullanılacak paket sürümlerini, yapılandırma dosyalarını ve servis bağımlılıklarını kaydedin.
- Yedekten küçük bir dosya veya test verisi geri yükleyerek bütünlük ve erişim kontrolü yapın.
- Geri dönüş kriterlerini ölçülebilir biçimde yazın: servisin belirli sürede başlamaması, hata oranının yükselmesi veya kritik sağlık kontrolünün başarısız olması gibi.
İşlemi yalnızca tek bir SSH oturumuna bağlamayın. Bağlantı kopsa bile sürecin izlenebilmesi için güvenilir bir oturum yöneticisi, sağlayıcı konsolu veya alternatif yönetim kanalı kullanın. Paket yöneticisinde bekleyen kilit, yarım kalmış işlem veya bozuk bağımlılık bulunmadığını doğrulamadan yeni bir güncelleme başlatmayın.
Komutları dağıtımınızın ve servis sağlayıcınızın dokümantasyonuna göre uyarlayın. Üretimde doğrulamadan kopyala-yapıştır komut çalıştırmayın; özellikle disk, ağ, güvenlik duvarı ve önyükleme yapılandırmasını değiştiren işlemlerde önce etkisini inceleyin.
# Örnek akış; gerçek komutları dağıtımınıza göre uyarlayın
mevcut sürüm ve servis durumunu kaydet
paket bağımlılıklarını ve bekleyen işlemleri kontrol et
güncellemeyi uygula
servis yapılandırmalarını doğrula
planlı yeniden başlatmayı gerçekleştir
Yeniden başlatmadan önce aktif bağlantıları, kuyrukları ve uzun süren işlemleri değerlendirin. Veritabanı veya dosya yazma işlemleri sürerken zorla kapatma veri bozulmasına yol açabilir. Gerekirse trafiği azaltın, görevleri duraklatın ve servisleri bağımlılık sırasına göre kontrollü biçimde kapatın.
Yeniden Başlatma Sonrası Doğrulama
Sunucunun açılması bakımın tamamlandığı anlamına gelmez. Önce temel sistem durumunu, ardından servis ve uygulama katmanını doğrulayın.
- SSH veya yönetim konsolu erişimini test edin.
- Diskleri, dosya sistemlerini, ağ arayüzlerini, DNS çözümlemesini ve sistem saatini kontrol edin.
- Kritik servislerin otomatik başladığını ve yeniden başlatma döngüsüne girmediğini inceleyin.
- Web, API, veritabanı ve kuyruk sağlık kontrollerini ayrı ayrı çalıştırın.
- Sistem ve uygulama günlüklerinde yeni hata, izin problemi veya bağlantı reddi arayın.
- CPU, bellek, disk kullanımı, gecikme ve hata oranlarının normal seviyelere döndüğünü izleyin.
Sorun Durumunda Geri Dönüş
Servis başlamıyor, performans belirgin biçimde düşüyor veya kritik veri işlemleri başarısız oluyorsa art arda yeniden başlatmak ya da rastgele dosya silmek yerine geri dönüş planını uygulayın. Önce etkilenen düğümü trafikten çıkarın, hata kayıtlarını koruyun ve kapsamı sınırlayın.
Gerekirse doğrulanmış önceki paket sürümüne, snapshot'a veya yedeğe dönün. Geri dönüş sonrasında sağlık kontrollerini yeniden çalıştırın; veri kaybı ihtimali varsa yedeği kaynak sistemin üzerine yazmadan önce olayın kapsamını belirleyin. Kök neden incelenmeden aynı güncellemeyi tekrar uygulamayın.
Bakım kaydına uygulanan sürümleri, başlangıç ve bitiş zamanlarını, gözlenen hataları, alınan kararları ve geri dönüş sonucunu ekleyin. Böylece sonraki operasyon kişisel hafızaya değil, güvenli ve tekrarlanabilir bir prosedüre dayanır.