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。然后，事故不会变成灾难，而是变成可预测的结果的可管理事件。