DR planı hazırlama: hedeften tatbikata uygulama yöntemi

Felaket kurtarma planı neyi çözer?

Felaket kurtarma (DR) planı, bir veri merkezi arızası, fidye yazılımı saldırısı, yanlış bir silme işlemi ya da sağlayıcı kesintisi gibi büyük bir olaydan sonra kritik BT hizmetlerinin kabul edilebilir sürede ve kabul edilebilir veri kaybıyla yeniden ayağa kalkmasını sağlayan belgelenmiş ve sınanmış bir yöntemdir. Yedek almak bunun bir parçasıdır ama yedeğin varlığı plan olduğu anlamına gelmez: yedeği kim, hangi sırayla, hangi altyapıda geri yükleyecek, uygulamaların birbirine bağımlılığı nasıl çözülecek sorularının yanıtı plandadır.

Bu sayfa BT ve DR odağındadır. İş sürekliliği daha geniş bir kavramdır: insan, tesis ve süreç unsurlarını da kapsar. DR planı, iş sürekliliği planının teknoloji ayağıdır.

RPO ve RTO: planın temel hedefleri

Plan şu hedefler etrafında kurulur. RPO (Recovery Point Objective), en fazla ne kadar veri kaybını göze alabildiğinizi söyler; yani son kurtarılabilir noktanın olaydan ne kadar önce olabileceğini. RTO (Recovery Time Objective) ise hizmetin ne kadar sürede yeniden çalışır hale gelmesi gerektiğini belirtir.

Bu hedefleri BT ekibi tek başına koyamaz. İş birimleri, kendi süreçleri için kesinti ve veri kaybı toleransını belirtir; BT bunları teknik maliyetle birlikte sunar. Hedef sıkılaştıkça maliyet hızla artar: sürekli veri çoğaltma ve hazır bekleyen ikinci ortam, günlük yedeklemeden çok daha pahalıdır. Bu yüzden her sisteme aynı hedef verilmez; sistemler kritikliklerine göre kademelendirilir.

Adım adım: planın hazırlanması

Plan genellikle şu akışla hazırlanır.

İlk aşama risk değerlendirmesi ve iş etki analizidir (BIA). Hangi sistemlerin durması hangi iş sürecini ne kadar etkiler, hangi tehditler gerçekçi, hangi bağımlılıklar gizli sorularına bu aşamada yanıt aranır. Çıktı, kritiklik sırasına dizilmiş bir sistem listesi ve her biri için RPO ile RTO hedefidir.

İkinci aşama strateji seçimidir: her kademe için uygun kurtarma deseni belirlenir. Üçüncü aşama mimaridir: veri nasıl çoğaltılacak, ağ ve ad çözümleme nasıl yönlendirilecek, kimlik hizmeti ve sırlar (anahtarlar, parolalar) kurtarma ortamında nasıl bulunacak. Dördüncü aşama prosedürlerin yazılmasıdır: kim arar, kim karar verir, hangi sırayla hangi sistem açılır, geri dönüş (failback) nasıl yapılır. Son aşama sınamadır; yazılmış plan test edilmeden geçerli sayılmaz.

Kurtarma desenleri: yedekten çoklu bölgeye

Bulut ortamında yaygın desenler vardır; maliyet ve kurtarma hızı ters orantılı ilerler.

• Backup and restore: Veriler yedeklenir, olay olunca sıfırdan yeni ortam kurulup yedek geri yüklenir. En ucuz ve en yavaş desendir.
• Pilot light: İkinci ortamda yalnızca çekirdek bileşenler (örneğin çoğaltılan veritabanı) sürekli çalışır; kalan bileşenler olay anında otomasyonla açılır.
• Warm standby: İkinci ortamda uygulamanın küçültülmüş ama çalışan bir kopyası bekler; olay anında ölçeklenip trafiği devralır.
• Multi-site active-active: Tüm ortamlar canlı trafik alır. En yüksek maliyet ve en karmaşık veri tutarlılığı sorunudur, en kısa kesintiyi vaat eder.

Desen seçimi RTO ve RPO hedefinden başlar, tersinden değil. Her sistemi en pahalı desene koymak hem bütçeyi hem de operasyon yükünü şişirir.

Veri çoğaltma, ağ ve otomasyon

Kurtarmanın kalbi veridir. Eşzamanlı çoğaltma sıfıra yakın veri kaybı sağlar ama gecikme ve uzaklık kısıtları getirir; eşzamansız çoğaltma esnektir ama son işlemler kaybolabilir. Veritabanı ve dosya verisi için çoğaltma biçimi sistem bazında seçilir. Çoğaltma, bozulmuş ya da şifrelenmiş veriyi de çoğaltacağı için fidye yazılımı senaryosunda tek başına koruma sağlamaz; geriye dönük noktalar ve değiştirilemez yedekler de gerekir.

Ağ tarafında kurtarma ortamına trafik yönlendirme, ad çözümleme kayıtlarının güncellenmesi ve sağlık kontrolleri planlanır. Otomasyon ise insan hatasını azaltır: kurtarma altyapısı kodla tanımlanır, çalıştırma kılavuzları (runbook) adım adım yazılır ve mümkün olduğunca betiklenir. Olay anında panikle el ile yapılan işlemler en çok hata çıkan işlemlerdir.

Test, tatbikat ve sık yapılan hatalar

Plan, tatbikatla yaşar. Masa başı tatbikatta ekip senaryoyu konuşarak geçer; kısmi testte tek bir sistem kurtarma ortamında açılır; tam testte iş yükü gerçekten ikinci ortama devredilir. Her tatbikatın sonunda gerçek kurtarma süresi hedefle karşılaştırılır ve eksikler plana işlenir.

• Hedefleri hiç ölçmemek: RTO kâğıtta kısa, gerçekte çok daha uzun çıkar.
• Yedeği hiç geri yüklememek: bozuk ya da eksik yedek ancak olay anında fark edilir.
• Bağımlılıkları atlamak: uygulama ayağa kalkar ama kimlik hizmeti, ad çözümleme ya da lisans sunucusu kurtarılmadığı için çalışmaz.
• Planı tek kişiye bağlamak: o kişi ulaşılamazsa kimse ne yapacağını bilmez.
• Planı güncellememek: mimari değişir, plan eski kalır.
• Sağlayıcıyı ve sorumluluk sınırını yanlış varsaymak: bulutta platformun dayanıklılığı sizin uygulamanızın kurtarılabilirliğini kendiliğinden sağlamaz.

Nasıl öğrenilir ve Mindset programlarında nerede çalışılır?

Önce iş etki analizi ve RPO/RTO kavramlarını bir örnek sistem üzerinde çalışın: kendi çalıştığınız kurumda bir uygulama seçip hedefleri yazın, sonra hangi desenin uygun olacağını gerekçelendirin. Ardından seçtiğiniz bulut sağlayıcıda küçük bir kurtarma senaryosunu uçtan uca deneyin ve süreyi ölçün.

Mindset kataloğundaki Felaket Kurtarma Planlaması programı risk değerlendirmesi ve iş etki analizi, DR strateji seçimi ve teknoloji mimarisi, test, denetim ve olgunluk modeli, kurtarma prosedürleri ve DR planı hazırlama başlıklarını içeriyor. AWS Üzerinde Felaket Kurtarma Mimarileri (Pilot Light, Warm Standby) programı kurtarma desenleri, veri replikasyonu, otomasyon ve tatbikat modüllerini işliyor. Azure Site Recovery ile İş Sürekliliği Senaryoları programında ise replikasyon yapılandırması, kurtarma planları, failover ve failback senaryoları ele alınıyor.