Süreklilik planlamasının iki temel kavramı sade anlatımla.
Süreklilik planlamasının tamamı iki soruya dayanır. Bu iki sorunun cevabı, yedekleme sıklığından mimari kararına kadar her şeyi belirler.
RTO — Hedef kurtarma süresi
Soru: Bu sistem durursa, ne kadar sürede geri gelmiş olmalı?
Ölçtüğü: Kabul edilebilir kesinti süresi.
Örnek: "Sipariş sistemi en fazla dört saat kapalı kalabilir."
Neyi belirler:
- Yedeklilik ihtiyacı
- Hazır kaynak bulundurma
- Otomatik devretme gerekliliği
- Müdahale ekibinin erişilebilirliği
RPO — Hedef kurtarma noktası
Soru: Bir kayıp yaşandığında, ne kadar geriye dönmek kabul edilebilir?
Ölçtüğü: Kabul edilebilir veri kaybı.
Örnek: "En fazla bir saatlik veri kaybını kabul edebiliriz."
Neyi belirler:
- Yedekleme sıklığı
- Kopya (replikasyon) ihtiyacı
- Ara kayıt tutma gerekliliği
Görsel anlatım
Bir olayı zaman çizgisinde düşünün:
| Zaman | Olay |
|---|---|
| T-2 saat | Son yedek alındı |
| T | Arıza gerçekleşti |
| T+4 saat | Sistem geri geldi |
RPO gerçekleşen: 2 saat (son yedekten arızaya kadar olan veri kayboldu)
RTO gerçekleşen: 4 saat (arızadan geri dönüşe kadar geçen süre)
Hedefiniz bu değerlerin altındaysa yeterli, üstündeyse yatırım gerekir.
Nasıl belirlenir?
Kritik ilke: Bu değerleri BT değil, iş tarafı belirlemelidir.
Sorulacaklar:
- Bu sistem durursa hangi işler durur?
- Bir saatlik duruşun maliyeti nedir?
- Ne kadar süre manuel çalışabiliriz?
- Müşteri ve yasal yükümlülüklerimiz ne gerektiriyor?
- Bir günlük veriyi yeniden girmek mümkün mü?
- Kayıp veri telafi edilebilir mi?
Maliyet ilişkisi
Hedefler sıkılaştıkça maliyet hızla artar:
| RTO | Gereken yapı | Maliyet |
|---|---|---|
| Günler | Yedek yeterli | Düşük |
| Saatler | Yedek + hazır kaynak | Orta |
| Dakikalar | Bekleyen ikincil sistem | Yüksek |
| Saniyeler | Otomatik devretme, çok sistem | Çok yüksek |
| RPO | Gereken yapı | Maliyet |
|---|---|---|
| Bir gün | Günlük yedek | Düşük |
| Saatler | Sık yedek | Orta |
| Dakikalar | Sürekli kayıt/kopya | Yüksek |
| Sıfır | Eşzamanlı kopya | Çok yüksek |
Bu yüzden her sistem için "sıfır" hedefi koymak, karşılanamaz bir bütçe demektir.
Sistem bazlı farklılaştırma
| Sistem | Tipik RTO | Tipik RPO |
|---|---|---|
| Sipariş/üretim sistemi | Saatler | Dakikalar-saatler |
| Muhasebe | Bir gün | Bir gün |
| Kurumsal web sitesi | Saatler | Bir gün |
| E-posta | Saatler | Dakikalar |
| Dosya paylaşımı | Bir gün | Bir gün |
| İç raporlama | Günler | Bir gün |
| Arşiv | Bir hafta | Uzun |
Bu tablo örnektir; kendi değerlerinizi iş etkisine göre belirleyin.
Mevcut durumu ölçün
Hedefleri belirledikten sonra gerçek durumu ölçün:
- ☐ Yedekler ne sıklıkla alınıyor? → mevcut RPO
- ☐ Geri yükleme testi ne kadar sürdü? → mevcut RTO
- ☐ Sistemin yeniden kurulumu ne kadar sürer?
- ☐ Yedeğe erişim ne kadar sürer?
- ☐ Ekip ne kadar sürede müdahale edebilir?
Hedef ile gerçek arasındaki fark, yapılacak yatırımı gösterir.
RTO hesabına dahil edilmesi gerekenler
RTO yalnız teknik geri yükleme süresi değildir:
- Sorunun fark edilmesi
- Kapsamın belirlenmesi
- Karar verilmesi
- Ekibin toplanması
- Yedeğe erişilmesi
- Geri yükleme
- Doğrulama
- Kullanıcılara açılması
Bu adımların toplamı, gerçek RTO'dur. Sadece geri yükleme süresini ölçmek yanıltır.
Sık yapılan hatalar
- Hedefleri BT'nin belirlemesi — iş etkisi bilinmeden karar verilir
- Her sisteme aynı hedefi vermek
- Hedefleri gerçekçi olmayan biçimde sıkı tutmak
- Mevcut durumu ölçmemek
- Tespit süresini hesaba katmamak
- Hedefleri belirleyip yatırım yapmamak
Sonuç
RTO ve RPO, süreklilik konuşmasını duygusal olmaktan çıkarıp somutlaştırır:
"Sistemimiz güvenli olsun" yerine "Sipariş sistemi en fazla dört saat kapalı kalabilir ve en fazla bir saatlik veri kaybı kabul edilebilir" demek, hangi yatırımın gerektiğini doğrudan gösterir.
Yorumlar (0)
Henüz yorum yok — ilk yorumu siz yazın.
Yorum yaz