容灾演练多久做一次？重点验证什么？

简化版

演练频率应按业务等级、变更速度和风险决定，而不是全公司统一“一年一次”：核心链路可月度做组件故障、季度做可用区切换、至少年度做地域级灾备。 重点验证实际 RPO/RTO、数据正确性、切流与 fencing、剩余容量、依赖完整性、告警和人工 Runbook，并跟踪问题复验。

详细版

将演练拆成高频小故障和低频大切换。每次重大架构、复制链路、DNS、权限或灾备资源变更后，应触发专项演练，不必等日历。长期未演练的预案要视为未验证。

演练前定义稳态、故障范围、停止条件和回滚；演练中记录每阶段时间和数据水位；演练后核对已确认交易、积压、缓存和外部流水。成功标准不是“切过去了”，而是业务指标、数据缺口与恢复时间全部达标。

完整版教学

一、频率来自风险变化速度

如果系统每周发布、每月调整拓扑，年度演练只能验证早已过时的架构。演练间隔应短于关键假设可能失效的周期。核心程度、历史事故、人员变化和自动化成熟度都会影响频率。

记忆钩子：预案的保质期由系统变化速度决定，不由文档发布日期决定。

二、建立分层演练日历

层级	示例	建议节奏示例
实例/进程	kill、重启	每周或持续混沌
依赖/节点	DB 只读、缓存故障	月度
可用区	AZ 摘流	季度
地域灾备	跨地域切换	半年/年度
恢复备份	从隔离备份重建	季度

表中只是起点，高风险变更后立即专项验证。监管要求可能规定更高频率与证据留存。

三、每次实验必须有可量化目标

目标 RPO <= 60s
目标 RTO <= 15min
切换期核心成功率 >= 99.9%
故障后剩余 CPU <= 70%
任何账务差异 = 0

这些门槛在演练前冻结，不能结束后根据结果改标准。低流量时还要生成代表性验证请求，否则“没有错误”可能只是没有业务。

四、验证链条而不是单组件

数据库提升成功并不代表业务恢复。还要验证应用连接刷新、注册中心、DNS、密钥、消息消费、第三方白名单、监控和客服查询。地域切换还应检查出口 IP、证书、时间同步和跨域配额。

数据方面对比最后确认业务位点、恢复后位点和外部支付/订单流水，计算真实 RPO；按时间线记录检测、决策、恢复、切流和验证，得到真实 RTO。

五、演练本身如何保证安全

从小范围、白名单和低峰开始，设错误率、P99 与金额差异自动停止条件。控制端与被测故障域隔离，回滚命令预先验证。重大演练设置总指挥、观察员和业务确认人，避免多人同时操作。

假设目标 15 分钟，若第 8 分钟错误率超过 2% 持续 30 秒，应按护栏停止，而不是为了完成剧本继续扩大损失。

六、复盘与覆盖度

每个问题记录 owner、期限和复验场景；修复未复验不能关闭。维护“关键假设—最近验证时间—证据”的矩阵，例如旧主 fencing、备用容量、备份可恢复性。这样能发现某个关键能力两年没有真实验证。

指标包括演练覆盖率、按时完成率、实际/目标 RPO RTO、自动化比例、未关闭问题和重复问题。频率过高但每次只走形式，同样没有价值。

七、常见误区与追问

• 误区：每年做一次全量演练就够了。 高频变更会让证据很快失效。
• 误区：演练成功切流就结束。 数据、容量、依赖与回切都需要验证。
• 误区：测试环境演练可以完全代表生产。 真实流量、配额和网络拓扑往往不同。
• 误区：发现问题说明演练失败。 发现并修复未知风险正是演练价值。
• 追问：核心系统多频繁？ 结合风险分层，小故障高频、全地域低频且重大变更后加演。
• 追问：如何避免演练变事故？ 爆炸半径、自动护栏、已验证回滚和明确指挥权。
• 追问：没有真实灾备环境怎么办？ 可先恢复到隔离环境并演练组件，但要记录未验证的真实切流风险。

八、加强记忆

演练频率按“业务风险×变化速度”决定，形式上采用“小故障常练、大切换周期练、重大变更马上练”。每次用 RPO、RTO、业务 SLO、数据和容量验收，问题必须有 owner 并复验。最后维护关键假设的新鲜度，避免一份过期预案制造虚假安全感。