Sunucular işini sessizce yapar. Ne zaman ki bir disk sesi değişir, bir yedekleme işi sessizce başarısız olur ya da bir sabah kimse dosya sunucusuna bağlanamaz — ancak o zaman fark edilirler. Bu sessizlik, sunucu bakımını her işletmede ertelenen işlerin başına koyar.
Oysa sunucu arızalarının büyük bölümü aniden ortaya çıkmaz. Öncesinde haftalar, bazen aylar süren uyarı sinyalleri verir. Periyodik bakımın amacı da bu sinyalleri arıza hâline gelmeden yakalamaktır.
Sunucu bakımı tam olarak neyi kapsar?
Bakım, "sunucuya bakmak" gibi belirsiz bir iş değildir. Ölçülebilir kontrollerden oluşur ve her birinin ne zaman alarm vermesi gerektiği önceden tanımlanmalıdır.
- Donanım sağlığı: RAID dizisi durumu, disk SMART değerleri, güç kaynağı ve fan çalışması, sıcaklık okumaları, RAM hata sayaçları.
- Depolama kapasitesi: Her birimin doluluk oranı ve büyüme hızı. Bir birimin haftada ne kadar dolduğu bilinmiyorsa, ne zaman dolacağı da bilinemez.
- Yedekleme doğrulama: Yedek işlerinin başarıyla bittiği ve alınan yedekten geri dönülebildiği. Bu ikisi farklı şeylerdir.
- Güncelleme durumu: İşletim sistemi, firmware, hipervizör ve kritik uygulama yamaları. Hangi yamanın neden ertelendiği de kayıt altında olmalıdır.
- Servis ve günlük denetimi: Beklenen servislerin çalışır durumda olması, olay günlüklerinde tekrarlayan hataların taranması.
- Güvenlik kontrolleri: Yerel yönetici hesapları, açık portlar, süresi dolan sertifikalar, gereksiz roller.
- Performans eğilimi: CPU, RAM ve disk gecikmesinin zaman içindeki seyri. Anlık değer değil, eğilim önemlidir.
Bakım ihmal edildiğinde ne oluyor?
Bakımsız bir sunucuda karşılaşılan sorunlar rastgele değildir; belirli birkaç kalıpta toplanır.
RAID dizisinde sessiz bozulma
RAID 5 veya RAID 6 dizilerinde bir disk arızalandığında sistem çalışmaya devam eder. Kimse bildirimleri izlemiyorsa dizi haftalarca tek disk eksikle çalışır. İkinci disk de arızalandığında veri kaybı kaçınılmaz olur ve bu noktada kurtarma çok daha zor, bazen imkânsızdır.
Disk dolması kaynaklı servis durması
Günlük dosyaları, geçici dosyalar ve veritabanı işlem günlükleri birikir. Sistem birimi dolduğunda işletim sistemi yazma yapamaz; servisler beklenmedik biçimde durur. Bu arıza tipi neredeyse tamamen öngörülebilirdir çünkü doluluk oranı doğrusal artar.
Başarısız yedekleme zinciri
Yedekleme yazılımı bir hafta boyunca hata verir, uyarı e-postası kimsenin okumadığı bir kutuya düşer. Gerçek bir kayıp yaşandığında geri dönülecek güncel bir yedek bulunmaz. Sahada en sık karşılaşılan senaryolardan biri budur.
Yamasız kalan güvenlik açıkları
Uzun süre yamanmayan sunucular, otomatik tarama yapan saldırganlar için hazır hedeftir. Özellikle internete açık servisler barındıran sunucularda yama gecikmesi doğrudan risk demektir.
Sürünerek gelen performans düşüşü
Kullanıcılar "sistem yavaşladı" der ama ne zaman yavaşladığını söyleyemez. Ölçüm geçmişi yoksa nedenin donanım mı, veri artışı mı, yoksa hatalı bir yapılandırma mı olduğu ayırt edilemez.
Aylık kontrol listesi
Aşağıdaki sırayı ayda bir uygulamak, yukarıdaki sorunların büyük bölümünü ortaya çıkmadan yakalar. Her adımda bulunan değeri bir yere kaydedin; asıl değer tek seferlik kontrolde değil, aylar arası karşılaştırmadadır.
- RAID denetleyici arayüzünden dizi durumunu ve her diskin SMART değerlerini okuyun. "Optimal" dışında bir durum varsa işlem gerektirir.
- Tüm birimlerin doluluk oranını kaydedin. Geçen aya göre artış hızını hesaplayın ve kalan süreyi tahmin edin.
- Son 30 günün yedekleme raporunu inceleyin. Başarısız iş var mı, varsa nedeni ne?
- Rastgele seçilmiş bir dosya veya sanal makineyi yedekten gerçekten geri döndürün. Bu adım atlanırsa listenin geri kalanı yarım kalır.
- Bekleyen güncellemeleri listeleyin. Uygulanacakları bakım penceresini planlayın, ertelenenlerin gerekçesini yazın.
- Olay günlüklerinde son 30 günde tekrarlayan hata ve uyarıları tarayın.
- Sıcaklık ve fan hızı okumalarını kontrol edin. Yükselen bir eğilim tozlanma veya soğutma sorununa işaret eder.
- Kesintisiz güç kaynağının akü durumunu ve son test sonucunu kontrol edin.
- Yerel yönetici hesaplarını ve süresi yaklaşan sertifikaları gözden geçirin.
- Bulguları kısa bir notla kayıt altına alın. Bu kayıt, gelecekteki arızada en hızlı teşhis aracınız olacaktır.
Hangi belirtiler bekleyemez?
Aylık döngüyü beklemeden müdahale gerektiren durumlar vardır:
- RAID dizisinin "degraded" durumuna düşmesi
- Diskten gelen tıklama, sürtünme veya periyodik ses değişimi
- Sistem biriminde kalan alanın yüzde onun altına inmesi
- Art arda iki gün başarısız olan yedekleme işi
- Beklenmedik yeniden başlatmalar veya mavi ekran kayıtları
- Bellek hata sayacının artması
Bu belirtilerin ortak özelliği, hepsinin daha büyük bir arızanın habercisi olmasıdır. Erken müdahale genellikle tek bir parça değişimiyle sınırlı kalır; geciken müdahale veri kurtarma sürecine dönüşür.
Bakımı kim yapmalı?
Bakımın kim tarafından yapıldığından çok, düzenli ve kayıtlı yapılması önemlidir. İç ekibi olan işletmelerde kontrol listesinin bir sorumluya atanması ve sonuçların yazılı tutulması çoğu zaman yeterlidir.
İç ekibi olmayan ya da sunucu sayısı artan işletmelerde bu iş genellikle ertelenir; çünkü acil değildir ve aciliyeti olan işler her zaman öne geçer. Bu noktada bakımı dışarıdan bir ekibe düzenli aralıklarla yaptırmak, hem sürekliliği hem de kayıt disiplinini sağlar.
Sunucu altyapınızın mevcut durumunu değerlendirmek veya düzenli bakım kurgusu oluşturmak isterseniz MayraNet ekibiyle iletişime geçebilirsiniz. İlk adım genellikle kısa bir envanter ve mevcut durum tespitidir.