3. 故障演练方案设计方法

故障演练方案不是一份“操作步骤清单”，而是一份把风险、动作、边界和验收绑定在一起的工程契约。方案设计得越具体，演练时越不容易失控；方案设计得越模糊，演练就越容易变成“碰运气”。本节围绕六个核心要素展开：演练范围、故障注入点、影响面评估、回滚策略、成功标准与演练报告模板，并给出可直接参考的示例结构。

一、先定义演练范围：把“能碰什么”写死

演练范围回答三个问题：演练哪些系统、哪些环境、哪些时间段、哪些人员参与。范围定义必须落到具体对象，而不是“核心业务”这类模糊描述。例如，一次针对 Redis 主从切换的演练，范围可以写成：

• 系统范围：订单服务的 Redis 集群 order-cache-prod，包含 1 主 2 从、3 个哨兵节点。
• 环境范围：预发布环境 staging，与生产同拓扑但数据为脱敏副本。
• 时间窗口：周六 02:00–04:00，避开订单高峰与对账任务。
• 人员范围：DBA 1 人、SRE 1 人、业务研发 1 人、观察员 1 人。
• 明确排除：不涉及支付网关、不修改持久化配置、不触发全量数据迁移。

范围一旦确定，任何超出范围的临时动作都必须走变更审批，否则演练就失去了“可控”的前提。

二、故障注入点：选在“能验证恢复能力”的位置

故障注入点不是随便挑一个节点杀掉，而是根据演练目标选择能暴露恢复链路薄弱环节的位置。常见注入点与验证目标如下：

选择注入点时，要遵循“单点可控、可观测、可回滚”原则。一次演练只注入一个主要故障，避免多故障叠加导致无法归因。注入前必须确认该点有对应的监控指标和日志，否则故障发生了也看不到证据。

三、影响面评估：从“技术影响”推到“业务影响”

影响面评估要回答：故障注入后，哪些用户、哪些接口、哪些数据会受影响，影响持续多久，是否可接受。建议按“技术链路 → 业务功能 → 用户感知”三层展开：

• 技术链路：主节点不可用 → 写请求失败 → 客户端重试 → 哨兵选主 → 新主可写。预计恢复时间 10–30 秒。
• 业务功能：订单创建接口依赖 Redis 写缓存，若重试窗口内未恢复，部分请求返回 503。
• 用户感知：预发布环境无真实用户，影响面为 0；若在生产演练，需评估订单失败率是否超过 0.1%。

影响面评估的结论应直接决定演练是否继续。如果评估发现“恢复时间可能超过业务容忍阈值”，就必须先补充降级方案或缩小注入范围，而不是硬着头皮执行。

四、回滚策略：不是“恢复原状”四个字

回滚策略必须包含触发条件、回滚动作、回滚验证、回滚时限。以主节点故障注入为例：

触发条件：选主超过 60 秒未完成，或业务错误率超过 1%
回滚动作：
  1. 停止故障注入（恢复网络/重启进程）
  2. 若哨兵未自动选主，手动执行 SLAVEOF NO ONE 提升从节点
  3. 将客户端指向新主节点，确认连接池恢复
回滚验证：PING 返回 PONG，写入测试 key 成功，监控错误率回落至 0.1% 以下
回滚时限：从触发到业务恢复不超过 5 分钟

回滚策略要提前在预发布环境验证一遍，确保命令、权限、路径都是真实可用的。演练现场最怕“回滚脚本跑不通”，那等于没有回滚。

五、成功标准：可量化、可判定、可复现

成功标准不能是“系统恢复正常”这种主观描述，而应写成可观测的指标。例如：

• 故障注入后，哨兵在 30 秒内完成主从切换。
• 客户端在 60 秒内全部重连到新主节点。
• 演练期间写入失败请求占比 低于 0.5%。
• 切换后主从数据差异为 0 条（通过抽样比对验证）。
• 所有告警在 2 分钟内触发并通知到值班人。

成功标准要区分“必须达成”和“观察项”。必须达成的指标未通过，演练判定为失败，需要复盘改进；观察项用于收集数据，不直接判定成败。

六、演练报告模板：把过程变成可追溯资产

演练报告不是流水账，而是把假设、动作、观测、结论、改进项固化下来。以下模板可直接参考：

报告应在演练结束后 24 小时内完成初稿，改进项要指定负责人和截止时间，否则报告就只是归档文件，无法推动系统真正变强。