Skip to main content

> felaket_kurtarma_(dr):_rpo,_rto_ve_canlı_çoklu_bölge_failover_tatbikatları

Felaket Kurtarma (DR): RPO, RTO ve Canlı Çoklu Bölge Failover Tatbikatları

Kağıt üzerindeki teorik felaket kurtarma dokümanları gerçek bir veri merkezi çöküşünde neden iflas eder ve periyodik canlı çoklu bölge (multi-region) tatbikatları RPO ile RTO'yu nasıl doğrular?

Staff/Principal (L6+)

ÖZET VE TEKNİK CEVAP

Yalnızca statik PDF dosyalarında veya masa başı toplantılarda var olan Felaket Kurtarma (DR) planları, gerçek bir bulut bölgesi (AWS/Azure) çöküşünde neredeyse her zaman iflas eder. Test edilmeyen yedek ortamlar konfigürasyon kaymasına (drift) uğrar: Süresi dolmuş SSL sertifikaları, eski veritabanı şifreleri, eksik IAM yetkileri ve unutulmuş asenkron replikasyon gecikmeleri sistemi kilitler. Kurtarma Noktası Hedefi (RPO: tolere edilebilir maksimum veri kaybı süresi) ve Kurtarma Süresi Hedefi (RTO: tolere edilebilir maksimum kesinti süresi), canlı yük altında test edilene kadar sadece kağıt üzerindeki hayali sayılardır. Güvenilir ekipler 3 ayda bir canlı çoklu bölge failover tatbikatı yapar: Route 53 ile canlı trafiğin %100'ü yedek bölgeye aktarılır ve sistemin sıfır veri kaybıyla çalıştığı kanıtlanır.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Felaket kurtarma mimarisi 4 operasyonel seviyeden oluşur: (1) Yedekten Dönme (RPO: saatler, RTO: 24 saat+): Soğuk S3 yedekleri; en ucuz model. (2) Pilot Light (RPO: 10 dk, RTO: 2 saat): Veritabanı ikincil bölgeye sürekli kopyalanır; sunucular kriz anına kadar kapalı tutulur. (3) Warm Standby (RPO: saniyeler, RTO: 10 dk): İkincil bölgede küçük ölçekli sunucu ve replika veritabanı 7/24 çalışır. (4) Çoklu Bölge Active-Active (RPO: 0, RTO: ~0): İki bölgede de tam aktif çalışan, çift yönlü veri kopyalayan (CockroachDB, Aurora Global) en üst seviye model. Canlı tatbikat; DNS yönlendirmesini, veritabanı liderliğini ve şifre senkronizasyonunu test eder.

2. Doğru Kullanım Senaryosu

Kritik finansal sistemler, katı uptime taahhüdü olan kurumsal B2B SaaS platformları, sağlık teknolojileri ve küresel e-ticaret siteleri.

3. Prodüksiyon Arıza Modları

AWS US-East-1 bölgesi çöktüğünde bir borsa platformunun 18 saat kapalı kalması; çünkü kriz anında yedek bölgedeki veritabanı şifreleme anahtarının süresinin dolduğu ortaya çıkmıştır; DNS TTL süresinin 24 saat (86.400 sn) unutulması yüzünden trafiğin yedek bölgeye saatlerce aktarılamaması.

4. Teşhis ve Telemetri Sinyalleri

Felaket kurtarma dokümanlarının 1 yıldan uzun süredir güncellenmemesi; şirket tarihinde tek bir canlı failover tatbikatı bile yapılmamış olması; bulut bölgeleri arasındaki replikasyon gecikmesinin (lag) izlenmemesi.

5. Önleme ve Mimari Bariyerler

Her çeyrekte canlı üretim failover tatbikatlarını zorunlu kılın; failover DNS kayıtlarının TTL süresini maksimum 60 saniye yapın; ikincil bölgenin ana bölgeyle birebir aynı olduğunu Terraform drift kontrolleriyle denetleyin; bölgeler arası replikasyon gecikmesine sıkı alarmlar koyun.

6. Mimari Ödünleşimler (Trade-offs)

Sıcak yedek veya Active-Active çoklu bölge altyapısı kurmak bulut maliyetini %60 ila %100 artırır; ancak büyük bulut sağlayıcı çöküşlerinde şirketin hayatta kalmasını kesin olarak garanti eder.

Vaka İncelemesi (TinyCTO Örneği)

2.000 hastaneye hizmet veren bir sağlık SaaS şirketi, AWS `us-west-2` bölgesinde Aurora Global Database ile Sıcak Yedek (Warm Standby) tutuyordu. SRE ekibi 6 ayda bir planlı canlı tatbikat yapıyordu: Route 53 ile trafiği aktarıp ikincil veritabanını ana yapıyordu. AWS Virginia bölgesi elektrik kesintisiyle çöktüğünde, ekip 4 dakikada sıfır veri kaybıyla (RPO=0, RTO=4 dk) yedek bölgeye geçti; rakipleri 12 saat kapalı kalırken hastanelerin acil servis erişimi hiç kesilmedi.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Felaket Kurtarmada (DR) RPO ile RTO arasındaki fark nedir?

RPO (Kurtarma Noktası Hedefi) tolere edilebilen maksimum veri kaybı süresidir; RTO (Kurtarma Süresi Hedefi) ise sistemin ayağa kalkması için tolere edilebilen maksimum kesinti süresidir.
Q2

Etkili bir çoklu bölge felaket kurtarma geçişi için neden 60 saniyelik DNS TTL süresi şarttır?

Çünkü yüksek TTL süreleri (ör. 24 saat) servis sağlayıcıların eski IP'yi önbellekte tutmasına ve kullanıcıların saatlerce çöken bölgeye gitmeye devam etmesine yol açar.

Felaket Kurtarma (DR): RPO, RTO ve Canlı Çoklu Bölge Failover Tatbikatları — Sıkça Sorulan Sorular

En pahalı Felaket Kurtarma (DR) stratejisi hangisidir?

Çoklu Bölge Active-Active: İki veya daha fazla coğrafi bölgede tam kapasite sunucuların ve çift yönlü veritabanı kopyalamanın 7/24 eşzamanlı çalıştığı model.

İkincil felaket kurtarma ortamlarında 'Konfigürasyon Kayması' (Configuration Drift) nedir?

Değişiklikler kod olarak yönetilmediğinde (IaC), ikincil bölgenin ana bölgeden zamanla farklılaşması (eski şifreler, eksik yetkiler, farklı şemalar).

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸RPO = Maximum tolerable data loss; RTO = Maximum tolerable downtime duration.
  • ▸Theoretical DR plans fail; only periodic live multi-region drills prove recovery.
  • ▸Keep failover DNS TTL <=60 seconds to enable rapid global traffic rerouting.
  • ▸Use Infrastructure as Code (Terraform) to eliminate secondary region configuration drift.

Yaygın Yanılgılar

  • ✗Yanılgı: Storing nightly database backups in S3 is a complete DR plan (Gerçek: Restoring Terabytes from S3 takes 12-24 hours, failing strict business RTOs).
  • ✗Yanılgı: Multi-region failover can be tested during business hours without traffic (Gerçek: Real validation requires shifting live production traffic).

Karar Kılavuzu & Önceliklendirme

Define quantitative RPO and RTO targets for every core tier with executive sign-off. Schedule bi-annual live multi-region failover drills with automated DNS switching.

Doğrulanmış Kaynaklar & Referanslar