RPO ve RTO nedir? İş sürekliliği hedefleri nasıl belirlenir?

RPO: Ne kadar veriyi kaybetmeyi tolere edebilirsiniz?

Recovery Point Objective, kesinti sonrasında verinin hangi geçmiş noktaya kadar geri getirilebilmesi gerektiğini ifade eder. NIST SP 800-34, RPO’yu en güncel yedek kopyası dikkate alındığında verinin kurtarılacağı zaman noktası olarak tanımlar.

Örneğin RPO dört saat olarak belirlenmişse koruma tasarımı, kesinti anında dört saatten fazla veri kaybı oluşmamasını hedeflemelidir. Bu bir garanti değil; iş ihtiyacından türetilen tasarım hedefidir.

RTO: Hizmet ne kadar sürede geri gelmeli?

Recovery Time Objective, bir sistem kaynağının kabul edilemez iş etkisi oluşmadan önce ne kadar süre kullanılamaz kalabileceğini tanımlar. Süre yalnızca veriyi kopyalamayı değil; altyapıyı hazırlama, uygulamayı başlatma, bağlantıları kurma ve sonucu doğrulama adımlarını da kapsamalıdır.

Daha kısa RTO genellikle daha hazır alternatif kaynak, daha fazla otomasyon ve daha sık test gerektirir. Bu nedenle her sisteme aynı hedefi vermek maliyet ve karmaşıklığı gereksiz artırabilir.

Hedefler iş birimiyle birlikte belirlenir

RPO ve RTO yalnızca BT ekibinin teknik kararı değildir. Süreç sahibi; kesintinin sipariş, üretim, müşteri hizmeti, finans veya mevzuat üzerindeki etkisini açıklamalıdır.

• Hangi iş süreci bu sisteme bağlı?
• Kesintinin ilk saat ve ilk gün etkisi nedir?
• Eksik işlemler yeniden girilebilir mi?
• Uygulamanın dış sistem ve insan bağımlılıkları neler?
• Kurtarma sonrasında hangi doğrulamalar yapılmalı?

RPO/RTO hedefini test edilebilir hale getirin

Hedef yazmak tek başına yeterli değildir. Kurtarma senaryosunda başlangıç ve bitiş noktaları, sorumlular, veri doğrulama yöntemi ve kabul kriterleri tanımlanmalıdır.

Test sonucu hedefin karşılanmadığını gösteriyorsa iki seçenek vardır: mimari ve süreç geliştirilir ya da iş birimiyle hedef gerçekçi biçimde yeniden değerlendirilir. Ölçülmeyen RPO/RTO, karar vermeyi kolaylaştıran bir hedef olmaktan çıkar.