适用场景

演练的目的不是「证明系统很强」，而是找出预案里没写的坑。所以要先做桌面推演找出流程问题，再做真实注入验证技术手段，最后一定要记录并闭环改进项。

配置步骤（演练日组织与执行）

# 演练日流程（半天）
09:00 开工会：宣布范围、角色、沟通渠道、终止条件
09:15 基线采集：记录当前业务指标（错误率、时延、容量水位）
09:30 注入 1：单实例故障（进程被杀 / 实例下线）
    观察：告警时间、自动恢复时间、业务影响
10:00 注入 2：依赖超时（下游延迟注入 500ms）
    观察：熔断是否触发、降级是否生效
10:30 注入 3：数据库主从切换或读写延迟
11:00 停止注入，恢复环境，验证业务回到基线
11:15 复盘会：时间线、问题、改进项

关键参数与建议

  • 分级：桌面推演 → 单组件注入 → 全链路演练，逐级提升风险
  • 实验设计：明确假设（预期行为）、注入内容、观察指标、终止条件
  • 影响面控制：先在测试/预发环境，生产演练要选低峰并设爆炸半径
  • 终止条件：错误率或时延超阈值立即停止注入（kill switch）
  • 参与角色：指挥、执行、观察、业务验证，四方齐全
  • 观察项：告警是否触发、预案是否可执行、切换是否在规定时间内完成
  • 复盘：时间线 + 问题清单 + 改进项（负责人与时间）
  • 常态化：每季度至少一次单组件注入，每年一次全链路

容易踩的坑

  • 没有基线采集，演练后无法判断影响
  • 注入顺序不合理，前面的问题没恢复就叠下一个
  • 无人记录时间线，复盘全靠回忆
  • 观察组与执行组沟通不畅，误操作互相冲突
  • 演练结束不恢复环境，第二天业务异常
  • 复盘只谈技术，忽略流程与沟通问题

验证与巡检

# 演练记录字段
时间 | 动作 | 预期 | 实际 | 告警是否触发 | 耗时 | 问题

# 演练后确认
1) 业务指标回到基线
2) 所有注入项已恢复
3) 改进项清单已建立
  • 巡检：时间线记录完整、环境已恢复、改进项有责任人与完成时间

小结

故障演练验收：告警在规定时间内触发、预案步骤可执行、RTO 达标，且产出的改进项在下一次演练前全部闭环。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。