Felaket Matrisi: Better Safe Than Sorry

Neden en kötü senaryoları hayal etmek, en iyi hazırlık yöntemidir?

Deprem tatbikatlarını hatırlıyor musunuz? Okullarda zil çalar, herkes masanın altına girer, sonra düzenli şekilde bahçeye çıkılırdı. Çoğumuz bunu ciddiye almazdık. Ta ki gerçek bir deprem yaşayana kadar.

IT altyapısında da durum farklı değil. "Sunucu çökerse ne yaparız?" sorusunu sormak istemeyiz. Sanki soru sormak felaketi davet edecekmiş gibi hissederiz. Ama ISO 27001'in bize öğrettiği şey tam tersi:

Felaketi hayal etmek onu davet etmez. Hazırlıksız yakalanmayı engeller.

Risk Matrisi: Korkuları Sayılara Dönüştürmek

ISO 27001'in temel araçlarından biri Risk Değerlendirme Matrisi'dir. Karmaşık görünür ama özü basittir:

Risk = Olasılık × Etki

Her potansiyel felaketi iki eksende değerlendirirsiniz:

Bu matris, sınırlı kaynaklarınızı nereye yönlendireceğinizi gösterir. Her şeye hazırlanamayız, ama kritik risklere mutlaka hazırlanmalıyız.

Gerçek Hayattan Bir Matris Örneği

Bir e-ticaret müşterimiz için hazırladığımız risk matrisinden birkaç satır:

Son satıra dikkat edin. Teknik olmayan riskler de matrise girer. Kurumsal hafıza kaybı, teknik bir arıza kadar yıkıcı olabilir.

Felaket Senaryosu Nasıl Yazılır?

Risk matrisindeki her "Kritik" ve "Yüksek" risk için bir felaket senaryosu dokümante edilmelidir. İyi bir senaryo şu soruları yanıtlar:

1. Ne oldu? Spesifik olun. "Sunucu çöktü" değil, "Primary veritabanı sunucusu disk controller arızası nedeniyle erişilemez durumda."

2. Nasıl fark ettik? Monitoring alarmı mı? Müşteri şikayeti mi? Tesadüfen mi?

3. İlk 15 dakikada ne yapıyoruz? Kim aranacak? Hangi sistemler kontrol edilecek? Karar verici kim?

4. Kurtarma adımları neler? Sıralı, net, belirsizlik içermeyen adımlar. Panik anında "düşünecek" vaktiniz yok.

5. Normal duruma dönüş kriterleri neler? Sistem "çalışıyor" ne demek? Hangi metrikler normale dönmeli?

6. Olay sonrası ne yapılacak? Post-mortem analizi. Tekrarı nasıl önleriz?

Tatbikat: Planın Gerçeklikle Sınavı

Bir felaket planınız var. Harika. Peki hiç test ettiniz mi?

Mike Tyson'ın meşhur sözü burada geçerli: "Herkesin bir planı var, ta ki suratına yumruk yiyene kadar."

Tatbikat, planınıza kontrollü bir yumruk atmaktır.

Tatbikat Türleri

1. Masa Başı Tatbikatı (Tabletop Exercise)

En basit ve en az riskli yöntem. Ekip bir odada toplanır, senaryo okunur, herkes kendi rolünde ne yapacağını söyler.

Örnek: "Saat 14:00, Cuma. Primary DB sunucusu yanıt vermiyor. Monitoring 5 dakikadır alarm veriyor. Ne yapıyorsunuz?"

Her kişi sırayla: Kimi arıyorum, neyi kontrol ediyorum, hangi kararı alıyorum...

Masa başı tatbikatı planınızdaki boşlukları ortaya çıkarır. "Bu durumda kimi arayacağız?" sorusuna kimse cevap veremiyorsa, planınız eksik demektir.

2. Simülasyon Tatbikatı

Gerçek sistemlere dokunmadan, test ortamında senaryo canlandırılır.

Örnek: Staging ortamında veritabanını kasıtlı olarak durdurun. Ekip gerçekmiş gibi müdahale etsin. Failover süresi ölçülsün.

3. Canlı Tatbikat

Gerçek sistemlerde, kontrollü koşullarda yapılır. En riskli ama en öğretici yöntem.

Örnek: Bakım penceresi içinde primary sunucuyu kapatın. Otomatik failover çalışıyor mu? Manuel müdahale gerekiyor mu? Gerçek süreleri ölçün.

Netflix'in "Chaos Monkey" yaklaşımı buna örnektir: Üretim ortamında rastgele sunucuları kapatarak sistemin dayanıklılığını sürekli test ederler.

Tatbikat Kontrol Listesi

Her tatbikat öncesi ve sonrası:

Öncesi:

• [ ] Senaryo yazıldı ve onaylandı
• [ ] Katılımcılar bilgilendirildi
• [ ] Geri dönüş planı hazır (tatbikat ters giderse)
• [ ] Müşteriler/kullanıcılar bilgilendirildi (gerekiyorsa)
• [ ] Ölçüm kriterleri belirlendi (RTO, RPO)

Sonrası:

• [ ] Gerçekleşen süreler kaydedildi
• [ ] Beklenenden sapmalar not edildi
• [ ] Katılımcı geri bildirimleri toplandı
• [ ] Plan güncelleme ihtiyaçları listelendi
• [ ] Sonraki tatbikat tarihi belirlendi

RTO ve RPO: İki Kritik Metrik

Felaket planlamasında iki terim sürekli karşınıza çıkar:

RTO (Recovery Time Objective): Sistemin ne kadar sürede ayağa kalkması gerekiyor?

Örnek: E-ticaret sitesi için RTO 1 saat. 1 saatten uzun kesinti kabul edilemez.

RPO (Recovery Point Objective): Ne kadarlık veri kaybı kabul edilebilir?

Örnek: RPO 15 dakika. En fazla son 15 dakikalık işlemleri kaybedebiliriz.

Bu iki metrik, yedekleme stratejinizi ve altyapı yatırımınızı belirler:

• RTO 1 saat istiyorsanız, hot standby gerekir.
• RPO 15 dakika istiyorsanız, 15 dakikada bir replikasyon gerekir.

Tatbikatlar, gerçek RTO ve RPO'nuzu ölçer. Planladığınız 1 saat, gerçekte 4 saat olabilir. Bunu tatbikatta öğrenmek, gerçek felakette öğrenmekten çok daha iyidir.

Neden "Better Safe Than Sorry"?

Felaket planlaması ve tatbikat masraflı görünür. Zaman alır, kaynak tüketir, kimse "acil" görmez.

Ama bir hesap yapalım:

Hazırlık maliyeti:

• Risk analizi: 2-3 iş günü
• Senaryo yazımı: 1-2 iş günü
• Yıllık tatbikat: 1 iş günü
• Toplam: Yılda ~5 iş günü

Hazırlıksız yakalanma maliyeti:

• Panik ve kaotik müdahale: Süre belirsiz
• Veri kaybı: Değeri hesaplanamaz
• Müşteri kaybı: Uzun vadeli gelir etkisi
• İtibar hasarı: Yıllar süren onarım
• Ekip tükenmişliği: Görünmez ama gerçek

Matematik yine açık.

Ankara'nın Avantajı

VeriTeknik olarak felaket kurtarma planlamasında coğrafi bir avantajımız var. Ankara, İstanbul'a göre sismik açıdan çok daha güvenli bir lokasyon. Bu nedenle İstanbul merkezli birçok firma için Disaster Recovery sitesi olarak hizmet veriyoruz.

Ama lokasyon tek başına yetmez. Lokasyondaki altyapının da test edilmiş, tatbikatlardan geçmiş, çalıştığı kanıtlanmış olması gerekir.

Sonuç

ISO 27001 risk matrisi, korkularınızı kağıda döker. Felaket senaryoları, "ne yapacağız?" sorusunu önceden yanıtlar. Tatbikatlar, planınızın gerçekten çalışıp çalışmadığını gösterir.

Hepsi bir arada: Uykularınızı kaçıran senaryoları, iyi uyumanızı sağlayan planlara dönüştürür.

Felaketi hayal etmek kötümserlik değil, mühendislik gerçekçiliğidir. Ve evet—

Better safe than sorry.