Felaket kurtarma senaryoları

1) DR'ye neden ihtiyaç duyulur ve amaç nedir

Felaket Kurtarma (DR), felaketlerden sonra hizmetlerin kurtarılmasına yönelik bir dizi mimari, süreç ve eğitimdir (veri merkezi/bölge arızası, veri kaybı, toplu yapılandırma hataları). DR'nin amacı, müşteri güvenini ve mevzuata uygunluğu korurken, hedef RTO'ları/RPO'ları kontrollü maliyet ve risk altında karşılamaktır.

Kurtarma Süresi Hedefi (RTO) - İzin verilen kesinti süresi.
Kurtarma Noktası Hedefi (RPO) - izin verilen veri kaybı (son tutarlı noktadan bu yana geçen süre).
RLO (Recovery Level Objective - Kurtarma Seviyesi Hedefi): Önce geri dönmesi gereken işlevsellik düzeyi (minimum uygulanabilir hizmet).

2) Sistemlerin kritikliğe göre sınıflandırılması

Tier 0 (hayati): ödemeler, giriş, KYC, temel işlemler - RTO ≤ 15 dakika, RPO ≤ 1-5 dakika.
Katman 1 (yüksek): çalışma panelleri, raporlar D-1 - RTO ≤ 1 h, RPO ≤ 15-60 dk.
Katman 2 (ortalama): arka ofis, neredeyse gerçek zamanlı analitik - RTO ≤ 4-8 saat, RPO ≤ 4-8 saat.
Seviye 3 (düşük): kritik olmayan yardımcı - RTO ≤ 24-72 h, RPO ≤ 24 h.

Hizmet kataloğundaki her hizmete Tier + hedef RTO/RPO atayın; Kararlar ve bütçeler bunlara karşı kontrol edilmelidir.

3) Tehdit modeli ve senaryoları

İnsan yapımı: AZ/bölge/sağlayıcının hatası, ağ bozulması/DNS, veritabanı/depolama arızası, yığın serbest bırakma hatası.
İnsan faktörü: hatalı yapılandırmalar/IaC, veri silme, anahtar uzlaşma.
Doğal/dış: yangın/sel, elektrik kesintileri, yasal engellemeler.
Her biri için - olasılık/etkiyi değerlendirin, DR senaryosuna ve oyun kitabına bağlantı verin.

4) DR mimari desenleri

1. Aktif-Aktif (Çok Bölgeli): Her iki bölge de trafiğe hizmet eder.

Artıları: minimum RTO/RPO, yüksek kararlılık.
Dezavantajları: veri karmaşıklığı/tutarlılığı, yüksek fiyat.
Nerede: okuma ağırlıklı, önbelleğe alınmış yükler, durumsuz hizmetler, çoklu ana DB (katı çakışma kuralları).

2. Aktif-Pasif (Hot Standby): Sıcak pasif, tamamen ısıtılmış bir kopyayı tutar.

RTO: dakikalar; RPO: Dakikalar. Otomatik yük devretme ve çoğaltma gerektirir.

3. Sıcak Bekleme: Kaynakların bir kısmı ısınır, kaza durumunda ölçeklenir.

RTO: onlarca dakika; RPO: 15-60 dakika. Daha ekonomik ama daha uzun.

4. Pilot Light: minimal "kıvılcım" (meta veriler/görüntüler/komut dosyaları) + hızlı yayılma.

RTO: saatler; RPO: saatler. Ucuz, Tier 2-3 için uygun.

5. Yedekleme ve Geri Yükleme: çevrimdışı yedeklemeler + manuel ısınma.

RTO/RPO: saat/gün. Sadece düşük kritiklik ve arşivler için.

5) Veri ve tutarlılık

• Senkron - neredeyse sıfır RPO, ama ↑latentnost/stoimost.
• Asenkron - daha iyi performans, RPO> 0 (günlüklerin kuyruğu).
• Tutarlılık: Bir model seçin (güçlü/nihai/nedensel). Ödemeler için - kesinlikle, analitik için - nihai.
• Anlık görüntüler: Düzenli olarak tutarlı noktalar oluşturun + günlükleri saklayın (WAL/yineleme).
• Bölgeler arası işlemler: 2PC kaçının; Idempotent işlemleri, şarküteri ve tekrarlama (veri tekilleştirme ile yeniden deneme), olay kaynağı kullanımı.
• Kuyruklar/veri yolları: çoğaltma/yansıtma, DLQ, sipariş ve tüketicilerin idempotency.

6) Ağ, trafik ve DNS

GSLB/Anycast/DNS: failover/failback politikaları, düşük TTL (ama çok fazla değil), çeşitli bölgelerden sağlık kontrolleri.
L7 yönlendirme: bölgesel haritalar, bozulma bayrakları (işlev kısıtlaması).
Özel bağlantılar/VPN: Sağlayıcılara yedekleme kanalları (PSP/KYC/CDN).
Hız sınırlaması: Kurtarma sırasında fırtına koruması.

7) Stateful vs Stateless

Stateless script/autoscale ile taşınır; Durum bilgisi tutarlı bir veri stratejisi gerektirir (çoğaltma, anlık görüntüler, çoğaltma promosyonu, çekirdek).
Önbellek/oturumlar: Bölgeler arası çoğaltma veya günlüklerle yeniden tohumlama ile harici (Redis/Memcached); oturumları belirteçlerde (JWT) veya paylaşılan depoda tutun.

8) DR tetikleyicileri ve otomasyon

SLO gardrails ve quorum probları - otomatik bir bölge-yük devretme çalışma kitabı.
Kaza durumunda donmayı değiştirin: alakasız sürümleri/geçişleri engelleyin.
Kod Olarak Altyapı: stand-by manifestolarının dağıtımı, sürüklenme kontrolü.
Rol tanıtımı: Otomatik çoğaltma DB + yazarlar/sırlar giyinme teşvik.

9) İletişim ve Uyumluluk

Savaş odası: IC/TL/Comms/Scribe; SEV güncelleme aralıkları.
Durum sayfası: etki coğrafyası, ETA, geçici çözümler.
Düzenleyici: bildirim son tarihleri, veri güvenliği, değiştirilemez kanıt depolama.
Ortaklar/sağlayıcılar: onaylanmış kişiler, özel kanal.

10) DR testleri ve egzersizleri

Masa üstü: Senaryo ve çözümleri tartışmak.
Oyun Günü (sahne/prod-light): AZ/bölgeler arızasının simülasyonu, sağlayıcı kapatma, DNS sıfırlama.
Testleri geri yükle: yedeklemeleri düzenli aralıklarla tek başına geri yükleyin ve bütünlüğü doğrulayın.
Kaos/Başarısızlık enjeksiyonu: kontrollü ağ/düğüm/bağımlılık hataları.
Egzersiz KPI: RTO/RPO, playbook kusurları, CAPA elde.

11) Finans ve Strateji Seçimi (FinOps)

Azaltılmış RPO/RTO için $ sayın: hedefler ne kadar düşük olursa, kanallar, lisanslar, rezervler o kadar pahalı olur.
Hibrit: Seviye 0 - aktif-aktif/sıcak; Kademe 1 - sıcak; Tier 2-3 - pilot/yedek.
Pahalı veriler: soğuk katmanlar (arşiv/S3/GLACIER), artımlı anlık görüntüler, veri tekilleştirme kullanın.
DR-infra maliyetlerinin ve sertifikalarının/lisanslarının periyodik olarak gözden geçirilmesi.

12) DR Olgunluk Metrikleri

Her Katman için RTO (gerçek) ve RPO (gerçek).
DR Kapsamı: Tasarlanmış bir senaryo/oyun kitabı/test ile hizmetlerin %'si.
Yedekleme Başarısı ve Geri Yükleme Başarısı: Yedeklemelerin ve kanıtlanmış geri yüklemelerin günlük başarısı.
Felaket Bildirme Zamanı: Yük devretme kararının hızı.
Failback Zaman normal topolojiye döner.
Kusur Oranı Egzersizleri: bulunan boşluklar/öğretiler.
Uyumluluk kanıtı bütünlük.

13) Kontrol listeleri

DR uygulamasından önce

• Hizmet dizini Katman, RTO/RPO, bağımlılıklar ve sahipler içerir.
• Katman ve bütçeye göre seçilen desen (AA/AP/WS/PL/BR).
• Tutarlılık ve çoğaltma anlaşmaları belgelenmiştir.
• GSLB/DNS/yönlendirme ve sağlık kontrolleri yapılandırılmış ve test edilmiştir.
• Yedeklemeler, anlık görüntüler, değişiklik günlükleri - etkin, geri yükleme için kontrol edildi.
• DR oyun kitapları ve sağlayıcı kişileri güncel.

Kaza sırasında (kısaca)

• SEV ilan edin ve bir savaş odası kurun; Bültenleri dondurun.
• Probların nisabını kontrol edin; Etkiyi/coğrafyayı kaydedin.
• Failover Runbook'u Çalıştırın: Trafik, Promosyon DB, Kuyruklar, Önbellek.
• Degrade-UX/limitlerini etkinleştir; Güncellemeleri SLA'da yayınlayın.
• Kanıt toplayın (zaman çizelgesi, grafikler, günlükler, komutlar).

Kazadan sonra

• N aralıklarının SLO'sunu gözlemleyin; failback'i planlandığı gibi yürütün.
• AAR/RCA Davranış; CAPA'yı yayınlayın.
• Oyun kitaplarını, uyarı katalizörlerini, DR test vakalarını güncelleyin.
• Paydaşlara/düzenleyicilere rapor verin (gerekirse).

14) Şablonlar

14. 1 DR komut dosyası kartı (örnek)

ID: DR-REGION-FAILOVER-01
Scope: prod EU ↔ prod US
Tier: 0 (Payments, Auth)
Targets: RTO ≤ 15m, RPO ≤ 5m
Trigger: quorum(probes EU, US) + burn-rate breach + provider status=red
Actions:
- Traffic: GSLB shift EU→US (25→50→100% with green SLIs)
- DB: promote US-replica to primary; re-point writers; freeze schema changes
- MQ: mirror switch; drain EU DLQ; idempotent reprocess
- Cache: invalidate region-specific keys; warm critical sets
- Features: enable degrade_payments_ux
- Comms: status page update q=15m; partners notify
Guardrails: payment_success ≥ 98%, p95 ≤ 300ms
Rollback/Failback: EU green 60m → 25→50→100% with guardrails
Owners: IC @platform, DB @data, Network @netops, Comms @support

14. 2 Runbook "Çoğaltma veritabanını tanıtın" (fragman)

1) Freeze writes; verify WAL applied (lag ≤ 30s)
2) Promote replica; update cluster VIP / writer endpoint
3) Rotate app secrets/endpoints via remote config
4) Validate: read/write checks, consistency, replication restart to new secondary
5) Lift freeze, monitor errors p95/5xx for 30m

14. 3 DR Egzersiz Planı (Kısa)

Purpose: to check RTO/RPO Tier 0 in case of EU failure
Scenario: EU incoming LB down + 60s replication delay
Success criteria: 100% traffic in US ≤ 12m; RPO ≤ 5m; SLI green 30m
Artifacts: switching logs, SLI graphs, step times, command output

15) Anti-desenler

Düzenli geri yükleme testleri olmadan "yedeklemeler var".
Sırlar/uç noktalar otomatik olarak değiştirilmez.
Hiçbir idempotency - yinelenen/kayıp işlemleri redelivery.
Bozulma özelliği olmayan bölgeler için aynı yapılandırmalar bayraklar içerir.
"Yanlış alarm" korkusuyla Bildirilecek Uzun Zaman.
Tek bölgeli sağlayıcılar (PSP/KYC) alternatifsiz.
Geri dönüş planı yok - "sonsuza dek" acil bir topolojide yaşıyoruz.

16) Uygulama Yol Haritası (6-10 hafta)

1. Ned. 1-2: Hizmetlerin Seviye'ye göre sınıflandırılması, hedef RTO/RPO'nun belirlenmesi, DR modellerinin seçilmesi.
2. Ned. 3-4: çoğaltma/yedeklemeler, GSLB/DNS, promosyon prosedürleri ayarlama; playbooks ve runbooks've.
3. Ned. 5-6: ilk DR egzersizleri (masa üstü aşama), metrikleri ve CAPA'yı sabitleme.
4. Ned. 7-8: Trafik Kısıtlı Egzersiz Prod-Light; Yük devretme otomasyonu.
5. Ned. 9-10: maliyet optimizasyonu (FinOps), Tier 0'ın sıcak/AA'ya aktarılması, üç aylık alıştırma ve raporlama düzenlemeleri.

17) Alt satır

Etkili DR sadece yedeklemelerle ilgili değildir. Bunlar tutarlı mimari, yük devretme/yük devretme otomasyonu, veri disiplini (idempotency/replication), eğitim ve şeffaf iletişimdir. RTO/RPO'lar gerçek olduğunda, oyun kitapları çalıştığında ve alıştırmalar düzenli olduğunda, felaket kontrollü bir olaya dönüşür, ardından hizmetler hızlı ve tahmin edilebilir bir şekilde normale döner.