《后端架构设计·高性能与高可用》附录 C 故障演练检查表

演练不是故障表演

故障演练的目的不是“看系统会不会挂”，而是验证三件具体的事：

1. 故障是否被及时观测到；
2. 保护机制是否按设计生效；
3. 恢复路径是否真的可执行。

如果演练结束只留下一段“服务重启后恢复”的记录，没有观测时间线、没有保护机制的状态变化、没有恢复步骤的实际耗时，这次演练的价值接近于零。

卷二讨论的限流、熔断、舱壁、重试、超时、摘流、切换，都是“平时不生效、故障时才生效”的机制。不演练，就无法确认它们是否真的接线正确。本附录给出一套可重复、可中止、可复盘的检查表。

演练前必须确认的十项

十项里最容易缺的是第 7 和第 10。没有中止条件，演练会从“受控实验”变成“真实事故”；没有记录人，事后只能凭记忆复盘，时间线一定失真。

目标要具体

不好的目标：

• 验证系统高可用；
• 提升故障处理能力；
• 看看会不会挂。

好的目标：

• 验证库存服务超时 2 秒时，订单接口在 500ms 内返回降级结果；
• 验证摘除一台实例后，负载在 30 秒内重新均衡，错误率不超过 0.1%；
• 验证主备切换后，写请求在 60 秒内恢复，丢失数据为零。

目标越具体，通过标准越容易写，演练结束后也越容易判断“到底验没验成”。

八个可重复场景

下面八个场景都可以用进程内注入、配置开关或受控的依赖故障实现，不依赖随机网络故障。

场景 1：实例宕机

场景 2：依赖变慢

场景 3：依赖返回错误

场景 4：缓存失效

场景 5：消息积压

场景 6：数据库主备切换

场景 7：限流触发

场景 8：发布与回滚

观测信号对照

演练时最怕“感觉有问题但拿不出证据”。下面是最小信号集，演练前确认每一项都能查到。

演练前做一次“空跑”：不注入故障，只确认这些信号在同一时间窗口内都能看到。空跑能发现大部分采集配置问题，比演练中临时找指标高效得多。

中止与回滚

中止不是失败，是演练的一部分。以下情况应立即停止：

• 影响范围超出审批范围；
• 错误率或延迟超过预设上限；
• 保护机制未生效，且流量持续打向下游；
• 数据出现不一致或不可逆变化；
• 值班人员无法判断当前状态。

回滚步骤要写成可执行的命令，而不是“恢复配置”。例如：

# 1. 停止注入
kill -TERM "$(cat .local/drill/inject.pid)"

# 2. 恢复限流阈值
curl -X POST localhost:8080/admin/ratelimit -d '{"rate":200}'

# 3. 确认指标恢复
curl -s localhost:8080/metrics | grep 'order_http_errors_total'

# 4. 恢复流量
curl -X POST localhost:8080/admin/traffic -d '{"weight":100}'

每一步都要有验证，不能一口气执行完再检查。回滚本身也可能失败，因此要准备“回滚的回滚”——最坏情况下如何回到演练前状态。

执行记录表

演练过程中由记录人填写，不做事后补记。

时间要精确到秒，信号要写具体数值，不写“正常/异常”。事后复盘时，这张表是唯一可靠的事实来源。

演练后复盘

复盘回答四个问题，不追责个人：

1. 目标验证了吗？通过标准是否达成？
2. 观测是否及时？从故障发生到被发现用了多久？
3. 保护机制是否按设计生效？没有生效的原因是什么？
4. 恢复步骤是否可执行？实际耗时与预计差多少？

输出至少包含：

• 一条时间线；
• 一组前后指标对比；
• 一份改进项清单，每项有负责人和截止时间；
• 对检查表本身的修订建议。

改进项要能验证。“加强监控”不是改进项，“为支付超时增加 P99 告警，阈值 800ms，持续 2 分钟”才是。

演练频率与范围

频率不是越高越好。每次演练都有成本和风险，关键是“改动之后有没有验证”。改了限流逻辑却不演练，等于把新逻辑直接交给生产验证。

演练范围应该从单机制开始，逐步扩大。跳过单机制直接做全链路，问题会叠加在一起，既难定位也难中止。

谁应该参加

负责人和操作人分开，是为了避免“操作顺利就继续加码”的惯性。记录人独立，是为了保证时间线不被事后解释覆盖。

七条禁止事项

第一，不在生产环境做未经审批的演练。

第二，不注入无法停止的故障。任何注入都必须有对应的停止手段。

第三，不在没有观测的情况下演练。看不到信号，等于制造事故。

第四，不在流量高峰或大促前演练。

第五，不把演练脚本写成随机破坏。随机性留给专门的混沌平台，卷二强调可重复。

第六，不让同一个人既操作又记录。记录会被操作节奏带偏。

第七，不把演练结果当成“系统没问题”的证明。一次通过只说明这次场景、这次配置、这个时间点通过。

一页清单

打印或复制到演练工单里：

[ ] 目标一句话，含验证的机制
[ ] 影响范围与审批
[ ] 相关团队已通知
[ ] 关键信号空跑可见
[ ] 注入方式可停止
[ ] 中止条件与有权停止的人
[ ] 回滚步骤逐步可执行
[ ] 数据可重置
[ ] 记录人就位
[ ] 时间线开始记录
[ ] 演练后复盘会议已排期
[ ] 改进项有负责人和截止时间

常见错误与边界

第一，只演练“服务挂掉”。真实故障更多是变慢、部分失败和依赖超时；这些场景不会让健康检查失败，却会拖垮调用方。

第二，没有基线。演练前不记录正常指标，事后无法判断“恢复了没有”。

第三，把保护机制当成必然生效。限流、熔断、舱壁都需要配置正确、依赖可用、指标可观测，任何一环缺失都会失效。

第四，演练范围过大。一次只验证一个机制，多个故障叠加会让归因变得不可能。

第五，忽略客户端行为。服务端降级了，客户端是否重试、是否尊重错误码，决定最终用户体验。

第六，复盘没有改进项，或者改进项没有截止时间。这样的复盘只是写了一份文档。

小结

故障演练验证的是观测、保护和恢复三件事，不是“系统会不会挂”。演练前确认十项准备，选择可重复的注入方式，写清中止条件和回滚步骤；演练中由专人记录时间线；演练后输出时间线、指标对比和改进项。

八个场景覆盖实例宕机、依赖变慢、依赖报错、缓存失效、消息积压、主备切换、限流触发和发布回滚。它们都不依赖随机网络故障，适合在受控环境中反复执行。卷四会把其中一部分平台化、自动化，卷二先确保每一次演练都是可控、可观测、可复盘的。