Recovery Time Objective ifadesi Türkçede toparlanma süresi hedefi diye anılır ve gerçek tatbikat kayıtlarıyla doğrulanmalıdır. Yönetim kurulunda sık duyulan soru şudur. Sistem kapalı kaldığında en geç ne zaman iş akışı devam edebilir? DRaaS paketinde cevap, hangi uygulamaların ikincil ortamda açıldığı, DNS ve kimlik adımlarının kimin sorumluluğunda olduğu ve tatbikat sırasında hangi saat diliminin ölçüldüğüyle netleşir.
Bu metin DRaaS ürün sayfasını destekler. Ürün satışı yapmaz. Veri kaybı penceresi tartışmasını veri kaybı penceresi ve DRaaS tasarımı yazısında, hizmet modelinin sınırlarını DRaaS nedir içinde ele aldık.
Hızlı Özet
Toparlanma süresi hedefi bir hedef olarak değerlendirilir, taahhüt değildir ve yedek ortama geçiş tatbikatı ile doğrulanmalıdır. Teknik panelde sanal makine açılması ile kullanıcının oturum açması aynı an değildir. Kesin sayı yalnızca imzalı sözleşme ve sağlayıcı dokümantasyonu ile netleşir.
Yedek ortama geçiş tatbikatı, bu hedefin gerçekçi olup olmadığını ölçmenin en güvenilir yoludur. Tatbikat raporu olmadan slayt üzerindeki dakika değeri operasyon ekibine güven vermez.
Leon-X Bulutistan altyapısının sahibi değildir. Toparlanma ve veri kaybı penceresi hedeflerini iş önceliğiyle eşleştirir, DRaaS tatbikat planını ve runbook adımlarını koordine eder.
İçindekiler
- Toparlanma Süresi Hedefi Ne Ölçer
- Toparlanma Süresi ile Veri Kaybı Penceresi Ayrımı
- Yedek Ortama Geçiş Tatbikatında Süre Nereden Başlar
- Süreyi Uzatan Operasyon Katmanları
- DRaaS Ortamında Tatbikat Senaryoları
- Tatbikat Raporunda Minimum Kayıtlar
- Yaygın Yanlış Anlamalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Pexels, veri merkezinde sunucu altyapısı.
Toparlanma Süresi Hedefi Ne Ölçer
Toparlanma süresi hedefi iş sürekliliği dilinde zaman boyutudur. Soru şudur. Kesinti başladıktan sonra hangi saatte kullanıcı tekrar iş yapabilir? Cevap yalnız sanal makine boot süresi değildir. Uygulama servislerinin ayağa kalkması, veritabanı tutarlılık kontrolü ve erişim yollarının açılması da süreye girer.
DRaaS modelinde ikincil site önceden boyutlandırılmış compute ve depolama sunar. Yedek ortama geçiş kararı verildiğinde replike edilmiş iş yükleri başlatılır. Panelde yeşil durum görünse bile arka uç bağımlılıkları gecikmiş kopyada kalırsa kullanıcı hata alır. Bu nedenle hedef, uçtan uca iş akışı üzerinden tanımlanmalı ve hedef olarak değerlendirilir.
Ankara iş sürekliliği rehberi BCP ile teknik kurtarma katmanını ayırır. Toparlanma süresi tartışması teknik katmanda kritik uygulama listesi ve bağımlılık haritasıyla başlar.
Toparlanma Süresi ile Veri Kaybı Penceresi Ayrımı
Veri kaybı penceresi hangi saate kadar olan veriyi geri getirmek zorunda olduğunuzu tarif eder. Toparlanma süresi hedefi ise sistemin ne kadar sürede tekrar hizmet vereceğini tarif eder. İki satır sözleşmede birbirinin yerine yazıldığında yönetim yanlış risk alır.
Örnek senaryo düşünün. Replikasyon sık çalışıyor ancak DNS güncellemesi ve TLS kimlik belgesi doğrulaması uzun sürüyor. Veri tarafı dar pencerede kalırken kullanıcı erişimi gecikebilir. Tatbikat her iki boyutu ayrı ölçmelidir.
BaaS kapsamı yalnızca kopyayı saklar. Geri dönüş süresi indirme ve kurulum adımlarına bağlıdır. DRaaS çalışan sistem beklentisi taşır. Karıştırıldığında hem maliyet hem süre beklentisi kayar.
Yedek Ortama Geçiş Tatbikatında Süre Nereden Başlar
Tatbikat planında başlangıç ve bitiş noktası yazılı olmalıdır. Ekipler arasında farklı tanım kullanıldığında ölçüm karşılaştırılamaz.
| Aşama | Örnek başlangıç tetikleyici | Ölçülen çıktı |
|---|---|---|
| Karar | olay ilanı veya planlı test onayı | karar saati ve sorumlu |
| Teknik geçiş | replike VM başlatma komutu | ilk ping veya servis portu |
| Uygulama doğrulama | test kullanıcı oturumu | işlevsel işlem tamamlandı |
| İş onayı | iş birimi kontrol listesi | hizmet yeniden açık kabulü |
Tablodaki süreler örnek çerçevedir. Sayı taahhüdü bu yazıda verilmez. Her satır yönetim onayı ile hedef olarak değerlendirilir.
Tatbikat sırasında ölçülen süre, yazılı hedeften uzunsa kök neden analizi yapılır. Kısa görünse bile üretim trafiği olmadan ölçüldüğü not edilir.
Süreyi Uzatan Operasyon Katmanları
Replikasyon hızlı olsa bile aşağıdaki adımlar toparlanma süresini uzatır.
DNS ve trafik yönlendirme. TTL değerleri ve sağlayıcı paneli değişiklik süresi kullanıcı tarafında gecikme üretir. Yedek ortama geçiş öncesi düşük TTL planı yazılmalıdır.
Kimlik ve erişim. Active Directory, LDAP veya bulut kimlik servisi ikincil ortamda senkron değilse oturum açılamaz. Federasyon hataları tatbikat raporunda ayrı satır olarak yer almalıdır.
Uygulama başlangıç sırası. Veritabanı önce, ara katman sonra, ön yüz en son açılmalıdır. Runbook sırası ters ise servisler birbirini bekler.
Manuel onay adımları. Bazı kurumlar yedek ortama geçiş için üst yönetim onayı ister. Bu sürenin teknik hesaba dahil edilip edilmeyeceği önceden cevaplanmalıdır.
Üretime dönüş. Geri dönüş planı ayrı bir süre çizelgesi gerektirir. Yalnız ikincil siteye geçiş ölçülüp geri dönüş ihmal edilirse yıllık tatbikat eksik kalır.
Yedekleme geri yükleme tatbikatı kontrol listesindeki disiplin DRaaS yedek ortama geçiş testi için de geçerlidir. Panel rengi kanıt değildir.
DRaaS Ortamında Tatbikat Senaryoları
Planlı tatbikat üretimi etkilemez. Kontrollü pencerede seçili uygulamalar ikincil ortamda açılır, iş birimi doğrulama yapar, ardından üretime dönüş uygulanır. Ölçülen süre bu döngünün tamamını kapsamalıdır.
Plansız tatbikat simülasyonu daha gerçekçidir ancak operasyon riski taşır. Ağ kesintisi veya depolama yalıtımı rol oyunu ile tetiklenir. Karar zinciri ve iletişim kanalları da test edilir.
Kısmi geçiş yalnızca bir uygulama grubunu kapsar. Tam site geçişi tüm kritik listeyi içerir. Toparlanma süresi hedefi uygulama sınıfına göre farklı yazılabilir ve hedef olarak değerlendirilir. Tek kurumsal dakika değeri nadiren tüm portföye uyar.
Leon-X bu senaryoları gereksinim toplantılarında yapılandırır. Altyapı sahibi değildir. Paket kapsamı proje öncesinde doğrulanır.
Tatbikat Raporunda Minimum Kayıtlar
Denetim ve iç iyileştirme için rapor şablonu standart tutulmalıdır.
- Olay veya test kimliği, tarih ve sorumlu ekip
- Kapsamdaki VM veya servis adları
- Geçiş başlangıç ve işlevsel doğrulama bitiş zaman damgaları
- Ölçülen toparlanma süresi ve yazılı hedefin karşılaştırması
- DNS, kimlik ve uygulama katmanında yaşanan gecikmeler
- Veri tutarlılık kontrolü sonucu
- Üretime dönüş süresi ve senkronizasyon durumu
- Açık aksiyon maddeleri ve sonraki tatbikat tarihi
Rapor yönetime özet, teknik ekibe detaylı ek olarak sunulabilir. Sayısal hedef taahhüdü yalnızca imzalı sözleşmede yer alır.
Yaygın Yanlış Anlamalar
Replikasyon gecikmesi düşükse toparlanma süresi de düşüktür. Veri kanalı hızlı olabilir, uygulama ve ağ adımları yavaş kalabilir.
Sanal makine açıldı, süre tamamlandı. Kullanıcı işlemi yapılmadan ölçüm kapanmamalıdır.
Yıllık yedekleme testi DRaaS yedek ortama geçiş yerine geçer. BaaS geri yükleme ile çalışan sistem geçişi farklı senaryolar üretir.
Tüm sistemler aynı toparlanma hedefiyle korunur. Lisans ve kota nedeniyle liste sınırlı kalır. Listeye eklenmeyen servisler kapsam dışıdır.
DRaaS alındı, tatbikat gereksiz. Paket kapasitesi tanımlıdır ancak runbook ve bağımlılıklar kuruma özeldir. Tatbikat olmadan hedef kanıtlanmış sayılmaz.
Kontrol Listesi
- Kritik uygulama envanteri ve bağımlılık haritası güncel
- Her sınıf için toparlanma süresi hedefi yönetimce onaylı
- DRaaS kapsam listesi VM veya servis adıyla eşleşiyor
- Yedek ortama geçiş ve üretime dönüş runbook sürüm numarası tatbikatla uyumlu
- DNS TTL ve kimlik belgesi geçerlilik kontrolleri plana yazılı
- Yıllık tatbikat takvimde ve rapor şablonu hazır
- DRaaS seçeneği gereksinimlerle karşılaştırıldı
Leon-X ile Sonraki Adım
Leon-X iş önceliklerinizi toparlanma süresi hedefleriyle eşleştirir. DRaaS, BaaS ve yerel replikasyon seçeneklerini yan yana değerlendirir, yedek ortama geçiş tatbikatı ve runbook adımlarını operasyon ekibinizle koordine eder. Keşif için iletişime geçin.
Sık Sorulan Sorular
Hedef değerini kim belirler?
İş birimi etki analizi ve BT teknik gerçekliği birlikte yazılır. Nihai satır yönetim onayı ile hedef olarak değerlendirilir. Sayısal taahhüt sözleşmede netleşir.
Tatbikat ne sıklıkla yapılmalıdır?
Kritiklik sınıfına göre değişir. Yılda en az bir planlı test çoğu kurum için başlangıç çerçevesidir. Sıklık iç politika ve düzenleyici gereksinimlerle uyumlu olmalıdır.
Ölçülen süre hedeften uzunsa ne olur?
Kök neden analizi, runbook güncellemesi ve gerekirse mimari iyileştirme planı çıkarılır. Hedef revizyonu yönetim kararıdır.
Üretime dönüş tatbikatı zorunlu mudur?
İkincil ortamda çalışmak üretim riski taşır. Geri dönüş adımları test edilmezse senkronizasyon gecikmesi birikir.
Sonuç
Toparlanma süresi hedefi, kesinti sonrası iş akışının ne zaman devam edebileceğini tarif eder ve yedek ortama geçiş tatbikatı ile doğrulanmalıdır. DRaaS teknik kapasite sunar, DNS, kimlik, uygulama sırası ve onay zinciri süreyi belirler. Veri kaybı penceresi ile toparlanma süresini ayrı satırlarda tutun, ölçümü uçtan uca işlevsel doğrulamayla bitirin. Leon-X altyapı sahibi değildir, tatbikat planını ve gereksinim eşleştirmesini koordine eder.
Kaynaklar
- Leon-X iç claim ledger,
docs/research/leonx-seo-claim-evidence.md - DRaaS ürün sayfası,
/solutions/bulutistan/draas
