DR策略和RTO/RPO

1）基本原則

1.目標早於資金。首先，我們制定RTO/RPO和關鍵場景，然後選擇技術。
2.按重要性劃分。並非所有服務都需要「黃金」；按業務關鍵性劃分。
3.數據-DR.一致性、復制、損壞檢測和恢復點比「鐵」更重要。
4.自動化和可驗證性。如果沒有IaC，恢復回歸測試和遙測，DR就毫無意義。
5.教義和證據。沒有常規「遊戲日」的計劃是準備就緒的幻覺。
6.安全和合規。加密，隔離，WORM/immutable備份，DPA/轄區。

2）術語和合規性

RTO-從事件發生到「正常」恢復服務的時間。
RPO是恢復時最後一個健康數據點的「年齡」。
RLO（恢復水平目標）是必須恢復（最低可行服務）的功能級別。
MTD （Maximum Tolerable Downtime）是企業遭受不可接受的損害的門檻。
RTA/RPA （Actual）-實踐中的實際恢復時間/點。

聯系：RTO ≤ MTD；RPA ≤ RPO.目標與事實之間的差距是驗屍和改進的主題。

3）DR策略類（準備級別）

4）我們為之辯護的場景

區域/雲/數據中心損失（電氣，網絡，提供商）。
數據腐敗/操作員錯誤（刪除，「擊敗」副本，邏輯損壞）。
惡意軟件/勒索軟件（ransomware）。
版本/配置缺陷（質量外觀）。
依賴性崩潰（KMS，DNS，秘密，支付提供商）。
法律事件（阻止，禁止從管轄權中刪除數據）。

對於每個腳本,指定RTO/RPO、DR級別、花花公子、負責。

5）數據策略（RPO關鍵）

5.1 Becaps

完整+增量+事務日誌（用於DB）。
固定/WORM存儲和離線副本（「空插」）。
帶有元數據和加密子圖的後備目錄；定時測試恢復。

5.2復制

同步（低RPO，↑latentnost，戰利品傳播的風險）。
異步（對perf的低影響，RPO> 0；與戰利品檢測器結合使用）。
用於流復制和狀態重建的CDC（更改數據捕獲）。

5.3邏輯損壞保護

帶有≥ N天窗口的轉換/時間點（PITR）。
不變量簽名（平衡，和和，chexumma）是「bit」數據的早期特征。
「慢速」復制通道（延遲15-60分鐘）作為防止即時損壞的緩沖區。

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）應用程序、狀態、緩存

Statless層-在任何區域（Git中的映像/圖表/清單）中擴展和重新啟動。
狀態（DB/緩存/Kew）：真相來源-DB之一；緩存和索引可重新生成。
相等性和重新驅動-允許重新傳遞事件；使用outbox/inbox、dedup和版本。

7）網絡和輸入點

GSLB/DNS收件人：後端/基於健康，在事故窗口中短TTL。
Anycast/L7代理：單個IP,區域健康路由。
區域域和管轄區政策（PII的geo-pinning）。
證書管理員/KMS：備用鏈條,雙鍵。

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）操作模型和自動化

IaC/GitOps：第二區域基礎設施=代碼,「單鍵」部署。
策略作為代碼：門「沒有DR清單/備份/備份-沒有發布」。
Runbooks：分步指令和與兩個區域相同的「紅色按鈕」。
秘密：短期信條，OIDC聯合會，損害/召回計劃。

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）演習和測試（遊戲日）

情景表：DB損失，「重擊」數據，KMS故障，區域下降，突然失控。
頻率：任務關鍵的季度；每半年一次-為其他人。
演習指標：RTA/RPA vs目標，自動步驟比例，手動幹預次數，花花公子錯誤。
發行版中的Chaos-smoke：依賴性降解不應「打破」DR路徑。

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 improvements

10）花花公子（規範模板）

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可觀測度量

Replica lag（秒），RPO漂移（目標和實際RPO之間的差異）。
Restore SLI：周圍環境寒冷/溫暖恢復的時間。
覆蓋率：花花公子/後援/PITR ≥ N天服務的百分比。
演練得分：自動步驟比例、RTA分布、錯誤率。
Immutability：WORM/air-gapped中後備的百分比。
事件度量：回收器之後的隊列長度/重新驅動速度。

12）成本和權衡

CapEx/OpEx：溫暖的展位比Active/Active便宜,但比Pilot Light便宜。
Egress：跨區域/跨雲復制成本；緩存/壓縮/本地聚合。
RTO/RPO vs$：每個「九」的可用性和二秒RPO成本都高出兩倍-與業務保持一致。
綠色窗口：batch復制-在便宜/「綠色」時鐘。

13）安全和合規性

「靜止」和「過境」加密，按區域分開KMS域。
Ransomware防護：「3-2-1」（3份副本，2個媒體，1個離線），MFA-delete。
司法管轄區：PII的geo-pinning，備用本地化，TTL之上的Legal Hold。
時間訪問：DR操作的臨時角色,審計日誌。

14）反模式

「我們以後寫一個計劃」-DR沒有練習。
不受邏輯損壞保護的復制-閃爍地復制錯誤。
單個KMS/secret區域是不可能的捕獲器。
沒有定期恢復的後備箱是「Shredinger」 DR。
區域之間的密切相關的同步交易是級聯潛伏期/下降。
沒有優先級：相同的DR級別適用於一切（昂貴且無用）。

15）建築師支票清單

1.RTO/RPO/RLO是按服務和腳本定義的?

2.數據分類：真理來源，PITR/窗口，WORM/immutable？

3.選擇了DR級別（Backup/Restore, Pilot, Warm, A/P, A/A）?

4.網絡：GSLB/Anycast，庫存證書/鑰匙，「只讀」標誌？

5.應用： 等效性,outbox/inbox抵消交易?

6.IaC/GitOps/Policy as Code： 單擊推出第二個區域?

7.演習：時間表，KPI RTA/RPA，後培訓活動？
8.監視：lag、RPO-drift、restore-SLI、drill-score、immutable back？

9.安全/合規性： KMS域,司法管轄區,法律保留?

10.成本：egress預算，「綠色」窗口，經濟上合理的水平？

16）迷你食譜和素描

16.Postgres的1個PITR（想法）：

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邏輯損壞保護（延遲復制副本）：

yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption

16.3流量切換（GSLB 偽API）：

bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 100

16.4檢查feilover後不變式（偽代碼）：

python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))

結論

DR是做出技術和組織決策的能力,其速度快於損害的增長。確定現實的RTO/RPO，選擇足夠的準備水平，自動化基礎架構和檢查，定期培訓和測量實際RTA/RPA。然後，事故不會變成災難，而是變成可預測的結果的可管理事件。