1. GİRİŞ

Disaster Recovery (DR) — felaket kurtarma — modern yazılım ve platform operasyonlarının kritik bir parçasıdır. DevOps perspektifinden bakıldığında DR, yalnızca yedekleme veya restore işlemlerinden ibaret değildir; uygulamanın tasarımından altyapı otomasyonuna, gözlemlenebilirlikten organizasyonel süreçlere kadar geniş bir alanı kapsayan bir disiplin gerektirir. Bulut dönüşümü, dağıtık mimariler ve sürekli entegrasyon/sürekli teslimat (CI/CD) uygulamaları, felaket kurtarma planlamasını hem daha kolay hem de daha karmaşık hale getirmiştir: kolay çünkü altyapıyı kodla tanımlayıp yeniden oluşturmak mümkün; karmaşık çünkü bağımlılık ağları, stateful veri ve dış sağlayıcılar yönetilmelidir.

Bu neden bugün önemli?

• Hizmet kesintileri doğrudan gelir, müşteri güveni ve yasal yaptırımlar ile sonuçlanabilir.
• Global altyapı bağımlılıkları, tedarik zinciri riskleri ve siber saldırılar DR planlarının gerekliliğini artırdı.
• DevOps ve SRE kültürü içinde hızlı iyileşme ve öğrenme odaklı post‑incident süreçleri işletme değerini direkt etkiler.

Kimler için önemli?

CTO, SRE, DevOps ekipleri, platform mühendisleri, güvenlik ve uyumluluk ekipleri, ürün sahipleri ve iş birimleri için felaket kurtarma stratejileri hayati öneme sahiptir. Finansal, sağlık veya kamusal hizmetler gibi yüksek uyumluluk gerektiren sektörlerde DR aynı zamanda regülasyon gerekliliklerini karşılamak için zorunludur.

Hangi problemleri çözer?

• Beklenmedik altyapı arızalarından hızlı kurtulma
• Veri kaybını minimize etme ve iş süreçlerini sürdürme
• Denetim ve uyumluluk için kanıt ve süreçler sağlama

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

• Disaster Recovery (DR): Hizmetin beklenmedik kesintilerinden sonra sistemi eski veya kabul edilebilir çalışma durumuna döndürme süreçleri ve araçları.
• Business Continuity (BC): İş süreçlerinin aksatılmadan sürdürülmesine yönelik stratejiler; DR BC'nin teknik bileşenidir.
• RTO (Recovery Time Objective): Hizmetin kabul edilebilir maksimum kesinti süresi.
• RPO (Recovery Point Objective): Kabul edilebilir maksimum veri kaybı süresi (ör. 15 dakika, 1 saat).
• Failover: Trafiğin veya işlemlerin birincil ortamdan ikincil (DR) ortama otomatik veya manuel olarak geçirilmesi.
• Failback: Birincil ortama hizmetleri geri taşıma süreci.

2.2 DR mimari kategorileri

• Cold standby: DR ortamı önceden hazırlanmaz; arıza durumunda altyapı oluşturulur. Maliyet düşük, RTO yüksek.
• Warm standby: Temel bileşenler çalışır ancak tam kapasiteyle değil; RTO orta seviyede.
• Hot standby / Active‑Passive: İkincil ortam sürekli güncel tutulur ve hızlı failover sağlar; maliyet daha yüksektir.
• Active‑Active: Hem birincil hem ikincil ortamlar üretimde çalışır; trafik bölünür. En düşük RTO ve RPO sağlar ama en karmaşık mimaridir.

3. NASIL ÇALIŞIR?

3.1 Sistem mimarisi — DR akışı

DR akışı tipik olarak şöyle işler: risk değerlendirmesi → RTO/RPO belirlenmesi → DR mimarisi seçimi (cold/warm/hot/active‑active) → veri replikasyonu ve konfigürasyon senkronizasyonu → otomasyon ve failover planları → test, tatbikat ve sürekli iyileştirme. Her adım teknik ve organizasyonel girdiler ister. Risk analizi; coğrafi, mali, regülasyonel ve tedarikçi risklerini içermelidir.

3.2 Bileşenler ve veri akışı

1. Veri replikasyonu: Synchronous (eş zamanlı) veya asynchronous (gecikmeli) replikasyon; trade‑off'lar RPO ve latency'ye göre seçilir.
2. Konfigürasyon yönetimi: IaC (Terraform, Pulumi) ve config management ile ortamlar tutarlı tutulur.
3. State management: Session state, cache ve database state'lerinin nasıl ele alınacağı planlanır (sticky session vs session store).
4. DNS ve trafik yönlendirme: Global load balancing, health checks ve DNS TTL stratejileri failover'ı etkiler.
5. Monitoring ve otomatik failover: Sağlam alarmlar ve guardrail'ler ile yalnızca gerçek sorunlarda otomatik failover tetiklenir.

3.3 Çalışma mantığı — otomasyon ve insan

DR otomasyonu RTO'yu azaltır fakat insan süreci tamamen ortadan kaldırmaz. Kritik doğrulama, iletişim ve exception kararlarında insan onayı gerekebilir. Otomasyonun güvenli olabilmesi için guardrail'ler, canary‑style failover ve rollback planları zorunludur. Ayrıca runbook'lar, playbook'lar ve iletişim planları net şekilde tanımlanmalıdır.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix — multi‑region resilience

Netflix gibi global hizmet sağlayıcılar, region bazlı dağıtımlar ile hizmeti coğrafi olarak çoğaltır. Active‑Active ya da active‑passive stratejilerle region arası trafik yönlendirilir, veri ve cache replikasyonu stratejileri ile performans korunur. Chaos engineering ile DR planları test edilir.

Uber — hızlı failover ve degradation

Uber gibi düşük latency gerektiren platformlar, kritik iş akışlarını degrade edilebilir hale getirir. Örneğin fiyat hesaplama veya bazı analitik pipeline'ları geçici olarak devre dışı bırakılarak temel dispatch fonksiyonalitesi korunur.

Amazon — AWS DR ve multi‑AZ stratejileri

AWS müşterileri genellikle multi‑AZ ve multi‑region replikasyon ile DR sağlar. Managed servislerin snapshot, replica ve cross‑region replication özellikleri DR planlarının temel taşlarındandır.

Stripe — finansal uyumluluk ve kayıtlı kanıt

Stripe benzeri fintech firmaları, transaction verilerinin immutable kayıtlarını tutar ve DR senaryolarında denetlenebilir kanıt sağlayabilecek süreçler kurar. RPO sıkı, RTO ise iş gereksinimine göre optimize edilir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• İş sürekliliği: DR ile kritik iş fonksiyonları süreklilik sağlar.
• Risk azaltma: Bölgesel arızalarda minimum etki ile operasyonun devamı mümkün olur.
• Uyumluluk: Denetimler için yapılandırılmış, test edilmiş DR süreçleri gereklidir.

Sınırlamalar

• Maliyet: Hot standby ve active‑active senaryolar yüksek maliyet getirir.
• Karmaşıklık: Veri tutarlılığı, bağımlılık yönetimi ve failover otomasyonunun karmaşıklığı yönetim zorluğu yaratır.
• Test gereksinimi: DR planları düzenli test edilmezse işe yaramaz; test etmek ise operasyonel zahmet gerektirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo DR yaklaşımlarını maliyet, RTO/RPO ve operasyonel karmaşıklık açısından karşılaştırır.

7. EN İYİ PRATİKLER

Production kullanımı

• RTO ve RPO'yu iş gereksinimleri ile hizalayın; stakeholder'larla net anlaşın.
• İaC kullanarak tüm ortamların sürümlenmesini sağlayın; DR ortamının birincil ortamla aynı kodla oluşturulabileceğinden emin olun.
• Failover otomasyonlarını guardrail'lerle birlikte uygulayın: canary failover, step scaling ve otomatik geri dönüş (auto rollback) stratejileri.
• DNS TTL'lerini ve global load balancer ayarlarını RTO hedefleriyle uyumlu planlayın; çok düşük TTL yanlış alarm riskini artırır.

Performans optimizasyonu

• Veri replikasyonunda bandwidth ve latency etkilerini izleyin; compression ve deduplication kullanın.
• Critical path'leri belirleyin ve bu yol üzerinde düşük RPO/RTO sağlayacak stratejiler uygulayın.
• Snapshot ve incremental backup stratejileri ile restore sürelerini azaltın.

Güvenlik

• DR ortamlarında da güvenlik kontrollerinin (IAM, network policy, encryption) aynı seviyede olduğunu doğrulayın.
• Backup verilerini şifreleyin ve erişim kontrollerini merkezi olarak yönetin.
• DR tatbikatlarında güvenlik ve veri bütünlüğü kontrollerini ayrı bir checklist olarak çalıştırın.

Ölçeklenebilirlik ve operasyon

• DR testlerini otomatikleştirin ve CI/CD pipeline'larına entegre edin; her büyük değişiklik sonrası DR testi yapın.
• Runbook ve playbook'ları versionlayın ve PR ile güncelleme sürecine dahil edin.
• Post‑incident öğrenme döngülerini (post‑mortem) zorunlu kılın ve kapatılan aksiyonları takip edin.

8. SIK YAPILAN HATALAR

• DR planını yazıp test etmeyi unutmak — belge kağıt üzerinde kalırsa işe yaramaz.
• RTO/RPO hedeflerini iş ile hizalamamak; teknik olarak mümkün olsa bile maliyet gerekçelendirilmezse sürdürülemez.
• Dependecy haritası çıkarmadan failover otomasyonları oluşturmak; gizli bağımlılıklar restore süresini uzatır.
• Testleri sadece tatbikat olarak görmek; gerçekçi trafik ve veri ile test edilmemiş senaryolar yanıltıcı sonuç verir.
• İletişim planı hazırlamamak; stakeholder'ların bilgilendirilmemesi olumsuz etkiyi büyütür.

9. GELECEK TRENDLER

AI destekli DR ve otomatik iyileştirme

AI/ML, anomalileri erken tespit, root cause tahmini ve otomatik remediasyon önerileri ile DR süreçlerini hızlandıracak. Predictive provisioning sayesinde yük tahmini ile pre‑scale stratejileri uygulanabilecek.

Policy as code ve continuous DR

Policy as code ile DR politika ve kontrollerinin pipeline'lara entegre edilmesi — continuous DR — işletmelerin DR olgunluğunu artıracak. DR testlerinin CI süreçlerine dahil edilmesi sayesinde regresyon riski düşecek.

Multi‑cloud DR çözümlerinin olgunlaşması

Multi‑cloud ve hybrid senaryolar için özel DR çözümleri, cross‑region replikasyon, global traffic steering ve bağımsız restore yolları sunarak riskleri dağıtacak. Ancak bu çözümler operasyonel karmaşıklığı da yönetilebilir hale getirmeli.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. DR planı ne sıklıkla test edilmelidir?

   Minimal olarak yılda bir tam tatbikat önerilir; kritik hizmetler için çeyreklik veya her büyük release sonrası test tavsiye edilir. Ayrıca otomatik smoke testleri her deploy sonrası çalışmalıdır.

2. Cold standby yeterli mi?

   İş gereksinimlerine bağlıdır. Kritik müşteri‑facing hizmetler için cold standby genelde yetersizdir çünkü RTO uzun olur.

3. RTO ve RPO nasıl belirlenir?

   İş etkisi analizi (BIA) yapılarak hangi hizmetlerin ne kadar kesinti tolere edebileceği belirlenir; finansal ve operasyonel etkiler göz önünde bulundurulur.

4. DR testleri gerçek verilerle mi yapılmalı?

   Gerçekçi veri setleri önemlidir fakat hassas veriler maskeleyerek veya synthetic veriler kullanarak testler yapılmalıdır. Canlı verinin kullanımı regülasyonlara göre sınırlandırılabilir.

5. Failover otomatik mi olmalı?

   Otomatik failover faydalıdır ancak yanlış alarm riskine karşı guardrail'ler ve insan onayı gerektiren senaryolar tanımlanmalıdır.

6. DR için en kritik metrikler nelerdir?

   RTO, RPO, successful failover time, restore time, backup success rate ve disaster drill coverage gibi metrikler izlenmelidir.

7. IaC DR süreçlerine nasıl katkı sağlar?

   İaC ile DR ortamı hızlıca koddan yeniden oluşturulabilir; bu, cold veya warm standby senaryolarında RTO'yu önemli ölçüde düşürebilir.

8. DR planında hangi ekipler yer almalı?

   Platform/DevOps, SRE, güvenlik, uygulama ekipleri, müşteri destek, iletişim/PR ve iş sahipleri (product owners) dahil olmalıdır.

Anahtar Kavramlar

RTO

Hizmetin kurtarılması için hedeflenen maksimum süre.

RPO

Kabul edilebilir veri kaybı süresi; replikasyon stratejilerini belirler.

Failover

Hizmetin birincil ortamdan ikincil ortama geçirilmesi.

Failback

Hizmetin tekrar birincil ortama geri alınması süreci.

Business Impact Analysis (BIA)

İş süreçlerinin arızalara karşı kritikliğini ve mali etkilerini değerlendiren çalışma.

Öğrenme Yol Haritası

1. 0–1 ay: DR temel kavramlarını, RTO/RPO tanımlarını ve basit backup/restore proseslerini öğrenin.
2. 1–3 ay: IaC araçları (Terraform/Pulumi), snapshot ve replikasyon mekanizmalarını deneyin; küçük bir uygulama için warm standby kurun.
3. 3–6 ay: Failover otomasyonları, DNS ve trafik yönlendirme stratejileri üzerinde pratik yapın; DR tatbikatları planlayın.
4. 6–12 ay: Active‑Active ve cross‑region replikasyon senaryoları, chaos engineering ile DR testleri ve post‑mortem uygulamalarını öğrenin.
5. 12+ ay: Multi‑cloud DR, predictive provisioning, AI destekli erken uyarı ve continuous DR uygulamalarında uzmanlaşın.