Felaket Kurtarma Projesinde Teknik Kurulumdan Önce Sorulması Gereken Sorular

Felaket kurtarma toplantıları çoğu zaman kaç sanal makinenin replike edileceğiyle başlıyor. İlk sorduğum soru ise hangi iş sürecinin önce dönmesi gerektiğidir. Çünkü yüz sunucuyu yanlış sırada açmak, üç kritik hizmeti doğru sırada açmaktan daha az değerli olabilir.

22 Şubat 2026 tarihli çalışmada teknik envanteri iş etkisi analiziyle eşleştirdik. Uygulama sahibi, altyapı ekibi ve yönetim aynı “kritik” kelimesine farklı anlam verdiği için kararları ölçülebilir süre ve kabul edilebilir veri kaybıyla ifade ettik.

Atölyelerde “Bu sistem duramaz” cevabını doğrudan kabul etmedik; kesintinin bir saat, bir gün ve üç gün sonraki etkisini ayrı sorduk. Finansal kayıp tek ölçüt değildi. İş güvenliği, yasal bildirim, müşteri taahhüdü, üretim planı ve biriken manuel işlem yükü de değerlendirildi. Ayrıca geçici manuel yöntem gerçekten uygulanabilir mi, gereken form ve yetki çevrimdışı bulunabilir mi diye kontrol ettik. Bu görüşmeler bazı sistemlerin beklenenden daha kritik, bazılarının ise birkaç gün kontrollü biçimde bekleyebileceğini gösterdi. Sonuçta DR kapasitesi eşit dağıtılmadı; işin kritik yoluna ve doğrulanmış bağımlılıklara yönlendirildi.

Sorunun ortaya çıkışı

Çok sayıda uygulama DR kapsamına alınmak isteniyor, fakat iş önceliği ve bağımlılık bilgisi bulunmuyordu. Her sistem kritik işaretlenince kapasite ve proje maliyeti gerçekçi olmaktan çıktı.

BIA atölyelerinde süreç kesintisinin zaman içindeki etkisi, manuel çalışma alternatifi, veri kaybı toleransı ve mevzuat yükümlülüğü soruldu. Teknik ekip bu sonuçları servis ve altyapı bağımlılıklarına çevirdi.

İlk belirtiler ve yanlış varsayımlar

Uygulamanın açılması hizmetin dönmesi sayılıyordu. Kimlik, ağ, DNS, veri tabanı, dosya paylaşımı ve dış entegrasyon çalışmadan uygulama kullanılamaz. Her sistem için sıfıra yakın RPO/RTO istemek de teknik ve mali gerçekliği göz ardı eder.

DR lokasyonunun her senaryoda kullanılabilir olacağı varsayılamaz. Aynı kimlik bağımlılığı, ortak telekom güzergâhı veya bölgesel olay iki ortamı birden etkileyebilir. Personel erişimi ve karar yetkisi de tasarımın parçasıdır.

Teknik analiz

Servis kataloğu sunucu envanteriyle eşleştirildi. Her servis için sahip, kullanıcı grubu, veri kaynağı, upstream ve downstream bağımlılık, RPO, RTO, minimum kapasite ve doğrulama adımı yazıldı. Kritik yol diyagramı kurtarma dalgalarını belirledi.

Kapasite hesabı normal zirveyi kopyalamak yerine felaket anındaki minimum kabul edilebilir hizmete göre yapıldı. Ağ adresleme, isim çözümleme, sertifika, lisans ve üçüncü taraf izinleri test sorularına eklendi.

Uygulanan çözüm veya önerilen mimari

Servisler üç kurtarma dalgasına ayrıldı. Runbook teknik komut listesinden ibaret tutulmadı; karar, iletişim, bağımlılık kontrolü, iş birimi testi ve normale dönüş adımlarını içerdi.

Masa başı tatbikatla belirsiz roller bulundu, ardından izole teknik test yapıldı. Test sonucu gerçek RTO, veri noktası, başarısız bağımlılık ve düzeltme sahibiyle kaydedildi. Mimari bu ölçümlere göre güncellendi.

Alternatifler ve karar gerekçesi

Aktif-aktif, sıcak bekleme, pilot light ve yedekten geri yükleme farklı maliyet ve süre profillerine sahiptir. En pahalı model her iş yükü için en doğru model değildir. Uygulama mimarisi ve iş etkisi seçimde belirleyicidir.

Karma yaklaşım seçildi: en kritik servisler hazır kapasiteye, toleranslı servisler yedekten dönüşe bağlandı. Karar üretici özelliklerinden önce ölçülebilir iş hedefleriyle gerekçelendirildi.

Güvenlik ve operasyonel riskler

DR ortamı daha seyrek kullanıldığı için yama ve erişim açısından zayıf kalabilir. Üretimle aynı güvenlik tabanı, ayrıcalık kontrolü ve izleme uygulanmalıdır. Replikasyon zararlı değişikliği taşıyabileceğinden temiz kurtarma noktası korunmalıdır.

Eski iletişim listesi ve tek kişiye bağlı runbook tatbikatta başarısız olur. Roller yedeklenmeli, çevrimdışı erişilebilir kopyalar tutulmalı ve üçüncü tarafların kriz yükümlülükleri sözleşmede doğrulanmalıdır.

Çıkarılan Dersler

Kontrol Listesi