2025 Eylül’de İzmir merkez ofisteki bir sigorta şirketinin kendi datacenter’ında trafo arızası + jeneratör start fail kombinasyonu yaşandı. Sonuç: 12 saatlik tam blackout. Tek farkla: 18 dakika sonra tüm sistemler Ankara’daki DR site’tan çalışıyordu. Müşteri portali çalışıyor, ödemeler geçiyor, agent’lar poliçe yazabiliyordu. Bu yazı, o günden ders niteliğinde notlar; DRaaS’ın “broşürde yazıyor” değil “gerçekten işe yarıyor” olduğunu gösteren saha vakası.

RPO ve RTO: Önce Bunları Doğru Tanımla

Terim	Anlamı	Sigorta şirketi hedefi
RPO (Recovery Point Objective)	Maksimum kabul edilebilir veri kaybı süresi	5 dakika
RTO (Recovery Time Objective)	Maksimum sistem ayakta olmama süresi	30 dakika
MTTR (Mean Time To Recover)	Ortalama kurtarma süresi	15 dakika hedef
MTBF (Mean Time Between Failures)	Hatalar arası ortalama süre	—

RPO/RTO ne kadar düşükse maliyet o kadar yüksek. Sigorta şirketi için 5 dk RPO + 30 dk RTO yaklaşık aylık $4.200 ekstra DRaaS maliyetiyle karşılandı.

Mimari: Active-Standby (Warm) Setup

İki temel DR mimarisi:

• Active-Active: İki site de aktif, trafik load balancer ile dağıtılıyor. Failover seamless, RTO ~~saniyeler. Maliyet 2x.
• Active-Standby: Primary aktif, secondary “warm standby” — VM’ler hazır ama kapalı. Failover ~~10-30 dk. Maliyet ~~1.3x.

Sigorta şirketi için Active-Standby seçildi (cost optimum, RTO 30 dk yeterli).

Mimari diagram:

İzmir DC (Primary)              Ankara DC (DR Site)
  ┌──────────────────┐            ┌──────────────────┐
  │  Web/API VMs     │  → CDP →   │  Web/API VMs     │ (kapalı)
  │  App VMs         │  → CDP →   │  App VMs         │ (kapalı)
  │  PostgreSQL      │  → SR →    │  PostgreSQL      │ (read replica)
  │  File Server     │  → CDP →   │  File Server     │ (kapalı)
  │  Redis           │  → CDP →   │  Redis           │ (kapalı)
  │  Object Storage  │  ↔ MR ↔    │  Object Storage  │ (active replica)
  └──────────────────┘            └──────────────────┘
       │                                  │
       └─────── Cross-Connect 10Gbps ─────┘
       
CDP = Continuous Data Protection
SR  = Streaming Replication
MR  = Multi-region Replication

Replikasyon Teknolojileri

Her workload için doğru teknoloji:

• VM disk: Veeam Backup & Replication ile CDP — değişiklikler sürekli replike edilir, RPO <5 dk.
• PostgreSQL: Native streaming replication, asynchronous mode. RPO ~~5-15 saniye.
• Redis: Sentinel + replica. RPO ~~saniyeler.
• Object storage: CloudSpark S3 multi-region replication, RPO ~~30 sn.
• File server: DFS-R (Windows) veya rsync cron (Linux). RPO 5-15 dk.

Sigorta şirketi PostgreSQL veritabanı 1.2 TB. İlk seed (initial replication) 4 saat sürdü (10 Gbps cross-connect üzerinden). Sonra delta replication sürekli, anlık.

Failover Prosedürü: Runbook

DR olayında stres yüksektir, runbook olmazsa unutulur. Sigorta şirketinde dökümante edilmiş runbook:

1. 0:00 – Tespit: Monitoring tool primary site’ı down olarak işaretler. SOC ekibi 5 dakika içinde durumu doğrular (geçici mi, gerçek DR mi?).
2. 0:05 – Karar: Operasyon yöneticisi failover kararını verir. CTO bilgilendirilir.
3. 0:07 – PostgreSQL promotion: DR site’taki standby instance master’a promote edilir. Streaming replication kesilir, write kabul etmeye başlar.
4. 0:09 – VM start: DR site’taki “warm standby” VM’ler başlatılır (Veeam orchestration ile tek tıkla). Sıraya göre: database → app server → web server. Toplam ~~6 dakika.
5. 0:15 – Health check: Otomatik smoke test (sentetik kullanıcı login, poliçe arama, ödeme test). Sonuç temiz ise devam.
6. 0:17 – DNS failover: Public DNS A record DR site IP’ye değiştirilir (TTL 60 sn). CDN edge cache invalidate.
7. 0:18 – Trafik DR’da: Kullanıcı trafiği DR site’a akmaya başlar. Real-time monitor.
8. 0:30 – İletişim: Müşteri ve içe iletişim mesajı: “Sistemler DR site’ta çalışıyor, hizmette kesinti yok.”

Toplam: 18 dakika. Hedef RTO 30 dk altında.

Failback: Primary Geri Geldikten Sonra

DR olayı kapandıktan sonra (primary site geri geldiğinde) failback yapılır. Acele edilmemesi gereken kısım:

1. Primary site’ın stabilitesi 24 saat gözlemlenir.
2. DR’da biriken yeni veri primary’ye reverse-replicate edilir.
3. Replication tutarlılığı doğrulandıktan sonra, planlı bakım penceresinde DNS primary’ye döner.
4. Original replication direction restore edilir.

Sigorta şirketinde failback 3 gün sonra cumartesi gece yapıldı, 22 dakika sürdü.

Drill Disiplini: Teori vs Pratik

DR planının test edilmemesi en sık ölümcül hata. Sigorta şirketinde drill takvimi:

• Yıllık 1 kez: Tabletop exercise (sadece yöneticiler, senaryo simülasyonu).
• Yıllık 2 kez: Partial failover (1-2 servis, kontrollü).
• Yıllık 1 kez: Full failover drill (planlı bakım penceresinde, gerçek failover).

Bu 2025 olayı sayesinde drill’in ne kadar değerli olduğu kanıtlandı: ekip runbook’a alışıktı, panik yapılmadı, prosedür adım adım uygulandı.

Maliyet Analizi

Kalem	Aylık (USD)
DR site VM’ler (warm standby)	1.800
Storage replikasyon (1.2 TB DB + 800 GB diğer)	620
Cross-connect 10 Gbps (İzmir-Ankara)	1.200
Veeam B&R Enterprise lisansı	380
Object storage replication	180
Toplam	~4.180

2025 olayında 12 saatlik kesinti olsaydı kaybedilen iş tahmini: ~~340.000 TL gelir + müşteri güveni kaybı + KVKK ihlali riski. DR yatırımının yıllık maliyeti karşılığını bir incident’te ödedi.

Sahada Düşülen Üç Tuzak

1. Drill yok: “DR’mız var, yeter” diyenler ilk gerçek olayda 4 saatlik recovery yaşar.
2. Identity / DNS atlanmış: VM’ler DR’da açıldı ama kullanıcılar AAD’a erişemiyor (AAD primary site’a bağlı). Identity infrastructure’ı da DR’a koy.
3. License binding’i düşünmemek: Bazı uygulamalar MAC address’e bağlı lisans kullanıyor. Failover sonrası uygulama “lisans hatası”. Vendor ile önceden talkım.

Sonuç: DR Bir Sigorta Polisi Gibi

DRaaS’ı “olur da bir gün” diye yapmak; gerçek DR olayında “iyi ki yapmıştık” diye sevinmek. Tek bir gerçek incident DR yatırımının yıllarca olan maliyetini karşılar. Asıl iş kurmak değil, drill etmek + güncel tutmak + ekibi hazır tutmak.

CloudSpark olarak BIA (Business Impact Analysis), RPO/RTO planlama, DRaaS implementasyonu (Veeam, Acronis, Zerto), drill yönetimi ve runbook hazırlama konularında end-to-end danışmanlık veriyoruz.