Sunucu bakım penceresi nasıl planlanır ve bakım sırasında hizmet kesintisi nasıl azaltılır?

Bakım penceresi, sunucu üzerinde güncelleme, güvenlik yamaları, yeniden başlatma, disk kontrolü, servis ayarı veya yapılandırma değişikliği yapacağınız zaman aralığıdır. Amaç yalnızca işi tamamlamak değil; kullanıcıyı mümkün olduğunca az etkilemek, geri dönüş planını hazır tutmak ve bakım sonrası sistemi hızlı doğrulamaktır. Microsoft’un izleme ve bakım yaklaşımı, sorun oluşmadan önce düzenli önleyici bakım yapılmasını ve bir olay olduğunda hasarı sınırlayacak bir planın hazırlanmasını önerir. AWS tarafındaki yedekleme rehberleri de, kurtarma hedeflerini ve yedekleme işlemlerinin nasıl izleneceğini önceden tanımlamayı vurgular.

Bakım penceresinden önce netleştirilecekler​

Bakım işine başlamadan önce şu soruların cevabı belli olmalıdır:

• Hangi servisler duracak, hangileri çalışmaya devam edecek?
• Kesinti olacaksa kullanıcıya ne kadar önceden haber verilecek?
• İşlem geri alınabilecek mi, yoksa tek yönlü bir değişiklik mi yapılacak?
• Bakım sonrası “başarılı” sayılmak için hangi kontroller yapılacak?
• Bir şey ters giderse hangi adımda sistemi geri alacaksınız?

Burada en büyük hata, bakım penceresini sadece “süre” olarak görmek. Asıl önemli olan, o sürede yapılacak işin kapsamı ve her adımın sırasıdır. Örneğin güvenlik güncellemesi, veritabanı tarafında değişiklik, uygulama servislerinin yeniden başlatılması ve önbellek temizliği aynı pencereye sıkıştırılırsa sorun çıktığında hangi adımın etkili olduğunu anlamak zorlaşır.

İyi bir bakım planında bulunması gereken parçalar​

• Değişiklik listesi: Yapılacak işlemleri tek tek yazın; örneğin “paket güncellemesi”, “SSL sertifikası yenileme”, “servis yeniden başlatma”.
• Bağımlılıklar: Web sunucusu, veritabanı, DNS, yük dengeleyici ve yedekleme sistemi arasındaki sırayı belirleyin.
• Yedek ve geri dönüş noktası: Bakımdan önce geçerli bir yedek veya geri dönüş planı olduğundan emin olun.
• İzleme kontrolü: Bakım sırasında ve sonrasında CPU, bellek, disk I/O, servis durumu ve hata kayıtlarını kontrol edin.
• Doğrulama adımı: Sadece servis “çalışıyor” demek yetmez; giriş, temel sayfalar, panel erişimi ve kritik işlemler test edilmelidir.

Microsoft’un SharePoint için performans ve yedekleme rehberleri, yedek çözümünün bakım penceresi içinde tamamlanabilmesini test etmeyi ve sistemin SLA hedeflerini karşılayıp karşılamadığını doğrulamayı önerir. Bu yaklaşım, küçük siteler için de geçerlidir: bakım süresi, yedek alma süresi ve geri dönüş süresi ayrı ayrı ölçülmelidir.

Kesintiyi azaltmak için pratik yöntemler​

Küçük ama etkili bazı uygulamalar bakım etkisini azaltır:

• Yoğun kullanım saatleri yerine gerçek trafik verisine göre zaman seçin.
• Aynı anda çok fazla değişiklik yapmayın; adımları mümkünse bölün.
• Önce test ortamında deneyin, sonra canlıya uygulayın.
• Bakım sırasında kullanıcıya kısa ve net durum mesajı verin.
• Bakım bitince sistemin yalnızca açıldığını değil, doğru çalıştığını da kontrol edin.

Özellikle disk, veritabanı ve yedekleme işlemleri aynı anda çalışıyorsa performans düşüşü normal olabilir. Bu yüzden bakım saatinde beklenen yük artışını, gecikmeyi ve olası I/O dar boğazını önceden hesaba katmak gerekir. AWS’nin performans rehberleri de, sistem performansının düzenli izlenmesini ve alarm tabanlı bildirimlerle düşüşlerin erken fark edilmesini önerir.

Bakım sonrası yapılacak temel kontroller​

Bakım tamamlandıktan sonra şu kontroller genelde yeterli bir başlangıç sağlar:

• Servisler ayağa kalktı mı?
• Uygulama ana sayfası ve giriş sayfası açılıyor mu?
• Hata günlüğünde yeni kritik kayıt var mı?
• CPU, RAM ve disk kullanımı normal sınırda mı?
• Yedekleme, zamanlanmış görevler ve izleme uyarıları çalışıyor mu?

Eğer işlem sonrasında performans bozulduysa, önce değişikliğin hangi bölümünde sorun çıktığını ayırın. Sorun, yeni yapılandırmadan mı, servis yeniden başlatmasından mı, yoksa yedekleme/izleme ajanından mı kaynaklanıyor; bunu netleştirmeden yapılan hızlı müdahaleler genelde kalıcı çözüm üretmez. Bu noktada günlükler ve izleme verileri, varsayımla değil kanıtla ilerlemek için en değerli kaynaktır.

Sık yapılan hatalar​

• Bakım penceresini duyurmadan uygulamak.
• Yedeği doğrulamadan güncelleme yapmak.
• Geri dönüş planı olmadan yapılandırma değiştirmek.
• Bakım sonrası testleri atlamak.
• İzleme kapalıyken bakım yapmak ve sorunları sonradan fark etmek.

Özetle, iyi bir bakım penceresi “işi ne kadar hızlı yaptığınızdan” çok, değişikliği kontrollü yürütüp sorunu erken fark etmenize bağlıdır. Plan, yedek, izleme ve doğrulama birlikte düşünülürse, bakım çoğu zaman operasyonu bozmak yerine sistemi daha güvenli hale getirir.