RTO ve RPO: İş Sürekliliği Hedeflerini Belirlemek

"Yedeğimiz var" cümlesi bir plan değildir. Gerçek soru şudur: Sunucu şu an tamamen kaybolsa, kaç saat içinde geri dönersiniz ve kaç saatlik veriyi kaybedersiniz?

Bu yazı, iş sürekliliği hedeflerini sayısallaştırmayı ele alıyor.

İki Temel Ölçü

Süreklilik planlaması iki sayıya dayanır:

• Kurtarma süresi hedefi: Hizmet ne kadar sürede döner?
• Kurtarma noktası hedefi: Ne kadarlık veri kaybedilir?

Bu ikisi bağımsız kavramlardır ve karıştırılmaları yaygın bir hatadır: bir sistem çok hızlı ayağa kalkıp yine de bir günlük veri kaybettirebilir, ya da hiç veri kaybettirmeyip günlerce kapalı kalabilir.

Birincisi kesinti süresini, ikincisi yedekleme sıklığını belirler. İkisini ayrı ayrı hedeflemek gerekir.

Hedefleri Kim Belirler?

Bu kararlar teknik değil, iş kararlarıdır:

Bu ayrım süreçteki en kritik noktadır: teknik ekip tek başına hedef belirlerse ya gereğinden fazla harcama yapar ya da iş için kabul edilemez bir risk alır.

Doğru yaklaşım, iş biriminin ihtiyacı söylemesi ve teknik ekibin maliyeti sunmasıdır. Karar birlikte verilir.

İş birimine soru sorarken dikkat edilmesi gereken bir nokta vardır: soru "ne kadar kapalı kalabiliriz?" diye sorulursa cevap her zaman "hiç" olur. Doğru soru maliyetle birlikte sorulmalıdır.

Her Sistem Aynı Değildir

Tüm sistemlere aynı hedefi koymak pahalı bir hatadır:

1. Kritik: Dakikalar içinde dönmeli.
2. Önemli: Birkaç saat kabul edilebilir.
3. Normal: Bir iş günü yeterli.
4. Düşük öncelikli: Birkaç gün sorun değil.

Bu sınıflandırma bütçeyi doğru yere yönlendirir: tüm sistemleri en yüksek seviyeye çıkarmak, gerçekten kritik olanlara ayrılabilecek kaynağı tüketir.

Bir e-ticaret sitesinde sipariş sistemi birinci gruptayken, raporlama sistemi üçüncü grupta olabilir. İkisine aynı yatırımı yapmak mantıksızdır.

Sınıflandırma yaparken bağımlılıklar da dikkate alınmalıdır. Kritik bir sistem, normal öncelikli bir sisteme bağımlıysa gerçek önceliği değişir.

Hedef ile Maliyet İlişkisi

Hedef sıkılaştıkça maliyet hızla artar:

Tablonun her satırı arasında ciddi bir maliyet sıçraması vardır: kurtarma süresini saatlerden dakikalara indirmek, altyapı maliyetini genellikle iki katından fazla artırır.

Bu nedenle hedef, gerçek iş ihtiyacına göre belirlenmelidir. "Ne kadar hızlıysa o kadar iyi" yaklaşımı, ödenmeyecek faturalar üretir.

Veri kaybı hedefi tarafında da benzer bir ilişki vardır. Günlük yedek ile sürekli çoğaltma arasındaki maliyet farkı çok büyüktür.

Gerçek Süreyi Ölçmek

Hedef koymak yetmez, mevcut durumu bilmek gerekir:

• Tam bir geri yükleme tatbikatı yapın.
• Süreyi kronometreyle ölçün.
• Tüm adımları dahil edin. Sadece kopyalamayı değil.
• Farkı raporlayın.

Üçüncü madde ölçümü gerçekçi kılar: gerçek kurtarma süresi yalnızca yedeğin açılma süresi değildir; sunucu temini, işletim sistemi kurulumu, yapılandırma, DNS değişikliği ve doğrulama da bu sürenin parçasıdır.

Bu adımlar dahil edildiğinde, "iki saatte dönerim" varsayımının aslında sekiz saat olduğu sıkça görülür.

Dördüncü madde ise karar vericiye bilgi taşır. Hedef ile gerçek arasındaki fark görünür olmalıdır; bu fark ya yatırımla kapatılır ya da hedef gerçekçi hâle getirilir.

Farklı Senaryolar İçin Farklı Planlar

Her arıza aynı müdahaleyi gerektirmez:

1. Tek disk arızası. RAID ile kesintisiz.
2. Sunucu donanım arızası. Yedek sunucuya geçiş.
3. Veri bozulması veya silinme. Yedekten geri dönüş.
4. Veri merkezi kaybı. Diğer lokasyon.
5. Fidye yazılımı. Yalıtılmış yedek.

Beşinci madde son yılların en önemli eklemesidir: sunucuya bağlı ve yazılabilir durumdaki yedekler fidye yazılımı tarafından da şifrelenir — bu senaryoda ancak çevrimdışı veya değiştirilemez yedekler işe yarar.

Üçüncü madde, çoğaltmanın neden yedek yerine geçmediğini açıklar. Silinen bir kayıt, çoğaltma yapan tüm kopyalarda anında silinir.

Bu ayrım plan yaparken netleştirilmelidir. Yüksek erişilebilirlik ile yedekleme farklı sorunları çözer.

Planın Yazılı Olması

Kurtarma planı bir belge olmalıdır:

Dördüncü satırda kritik bir tuzak vardır: kurtarma planı ve erişim bilgileri yalnızca kurtarılacak sistemde saklanıyorsa, felaket anında ikisine de ulaşamazsınız.

Planın çevrimdışı bir kopyası, ilgili kişilerin ulaşabileceği bir yerde bulunmalıdır.

Birinci satır ise gecikmeyi önler. Devreye alma kararını kimin vereceği belli değilse, herkes birbirini bekler.

Yedek sunucu ve çoklu lokasyon planlaması yaparken sağlayıcı seçenekleri belirleyici olur; fiziksel sunucu kiralama tarafında farklı lokasyonlarda hazır bekleyen yedek makine kurgusu mümkündür.

Sonuç

İş sürekliliğinde iki sayı belirleyicidir ve karıştırılmamalıdır: bir sistem çok hızlı ayağa kalkıp yine de bir günlük veri kaybettirebilir. Hedefleri iş birimi belirlemeli, teknik ekip maliyetini sunmalıdır — ama soru mutlaka maliyetle birlikte sorulmalı, yoksa cevap her zaman "hiç kapalı kalamayız" olur. Gerçek sürenizi tatbikatla ölçün; sunucu temini, kurulum, yapılandırma ve DNS değişikliği dahil edildiğinde iki saatlik varsayımlar sıklıkla sekiz saate çıkar.

Sıkça Sorulan Sorular (SSS)

Kurtarma süresi ile kurtarma noktası farkı ne?

Birincisi hizmetin ne kadar sürede döneceğini, ikincisi ne kadarlık verinin kaybedileceğini ifade eder. Bağımsız kavramlardır — bir sistem çok hızlı ayağa kalkıp yine de bir günlük veri kaybettirebilir, ya da hiç veri kaybettirmeyip günlerce kapalı kalabilir.

Hedefleri kim belirlemeli?

İş birimi ihtiyacı söyler, teknik ekip maliyeti sunar, karar birlikte verilir. Teknik ekip tek başına belirlerse ya gereğinden fazla harcar ya da kabul edilemez risk alır. Soruyu maliyetle birlikte sorun; yoksa cevap her zaman "hiç kapalı kalamayız" olur.

Çoğaltma yedek yerine geçer mi?

Hayır. Çoğaltma donanım arızasına karşı korur ama silinen veya bozulan bir kayıt tüm kopyalarda anında silinir. Ayrıca sunucuya bağlı ve yazılabilir yedekler fidye yazılımı tarafından da şifrelenir — bu senaryoda ancak çevrimdışı veya değiştirilemez yedekler işe yarar.

Gerçek kurtarma sürem ne?

Ancak tam bir tatbikatla öğrenilir. Ölçüme sadece yedeğin açılma süresini değil; sunucu temini, işletim sistemi kurulumu, yapılandırma, DNS değişikliği ve doğrulamayı da dahil edin. Bu adımlarla birlikte varsayılan süreler genellikle katlanır.