Replikasyon ve Kurtarmaya Hazırlık

Değil, ve bu iki şeyi karıştırmak felaket anında en pahalı sürprizi üretiyor.

Çoğaltma verinin ikinci bir kopyasını üretiyor. Kurtarılabilirlik ise o kopyadan çalışan bir sistemin ayağa kaldırılabilmesi. Aradaki fark; ağ yönlendirmesi, kimlik doğrulama, bağımlılık sırası, DNS, sertifikalar ve lisans anahtarları.

Somut örnek: veritabanınız ikinci sahaya sorunsuz çoğaltılıyor olabilir, ama uygulama sunucuları o sahada yoksa, ya da varsa bile üretimdeki dizin hizmetine bağlanmaya çalışıyorsa, elinizde çalışmayan bir kopya var demektir.

Bunu ancak deneyerek öğrenirsiniz. "Çoğaltma yeşil" panosu, kurtarılabilirlik hakkında hiçbir şey söylemiyor; yalnızca verinin aktığını söylüyor.

Dört başlıkta, ve dördü birden yeşil değilse hazırlık iddiası eksik kalıyor.

Çoğaltma gecikmesi: ikincil kopyanın birincilden ne kadar geride olduğu. Bu sayı gerçekleşen RPO'nuzdur; hedefiniz 15 dakikaysa ve gecikme saatlerdeyse, hedef kâğıt üzerinde kalmış demektir.

Kapsam eksiksizliği: kurtarma listesindeki sistemlerin gerçekten hepsi çoğaltılıyor mu? Yeni eklenen bir sunucu genellikle çoğaltma kapsamına alınmayı unutuyor ve bu, olay anında fark ediliyor.

Son tatbikat tarihi: altı ayı geçmiş bir tatbikat, o günden bu yana mimaride ne değiştiğine bağlı olarak değerini kaybediyor.

Tatbikatta ölçülen kurtarma süresi: hedefe göre nerede duruyor, ve zaman içinde uzuyor mu kısalıyor mu.

Dördü bir arada raporlanıyor; tek başına hiçbiri hazırlık anlamına gelmiyor.

Hedefinizi siz belirliyorsunuz; ölçüm o hedefe göre anlam kazanıyor.

Senkron çoğaltmada gecikme teorik olarak sıfırdır: yazma işlemi ikinci tarafta da tamamlanmadan onaylanmıyor. Bedeli, iki saha arasındaki ağ gecikmesinin doğrudan uygulamanın yazma performansına eklenmesi. Bu yüzden senkron çoğaltma coğrafi olarak yakın sahalar arasında kuruluyor.

Asenkron çoğaltmada gecikme dakikalar ya da saatler mertebesinde olabiliyor ve uygulama performansı etkilenmiyor. Karşılığında bir felakette o gecikme kadar veri kaybediliyor.

Asıl izlenmesi gereken şey mutlak sayı değil, sayının davranışı: gecikme genellikle sabit bir aralıkta seyrediyorsa sistem sağlıklı. Düzenli olarak tırmanıp düşüyorsa, genellikle bir toplu iş ya da yedekleme penceresi bant genişliğini doldurmuş oluyor; ve o pencerede yaşanacak bir felakette gerçek kayıp, ortalamanın çok üstünde olur.

Doğru kurgulanmış bir tatbikat üretime dokunmuyor.

Kurtarma, üretimden yalıtılmış bir ağ segmentinde yapılıyor. Kopyalar orada ayağa kaldırılıyor, uygulama açılıyor, veri bütünlüğü kontrol ediliyor, ama bu ortam üretim DNS'ine, üretim veritabanına ve dış entegrasyonlara bağlanmıyor.

Yalıtım bu yüzden tatbikatın en kritik teknik parçası: bağlantı kalırsa iki sistemin aynı anda yazması, çift e-posta gönderilmesi ya da ödeme sağlayıcısına test işlemi düşmesi gibi gerçek riskler doğuyor.

Tatbikatın gerçek maliyeti sistemde değil takvimde: hazırlık, yürütme ve raporlama ekipten zaman istiyor. Bu maliyeti kabul etmemenin karşılığı, planın ilk kez gerçek bir felakette denenmesi.

Üç ayrı işe yarıyor ve üçü de tatbikatın kendisi kadar değerli.

Denetim. ISO 22301 ve ISO 27001'in ilgili maddeleri kurtarmanın test edildiğine dair kanıt istiyor. Rapor, denetim gününde aranması gereken bir belge olmaktan çıkıyor.

İyileştirme. Raporda aksayan adımlar sırayla yazılı: hangi sistem beklenenden geç kalktı, hangi bağımlılık atlanmıştı, hangi yetki eksikti. Bir sonraki tatbikatın gündemi bu liste oluyor.

Karar. Ölçülen kurtarma süresi hedefin üstündeyse, ya hedefi ya mimariyi değiştirmek gerekiyor. Bu bir bütçe konuşmasıdır ve sayısız olmadan yapılamıyor. Rapor o sayıyı veriyor.

Raporlar biriktiğinde ayrıca bir eğilim oluşuyor: kurtarma süresi uzuyorsa ortam plandan uzaklaşıyor demektir.

Hepsi girmiyor, ve hepsini kapsama almak çoğu zaman yanlış karar.

Çoğaltma sürekli bant genişliği ve ikinci tarafta duran kapasite demek. Her sistemi aynı düzeyde çoğaltmak, bütçenin büyük kısmını düşük öncelikli iş yüklerine harcamak oluyor.

Doğru yöntem katmanlamak. Birinci katman: durduğunda iş duran sistemler: ödeme, sipariş, kimlik doğrulama. Bunlar en agresif çoğaltmayı hak ediyor. İkinci katman: birkaç saat durabilen ama gün boyu duramayan sistemler. Üçüncü katman: yedekten birkaç gün içinde dönmesi kabul edilebilir olanlar: iç raporlama, arşiv, test ortamları.

Katmanlama iş birimiyle birlikte yapılıyor ve yazılı hâle getiriliyor. Yazılı olmadığında, olay anında herkesin sistemi birinci katman oluyor.

Evet, ama mekanizma şirket içi ortamdan farklı ve bu farkın bilinmesi gerekiyor.

Şirket içi ortamda çoğaltma genellikle depolama ya da hypervisor katmanında yapılıyor. Bulutta ise sağlayıcının kendi çoğaltma ve snapshot hizmetleri devreye giriyor; bunlar bölge içinde ve bölgeler arasında farklı garantiler veriyor.

Kritik ayrım şu: bir bulut sağlayıcısının "yüksek dayanıklılık" taahhüdü veri kaybına karşı koruma sağlıyor, hesap düzeyinde bir hataya karşı sağlamıyor. Yanlışlıkla silinen ya da ele geçirilmiş bir hesapla silinen kaynak, aynı hesap içindeki yedeklilikle geri gelmiyor.

Bu yüzden bulut iş yüklerinde de ayrı bir kopya tutuluyor: farklı hesap, farklı bölge, ve üretim kimlik bilgileriyle erişilemeyen bir konum.

Ölçüm sürekli, rapor periyodik.

Çoğaltma gecikmesi ve kapsam eksiksizliği sürekli izleniyor; bir sistem kapsam dışına düştüğünde ya da gecikme eşiği aştığında bu bir olay olarak ele alınıyor, raporu beklemiyor.

Periyodik rapor ise dört başlığın bir arada durduğu ve eğilimin göründüğü belge. Kritik sistemler için altı aylık bir ritim çoğu kurumda doğru dengeyi kuruyor: tatbikat takvimiyle örtüşüyor ve yönetim kuruluna sunulabilecek sıklıkta.

Mimaride önemli bir değişiklik olduğunda ara rapor çıkarılıyor. Yeni bir uygulama, kimlik altyapısında değişiklik ya da veri merkezi taşıması, önceki raporun geçerliliğini doğrudan etkiliyor.

Üç seçenek var ve üçü de meşru; yanlış olan seçim yapmamak.

Hedefi değiştirmek. Belirlenen RTO gerçekçi değilse (çoğu zaman teknik ekibe danışılmadan konmuş bir sayıdır) iş birimiyle birlikte gözden geçirilir. Ulaşılamayan bir hedef, olmayan bir hedeften daha kötüdür, çünkü yanlış güven veriyor.

Mimariyi değiştirmek. Süreyi kısaltan şeyler bellidir ve hepsi maliyetlidir: ikincil sahada bekleyen hazır kapasite, daha sık çoğaltma, önceden hazırlanmış ağ yapılandırması, otomatikleştirilmiş devir adımları.

Kapsamı daraltmak. Bütün sistemleri hedefe getirmek yerine yalnızca birinci katmanı getirmek. Çoğu kurumda en iyi maliyet/fayda dengesi buradan çıkıyor.

Hangisi seçilirse seçilsin karar yazılı hâle getiriliyor; sözlü kalan bir kabul, bir sonraki denetimde bulguya dönüşüyor.