Bir işletmenin buluta geçmesi, kritik uygulamalarının her koşulda çalışacağını garanti etmez. Yanlış bir erişim kuralı, başarısız bir güncelleme, silinen bir tablo veya kesilen bağlantı aynı sonucu doğurabilir: çalışanlar işini tamamlayamaz, müşteriler hizmete ulaşamaz. Bulutta felaket kurtarma planı, bu olaylardan sonra hangi hizmetin, hangi verilerle, hangi sırada geri getirileceğini belirleyen operasyon planıdır.
CieloSync olarak konuyu yalnızca ikinci bir sunucu bulundurmak üzerinden ele almıyoruz. İyi bir planın başlangıç noktası, işletmenin kabul edebileceği kaybı anlamaktır. Ardından teknik mimari, sorumlular, geri dönüş adımları ve test senaryoları bu ihtiyaca göre tasarlanır. Aşağıdaki rehber, kendi ortamınızı değerlendirirken kullanabileceğiniz bir çalışma çerçevesi sunar.
1. Önce işin ne kadar bekleyebileceğini belirleyin
RTO, bir hizmetin kesinti sonrasında ne kadar sürede geri döndürülmesinin hedeflendiğini; RPO ise zaman açısından kabul edilebilir veri kaybını ifade eder. Örneğin dört saatlik RTO ile on beş dakikalık RPO aynı şey değildir: ilk hedef yeniden çalışmaya başlama süresini, ikincisi geri dönülen verinin ne kadar eski olabileceğini anlatır. Bu ayrım ve daha sıkı hedeflerin maliyetle ilişkisi Google Cloud felaket kurtarma planlama rehberinde de açıklanır.
Bu değerleri bütün sunuculara aynı şekilde vermek yerine iş süreci bazında tartışın. Depodaki sevkiyat uygulaması, aylık yönetim raporu ve kurumsal tanıtım sitesi farklı öncelikler taşıyabilir. “Hiç veri kaybetmeyelim” şeklindeki genel bir beklenti yerine hangi kayıtların yeniden oluşturulabileceğini, hangi işlemlerin ertelenemeyeceğini ve manuel çalışmanın ne kadar sürdürülebileceğini konuşun. Son kararı yalnızca IT ekibi vermemeli; ilgili iş biriminin de hedefleri sahiplenmesi gerekir.
2. Sunucu listesinden bağımlılık haritasına geçin
Bir uygulamanın sanal makinesini açmak, hizmetin geri geldiği anlamına gelmez. Uygulama; veritabanına, kimlik sağlayıcısına, dosya paylaşımına, DNS kaydına, lisans servisine veya başka bir API’ye ihtiyaç duyabilir. Bu nedenle kurtarma planında yalnızca cihaz adları değil, bir kullanıcının işlemini tamamlaması için gereken bütün bileşenler bulunmalıdır.
Her kritik hizmet için kısa bir hizmet kartı oluşturun: iş sahibi, teknik sorumlu, veri konumu, erişim yöntemi, bağımlılıklar, son başarılı kurtarma testi ve doğrulama adımı. Tek bir çalışanın bildiği parola, süresi geçmiş sertifika veya yalnızca şirket içindeki bir klasörde duran kurulum dosyası kurtarmayı durdurabilir. Planın kendisi de asıl ortam erişilemezken ulaşılabilir olmalıdır.
3. Yedekleme, replikasyon ve yüksek erişilebilirliği ayırın
Yedekleme belirli bir zamandaki veriye dönmeyi sağlar. Replikasyon verinin başka bir sisteme aktarılmasına yardımcı olur. Yüksek erişilebilirlik ise belirli bileşen arızalarında hizmetin sürmesini hedefler. Bunlar birbirini tamamlar; tek başına herhangi birinin varlığı bütün felaket senaryolarının karşılandığını göstermez.
Örneğin yanlışlıkla silinen kayıtlar replikayla diğer ortama da taşınabilir. Aynı yönetici hesabının hem üretimi hem yedekleri silebildiği bir yapıda ikinci kopya beklenen korumayı sağlamayabilir. Bu nedenle yedeklerin erişim yetkileri, silme koruması, şifreleme anahtarları ve geri yükleme yöntemi birlikte değerlendirilmelidir. Değiştirilemezlik özellikleri kullanılıyorsa bunların kapsamını ve saklama kilitlerinin nasıl çalıştığını kullanılan ürün özelinde doğrulayın.
4. Kurtarma modelini uygulamaya göre seçin
Her iş yükü için sürekli çalışan ikinci bir üretim ortamı kurmak gerekli olmayabilir. Daha uzun kesintiyi tolere edebilen bir uygulama yedekten kurulabilirken, kritik bir işlem platformu önceden hazırlanmış kapasite ve daha sık veri aktarımı isteyebilir. Seçim yapılırken yalnızca aylık kaynak bedeline değil, kurtarma sırasında gereken insan emeğine ve hazırlık süresine de bakın.
- Yedekten yeniden kurulum: Kurulum dosyaları, altyapı tanımları ve veriler kullanılarak ortam yeniden hazırlanır. Geri yükleme süresi özellikle ölçülmelidir.
- Hazır bekleyen temel altyapı: Bazı bileşenler önceden hazırlanır; olay sırasında kapasite tamamlanır ve uygulama devreye alınır.
- Çalışmaya hazır ikinci ortam: Daha fazla bileşen güncel tutulur; işletim ve veri tutarlılığı ihtiyacı da buna göre büyür.
Bu modelleri bir ürün paketi gibi değil, tasarım seçenekleri olarak değerlendirin. Kota, lisans, bölgesel kapasite ve ağ izinleri olay anında ilk defa karşılaşılacak ayrıntılar olmamalıdır.
5. Ayrı lokasyon tek başına bağımsızlık sağlamaz
İstanbul ve Ankara gibi farklı lokasyonların değerlendirilmesi, risk dağıtımının bir parçası olabilir. Ancak iki ortamın aynı kimlik hesabına, aynı internet çıkışına veya tek bir yönetim sistemine bağımlı olması ortak arıza alanları yaratabilir. Fiziksel ayrılık kadar yönetim, bağlantı ve yetkilendirme bağımsızlığını da inceleyin.
Verinin nerede tutulduğu, kimler tarafından erişilebildiği ve başka bir lokasyona hangi koşullarla aktarıldığı ayrıca belgelenmelidir. Teknik tasarımın uygunluğu ile sözleşmesel veya hukuki uygunluk ayrı incelemeler gerektirir. Bir lokasyon seçimi, diğer bütün yükümlülüklerin otomatik olarak karşılandığı anlamına gelmez.
6. Kurtarma adımlarını uygulanabilir bir akışa dönüştürün
Plan, olayın fark edilmesinden kullanıcıların yeniden çalışmasına kadar uzanmalıdır. Olayı kimin ilan edeceği, ikinci ortama geçiş kararını kimin vereceği ve iş birimlerine kimin bilgi ileteceği yazılmalıdır. Teknik adımların yanında her adımın başarı ölçütünü ve başarısız olduğunda izlenecek yolu da belirtin.
Örnek bir akış; olayın kapsamını doğrulama, etkilenen sistemleri güvenli biçimde ayırma, uygun geri dönüş noktasını seçme, bağımlılıkları hazırlama, uygulamayı başlatma ve iş işlemini doğrulama şeklinde ilerleyebilir. DNS değişikliği gerekiyorsa önbellek davranışı dikkate alınmalı; eski ve yeni ortamın aynı anda veri kabul etmesini önleyecek kurallar bulunmalıdır. Trafiği yönlendirmek ile veriyi tutarlı hâlde sunmak farklı kontrol noktalarıdır.
7. Testi “yedek başarılı” mesajıyla bitirmeyin
Bir tatbikatta yalnızca dosyanın geri açılması yeterli değildir. Yetkili bir test kullanıcısı oturum açabilmeli, örnek bir siparişi görüntüleyebilmeli ve gerekli entegrasyonun çalıştığını doğrulayabilmelidir. Test ortamı üretimde yanlış bildirim, fatura veya ödeme oluşturmamalıdır; dış entegrasyonlar kontrollü tutulmalıdır.
Kronometreyi teknik kurulum başladığında değil, senaryoda tanımlanan olayın başlangıcında çalıştırın. Bildirimin ulaşması, karar verilmesi, doğru kişinin bulunması ve verinin doğrulanması da toplam sürenin parçasıdır. Ölçülen sonucun hedefe uymadığı yerde yalnızca süreyi değiştirmek yerine darboğazın nedenini kaydedin.
Örnek çalışma: dağıtım şirketinin sevkiyat sistemi
Varsayımsal bir dağıtım şirketinde depo uygulaması, merkezdeki ERP ve taşıyıcı entegrasyonu birlikte çalışsın. Depo ekranı açıldığı hâlde taşıyıcı etiketi üretilemiyorsa iş süreci kurtarılmış değildir. Tatbikatta siparişin alınması, stok rezervasyonu, etiket çıktısı ve işlem kaydının kontrolü birlikte yapılmalıdır. Bunlar gerçek bir müşteri sonucu değil, planı nasıl sınayabileceğinizi gösteren örnek adımlardır.
İş birimi manuel sevkiyatla kısa süre devam edebiliyorsa bu alternatifin veri giriş ve mutabakat yöntemi de tanımlanabilir. Böylece teknik kurtarma sürerken işletmenin yapabilecekleri netleşir; sonradan sisteme girilecek kayıtların çift işlenmesi önlenir.
Başlangıç kontrol listesi
- Kritik hizmetlerin iş sahipleri ve kurtarma hedefleri yazılı mı?
- Kimlik, DNS, lisans ve entegrasyon bağımlılıkları kapsama alındı mı?
- Yedeklere erişim üretimden bağımsız biçimde sınırlandı mı?
- Geri yükleme ve işlev doğrulama süreleri ölçüldü mü?
- Asıl ortama geri dönüş ve veri mutabakatı planlandı mı?
- Tatbikat bulguları için sorumlu ve tamamlanma tarihi belirlendi mi?
CieloSync’in bulut çözümleri kapsamında ilk adım, ortamınıza uygun hedef ve sorumlulukları belirlemektir. Altyapınızı birlikte değerlendirelim; ikinci kopyanın varlığından çok, gerektiğinde işi nasıl yeniden başlatacağınızı konuşalım.