Yedeğiniz var, izlemeniz kurulu, planınız hazır. Peki bu plan hiç denendi mi? Kriz anında ilk kez uygulanan bir prosedür, plan değil bir varsayımdır — ve varsayımlar en kötü zamanda çöker.
Bu rehber, kendi sanal sunucunuz için kurtarma planınızı yazılı hâle getirmeyi ve düzenli olarak test etmeyi anlatıyor.
Her Şey İki Sayıdan Türer
Kurtarma planlaması, iki sorunun cevabıyla başlar. Bunlar teknik değil iş kararlarıdır ve yazıya geçmeden plan yapılamaz:
- Ne kadar veri kaybını göze alabilirsiniz? Bu sayı yedekleme sıklığınızı belirler. Cevap "bir gün" ise günlük yedek yeterlidir; "bir saat" ise saatlik yedek gerekir.
- Ne kadar süre kapalı kalabilirsiniz? Bu sayı kurtarma yönteminizi belirler. Dört saatiniz varsa yedekten kurulum yapabilirsiniz; on beş dakikanız varsa hazır bir yedek sistem gerekir.
Bu iki sayı belirlenmeden yapılan yatırımlar ya fazla ya yetersiz olur. Belirlendiğinde ise hangi çözümün gerekli, hangisinin lüks olduğu kendiliğinden ortaya çıkar.
Senaryo Bazlı Düşünmek
"Sunucu çöktü" tek bir senaryo değildir. Her birinin farklı müdahalesi vardır:
| Senaryo | İlk müdahale | Tipik süre |
|---|---|---|
| Servis çöktü, sunucu ayakta | Servisi yeniden başlat, logu oku | Dakikalar |
| Disk doldu | Log ve geçici dosyaları temizle | Dakikalar |
| Hatalı dağıtım | Önceki sürüme geri dön | Dakikalar |
| Veri bozulması | Yedekten seçici geri yükleme | Saatler |
| Sunucu erişilemez | Konsoldan bağlan, tanıla | Değişken |
| Ele geçirilme | Temiz kurulum + yedekten dönüş | Saatler |
| Sağlayıcı kesintisi | Alternatif altyapıya geçiş | Saatler |
Bu tabloyu kendi sisteminiz için doldurmak, planlamanın ilk adımıdır. Her satır için "ne yapacağız" sorusunun cevabı yazılı olmalıdır.
Runbook: Kriz Anında Okunacak Belge
Runbook, adım adım ne yapılacağını anlatan yazılı bir prosedürdür. Kriz anında düşünmek yerine okumak içindir — çünkü kriz anında düşünme kaliteniz düşer.
Ne İçermeli?
- Erişim bilgileri nerede. Sağlayıcı paneli, konsol erişimi, DNS yönetimi, yedek depolaması. Parolaların kendisi değil, nerede saklandıkları.
- Sistem haritası. Hangi servis nerede çalışıyor, hangi bağımlılıkları var, hangi portları kullanıyor.
- Senaryo başına adımlar. Yukarıdaki tablodaki her satır için sırayla ne yapılacağı.
- Doğrulama adımları. Kurtarma sonrası neyin çalıştığından nasıl emin olunacağı.
- İletişim planı. Kim bilgilendirilecek, müşterilere ne söylenecek, hangi kanaldan.
- Geri dönüş noktası. Müdahale işe yaramazsa nereye dönülecek.
Nerede Durmalı?
Bu, en sık yapılan hatadır: runbook, kurtarmaya çalıştığınız sunucuda durmamalıdır. Sunucu erişilemezse belgeye de erişemezsiniz.
Bağımsız bir yerde tutun ve ekipteki herkesin erişebildiğinden emin olun. Basılı bir kopya bile abartı sayılmaz — internet erişiminin olmadığı bir senaryo düşünülenden az uzaktır.
Tatbikat: Planı Gerçeğe Çevirmek
Tatbikat, planın işe yarayıp yaramadığını öğrenmenin tek yoludur. Kademeli olarak yapın:
Seviye 1: Masa Başı Tatbikat
Kimse hiçbir şeye dokunmaz. Bir senaryo seçilir ve ekip runbook'u okuyarak "ne yapardık" sorusunu adım adım cevaplar. Eksik adımlar, belirsiz talimatlar ve bilinmeyen bilgiler burada ortaya çıkar.
Riski sıfırdır ve genellikle şaşırtıcı sayıda eksik bulur. En az yılda bir yapın.
Seviye 2: Geri Yükleme Testi
Yeni bir sunucu açıp yalnızca yedeklerinizi ve runbook'u kullanarak sistemi ayağa kaldırın. Canlı ortama dokunulmaz.
Bu testte tipik bulgular: yedeğe dahil olmadığı fark edilen bir dizin, bozuk çıkan bir veritabanı dökümü, kimsenin bilmediği bir parola ve beklenenden uzun süren bir aktarım. Ölçtüğünüz süre, gerçek kurtarma sürenizdir — tahmin değil.
Seviye 3: Devralma Tatbikatı
Yedekli bir mimariniz varsa, ana sistemi planlı olarak durdurup devralmanın gerçekten çalıştığını doğrulayın. Bakım penceresinde yapılır.
Ölçülecekler: devralma gerçekleşti mi, ne kadar sürdü, kullanıcılar ne yaşadı, veri kaybı oldu mu, elle müdahale gerekti mi?
Tatbikatın Değeri: Bulunanlar
Tatbikat yapan ekiplerin en sık bulduğu eksikler:
- Yedeğe dahil edilmediği fark edilen bir yapılandırma dosyası
- Sadece bir kişinin bildiği bir erişim bilgisi
- Runbook'ta atlanmış bir bağımlılık — servis, listede olmayan başka bir servise ihtiyaç duyuyor
- Beklenenden çok uzun süren bir aktarım
- Süresi dolmuş bir sertifika veya erişim anahtarı
- Artık geçerli olmayan bir prosedür adımı (sistem değişmiş, belge güncellenmemiş)
Bunları tatbikatta öğrenmek ile kriz anında öğrenmek arasındaki fark, planlı bir öğleden sonra ile panik içinde geçen bir gece arasındaki farktır.
Sürekli Döngü
Sistem değiştikçe plan eskir. Runbook'u şu durumlarda güncelleyin: yeni bir servis eklendiğinde, mimari değiştiğinde, sağlayıcı değiştiğinde ve her tatbikattan sonra.
Güncellenmemiş bir runbook, güvendiğiniz ama yanlış yönlendiren bir belgedir — hiç olmamasından daha tehlikeli olabilir.
Sonuç
Kurtarma planı, test edilene kadar bir varsayımdır. İki sayıyla başlayın (kabul edilebilir veri kaybı ve kesinti süresi), senaryo başına adımları yazın, belgeyi sunucunun dışında tutun ve yılda en az bir kez tatbikat yapın. Bu döngüyü kuran ekipler, bir olay yaşandığında ne yapacaklarını bilir; kurmayanlar ise o anda öğrenir. Yaptığınız tek şey bir geri yükleme testi olsa bile — ölçtüğünüz süre, tüm tahminlerinizden değerlidir.
Sıkça Sorulan Sorular (SSS)
Ne sıklıkla tatbikat yapmalıyım?
Masa başı tatbikatı yılda en az bir kez, geri yükleme testini yılda bir kez ve mimaride büyük bir değişiklikten sonra mutlaka. Devralma tatbikatı, yedekli mimariniz varsa yılda bir bakım penceresinde yapılabilir.
Runbook yazmak çok mu emek ister?
İlk sürüm bir sayfa olabilir: erişim bilgileri nerede, sistem neyden oluşuyor, en olası üç senaryoda ne yapılacak. Mükemmel bir belge beklemek yerine basit bir sürümle başlayın; her tatbikat onu geliştirir.
Tek kişiyim, plana gerek var mı?
Özellikle var. Tek kişilik yapılarda tüm bilgi bir kişinin hafızasındadır ve o kişi ulaşılamaz olduğunda sistem de ulaşılamaz olur. Ayrıca kriz anında kendi hafızanıza güvenmek, yazılı bir listeye güvenmekten belirgin biçimde riskli.
Kurtarma süremi nasıl bilebilirim?
Yalnızca ölçerek. Bir geri yükleme testi yapıp süreyi kaydedin — bu, kesinti planlamanız için elinizdeki tek gerçek veridir. Tahmin edilen kurtarma süreleri gerçek sürelerin genellikle çok altındadır.
