Bir kurumsal yazılım bir saat boyunca durduğunda ilk kaybedilen şey teknoloji değil; kesilen siparişler, bekleyen müşteriler, işleyemeyen ödemeler ve hızla eriyen güvendir. İş sürekliliği ve felaket kurtarma (BC/DR), bu kesintilerin ne zaman olacağını tahmin etmekten çok, olduğunda işin ne kadar hızlı ve hangi maliyetle ayağa kalkacağını önceden karara bağlamakla ilgilidir. Bu yazı, konuyu teknik bir kurulum reçetesi olarak değil; karar vericilerin, iş sahiplerinin ve teknoloji yöneticilerinin bütçe, risk ve öncelik dilinde değerlendirebileceği bir çerçeve olarak ele alıyor.
İş Sürekliliği ile Felaket Kurtarma Aynı Şey Değildir
İki kavram sık sık birbirinin yerine kullanılsa da farklı sorulara yanıt verir. İş sürekliliği (Business Continuity), “kritik iş süreçlerimiz bir aksaklık sırasında nasıl çalışmaya devam eder?” sorusuna odaklanır; kapsamı yalnızca yazılım değil, insanlar, süreçler, iletişim ve alternatif çalışma biçimleridir. Felaket kurtarma (Disaster Recovery) ise bu bütünün teknoloji ayağıdır: sistemlerin, verilerin ve uygulamaların bir kesinti sonrası nasıl geri getirileceğini tanımlar.
Karar verici açısından ayrım şu yüzden önemlidir: yalnızca yedeklemesi olan bir kurum, “verimiz duruyor” diyebilir ama süreçleri saatlerce durabilir. Sürekliliği bir bütün olarak planlayan kurum ise hem veriyi hem de işi ayakta tutmayı hedefler. Bu, satın alınacak bir üründen çok, benimsenmesi gereken bir yönetim disiplinidir.
İki Temel Metrik: RTO ve RPO
BC/DR konuşmalarının neredeyse tamamı iki kısaltmanın etrafında döner. Bunları anlamak, teknik ekiple iş tarafını aynı masaya oturtan ortak dili kurar.
RTO — Kurtarma Süresi Hedefi (Recovery Time Objective)
RTO, bir sistemin kesintiden sonra ne kadar sürede yeniden çalışır hâle gelmesi gerektiğini söyler. “Ödeme sistemimiz en fazla 30 dakika, iç raporlama aracımız en fazla bir gün durabilir” gibi ifadeler birer RTO hedefidir. Düşük RTO daha az kesinti demektir ama genellikle daha yüksek altyapı ve mimari maliyeti getirir.
RPO — Kurtarma Noktası Hedefi (Recovery Point Objective)
RPO ise ne kadar veri kaybını göze alabileceğinizi tanımlar. Yedekler saatte bir alınıyorsa, en kötü senaryoda bir saatlik veri kaybedilebilir; RPO’nuz bir saattir. Finansal işlemler gibi alanlarda hedef dakikalara, hatta saniyelere inerken; nadiren değişen referans verilerinde günlük RPO yeterli olabilir.
Kritik nokta şudur: RTO ve RPO iş kararlarıdır, teknik ekibin tek başına belirleyeceği değerler değildir. Her hedefi sıfıra çekmek teknik olarak mümkün olsa da maliyeti çoğu kurum için savunulamaz. Doğru yaklaşım, her sistem için “durması işimize kaça mal olur?” sorusunu yanıtlayıp hedefleri buna göre kademelendirmektir.
İş Etki Analizi ile Önceliklendirme
Bütün sistemleri aynı düzeyde korumaya çalışmak hem pahalı hem gereksizdir. İş etki analizi (Business Impact Analysis, BIA), her sürecin durması hâlinde oluşacak finansal, operasyonel, yasal ve itibar etkisini değerlendirerek önceliklendirme yapmanızı sağlar. Bu çalışma tipik olarak üç soruyu yanıtlar: Bu süreç durursa kim ve ne etkilenir? Etkisi zamanla nasıl artar? Kabul edilebilir azami kesinti nedir?
BIA’nın çıktısı, sistemleri kritiklik düzeylerine (örneğin misyon-kritik, önemli, destekleyici) ayıran bir haritadır. Bu harita hem BC/DR yatırımını nereye yoğunlaştıracağınızı gösterir hem de tedarikçilerle yapacağınız hizmet seviyesi görüşmelerinin temelini oluşturur. Önceliklendirme, iyi bir veri yönetişimi pratiğiyle birlikte yürüdüğünde çok daha sağlam olur; çünkü hangi verinin ne kadar kritik olduğunu bilmeden doğru RPO belirlenemez.
Süreklilik Stratejileri: Karar Düzeyinde Seçenekler
Teknik detaylara girmeden, karar vericinin bilmesi gereken temel süreklilik yaklaşımları bir yelpaze oluşturur. Daha yüksek hazır olma düzeyi, daha yüksek maliyet anlamına gelir:
- Yedekleme ve geri yükleme: En ekonomik seçenek. Veriler düzenli olarak yedeklenir, kesinti sonrası geri yüklenir. RTO görece uzundur; nadiren değişen, kritik olmayan sistemler için uygundur.
- Sıcak/soğuk kopya (yedek ortam): Sistemin ikinci bir kopyası hazır bekletilir. “Soğuk” kopya devreye alınması zaman ister; “sıcak” kopya neredeyse anında devralır ama sürekli çalıştığı için daha pahalıdır.
- Çok bölgeli / yüksek erişilebilirlik: İş yükü birden fazla bağımsız ortama dağıtılır; biri düşerse diğerleri hizmeti sürdürür. En düşük RTO/RPO’yu sunar, en yüksek maliyeti taşır ve genellikle yalnızca misyon-kritik sistemler için gerekçelendirilebilir.
Karar verici için mesaj net: “her sisteme en güçlü koruma” değil, “her sisteme kritikliğine uygun koruma”. Bu dengeyi kurmak, toplam sahip olma maliyetini doğrudan etkiler; bu nedenle BC/DR kararlarını SaaS’ta TCO ve ROI değerlendirmesi ile birlikte ele almak sağlıklıdır.
Tedarikçi, Bulut ve Paylaşılan Sorumluluk
Sistemleriniz bir SaaS ürününde veya bulut sağlayıcıda çalışıyorsa, “yedeklemeyi sağlayıcı yapıyordur” varsayımı en pahalı hatalardan biridir. Çoğu bulut ve SaaS sözleşmesinde paylaşılan sorumluluk ilkesi geçerlidir: sağlayıcı altyapının ayakta kalmasından sorumluyken, verinizin yedeklenmesi ve kurtarılabilirliği çoğu zaman sizin sorumluluğunuzdadır. Sözleşmeyi imzalamadan önce şu soruların yanıtı yazılı olmalıdır: Sağlayıcının taahhüt ettiği çalışma süresi (uptime) nedir? Kesinti hâlinde tazminat/kredi mekanizması var mı? Verilerimin yedeği nerede, ne sıklıkta alınıyor ve geri yükleme sorumluluğu kimde? Sağlayıcıdan ayrılırsam verimi hangi formatta ve ne sürede geri alırım?
Bu maddeler, hizmet seviyesi anlaşmalarının (SLA) kalbindedir ve tedarikçi değerlendirmesinin ayrılmaz parçası olmalıdır. Konuyu daha geniş bir çerçevede ele almak için yazılım tedarikçisi seçimi ve bakım ve destek yönetimi rehberlerimiz, SLA maddelerini nasıl okumanız gerektiğine dair tamamlayıcı bir bakış sunar.
Değerlendirme Kriterleri
Bir BC/DR yaklaşımını ister kendi içinizde kurun ister bir tedarikçiden hizmet olarak alın, aşağıdaki kriterler karşılaştırma için sağlam bir temel oluşturur.
| Kriter | Neye Bakmalı? | Neden Önemli? |
|---|---|---|
| RTO uyumu | Hedeflenen kurtarma süresi iş ihtiyacını karşılıyor mu? | Kabul edilebilir kesinti süresini belirler |
| RPO uyumu | Kabul edilebilir veri kaybı sınırınıza uygun mu? | Veri bütünlüğü ve kayıp toleransını yönetir |
| Test edilebilirlik | Kurtarma senaryoları düzenli ve gerçekçi test ediliyor mu? | Planın kâğıt üstünde kalmasını önler |
| Sorumluluk netliği | Yedekleme ve kurtarma sorumluluğu sözleşmede açık mı? | Kriz anında belirsizliği ortadan kaldırır |
| Maliyet dengesi | Koruma düzeyi sistemin kritikliğiyle orantılı mı? | Aşırı veya yetersiz yatırımı engeller |
| İzlenebilirlik | Yedeklerin başarısı ve tazeliği raporlanıyor mu? | “Yedek var sanıyorduk” sürprizini önler |
Plan Test Edilmiyorsa Plan Değildir
BC/DR alanındaki en yaygın yanılgı, yazılı bir planın varlığını hazır olmakla eşitlemektir. Hiç denenmemiş bir kurtarma prosedürü, kriz anında ilk kez sınandığında sıklıkla başarısız olur: yedekler bozuk çıkar, geri yükleme beklenenden uzun sürer, kritik bir adım belgelenmemiştir. Bu nedenle olgun kurumlar süreklilik planlarını düzenli tatbikatlarla sınar; masabaşı senaryolardan gerçek geri yükleme denemelerine kadar farklı derinliklerde. Her tatbikat, RTO/RPO hedeflerinin gerçekçi olup olmadığını gösteren ve planı güncel tutan bir geri bildirim döngüsüdür. Bu disiplin, kalite güvence ve test süreçleri kültürünün doğal bir uzantısıdır.
Sık Yapılan Hatalar
- Her şeyi kritik ilan etmek: Öncelik yoksa bütçe dağılır ve hiçbir şey yeterince korunmaz.
- Yedeği doğrulamamak: Alınan yedeğin geri yüklenebilir olduğu düzenli olarak test edilmezse yedek sadece bir varsayımdır.
- İnsanı ve süreci unutmak: Sistem geri gelse bile kimin ne yapacağı belli değilse kesinti uzar. Süreklilik bir iletişim planıdır da.
- Sözleşmeyi okumamak: Sağlayıcının neyi taahhüt ettiğini kriz anında öğrenmek en pahalı yöntemdir.
Sık Sorulan Sorular
İş sürekliliği ve felaket kurtarma yalnızca büyük şirketler için mi?
Hayır. Ölçek değişse de mantık aynıdır: küçük bir işletme için bir gün süren kesinti, büyük bir kurum için bir saatlik kesinti kadar yıkıcı olabilir. Fark, korumanın kapsamında ve maliyetindedir, gerekliliğinde değil.
RTO ve RPO hedeflerini kim belirlemeli?
Bu hedefler iş ve teknoloji taraflarının ortak kararıdır. İş tarafı kabul edilebilir kesinti ve veri kaybını tanımlar; teknoloji tarafı bunun maliyetini ve uygulanabilirliğini ortaya koyar. Nihai değer, bu iki bakışın dengesidir.
Bulut kullanıyorsam ayrıca felaket kurtarma planına gerek var mı?
Evet. Bulut sağlayıcılar yüksek erişilebilirlik sunsa da veri kaybı, hatalı silme veya sağlayıcı kaynaklı kesintilere karşı sorumluluğun bir kısmı sizde kalır. Paylaşılan sorumluluk modelini netleştirmeden buluta “otomatik güvenlik” atfetmek risklidir.
Sonuç
İş sürekliliği ve felaket kurtarma, teknik bir sigorta poliçesinden çok bir iş kararları bütünüdür: neyin ne kadar kritik olduğunu, ne kadar kesinti ve veri kaybını göze alabileceğinizi ve bunun maliyetine değip değmediğini önceden kararlaştırmak. RTO ve RPO ile başlayan, iş etki analiziyle önceliklendirilen ve düzenli tatbikatlarla canlı tutulan bir yaklaşım, kesintiyi bir felakete dönüşmeden yönetilebilir bir olaya indirger.
Kurumunuz için doğru süreklilik düzeyini belirlemek, mevcut sistemlerinizi ve tedarikçi sözleşmelerinizi bu gözle gözden geçirmekle başlar. Yazılım çözümlerinizi dayanıklılık açısından değerlendirmek isterseniz yazilimstudyosu.com üzerinden bize ulaşabilir, ihtiyaçlarınıza uygun bir yol haritası için görüşebilirsiniz.