RTO, RPO ve MTTR: Kurtarma Hedeflerini Tanımlama

Belirli ve ölçülebilir kurtarma hedefleri olmadan uygun yedekleme stratejileri tasarlamak, doğru DR site katmanını seçmek veya kurtarma teknolojilerine yapılan yatırımların gerekip gerekmediğini değerlendirmek mümkün değildir. RTO, RPO ve MTTR, iş sürekliliği gereksinimlerini kesin mühendislik hedeflerine dönüştürür. Bu ölçümler, güvenlik ve IT ekiplerinin kesinti maliyeti ile DR yatırımlarının maliyeti hakkında yöneticilerle kanıta dayalı görüşmeler yapmasını sağlar; böylece iş gerekçeleri soyut olmaktan çıkar ve somut hale gelir.

Kurtarma Süresi Hedefi (RTO), bir kesintinin başlamasından normal Service'in yeniden sağlanmasına kadar kabul edilebilecek en uzun süredir. Kritik bir Payment System'i 10:00 AM'de arızalanır ve işletme kabul edilemez gelir kaybına uğramadan veya SLA'ları ihlal etmeden önce en fazla 2 saatlik downtime'ı tolere edebilirse RTO 2 saattir — sistem en geç 12:00 PM'de kurtarılmalıdır. RTO; DR site katmanı (15 dakikalık RTO için hot site, 48 saatlik RTO için cold site), çoğaltma sıklığı ve otomatik yük devretme hakkındaki seçimleri belirler.

Kurtarma Noktası Hedefi (RPO), zaman cinsinden ölçülen kabul edilebilir en yüksek veri kaybıdır — bir felaket gerçekleştiğinde ne kadar veri kaybının tolere edilebileceğini ifade eder. 1 saatlik RPO, sistemler kurtarıldığında felaketten en fazla 1 saat öncesine ait verileri içermeleri gerektiği anlamına gelir. RPO, yedekleme sıklığını belirler: 1 saatlik RPO için en az saatlik yedeklemeler (veya sürekli Replication) gerekir. 4 saatlik RPO, 4 saatlik yedekleme aralıklarını tolere edebilir. RPO veri kurtarmayla, RTO ise Service kullanılabilirliğinin yeniden sağlanmasıyla ilgilidir.

RTO ve RPO kurtarmanın farklı yönlerini ele alır ve birbirinden bağımsız olarak tanımlanmalıdır. Bir System'in dar bir RPO'su (1 saat; verilerin sık sık Replication ile çoğaltıldığı anlamına gelir) ancak geniş bir RTO'su (veriler güncel olsa da DR ortamının başlatılmasının 4 saat sürmesi anlamına gelir) olabilir. Tersine, bir System'in geniş bir RPO'su (24 saat; Nightly yedeklemenin yeterli olduğu anlamına gelir) ancak dar bir RTO'su (1 saatlik yük devretme gerektiğinden etkinleştirilmeye hazır, önceden provisioned edilmiş bir DR ortamının mevcut olması gerekir) olabilir. Her iki ölçüm de İş Etkisi Analizi'nden elde edilir.

Kurtarmaya Kadar Ortalama Süre (MTTR), bir incident sonrasında Service'i yeniden sağlamak için geçen gerçek ortalama süredir; kurtarma performansının operasyonel ölçümüdür. RTO tolere edilebilecek en yüksek downtime'ı (hedef/gereksinim), MTTR ise gözlemlenen ortalamayı (gerçek performansı) ifade eder. Kuruluşlar zaman içinde incident'lar arasındaki MTTR'yi ölçer ve kurtarma kapasitelerini değerlendirmek için bunu RTO ile karşılaştırır. MTTR'nin sürekli olarak RTO'yu aşması, DR kapasitelerinin yetersiz olduğunu ve otomasyon, personel veya altyapı yatırımlarının gerekli olduğunu gösterir.

Arızalar Arasındaki Ortalama Süre (MTBF), System güvenilirliğini ölçer — bir System'in arızalar arasında çalıştığı ortalama süredir. Daha Higher MTBF, daha iyi güvenilirlik anlamına gelir. MTBF ve MTTR birlikte bir System'in kullanılabilirlik yüzdesini belirler: Availability = MTBF / (MTBF + MTTR). MTBF'si 2000 saat ve MTTR'si 2 saat olan bir System'in kullanılabilirliği 2000/2002 = %99,9'dur. MTBF'yi anlamak, arızaların ne zaman olabileceğini tahmin etmeye ve bakım aralıklarını buna göre planlamaya yardımcı olur — MTBF'si düşen Hardware kullanım ömrünün sonuna yaklaşıyor demektir ve önceden değiştirilmelidir.

Tolere Edilebilecek En Uzun Kesinti Süresi (MTD), işletme geri döndürülemez zarara uğramadan önce bir System'in kullanılamayacağı mutlak en uzun süredir — müşteri kaybı, yasal cezalar veya sözleşmeden doğan yükümlülükleri yerine getirememe. MTD her zaman RTO'ya eşit veya ondan büyüktür. İlişki şöyledir: MTD işletmenin sınırıdır; RTO ise IT hedefidir. Bir sözleşme, cezalar uygulanmadan önce 4 saatlik bir SLA ihlaline izin veriyorsa MTD 4 saat olabilir. IT ekibi, MTD'ye ulaşmadan önce güvenlik payı bırakmak için 1-2 saatlik bir RTO tasarlar.

Service Düzeyi Anlaşmaları (SLA'lar), müşterilere verilen ve RTO ile RPO gereksinimlerini doğrudan etkileyen sözleşmeye dayalı taahhütleri tanımlar. %99,95 Uptime taahhüdü veren bir Cloud sağlayıcısının SLA'sı, yılda yaklaşık 4,4 saatlik downtime'a izin verir. SLA'nın ihlali, Service kredilerini veya sözleşmeyi feshetme haklarını devreye sokar. IT ile iş birimleri arasındaki dahili SLA'lar da benzer şekilde işler. Gerçek downtime'ın SLA taahhütleri içinde kalmasını sağlamak için RTO ve RPO tasarlanmalı; uyumluluğu göstermek üzere MTTR ölçülmeli ve raporlanmalıdır.

Teknoloji seçimleri doğrudan RTO ve RPO gereksinimleriyle belirlenir. 15 dakikalık RTO ve sıfır RPO, synchronous Replication ile active-active kümeleme gerektirir — veri kaybı olmaz ve otomatik yük devretme gerçekleşir. 1 saatlik RPO ile 4 saatlik RTO için log gönderimi veya warm standby'a asynchronous Replication kullanılabilir. 24 saatlik RPO ile 24 saatlik RTO için cold depolamaya Daily yedeklemeler kullanılabilir. Gerektiğinden daha yüksek dayanıklılık tasarlamak bütçeyi boşa harcar; daha düşük dayanıklılık tasarlamak ise incident'lar sırasında kabul edilemez iş riski oluşturur.

Kurtarma hedefleri yalnızca düzenli sınamalarla doğrulanırsa geçerlidir. Kuruluşlar, gerçek MTTR'yi ölçen ve gerçek veri kurtarma noktasını doğrulayan (geri yüklendiğinde veri ne kadar eskidir?) kurtarma sınamaları gerçekleştirmelidir. Bir sınama, MTTR'nin 1 saatlik RTO'ya karşı sürekli olarak 3 saat olduğunu ortaya çıkarırsa bu fark giderilmelidir — ya DR altyapısı (otomasyon, önceden kaynak sağlama) iyileştirilmeli ya da güncellenmiş bir BIA aracılığıyla iş beklentileri yeniden belirlenmelidir. Sınama sıklığı kritiklik düzeyiyle uyumlu olmalıdır: kritik sistemler üç ayda bir, diğerleri yılda bir.

RTO, RPO ve MTTR raporları, iş paydaşlarının anlayacağı terimlerle iletilmelidir. “Tier 1 sistemlerimiz için MTTR 47 dakika” demek yerine, “en kritik sistemlerimiz arızalandığında hizmeti ortalama bir saatten kısa sürede, sözleşmelerimizin izin verdiği 2 saatlik süre içinde geri yüklüyoruz” denmelidir. Düzenli raporlama, paydaşların güvenini artırır ve kuruluşun dayanıklılık duruşu hakkında ortak bir anlayış oluşturur. MTTR eğilimlerinin zaman içindeki gösterge paneli raporlaması, programdaki iyileşmeyi ortaya koyar ve DR yatırımları için bütçe gerekçesini destekler.

Bu dersteki CompTIA Security+ (SY0-701) kavramlarını anlayıp anlamadığınızı sınayın.

Bu derste şunları öğrendiniz: RTO, hizmetin kesintide kalabileceği en uzun süredir ve yük devretme hızı gereksinimlerini belirler; RPO, kabul edilebilir en yüksek veri kaybıdır ve backup ile çoğaltma sıklığını belirler; MTTR, ölçülen gerçek ortalama kurtarma süresidir ve DR programının etkililiğini değerlendirmek için RTO ile karşılaştırılır. Sırada backup stratejilerini — 3-2-1 kuralını ve ransomware'in yok edemeyeceği değiştirilemez backup'ları — inceleyeceğiz.