Disaster recovery (DR) plan’ı her şirketin bir yerinde var. 50-sayfalık PDF, runbook, step-by-step instructions. Ama gerçek bir incident’te test edildiğinde %70’i çalışmıyor.
Birkaç projede DR plan’ı kurguladım, ikisinde gerçek incident’te test ettim. Bu yazıda yaptığım hataları ve öğrendiklerimi anlatacağım.
Hata 1: Plan test edilmemiş
En yaygın. DR plan yazılıyor, kağıtta kalıyor. Gerçek test yapılmıyor.
Gerçek incident’te:
- Runbook’ta written command çalışmıyor (syntax değişmiş)
- Backup restore beklenen sürede tamamlanmıyor
- Recovery server’ın credentials’ları expired
- DNS TTL’i too high, propagation saatler sürüyor
- Team kişileri rotation’da, runbook’u ilk defa görüyor
Fix: Quarterly DR drill. Production’a yakın staging environment. Gerçekçi simulation.
Hata 2: RTO ve RPO belirsiz
RTO (Recovery Time Objective): Downtime ne kadar tolerable? (“4 saat”)
RPO (Recovery Point Objective): Data loss ne kadar tolerable? (“15 dakika”)
Bu ikisi framework’ün temel’i. Belirsizken:
- Backup frekansı belirsiz
- Replica stratejisi belirsiz
- Investment level belirsiz
Fix: Business ile konuş. “8 saat downtime OK” mı “2 saat’te up olmalı” mı? RPO “24 saat” vs “15 dakika” tamamen farklı architecture.
Hata 3: Backup test edilmemiş
Backup tutuyorsun ama restore etmeyi denemedin.
Gerçek test’te ortaya çıkanlar:
- Backup corrupt (silent failure)
- Restore script’i prod environment’ta çalışmıyor
- Backup decryption key unutulmuş
- Storage’a erişim permission’ı yok
- Backup incremental ama full restore mümkün değil
Fix: Ayda bir backup restore test. Staging environment’a restore, verify data integrity. Otomatize et.
Hata 4: Single point of failure (SPOF) gizli
Plan’ı yazarken obvious SPOF’lar handle edilmiş gibi görünüyor. Gerçek incident’te gizli SPOF’lar ortaya çıkıyor.
Example SPOF’lar:
- Tek CI/CD runner (prod deploy için gerekli ama DR’a dahil değil)
- Tek DNS provider (Cloudflare down olsa ne yapacaksın?)
- Tek certificate authority
- Tek secrets manager instance
- Tek monitoring provider
Fix: Dependency mapping. “Prod’u up tutmak için ne ne ne gerekli?” Her dependency için failover plan.
Hata 5: Team procedural knowledge gap
DR plan runbook halinde ama team içinde sadece 1-2 kişi detaylı biliyor. Bu 1-2 kişi tatilde veya ulaşılmıyor.
Fix:
- Rotation (herkes runbook’u çalıştırmış olsun)
- Documentation’ı step-by-step, assumption-free
- Game days quarterly
- On-call rotation’da new joiners pair eşliğinde
Hata 6: Communication plan eksik
Incident başladı. Kimi ararsın?
Typical gaps:
- Customer communication plan yok
- Stakeholder notification template yok
- Incident channel (Slack) prepared değil
- Status page otomatik update’lenmiyor
- Post-incident communication kim yapacak belirsiz
Fix:
- Incident communication ladder: Kim, kime, ne zaman.
- Template email’ler: Hazır. Duruma göre customize.
- Status page: Automated + manual. Real-time.
- Incident Slack channel: Pre-created.
- Customer communication: “We’re aware, investigating” → “ETA” → “Resolved” pattern.
Hata 7: Partial failure handling
DR plan “tam çöküş” için yazılmış. Ama %80 olasılıkla partial failure oluyor: bir servis down, diğerleri OK.
Partial failure’a tam fail-over uygulamak overshoot. Additional outage yaratıyor.
Fix:
- Graduated response. Partial failure için limited action. Full failure için DR plan.
- Service-level failover. Tek servisi yedekten getir, cluster rest çalışıyor.
- Decision framework. “Full DR trigger şartları: X, Y, Z olmadıkça graduated response.”
Hata 8: Post-incident review atlanıyor
Incident resolved. Team relief, “geçti bitti”. Blameless postmortem yapılmıyor.
Bu adım kritik:
- Root cause analysis
- Contributing factors
- What went well
- What could improve
- Action items (tracked to completion)
Postmortem’siz incident tekrar etme riski yüksek.
Fix: Her incident için postmortem zorunlu (major’lerde). Template:
- Timeline (what happened when)
- Impact (customer, business, technical)
- Detection (how discovered)
- Resolution (what fixed it)
- Root cause (5 whys)
- Action items (prevent + detect + mitigate)
Hata 9: Recovery = restore eşitliği
Recovery sadece data restore değil. Full service recovery:
- Data integrity check
- Dependency service restart ordering
- Cache warming (cold cache = slow performance)
- User session handling (lost sessions vs persistent)
- Monitoring re-enable
- Alerting silencing reset
- Customer communication update
Fix: Checklist-based recovery. “Restore completed” sadece ilk item.
Hata 10: Infrastructure-as-code yok
DR scenario’da secondary region’a spin up. Manual infrastructure create uzun sürüyor.
IaC (Infrastructure-as-Code):
- Terraform, CloudFormation, Pulumi
- Primary + secondary region template
- “terraform apply” ile fresh environment
Son proje’de secondary region spin up 4 saatten 30 dakikaya düştü. IaC sayesinde.
Fix: Critical infrastructure IaC’de. Manual setup discouraged.
Drill planning
Quarterly DR drill’in iyi setup’ı:
Pre-drill:
- Scenario belirle (specific failure)
- Participant list (on-call team + support)
- Time window (saatler)
- Success criteria (RTO met? RPO met? Communication ran? Documentation works?)
During drill:
- Real-time observation. Team ne yapıyor, neden?
- Stopwatch. RTO measurement.
- Note gaps. Runbook’ta olmayan steps.
Post-drill:
- Debrief session
- Findings document
- Action items tracked
- Runbook updates
Her quarter bir scenario. 12 ayda farklı failure modes test.
Budget for DR
DR maliyetli. Ama gerçek incident’in cost’undan çok daha az.
DR budget items:
- Secondary region infrastructure (idle %30-50 of primary cost)
- Backup storage (aylık maliyet)
- Monitoring tool’lar (paid tier)
- DR testing time (team hours)
- Training (workshops, simulation)
Incident cost estimate:
- Downtime × revenue/hour
- Customer trust loss
- Team overtime + recovery
- Regulatory penalties (compliance)
Balance: her şey yedekli ≠ practical. “Tolerable downtime” framework’ünde budget.
Cloud-specific considerations
AWS, GCP, Azure outage’ları oluyor. “Cloud reliability” infinite değil.
Multi-region strategy:
- Same cloud, different region (AWS eu-west-1 + eu-west-2)
- Multi-cloud (AWS + GCP)
- Hybrid (cloud + on-prem backup)
Complexity exponentially artıyor. Most teams single-region multi-AZ yeter.
Sonuç
DR plan kağıtta güzel görünüyor. Gerçek test’te problem’ler ortaya çıkıyor. 10 yaygın hata: test edilmemiş plan, belirsiz RTO/RPO, restore test edilmemiş, gizli SPOF, knowledge gap, communication eksik, partial failure, postmortem atlama, recovery ≠ restore, IaC eksik.
Quarterly drill + blameless postmortem + continuous improvement. Bu disiplinle DR plan gerçekten çalışıyor.
İlk drill painful olacak. Sorun ortaya çıkacak. İyi haber: production incident’te değil, controlled environment’ta.