灾难恢复方桉

1）为什么需要DR和什么目的

灾难恢复（DR）是用于灾难恢复服务的一组体系结构，过程和培训（数据中心/区域故障，数据丢失，大规模配置错误）。DR的目标是以可控的成本和风险执行目标的RTO/RPO，同时保持客户信心和合规性。

RTO（恢复时间目标）：允许的停机时间。
RPO（恢复点目标）：有效的数据丢失（来自最后一个一致点的时间）。
RLO（恢复水平目标）：必须首先返回的功能级别（最低可行服务）。

2）按临界值分类系统

0级（至关重要）：付款，登录，KYC，交易核心-RTO ≤ 15分钟，RPO ≤ 1-5分钟。
1级（高）：操作面板，D-1报告-RTO ≤ 1小时，RPO ≤ 15-60分钟。
Tier 2（平均）：后台,近实时分析-RTO ≤ 4-8小时,RPO ≤ 4-8小时。
Tier 3（低）：非关键辅助-RTO ≤ 24-72小时,RPO ≤ 24小时。

在服务目录中为每个服务分配Tier+目标RTO/RPO；与之核对决定和预算。

3）威胁模型和情景

人为：AZ/区域/提供程序故障, 网络/DNS降解,数据库/存储故障,大规模发布错误。
人为因素：错误的configi/IaC、数据删除、密钥损害。
自然/外部：火灾/洪水，能源中断，法律封锁。
对于每个-估计概率/影响，绑定到DR脚本和花花公子。

4） DR架构模式

1.主动活动（Multi-Region）：两个区域都为流量服务。

优点：RTO/RPO最低，稳定性高。
缺点：数据复杂性/一致性,价格高。
其中：读重，缓存负载，无状态服务，多主DB（严格的冲突规则）。

2.Active-Passive （Hot Standby）："热"passific拥有一个完全加热的副本。

RTO：分钟；RPO：分钟。需要自动故障切换和复制。

3.Warm Standby：加热资源的一部分,在发生事故时进行缩放。

RTO：几十分钟；RPO：15-60分钟更经济，但更长。

4.Pilot Light：最小"火花"（元数据/映像/脚本）+快速掉头。

RTO：时钟；RPO：时钟。便宜，适合Tier 2-3。

5.Backup&Restore：离线备份+手动预热。

RTO/RPO：每小时。仅适用于低关键性和档案。

5）数据与一致性

• 同步-几乎为零RPO，但↑latentnost/stoimost。
• 异步-性能更好,RPO> 0（日志尾）。
• 一致性：选择模型（strong/eventual/causal）。对于付款-严格来说，对于分析师-事件。
• 切片（Snapshots）：定期创建一致点+存储日志（WAL/redo）。
• 跨区域交易：避免2PC；使用等效操作，delh-i-re-yay（重复重复数据消除），事件源。
• 队列/总线：复制/镜像、DLQ、订购和用户体验。

6）网络、流量和DNS

GSLB/Anycast/DNS： failover/failback策略、低TTL（但不过分）、来自多个地区的健康检查。
L7路由：区域地图，降级标志（功能限制）。
Private-links/VPN：提供商备用通道（PSP/KYC/CDN）。
比例限制：恢复时抵御风暴。

7) Stateful vs Stateless

Stateless由脚本/自动标记携带；stateful需要一致的数据策略（复制、狙击、副本促销、法定人数）。
缓存/会话：具有跨区域复制或日志重播的外部（Redis/Memcached）；将会话保存在令牌（JWT）或共享存储中。

8）触发器和自动化DR

SLO Gardrails和法定探针→自动区域失败运行手册。
发生事故时更改冻结：阻止非相关发布/迁移。
基础架构作为代码：按清单部署摊位，漂移检查。
角色推广：DB副本的自动推广+作家/秘密的敷料。

9）沟通和合规性

War-room: IC/TL/Comms/Scribe;SEV的更新间隔。
状态页面：影响力地理，ETA，解决方案。
监管：通知时间、数据安全、不可更改的事件存储。
合作伙伴/提供商：已确认的联系人、专用渠道。

10） DR测试和练习

Tabletop：讨论脚本和解决方桉。
Game Day （stadage/prod light）：模拟AZ/区域故障、禁用提供程序、 DNS重置。
恢复测试：定期隔离恢复备份并验证完整性。
Chaos/Failure injection：受控的网络/主机/依赖性故障。
KPI演习：实现RTO/RPO，花花公子缺陷，CAPA。

11）财务和战略选择（FinOps）

计算每减少RPO/RTO$：目标越低-渠道、许可证、储备金越贵。

混合动力车： 0级-主动/热门；Tier 1 — warm;Tier 2–3 — pilot/backup.

数据价格昂贵：使用冷层（存档/S3/GLACIER）,增量快照,重复数据消除。
定期检讨DR-infra的成本和证书/许可证。

12） DR成熟度量标准

每个级别的RTO（事实）和RPO（事实）。
DR Coverage：使用正式脚本/花花公子/测试的服务百分比。
Backup Success&Restore Success：备份和经验证的恢复的日常成功。
时间到决定性灾难：失败决策的速度。
Failback Time：返回到正常拓扑。
否定率教学：发现的差距/教学。
Compliance Evidence Completeness：工件的完整性。

13）支票单

在实施DR之前

• 服务目录包含Tier、RTO/RPO、依存关系和所有者。
• 为层级和预算选定了一个模式（AA/AP/WS/PL/BR）。
• 一致性和复制约定已记录在桉。
• GSLB/DNS/路由和健康检查已配置和测试。
• Backaps、snapshots、change日志-包括在内,经过restore验证。
• DR花花公子和提供商联系人以实际形式。

事故发生时（简短）

• 宣布SEV并组装战争室；冻结发行版。
• 检查探针的法定人数；记录影响/地理。
• 执行Failover Runbook：流量、DB促销、队列、缓存。
• 包括degrade-UX/限制；根据SLA发布更新。
• 收集事件（时间线、图形、日志、命令）。

事故发生后

• 观察间隔的SLO N；按照计划执行失败。
• 进行AAR/RCA；制定CAPA。
• 更新花花公子、Alert催化剂、DR测试桉例。
• 向赌客/监管机构报告（如有必要）。

14）模板

14.1个DR脚本卡（示例）

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 "Promote DB复制副本"（片段）

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演习计划（简短）

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）反模式

"有备用"，没有定期的恢复测试。
秘密/后端不会自动切换。
重复交付时→重复的/丢失的交易不具有相容性。
对于没有降级标志的区域，相同的configas。
由于担心"虚假焦虑"，长时间的解雇。
单区域提供商（PSP/KYC）没有替代方案。
没有失败的计划-生活在"永远"的紧急拓扑中。

16）实施路线图（6-10周）

1.奈德。1-2：按级别分类服务,安装目标RTO/RPO,选择DR模式。
2.奈德。3-4：设置复制/备份，GSLB/DNS，促销程序；花花公子和跑书。
3.奈德。5-6：第一次DR演习（tabletop→stage）,指标固定和CAPA。
4.奈德。7-8：交通受限的演习；failover自动化。
5.奈德。9-10：成本优化（FinOps），Tier 0移至hot/AA，季度演习和报告法规。

17）结果

有效的DR不仅仅是备用。这些是一致的体系结构，故障转移/故障回传自动化，数据学科（相等/复制），培训和透明通信。当RTO/RPO是真实的，花花公子工作并定期进行演习时，灾难变成了托管事件，之后服务迅速且可预测地恢复正常。