Felaket Kurtarma Planı (DRP) Nasıl Hazırlanır?
RTO ve RPO'dan tatbikat senaryolarına kadar, gerçekten işe yarayan bir felaket kurtarma planının bileşenleri ve 8 adımlık kurulum yolu.
Felaket kurtarma planı, yangın veya deprem gibi uç senaryolar için hazırlanmış tozlu bir klasör değildir. Pratikte planı devreye sokan olaylar çok daha sıradandır: bir fidye yazılımı, silinen bir veritabanı, çöken bir depolama birimi ya da uzun süren bir elektrik kesintisi. Plan, bu anlarda kimin ne yapacağını tartışmadan uygulanabilecek kadar net olmalıdır.
1. Kritik servisleri önceliklendirin
Her sistem aynı anda ayağa kaldırılamaz. Bu nedenle ilk adım, iş etki analizidir: hangi servis durduğunda ciro, üretim veya yasal yükümlülük ne kadar sürede etkilenir? Genellikle ERP, e-posta, dosya sunucusu ve saha uygulamaları ilk halkayı oluşturur. Bu sıralamayı BT değil, iş birimleri onaylamalıdır.
2. RTO ve RPO'yu yazılı hedef hâline getirin
RTO, bir servisin kabul edilebilir azami kesinti süresidir; RPO ise kabul edilebilir azami veri kaybıdır. 'Mümkün olan en kısa sürede' bir hedef değildir. Örneğin ERP için RTO 4 saat, RPO 15 dakika gibi somut değerler belirlendiğinde altyapı gereksinimi de kendiliğinden netleşir. Hedeflerin maliyet karşılığını görmek için kesinti maliyeti hesaplayıcısını kullanın.
3. Yedek site seçenekleri ve maliyet dengesi
- Soğuk site: en ucuz, kurtarma günler sürer; yalnızca düşük kritiklikteki sistemler için uygundur.
- Ilık site: donanım hazır, veri periyodik kopyalanır; saatler mertebesinde kurtarma sağlar.
- Sıcak site / bulut replikasyonu: dakikalar içinde devralır, maliyeti en yüksek seçenektir.
- Karma model: kritik servisler sıcak, geri kalanı ılık yapıda tutularak bütçe optimize edilir.
Bulut tabanlı replikasyon son yıllarda ılık site maliyetiyle sıcak site performansı sunabildiği için birçok kurum için en dengeli seçenek hâline geldi. Karar öncesi rakamları görmek isterseniz bulut geçişi maliyet analizi yazımız yol gösterir.
4. Yedekleri değil, geri dönüşleri test edin
Yedekleme işinin başarıyla tamamlandığını gösteren yeşil bir ekran, verinin geri yüklenebileceğini kanıtlamaz. Her çeyrekte rastgele seçilmiş bir sunucunun izole ortamda tam geri yüklemesi yapılmalı, süre ölçülmeli ve RTO hedefiyle karşılaştırılmalıdır. Fidye yazılımı senaryosunda değiştirilemez (immutable) yedek katmanının kritik önemi için fidye yazılımı korunma rehberini inceleyin.
5. İletişim planı çoğu zaman eksik kalır
Kriz anında en çok zaman kaybettiren şey teknik sorun değil, koordinasyonsuzluktur. Planda kriz yöneticisi, teknik sorumlu, iletişim sorumlusu ve yedekleri isim isim yer almalı; telefon listesi kurumsal e-postadan bağımsız bir yerde saklanmalıdır. Müşteri ve tedarikçilere yapılacak bilgilendirmenin taslak metni önceden hazırlanmalıdır.
6. Tatbikat takvimi ve güncelleme döngüsü
Yılda en az bir kez masabaşı tatbikatı, altı ayda bir teknik geri yükleme testi önerilir. Her altyapı değişikliğinden sonra plan gözden geçirilmelidir; aksi hâlde belge birkaç ay içinde gerçekliğini yitirir. Süreç olgunluğunuzu ölçmek için BT sağlık quizini doldurabilir, kurumsal denetim için BT denetimi talebinde bulunabilirsiniz.
İyi bir felaket kurtarma planı, kurumun en kötü gününü sıradan bir operasyon gününe dönüştürür. Kendi kurumunuza özel RTO/RPO hedefleri ve bütçe senaryosu için teklif sihirbazını kullanabilirsiniz.
Sıkça sorulan sorular
- RTO ile RPO arasındaki fark nedir?
- RTO bir servisin ne kadar süre kapalı kalabileceğini, RPO ise en fazla ne kadarlık verinin kaybedilebileceğini tanımlar. İkisi ayrı ayrı belirlenir ve farklı yatırımlar gerektirir.
- Felaket kurtarma planı ne sıklıkla test edilmeli?
- Yılda en az bir masabaşı tatbikatı ve altı ayda bir gerçek geri yükleme testi önerilir. Büyük altyapı değişikliklerinden sonra plan ayrıca güncellenmelidir.