Uzun Süren Bir Kesintinin Anatomisi

Aşağıdaki senaryo, orta ölçekli şirketlerde tekrar eden bir örüntünün birleştirilmiş anlatımıdır. Belirli bir firmayı temsil etmez.

Durum

Bir dağıtım firması. İş yönetim sistemi tek bir sunucuda çalışıyor: uygulama, veritabanı ve dosya paylaşımı aynı makinede.

• Sunucu bir veri merkezinde kiralık
• Günlük yedek alınıyor, aynı sağlayıcının depolama alanında
• İzleme yok
• Yönetim, dışarıdan bir kişiye bağlı
• Felaket kurtarma planı yok

Olay: Cuma akşamı

Sunucunun disk dizisinde arıza oluştu. Yedekli disk yapılandırması vardı ama bir disk daha önce arızalanmış ve değiştirilmemişti — uyarı kimseye ulaşmamıştı çünkü izleme yoktu.

İkinci disk arızalanınca sistem tamamen durdu.

Cumartesi: fark ediliş

• Hafta sonu kimse sistemi kullanmıyordu
• Arıza pazartesi sabahı fark edildi
• Kesinti fiilen cuma akşamı başlamıştı

Kayıp süre: Yaklaşık iki gün, hiçbir müdahale yapılmadan geçti.

Pazartesi: müdahale girişimi

1. Kullanıcılar sisteme giremediğini bildirdi
2. Dış sorumluya ulaşılmaya çalışıldı — izindeydi
3. Sağlayıcıya destek talebi açıldı
4. Sağlayıcı donanım arızası tespit etti
5. Yedek parça temini gerekti

Sorun: Sözleşmede donanım arızası müdahale süresi taahhüdü yoktu.

Salı: donanım değişimi

• Donanım değiştirildi
• Sistemin sıfırdan kurulması gerekiyordu
• Kurulum yapılandırması belgelenmemişti
• Hangi bileşenlerin nasıl kurulduğu bilinmiyordu

Kayıp süre: Yapılandırmayı yeniden çıkarmak bir gün aldı.

Çarşamba: yedekten dönme

• Yedekler bulundu
• Son yedek pazar gecesine aitti (arızadan sonra alınmış, boş)
• Bir önceki yedek perşembe gecesine aitti
• Cuma günü girilen tüm veriler kayıptı
• Geri yükleme başlatıldı
• Geri yükleme beklenenden uzun sürdü (hiç test edilmemişti)

Perşembe: doğrulama sorunları

• Sistem açıldı ama bazı modüller çalışmıyordu
• Lisans anahtarları bulunamadı
• Üreticiden yeniden talep edildi
• Entegrasyonlar çalışmıyordu (IP adresi değişmişti)
• Dış sistemlerin beyaz liste güncellemesi gerekti

Cuma: normale dönüş

• Sistem çalışır hâle geldi
• Bir haftalık veri elle yeniden girildi
• Bazı siparişler tamamen kaybedildi

Toplam kesinti: Yaklaşık bir hafta.

Kesintinin neden bu kadar uzadığı

Kritik gözlem: Donanım arızası kesintinin yalnız küçük bir kısmını açıklıyor. Süreyi uzatan şey, hazırlık eksikliğiydi.

Kök nedenler

1. İzleme yoktu. İlk disk arızası fark edilseydi olay hiç yaşanmayacaktı.
2. Uyarılar kimseye gitmiyordu.
3. Tek kişiye bağımlılık vardı.
4. Yedekleme doğrulanmıyordu. Boş bir yedek oluşmuştu.
5. Geri yükleme hiç test edilmemişti.
6. Yapılandırma belgelenmemişti.
7. Lisans bilgileri saklanmıyordu.
8. Sözleşmede müdahale taahhüdü yoktu.
9. Felaket kurtarma planı yoktu.
10. Tüm roller tek sunucudaydı.

Sonrasında kurulan düzen

• ☐ İzleme ve uyarı kuruldu, uyarılar iki kişiye gidiyor
• ☐ Donanım uyarıları özel olarak izleniyor
• ☐ Yönetilen hizmet anlaşması yapıldı
• ☐ Sözleşmeye müdahale süresi taahhüdü eklendi
• ☐ Yedekler ayrı bir hizmete taşındı
• ☐ Yedekleme başarı/başarısızlık bildirimi kuruldu
• ☐ Yıllık geri yükleme tatbikatı başlatıldı
• ☐ Yapılandırma belgelendi
• ☐ Lisans ve erişim bilgileri parola yöneticisine alındı
• ☐ Veritabanı ayrı bir sunucuya taşındı
• ☐ Felaket kurtarma planı yazıldı
• ☐ Kabul edilebilir kesinti ve veri kaybı tanımlandı
• ☐ Alternatif çalışma yöntemleri belgelendi

Çıkarılacak dersler

1. İzleme, en ucuz süreklilik yatırımıdır. İlk disk arızası fark edilseydi olay hiç yaşanmazdı.
2. Kesinti süresini uzatan şey genelde teknik arıza değil, hazırlık eksikliğidir.
3. Belgelenmemiş bir sistem, kurtarılması en zor sistemdir.
4. Test edilmemiş yedek, yedek değildir.
5. Tek kişiye bağımlılık, kritik bir risktir.
6. Sözleşmedeki müdahale taahhüdü, kriz anında somut fark yaratır.
7. Lisans ve entegrasyon bilgileri de yedeklenmelidir.
8. Hafta sonu başlayan bir arıza, izleme yoksa günler sonra fark edilir.

Bu senaryodaki önlemlerin çoğu düşük maliyetlidir; yaşanan kayıp ise bunların toplamının kat kat üzerindedir.