Kurumsal Felaket Kurtarma (DRP) Tatbikatı Yönetimi: RPO/RTO Metriklerinin Ölçülmesi ve Raporlanması

Çoğu şirkette Felaket Kurtarma Planı (Disaster Recovery Plan - DRP), bir denetim klasörünün içine konulmuş, en son 4 yıl önce güncellenmiş ve kimsenin okumadığı 80 sayfalık bir Word dokümanından ibarettir. Gerçek bir kriz patlak verdiğinde o dokümanın hiçbir işe yaramadığı acı bir tecrübeyle öğrenilir. Bir DRP dokümanı ancak ve ancak canlı bir tatbikatla test edilip kronometre tutulduğunda gerçek bir plana dönüşür.

1. RPO ve RTO: Hedefleri Belirleme

Yönetim kurulu genellikle "Sıfır veri kaybı ve sıfır kesinti istiyoruz" der. Bir mühendisin görevi bu isteği finansal gerçeklikle eşleştirmektir:

RPO (Recovery Point Objective - Ne Kadar Veri Kaybını Göze Alabilirsiniz?):
- Son yedeğin üzerinden geçen süredir.
- Örnek: Günde bir kez gece 02:00'de yedek alıyorsanız, ertesi gün saat 16:00'da sistem çökerse 14 saatlik veri kaybı yaşanır (RPO = 14 Saat). Kritik finans sistemlerinde RPO < 15 dakika olmalıdır.
RTO (Recovery Time Objective - Ne Kadar Sürede Sistemi Ayağa Kaldırabilirsiniz?):
- Çökme anından sistemin kullanıcılara tekrar açıldığı ana kadar geçen süredir.
- Örnek: Yedekten dönmek 4 saat sürüyorsa RTO = 4 Saattir.

2. Tatbikat Senaryosu: "Sistem Odası Erişilemez Durumda"

Yılda en az bir kez hafta sonu planlı tatbikat icra edilmelidir:

Senaryo Aşamaları:
1. Saat 09:00: Ana sistem odasının ağ bağlantıları güvenlik duvarından izole edilir (Sözde felaket anı).
2. Saat 09:15: Kriz masası toplanır (IT Lideri, Altyapı Uzmanı, Veritabanı Yöneticisi, İletişim Sorumlusu).
3. Saat 09:30: İkincil lokasyondaki (veya buluttaki) DRP sunucuları yedekten başlatılır.
4. Saat 10:15: DNS yönlendirmeleri ikincil merkeze çevrilir (Failover).
5. Saat 10:45: Test kullanıcıları (Muhasebe/Sevkiyat) sisteme bağlanıp örnek fatura keser.
6. Saat 11:30: Test tamamlanır, geri dönüş (Failback) adımları icra edilir.

3. Yönetim Kurulu İçin DRP Raporu Şablonu

Tatbikat bittiğinde hazırlanan rapor teknik terimlerden arındırılmış, somut iş metriklerine dayanmalıdır:

+-------------------------+--------------------+--------------------+---------------+
| Kritik Sistem           | Hedef RTO / RPO    | Ölçülen RTO / RPO  | Durum         |
+-------------------------+--------------------+--------------------+---------------+
| Active Directory / DNS  | 30 Dk / 1 Saat     | 18 Dk / 0 Dk (Canlı)| [BAŞARILI]    |
| Ana ERP & SQL Veritabanı| 2 Saat / 15 Dk     | 1 Saat 12 Dk / 10 Dk| [HEDEF TUTTU] |
| E-Posta (Microsoft 365) | 15 Dk / 0 Dk       | 0 Dk (Bulut SaaS)  | [KESİNTİSİZ]  |
| Dosya Paylaşım Sunucusu | 4 Saat / 24 Saat   | 2 Saat 40 Dk / 8 Saat| [BAŞARILI]  |
+-------------------------+--------------------+--------------------+---------------+
Toplam İyileştirme Alanı: DNS TTL sürelerinin 3600'den 300 saniyeye düşürülmesi gerekiyor.

Karşılaşılan Kritik Hatalar ve Çözüm İpuçları

Dış Bağımlılıkların Unutulması: Şirket içi ERP'yi ikincil merkezde açtınız ancak ERP'nin konuştuğu e-Fatura entegratörünün IP kısıtlaması (IP Whitelist) eski merkez ofisin statik IP'sine tanımlıydı! Sonuç: Fatura kesilemedi. Çözüm: Tüm harici servis sağlayıcılara DRP merkezinin yedek dış IP adresleri önceden tanımlatılmalıdır.
İletişim Kanallarının Çökmesi: Şirketin e-posta sunucusu çöktüğünde personelle nasıl haberleşeceksiniz? Acil durum SMS grubu veya bağımsız bir kurumsal haberleşme kanalı hazır olmalıdır.

Mühendis Notu

DRP tatbikatında hataların çıkması bir başarısızlık değil; büyük bir kazançtır. Tatbikatta patlayan bir sorun, gerçek bir felakette şirketi iflastan kurtaracak dersi verir.