Kritik Hizmet Devamlılık Planı

⏱️ 30 saniyede

• Bir hizmet durduğunda gerçek bir bedel doğuyorsa (gelir, güven, yasal yükümlülük), o hizmetin devamlılığı şansa bırakılamaz.
• Önce bağımlılıkları çıkar: hizmet hangi sunucu, güç, internet ve veriye dayanıyor? Sonra her biri için hedef kurtarma süresi koy.
• Yedeklilik kur: ikinci sunucu, kesintisiz güç (UPS), alternatif hat. Geçişin otomatik mi elle mi olduğunu şimdiden bil.
• İzleme + uyarı kur ki bozulmayı müşteri değil sen öğren. Şablonu doldur, yılda bir gözden geçir ve gerçekten test et.

Neden bu plan?

Kritik bir hizmet çökene kadar herkes onun “hep çalıştığını” sanır. Oysa kesinti soyut bir ihtimal değil; bir disk dolar, bir güç kaynağı gider, bir kablo kesilir, bir saldırı gelir. Asıl fark, o an hazırlıklı mı yoksa çaresiz mi olduğundadır. Kesintinin kendisi değil, ne kadar sürdüğü ve nasıl yönetildiği işi yaralar.

Bu plan, bir kesintiyi kahramanlığa değil prosedüre çevirir. Hangi hizmetin neye dayandığını, çökünce kimin ne yapacağını ve ne zaman ayağa kalkması gerektiğini önceden yazarsın. Böylece olay anında karar vermeye değil uygulamaya odaklanırsın. Veri yedekleme planı verinin yedeğini garanti eder; bu plan ise hizmetin kendisinin ayakta kalmasını üstlenir. İkisi birlikte altyapı çökmesi karşısında işini dayanıklı kılar.

Nasıl doldurulur?

1. Kritik hizmetleri seç. “Çalışsa iyi olur” değil, durunca iş aksar olanları yaz. Her hizmet için bağımlılıklarını (sunucu, güç, internet, üçüncü taraf servis) ve bir hedef kurtarma süresi belirle — en geç ne kadar sürede geri dönmeli?
2. Yedekliliği tanımla. Tek nokta arızası nerede? Her kritik bağımlılık için bir yedek düşün: ikinci sunucu, kesintisiz güç, alternatif internet hattı. En kritik soru: geçiş otomatik mi, elle mi? Elle ise adımların yazılı ve erişilebilir olduğundan emin ol.
3. İzleme ve uyarıyı kur. Bir şeyin bozulduğunu müşteriden önce öğrenmen gerekir. Ne izlendiğini (erişilebilirlik, disk, sertifika süresi, yedek durumu), hangi araçla bakıldığını ve alarmın kime, nasıl gittiğini yaz. Uyarı kimseye ulaşmıyorsa izleme işe yaramaz.
4. Olay müdahale adımlarını sırala. Sabit bir akış kur: tespit → yalıt → düzelt → bilgilendir → kayıt. Önce neyin etkilendiğini izole et, yedeğe geç, müşteriyi bilgilendir, sonra olayı yaz. Panik anında düşünmek değil okumak istersin.
5. Nöbet ve iletişimi netleştir. Olay mesai dışında da olur. Kimin ne zaman sorumlu olduğunu, ulaşılamazsa sıradakini ve yedek haberleşme kanalını önceden belirle.

İnce ipuçları

Test edilmemiş yedek, yedek değildir. En sık yaşanan hayal kırıklığı, çökme anında “yedeğin de bozuk” olduğunu görmektir. Failover’ı ve geri yüklemeyi planlı bir tatbikatla dene; çalıştığını görmeden güvenme.

• Tek nokta arızasını avla. Plana bakıp her satırda sor: “bu çökerse ne olur?” Cevabı “her şey durur” olan her yer, yedeklilik gerektirir.
• Gerçekçi hedef koy. Her hizmet için “anında” demek pahalı ve gereksizdir. Bazı hizmetler 5 dakika, bazıları 1 gün bekleyebilir. Hedefi işin gerçek ihtiyacına göre koy.
• İletişimi unutma. Bir kesintide müşterinin en çok istediği şey bilgidir. Basit bir durum sayfası ya da hazır mesaj şablonu, sessizlikten çok daha güven verir. Bu sırada sahte “destek” mesajlarına karşı da dikkatli ol; kriz anı dolandırıcının fırsatıdır.
• Bağımsız izleme kullan. İzlemen, izlediğin sistemle aynı yerde durmasın; sunucu çökünce alarm da çökerse hiç haberin olmaz.
• Olay sonrası kısa not tut. Her kesintiden sonra “ne oldu, ne işe yaradı, ne eksikti” diye birkaç satır yaz. Bu notlar planı zamanla sağlamlaştırır.

Gözden geçir

Bağımlılıklar değişir, ekip değişir, yeni hizmetler eklenir. Bu planı yılda bir baştan oku: hizmet listesini, kurtarma hedeflerini ve nöbet listesini güncelle. Ama asıl gözden geçirme tatbikattır — yılda en az bir kez failover’ı ve geri yüklemeyi gerçekten dene. Kâğıttaki plan değil, test edilmiş plan seni ayakta tutar; hazırlık seviyelerinde bir üst basamağa çıkmanın yolu da budur.