DR Çözümleri

Felaket planlanmaz, kurtarma planlanır

Felaket kurtarma (DR), yedeklemenin devamı değil ayrı bir disiplindir. Yedekleme “veriyi geri getirebilir miyim?” sorusuna cevap verir; DR ise “işim kaç dakikada yeniden çalışır?” sorusuna.

Aradaki fark pratikte şudur: yedekten dönmek, sunucuyu yeniden kurmayı, veriyi yüklemeyi, ağı yapılandırmayı ve kullanıcıları yönlendirmeyi gerektirir — bu saatler, bazen günler alır. DR kurgusunda ise sistemin çalışmaya hazır bir kopyası zaten bekliyordur.

Bu yüzden DR konuşmasına teknolojiyle değil iki sayıyla başlıyoruz: RPO ve RTO.

RPO ve RTO: kurgunun tamamını bu iki sayı belirler

RPO ne kadar veri kaybını kabul edebileceğinizi söyler; geriye bakar. RTO ne kadar süre çalışamadan kalabileceğinizi söyler; ileriye bakar.

İkisi de birer iş kararıdır, teknik karar değil. Çünkü ikisinin de cevabı “sıfır” olmak ister ama sıfıra yaklaşmanın maliyeti üstel artar. Doğru soru “en iyi RTO nedir?” değil, “bir saatlik kesinti bize kaça mal olur?” sorusudur.

Hedefler belirlendikten sonra mimari kendiliğinden çıkar: RPO dakikalarsa sürekli replikasyon şarttır, RTO saatlerse hazır bekleyen bir ortam gerekir. Nasıl belirleneceğini ayrı bir yazıda anlattık.

Sözleşmeyle taahhüt ettiğimiz RTO 4 saat; replikasyon tarafında dakikalar mertebesinde RPO sağlanabiliyor.

Her sistem aynı RTO’yu hak etmez

En sık gördüğümüz hata, tüm sistemlere tek bir hedef koymak. Her şeyi kritik ilan etmek, pratikte hiçbir şeyi kritik ilan etmemekle aynı sonucu verir — bütçe yanlış yere gider.

Bu yüzden sistemleri katmanlıyoruz: durduğunda iş duran kritik sistemler, bir gün olmadan idare edilebilen önemli sistemler ve birkaç gün bekleyebilen destekleyici sistemler. Her katman kendi RPO/RTO hedefini ve kendi maliyetini alır.

Kapsama fiziksel sunucular, VMware ve Hyper-V sanal makineleri, veritabanları, dosya sunucuları ve uygulama sunucuları giriyor.

Tatbikat edilmeyen plan, plan değildir

Denenmemiş bir DR planında tipik olarak şunlar bulunur: güncelliğini yitirmiş IP planı, artık o kurumda çalışmayan birinin telefon numarası, replikasyon kapsamına hiç alınmamış bir dosya sunucusu, ve lisans sunucusuna bağımlı olduğu fark edilmemiş bir uygulama.

Bunların hepsi tatbikatta bulunması ucuz, krizde bulunması pahalı sorunlardır. Bu yüzden yılda 2 planlı tatbikat yapıyor, sonucunu raporla paylaşıyoruz — ölçülen RPO ve RTO değerleri, hedefe göre sapmalar ve bulunan eksiklerle birlikte.

Tatbikatımız failback ile biter: kriz bittiğinde birincil ortama kontrollü geri dönüş de denenir. Bunu atlayan kurumlar, krizden çıkarken ikinci bir kriz yaşıyor. Saat saat ne yaşandığını yazdık.