MTPD, RTO ve RPO Hedefleri Nasıl Belirlenir ve Onaylanır?

İş birimi “sistem hiç durmamalı, hiç veri kaybetmemeliyiz” der. BT ise mevcut altyapının ancak bir günde ve son gece yedeğinden geri dönebildiğini bilir. İki taraf da kendi cümlesini toplantıda tekrarlar, kimse karar vermez ve gerçek kesintide hedef de kapasite de kâğıt üzerinde kalır. MTPD, RTO ve RPO hedefleri bu iki gerçeğin yönetim kararıyla uzlaştırıldığı yerdir. Aşağıda kavramları yönetim diline nasıl çevireceğinizi, talep ile kapasite arasındaki boşluğu nasıl tabloya dökeceğinizi ve hedefleri nasıl onaylatıp ölçeceğinizi anlatıyoruz.

Kavramlar: MTPD, RTO, RPO, MBCO

Terimler ISO 22300 sözlüğünde tanımlanır; ISO 22301:2019’un BIA maddesi (8.2.2) MTPD ve RTO’yu notlarında anar. NIST SP 800-34 benzer kavramı MTD (maximum tolerable downtime) adıyla kullanır. Yönetim sunumunda her kavram tek anlamlı olmalı; yoksa toplantı tanım tartışmasına döner.

Kavram	Sorduğu soru	Kimin kararı
MTPD (azami tolere edilebilir kesinti süresi)	Bu faaliyet en fazla ne kadar durabilir, sonra etki kabul edilemez olur?	Üst yönetim, BIA verisiyle
RTO (kurtarma süresi hedefi)	Faaliyet asgari seviyede ne zamana kadar yeniden başlamalı?	Süreç sahibi önerir, yönetim onaylar
RPO (kurtarma noktası hedefi)	Kesinti anından geriye doğru en fazla ne kadarlık veri kaybı kabul edilebilir?	Süreç ve veri sahibi önerir, yönetim onaylar
MBCO (asgari iş sürekliliği hedefi)	Kesinti süresince hangi asgari hizmet seviyesi kabul edilebilir?	Süreç sahibi ve yönetim

MBCO çoğu kuruluşta tanımlanmadan bırakılır ve RTO tartışması bu yüzden bulanıklaşır. “Sipariş süreci 8 saatte geri dönmeli” cümlesi eksiktir. Doğrusu şuna benzer: “Sipariş süreci 8 saat içinde, en kritik müşteri grubunun siparişlerini günlük normal hacmin bir kısmıyla işleyebilecek seviyede geri dönmeli.” Asgari seviye tanımlanınca kurtarma kapsamı da daralır; belki tüm ERP değil, yalnız sipariş modülü ve bağlı stok sorgusu yeterlidir. Bu da daha küçük bir DR ortamı demektir.

Hedefler arasındaki mantıksal ilişki

Hedefler birbirinden bağımsız sayılar değildir. Tutarsızlığı onaydan önce yakalayın; onaydan sonra yakalarsanız imzalı bir belgeyi geri çekmek zorunda kalırsınız. Temel kurallar:

• RTO < MTPD: RTO, MTPD’ye eşit seçilirse en küçük gecikme doğrudan kabul edilemez etkiye dönüşür. Aradaki pay olayın fark edilmesi, karar alınması ve geri dönüş sonrası doğrulama içindir.
• Bağımlılık sırası: Bir faaliyetin RTO’su, ona girdi veren faaliyetlerin ve kullandığı sistemlerin RTO’sundan kısa olamaz. Kimlik doğrulama, ağ ve DNS gibi altyapı bileşenleri bu yüzden en kısa RTO’yu taşır. Domain controller ayağa kalkmadan hiçbir uygulama oturum açmaz.
• RPO zamanla ölçülür ama süre değildir: RPO kurtarmanın ne kadar süreceğini değil, hangi zamandaki veriye dönüleceğini tanımlar. Kısa RTO ile uzun RPO (hızlı ama eski veriyle açılma) ya da tersi mümkündür.
• Kayıp verinin yeniden girişi RTO’ya dahildir: RPO dört saatse, kaybolan dört saatlik işlemin kâğıttan veya e-postadan yeniden girilmesi gerekir. Bu süre teknik kurtarmanın üstüne eklenir.

Örnek hesap: Bir faaliyetin MTPD’si 48 saat olsun. Olayın fark edilmesi ve eskalasyon 2 saat, kriz ekibinin felaket ilanı kararı 2 saat, teknik geri yükleme 12 saat, uygulama doğrulaması ve kayıp verinin yeniden girişi 6 saat sürüyorsa toplam 22 saat eder. Bu durumda 24 saatlik RTO hem gerçekçidir hem de MTPD’ye karşı pay bırakır. Aynı faaliyet için iş birimi 4 saatlik RTO istiyorsa, yalnız teknik geri yükleme süresi bile hedefi aşar. Boşluk yatırımsız kapanmaz.

İş talebi ile teknik kapasite boşluğu

BIA’dan gelen hedefler talep tarafıdır; nasıl toplandığı iş etki analizi rehberinde anlatılır. Kapasite tarafı ise BT’nin bugün kanıtlayabildiği kurtarma süresi ve veri kaybıdır. Burada sahada sürekli karşılaştığımız iki tuzak var:

1. Kâğıt üzerindeki kapasite: “Replikasyonumuz var, 15 dakikada açılırız” cümlesi test edilmemişse kapasite değildir. Replika hedefte açıldığında IP adresi değişmiş, DNS kaydı eski adresi gösteriyor, uygulama lisansı MAC adresine bağlı çıkıyor olabilir. Kapasite sütununa yalnız son geri yükleme testinde ölçülen değeri yazın; ölçülmemişse “doğrulanmamış” yazın.
2. Tek sistem bakışı: Bir uygulamanın sanal makinesi bir saatte açılabilir; ama uygulama veritabanı sunucusuna, lisans sunucusuna, dosya paylaşımına ve dış entegrasyona bağlıysa kapasite, zincirin tamamının ayağa kalkma süresidir. En yavaş halka belirler.

Hangi hedefin hangi teknolojiyle karşılanacağı (yedekten dönüş, replika, cluster) ayrı bir mühendislik konusudur; bu karşılaştırma için RPO/RTO hedefine göre teknoloji seçimi yazısına bakabilirsiniz. Buradaki konu, o seçeneklerin maliyetinin iş talebiyle yönetim masasında nasıl karşılaştırılacağıdır.

Boşluk tablosu ve karar ağacı

Boşluk tablosu, yönetimin karar vereceği tek doküman olmalı. Yirmi sayfalık bir DR raporu okunmaz; dört sütunlu bir tablo okunur. Her öncelikli faaliyet için bir satır açılır:

Faaliyet	Talep (RTO / RPO)	Kanıtlanmış kapasite	Boşluk ve seçenekler
Sipariş alma	8 saat / 1 saat	24 saat / 24 saat (son test)	Replika + sık log yedeği; ya da hedefi gevşetme
Sevkiyat	24 saat / 4 saat	24 saat / 24 saat	RPO boşluğu; elle irsaliye geçici çözümü
Bordro	3 gün / 24 saat	24 saat / 24 saat	Boşluk yok

Tablodaki değerler örnektir. Her boşluk için şu karar ağacını izleyin:

1. Talep gerçekten MTPD’den mi türedi? İş birimi hedefi BIA etki ölçeğiyle gerekçelendiremiyorsa hedef yeniden değerlendirilir. Gerekçesiz “sıfır kesinti” talepleri bu adımda elenir.
2. Geçici çözüm var mı? Elle çalışma, alternatif kanal veya tedarikçi desteğiyle faaliyet asgari seviyede (MBCO) sürdürülebiliyorsa sistem RTO’su uzatılabilir. Geçici çözüm plana yazılır ve tatbikatta denenir.
3. Boşluğu kapatmanın maliyeti nedir? Teknik seçeneklerin yatırım ve işletme maliyeti, BIA’daki zaman bazlı etkiyle karşılaştırılır. Maliyet etkiyle orantılıysa yatırım bütçe planına girer.
4. Kapatılmayacaksa risk kabul edilir mi? Bu, yetkili yöneticinin imzasıyla verilen bir risk kabul kararıdır. Yetki sınırları kuruluşun risk kabul kriterleriyle uyumlu olmalıdır.
5. Ara dönem: Yatırım onaylansa bile devreye girene kadar geçerli olan gerçek kapasite plana yazılır. Plan, henüz satın alınmamış bir depolama ünitesine dayanamaz.

Hedeflerin yönetim onayı

Onay üç katmanlıdır. Süreç sahibi kendi faaliyetinin hedefini ve gerekçesini imzalar. BT veya hizmet sağlayıcı kapasite sütununu ve boşluğu kapatma seçeneklerini imzalar. Üst yönetim ise boşluk tablosunun tamamı için yatırım, geçici çözüm veya risk kabulü kararını verir. Karar kaydında şunlar bulunur:

• Onaylanan MTPD, RTO, RPO ve MBCO değerleri (faaliyet ve destekleyen sistem bazında)
• Kabul edilen boşluklar, gerekçe, geçerlilik süresi ve kabul eden kişi
• Onaylanan yatırımlar, sorumlu ve hedef tarih
• Bir sonraki gözden geçirme tarihi

Bu kayıt, iş sürekliliği yönetim sisteminin yönetimin gözden geçirmesi toplantısına doğrudan girdi olur; toplantının girdi ve çıktı yapısı için yönetimin gözden geçirmesi rehberine bakabilirsiniz. Onaylanan hedefler felaket kurtarma planına ve hizmet sözleşmelerine (dış kaynak BT, bulut, veri merkezi) aynen taşınmalıdır. Sözleşmede “en geç 48 saatte müdahale” yazıyor, onaylı RTO 8 saatse, o da bir boşluktur. Sahada en sık atlanan boşluk budur.

Hedeflerin periyodik doğrulanması

İş sürekliliği uyumu açısından onaylanmış bir hedef, test edilmedikçe bir varsayımdır. Doğrulama iki soruya cevap verir: hedef hâlâ iş gereksinimini yansıtıyor mu, ve kapasite hâlâ hedefi karşılıyor mu?

İlk soru BIA gözden geçirmesiyle cevaplanır. İkincisi ölçümle: geri yükleme testlerinde ve DR tatbikatlarında gerçekleşen kurtarma süresi ve veri kaybı kaydedilir, onaylı hedefle karşılaştırılır. Ölçümün başlangıç ve bitişini önceden tanımlayın. RTO kesintiden itibaren sayıldığı için başlangıç “kesintinin başladığı an”, bitiş “süreç sahibinin uygulamada test işlemi yapıp onay verdiği an”dır. Felaket ilanı kararının saati ayrıca kaydedilir; böylece tespit ve karar gecikmesi teknik kurtarma süresinden ayrı görülür. Yukarıdaki örnek hesap da bu yüzden tespit ve karar sürelerini içerir. Yalnızca sanal makinenin açılma süresini ölçmek, kullanıcı tarafındaki gerçek RTO’yu göstermez. Ping cevabı kurtarma değildir.

Tatbikat türlerinin hangi doğrulamaya uygun olduğu iş sürekliliği tatbikat türleri yazısında karşılaştırılır. Test sonucu hedefi tutmuyorsa durum düzeltici faaliyet olarak kaydedilir ve boşluk tablosu güncellenir. Hedeflerin felaket kurtarma planına ve geri dönüş prosedürlerine bağlanması için felaket kurtarma planı (DRP) hizmeti, BIA ile birlikte hedef çalışmasının yürütülmesi için BIA ve BCP hizmeti sayfalarına bakabilirsiniz. Kavramların BT kurtarma planlaması bağlamındaki resmi tanımları için NIST SP 800-34 Rev. 1 iyi bir başvuru kaynağıdır.

Sık sorulan sorular

RTO ile MTPD aynı değere ayarlanabilir mi?

Önerilmez. MTPD etkinin kabul edilemez hale geldiği sınırdır; RTO bu sınırdan önce, olay tespiti, karar ve doğrulama için pay bırakacak şekilde belirlenir. Değerler eşitse her gecikme doğrudan kabul edilemez etki yaratır.

RPO’yu kim belirler, BT mi iş birimi mi?

Kabul edilebilir veri kaybını iş birimi ve veri sahibi önerir, çünkü kaybın sonucunu onlar taşır. BT bu talebin hangi teknik seçenekle ve hangi maliyetle karşılanabileceğini gösterir. Nihai değer yönetim onayıyla kesinleşir.

Talep edilen hedef karşılanamıyorsa ne yapılmalı?

Boşluk tablosuna yazılır ve yönetime üç seçenek sunulur: yatırımla kapasiteyi artırmak, geçici çözümle asgari hizmet seviyesini sürdürmek ya da riski yetkili imzasıyla kabul etmek. Hedefi kapasiteye uydurmak için sessizce değiştirmek doğru değildir.

Hedefler ne zaman yeniden onaylanmalı?

Yılda bir, BIA gözden geçirmesiyle birlikte; ayrıca süreçte, sistemde veya hizmet sağlayıcıda önemli değişiklik olduğunda. Tatbikat ya da gerçek bir kesinti hedefin tutmadığını gösterirse boşluk tablosu güncellenip yeniden onaya sunulur.