DR Stratejileri ve RTO/RPO
1) Temel prensipler
1. Hedefler önce anlamına gelir. İlk olarak, RTO/RPO ve kritik senaryoları formüle ediyoruz, ardından teknolojiyi seçiyoruz.
2. Önem açısından segmentasyon. Tüm hizmetler "altın" gerektirmez; İş kritikliğine göre böl.
3. Veriler DR.'nin çekirdeğidir Tutarlılık, çoğaltma, bozulma algılama ve kurtarma noktası donanımdan daha önemlidir.
4. Otomasyon ve doğrulanabilirlik. DR, IaC, kurtarma regresyon testleri ve telemetri olmadan anlamsızdır.
5. Öğretiler ve kanıtlar. Düzenli "oyun günü" olmayan bir plan, hazır olma yanılsamasıdır.
6. Güvenlik ve uyumluluk. Şifreleme, izolasyon, WORM/değişmez yedeklemeler, DPA/yargı alanları.
2) Şartlar ve yazışmalar
RTO - olay anından hizmet "normal'olarak geri yüklenene kadar geçen süre.
RPO, kurtarmadaki son sağlıklı veri noktasının "yaşı'dır.
RLO (Recovery Level Objective - Kurtarma Seviyesi Hedefi) - geri yüklenmesi gereken işlevsellik seviyesi (minimum uygulanabilir hizmet).
MTD (Maksimum Tolere Edilebilir Kesinti Süresi) - işletmenin kabul edilemez hasara uğradığı eşik.
RTA/RPA (Gerçek) - uygulamalardan gerçek zaman/kurtarma noktası.
İletişim: RTO ≤ MTD; RPA ≤ RPO. Hedefler ve gerçek arasındaki boşluk ölüm sonrası ve gelişme konusudur.
3) DR strateji sınıfları (hazırlık seviyeleri)
4) Savunduğumuz senaryolar
Bölge/bulut/veri merkezi kaybı (elektrik, ağ, sağlayıcı).
Veri bozulması/operatör hatası (silme, bozuk kopyalar, mantıksal bozulma).
Kötü amaçlı yazılım/ransomware.
Serbest bırakma/yapılandırma hatası (kütle kesintisi).
Bağımlılığın çöküşü (KMS, DNS, sırlar, ödeme sağlayıcısı).
Yasal olaylar (engelleme, yargı alanından veri ihracatının yasaklanması).
Her senaryo için RTO/RPO, DR seviyesi, oyun kitabı, sorumlu kişileri belirtin.
5) Veri stratejileri (RPO'nun anahtarı)
5. 1 Yedeklemeler
Tam + artımlı + işlem günlükleri (DB için).
Değişmez/WORM depoları ve çevrimdışı kopyalar ("hava boşluklu").
Meta veriler ve kripto imzaları ile yedekleme kataloğu; Zamanlanmış test restorasyonları.
5. 2 Çoğaltma
Senkron (düşük RPO, ↑latentnost, bozulma yayılma riski).
Asenkron (perf üzerinde düşük etki, RPO> 0; Bozulma çocuğu ile birleştirin).
Akış replikasyonu ve devlet rekonstrüksiyonu için CDC (Veri Yakalamayı Değiştir).
5. 3 Mantıksal bozulmaya karşı koruma
N gün ≥ bir pencere ile sürüm oluşturma/" zaman içindeki noktalar" (PITR).
Değişmez imzalar (bakiyeler, toplamlar, chexums) "bozuk" verilerin erken tespitidir.
Anında bozulmaya karşı bir tampon olarak "yavaş" çoğaltma kanalları (15-60 dakika gecikme).
python def pick_restore_point(pitr, anomaly_signals, max_age):
healthy = [p for p in pitr if not anomaly_signals. after(p. time)]
return max(healthy, key=lambda p: p. time if now()-p. time <= max_age else -1)6) Uygulama, durum, önbellek
Durumsuz katman - herhangi bir bölgede ölçeklendirme ve yeniden başlatma (Git'te görüntü/grafik/manifestolar).
Durum (DB/caches/kew): Gerçeğin kaynağı DB'lerden biridir; Önbellekler ve indeksler fazla geniştir.
Idempotans ve yeniden sürüş - olayların yeniden teslimine izin verilir; Giden kutusu/gelen kutusu, dedup ve sürümleri kullanın.
7) Ağ ve giriş noktası
GSLB/DNS-feilover: gecikme/sağlık tabanlı, kısa TTL çökme penceresi.
Anycast/L7 proxy: tek IP, bölgesel sağlık yönlendirme.
Bölgesel alanlar ve yargı politikaları (PII için coğrafi sabitleme).
Sertifika dosyası/KMS: yedek zincirler, çift anahtarlı.
python if slo_breach("region-a") or health("region-a")==down:
route. shift(traffic, from_="region-a", to="region-b", step=20) # канарим enable_readonly_if_needed()8) Çalışma modeli ve otomasyon
IaC/GitOps: ikinci bölge altyapısı = kod,'tek düğme "dağıtımı.
Kod olarak Politika: gate "DR manifestoları/yedeklemeleri/uyarıları yok - serbest bırakma yok".
Runbooks: adım adım talimatlar ve her iki bölgeyle aynı "kırmızı düğme".
Sırlar: Kısa ömürlü krediler, OIDC federasyonu, uzlaşma/geri çağırma planı.
rego package dr deny["Missing PITR ≥ 7d"] {
input. db. pitr_window_days < 7
}
deny["No restore test in 30d"] {
now() - input. db. last_restore_test > 3024h
}9) Alıştırmalar ve testler (Oyun Günleri)
Senaryo tablosu: veritabanı kaybı, "bozuk" veri, KMS hatası, bölge düşüşü, ani çıkış sınırı.
Sıklık: kritik görev için üç ayda bir; Her altı ayda bir - geri kalanı için.
Egzersiz metrikleri: RTA/RPA vs hedefler, otomatik adımların oranı, manuel müdahalelerin sayısı, playbook hataları.
Bültenlerde kaos-duman: bağımlılık bozulması DR yollarını "kırmamalıdır".
T0: cut off the primary database (firewall drop)
T + 2m: GSLB shift 20% of traffic, then 100% at SLO_ok
T + 6m: checking business invariants and lag replication
T + 10m: post-drill: fixing RTA/RPA, playbook improvements10) Playbooks (kanonik şablon)
yaml playbook: "dr-failover-region-a-to-b"
owner: "platform-sre"
rto: "15m"
rpo: "5m"
triggers:
- "health(region-a)==down"
- "slo_breach(payments)"
prechecks:
- "backup_catalog ok; last_restore_test < 30d"
- "pitr_window >= 7d"
steps:
- "Announce incident; open war-room; assign IC"
- "Freeze writes in region-a (flag write_readonly)"
- "Promote db-b to primary; verify replication stopped cleanly"
- "Shift GSLB 20%→50%→100%; monitor p95/error"
- "Enable compensations and re-drive queues"
validation:
- "Business invariants (balances, duplicate_checks)"
- "Synthetic tests green; dashboards stable 30m"
rollback:
- "If db-b unhealthy: revert traffic; engage restore from PITR T-Δ"
comms:
- "Status updates each 15m; external note if SEV1"11) DR gözlemlenebilirlik metrikleri
Replica lag (sn), RPO-drift (hedef ve gerçek RPO arasındaki fark).
SLI'yi geri yükleyin: Ortama göre soğuk/sıcak iyileşme süresi.
Kapsam: Playbook/yedekleme/PITR ≥ N gün ile hizmetlerin %.
Matkap puanı: otomatik adımların oranı, RTA dağılımı, hata oranı.
Değişmezlik: WORM/hava boşluklu yedeklemelerin %'si.
Olay metrikleri: sahte sonra kuyruk uzunluğu/yeniden sürücü hızı.
12) Maliyet ve takaslar
CapEx/OpEx: Sıcak stand Active/Active'den daha ucuzdur, ancak Pilot Light'tan daha pahalıdır.
Çıkış: Bölgeler arası/bulutlar arası çoğaltmanın maliyeti; önbellek/sıkıştırma/yerel kümeler.
RTO/RPO vs $: Her "dokuz" kullanılabilirlik ve bir RPO saniyesi birkaç kat daha pahalıdır - işletme ile koordine edin.
Yeşil pencereler: toplu çoğaltma - ucuz/'yeşil "saatlerde.
13) Güvenlik ve uyumluluk
"Dinlenmede've" aktarımda "şifreleme, bölgeye göre ayrı KMS alanları.
Değişmez yedeklemeler, fidye yazılımı koruması: "3-2-1" (3 kopya, 2 medya, 1 çevrimdışı), MFA-silme.
Yargı alanları: PII için coğrafi sabitleme, yedeklemeleri yerelleştirme, TTL'nin üstünde Yasal Bekletme.
Zaman erişimleri: DR işlemleri için geçici roller, denetim günlüğü.
14) Anti-desenler
"Daha sonra bir plan yazalım" - DR egzersizsiz.
Mantıksal bozulmaya karşı koruma olmadan çoğaltma - hatayı anında çoğaltır.
Bir KMS/sır bölgesi - feilover mümkün değil.
Düzenli geri yükleme olmadan yedeklemeler - "Shredinger" DR.
Bölgeler arasındaki yakından ilişkili senkron işlemler kaskad gecikme/düşmedir.
Önceliklendirme yok: Her şey için aynı DR seviyesi (pahalı ve işe yaramaz).
15) Mimar kontrol listesi
1. Servis ve senaryoya göre tanımlanmış RTO/RPO/RLO?
2. Sınıflandırılmış veriler: gerçeğin kaynağı, PITR/pencere, WORM/değişmez?
3. Servis başına DR (Yedekleme/Geri Yükleme, Pilot, Sıcak, A/P, A/A) seçili mi?
4. Ağ: GSLB/Anycast, marjlı sertifikalar/anahtarlar, salt okunur bayraklar?
5. Uygulama: Idempotence, giden kutusu/gelen kutusu, dengeleme işlemleri?
6. IaC/GitOps/Policy as Code: İkinci bölgeye bir tıklama mı?
7. Matkap: Zamanlama, KPI RTA/RPA, eğitim sonrası faaliyetler?
8. İzleme: gecikme, RPO-drift, restore-SLI, matkap puanı, değişmez yedeklemeler?
9. Güvenlik/Uyumluluk: KMS Etki Alanları, Yargı Alanları, Yasal Bekletme?
10. Maliyet: çıkış bütçesi, yeşil pencereler, ekonomik olarak sağlam seviye?
16) Mini tarifler ve eskizler
16. Postgres için 1 PITR (fikir):
bash base backup daily + WAL archive pg_basebackup -D/backups/base/$ (date +% F)
archive_command='aws s3 cp %p s3://bucket/wal/%f --sse'
restore pg_restore --time "2025-10-31 13:21:00Z"...16. 2 Mantıksal bozulmaya karşı koruma (gecikmeli çoğaltma):
yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption16. 3 Trafik anahtarlama (GSLB pseudo-API):
bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 10016. 4 Değişmezlerin feiloverdan sonra kontrolü (pseudocode):
python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))Sonuç
DR, teknik ve organizasyonel kararları hasarın büyümesinden daha hızlı yapabilme yeteneğidir. Gerçekçi RTO/RPO'ları belirleyin, yeterli kullanılabilirliği seçin, altyapı ve kontrolleri otomatikleştirin, düzenli egzersiz yapın ve gerçek RTA/RPA'ları ölçün. O zaman kaza bir felakete değil, öngörülebilir bir sonuçla kontrollü bir olaya dönüşecektir.