Bir felaket kurtarma planının hazırlanmış olması, kurumun felakete hazır olduğu anlamına gelmez. Dosya sunucusunda duran bir prosedür; sorumlular değiştiğinde, altyapı büyüdüğünde, yönetici hesaplarına erişilemediğinde veya yedek beklenenden uzun sürede döndüğünde işe yaramayabilir.
Kurumsal IT operasyonlarında yıllar içinde gördüğüm en önemli ayrım şudur: yedek almak teknik bir işlemdir; hizmeti kabul edilebilir sürede ve doğru verilerle yeniden çalıştırmak ise iş sürekliliği yeteneğidir. Bu yetenek ancak düzenli tatbikat, ölçüm ve iyileştirme ile doğrulanabilir.
Yüksek erişilebilirlik, yedekleme ve felaket kurtarma aynı şey değildir
Yüksek erişilebilirlik, bir bileşen arızalandığında hizmetin başka bir bileşen üzerinden devam etmesini amaçlar. Yedekleme, verinin belirli bir zamandaki kopyasını korur. Felaket kurtarma ise insanları, süreçleri, verileri, uygulamaları, altyapıyı ve iletişimi birlikte yöneterek kritik hizmetleri yeniden çalıştırır.
Bir sunucunun ikinci düğümü bulunabilir ancak iki düğüm de aynı veri merkezindeki enerji, depolama veya ağ sorunundan etkilenebilir. Başka bir lokasyonda veri kopyası bulunabilir ancak DNS, sertifika, lisans, kimlik doğrulama veya uygulama bağımlılığı hazırlanmadıysa hizmet açılamayabilir.
Bu nedenle yüksek erişilebilir sunucu altyapısı felaket kurtarmanın önemli bir parçasıdır; fakat tek başına felaket kurtarma planı değildir.
İlk adım teknoloji değil, iş etki analizidir
Her sistemi aynı sürede kurtarmaya çalışmak hem pahalı hem de gerçekçi değildir. Öncelikle hangi iş süreçlerinin ne kadar kesintiye dayanabileceği belirlenmelidir. Otel işletmesinde PMS, POS, kartlı geçiş, internet erişimi ve rezervasyon entegrasyonunun öncelikleri farklı olabilir. Hastanede hasta kabul, laboratuvar, görüntüleme ve klinik uygulamalar aynı kurtarma grubunda değerlendirilemez.
İş etkisi
Hizmet durduğunda hangi operasyon, gelir veya müşteri deneyimi etkilenir?
Zaman etkisi
Kesintinin ilk saat, dört saat ve bir gün sonraki sonucu nedir?
Bağımlılıklar
Hizmet hangi uygulama, ağ, kimlik, tedarikçi ve lokasyonlara bağlıdır?
Alternatif süreç
İşlem geçici olarak manuel veya farklı bir sistemle yürütülebilir mi?
Bu çalışma sonunda sistemler kritik, önemli ve destekleyici sınıflara ayrılabilir. Kurtarma sırası teknolojik kolaylığa göre değil, iş etkisine göre oluşturulmalıdır.
RTO ve RPO gerçekçi ve ölçülebilir olmalıdır
RTO — Recovery Time Objective, bir hizmetin ne kadar süre içinde yeniden kullanılabilir olması gerektiğini belirtir. “En kısa sürede” bir RTO değildir. “Felaket ilanından sonra dört saat içinde kullanıcı girişine ve temel işlemlere açık olmalı” ölçülebilir bir hedeftir.
RPO — Recovery Point Objective, olaydan önceki hangi zamana kadar verinin geri getirilebilmesi gerektiğini ifade eder. Bir saatlik RPO, en fazla yaklaşık bir saatlik verinin kaybedilmesinin kabul edildiğini gösterir.
Sıfır RTO ve sıfır RPO kulağa ideal gelebilir; ancak bu hedeflerin uygulanması zor ve maliyetlidir. İş birimi veri kaybını kabul etmiyorsa teknik mimarinin replikasyon, ağ, depolama ve uygulama seviyesinde bunu desteklemesi gerekir.
Tatbikat tek seviyeden oluşmamalıdır
Masa başı tatbikatı
Teknik ekip, iş birimi, güvenlik, iletişim ve yönetim temsilcileri belirlenmiş bir senaryoyu birlikte değerlendirir. Ana veri merkezinin erişilemez olduğu varsayıldığında kim felaket ilan edecek, alternatif iletişim kanalı ne olacak ve tedarikçiye kim ulaşacak? Bu çalışma teknik değişiklik yapmadan sorumluluk ve prosedür boşluklarını ortaya çıkarır.
Bileşen geri yükleme testi
Seçilen bir sunucu, veri tabanı, sanal makine veya dosya grubu izole bir ortama geri yüklenir. Test yalnızca işlemin başarılı görünmesiyle bitmez; dosyaların açılması, veri tabanı tutarlılığı, uygulama servisleri ve erişim izinleri doğrulanır. Microsoft 365 tarafında koruma ve geri dönüş kapsamı, Microsoft 365 yedekleme ve iş sürekliliği rehberi ile birlikte değerlendirilmelidir.
Kısmi failover testi
Belirli bir uygulama veya servis kontrollü biçimde ikincil ortama geçirilir. Ağ yönlendirmesi, DNS, güvenlik politikaları, kimlik doğrulama, sertifikalar ve uygulama bağımlılıkları birlikte test edilir.
Uçtan uca felaket kurtarma tatbikatı
Birden fazla sistem, tanımlanmış kurtarma sırasına göre ikincil ortamda çalıştırılır. Teknik testin ardından iş birimi gerçek kullanıcı senaryolarını doğrular. Bu seviye dikkatli bir kurumsal IT değişiklik yönetimi süreci ve onaylı geri dönüş planı gerektirir.
Çalışabilir bir kurtarma runbook'u nasıl hazırlanır?
Felaket kurtarma dokümanı açıklayıcı bir politika metni değil, baskı altında uygulanabilecek bir çalışma talimatı olmalıdır. Her kritik hizmet için aşağıdaki bilgiler açıkça bulunmalıdır:
- Hizmet sahibi, teknik sorumlular ve felaket ilan etme yetkisi
- Sistem, ağ, uygulama, lisans ve tedarikçi bağımlılıkları
- Kurtarma önceliği ile hedef RTO ve RPO
- Güvenli acil erişim yöntemi ve yedek veya replikasyon kaynağı
- Adım adım failover ve teknik doğrulama testleri
- İş birimi kabul testi, iletişim akışı ve failback işlemi
- Planı durdurma veya geri alma eşikleri
Doküman yalnızca felaketten etkilenebilecek sistemde tutulmamalıdır. Yetkili kişilerin güvenli ve bağımsız bir kopyaya erişebilmesi gerekir. Parolalar doğrudan runbook içine yazılmamalı; kurumsal parola kasası ve acil erişim yöntemi kullanılmalıdır.
Başarılı tatbikat “sunucular açıldı” demek değildir
Tatbikat öncesinde başarı ölçütleri belirlenmelidir. Felaket kararının verilme süresi, ekibe ulaşma zamanı, servislerin hedeflenen RTO içinde açılması, geri yüklenen verinin RPO ile uyumu ve kullanıcı işlemlerinin sonuçları ayrı ayrı kaydedilmelidir.
DNS ve ağ değişikliklerinin yayılması, entegrasyonlardaki veri akışı, izleme ve güvenlik kontrolleri ile iş biriminin kabul sonucu da ölçülmelidir. Hedef RTO dört saatken hizmet altı saatte açılmışsa tatbikat yalnızca “tamamlandı” diye kapatılmamalıdır; iki saatlik farkın nedeni ve düzeltici faaliyeti belirlenmelidir.
Ransomware senaryosu klasik arızadan farklıdır
Donanım arızasında en güncel replika değerli olabilir. Fidye yazılımı veya veri bozulması senaryosunda ise replikasyon hatalı ya da şifrelenmiş veriyi ikincil ortama taşımış olabilir. Bu nedenle yalnızca en son kopya değil, temiz olduğu bilinen kurtarma noktası da değerlendirilmelidir.
Tatbikatta yedek yönetim platformunun ana kimlik altyapısından bağımsız erişimi, değiştirilemez veya çevrimdışı yedekler, çok faktörlü kimlik doğrulama ve ayrı yönetici hesapları kontrol edilmelidir.
Failback yapılmadan tatbikat tamamlanmış sayılmaz
İkincil ortamda hizmeti açmak operasyonun yarısıdır. Birincil ortam yeniden hazır olduğunda hangi verinin esas alınacağı, değişikliklerin nasıl eşitleneceği ve kullanıcıların nasıl geri taşınacağı belirlenmelidir.
Failback sırasında yanlış yönlü veri eşitleme, yeni verinin üzerine yazılması veya DNS'in erken değiştirilmesi ikinci bir kesintiye neden olabilir. Bu yüzden failback ayrı bir değişiklik olarak planlanmalı; yedek, tutarlılık kontrolü, bakım penceresi ve kullanıcı kabul testi içermelidir.
Felaket kurtarma tatbikatı için 15 kontrol
- Kritik iş süreçleri ve hizmet sahipleri belirlendi mi?
- Sistemler iş etkisine göre önceliklendirildi mi?
- Her kritik hizmet için RTO ve RPO onaylandı mı?
- Uygulama, ağ, DNS, kimlik, sertifika ve lisans bağımlılıkları kayıtlı mı?
- Felaket ilan etme kriteri ve yetkili kişi belli mi?
- Teknik ve yönetsel iletişim ağacı güncel mi?
- Acil erişim hesapları güvenli biçimde test edildi mi?
- Yedeklerin bütünlüğü ve geri yüklenebilirliği doğrulandı mı?
- Runbook başka bir ekip üyesi tarafından uygulanabilir mi?
- İkincil ortamın kapasitesi üretim yükünü karşılıyor mu?
- Teknik doğrulama ve iş birimi kabul senaryoları hazır mı?
- Gerçekleşen RTO ve RPO ölçülebiliyor mu?
- Fidye yazılımına karşı temiz ve bağımsız kurtarma noktası var mı?
- Failback süreci test kapsamına alındı mı?
- Bulgular için sorumlu, hedef tarih ve tekrar test tarihi belirlendi mi?
Test edilmemiş plan, doğrulanmamış bir varsayımdır
Felaket kurtarma yatırımı yalnızca ikinci veri merkezi, bulut replikasyonu veya yedekleme lisansı satın almak değildir. Asıl değer; kurumun kritik hizmetlerini hangi sırayla, hangi veriyle ve hangi sürede geri getirebildiğini kanıtlayabilmesidir.
Küçük bir masa başı çalışmasıyla başlanabilir, ardından bileşen geri yükleme ve kontrollü failover testlerine geçilebilir. Her tatbikat planı biraz daha gerçekçi, ekibi biraz daha hazırlıklı ve kurtarma süresini biraz daha öngörülebilir hale getirir.
Rehberin dayandığı teknik kaynaklar
Bu yaklaşım; NIST SP 800-34 Rev. 1, Microsoft iş sürekliliği ve felaket kurtarma rehberi, Azure Well-Architected felaket kurtarma önerileri ve CISA StopRansomware Guide ile birlikte değerlendirilmiştir. Her kurum, risk toleransı ve yasal yükümlülüklerine göre kendi prosedürünü oluşturmalıdır.