演练要验证什么
故障演练是用受控实验代替猜测：主动注入延迟、错误、实例退出或依赖中断，观察监控能否按预期发现、告警能否按时触达、预案是否真的可执行。产出不是“系统扛住了”这句结论，而是一份改进清单：哪些告警没触发、哪些看板缺数据、哪些步骤在文档里写错了。
| 演练前 | 写下假设（例如主库宕机应在 2 分钟内触发告警）与回滚方案，通知相关方 |
|---|---|
| 演练中 | 记录告警时间线、人工处置动作与数据缺口，指定专人记录 |
| 演练后 | 输出改进项：新增或调整告警、补充看板、修订预案与 runbook |
可注入的故障类型
- 实例级：杀掉进程或 Pod，验证副本接管与重启告警是否按预期触发
- 资源级：注入 CPU、内存、磁盘压力，验证容量类告警阈值是否合理
- 网络级：注入延迟、丢包、断开依赖链路，验证超时与降级策略
- 依赖级：关闭从库或暂停下游服务，验证级联影响是否可见
- 数据级：制造慢查询或大事务，验证数据库层告警与查询耗时看板
演练记录模板
演练记录模板
实验：关闭订单库从库
假设：2 分钟内触发 ReplicaDown（P2），5 分钟内触发复制延迟告警
回滚：重新拉起复制进程并核对数据一致性
实际：ReplicaDown 在 1m12s 触发；延迟告警未触发（阈值偏高）
结论：告警覆盖存在缺口
改进：调整复制延迟阈值；补充复制中断看板，并列入下次演练复测项从只读演练做起：先只观察注入的延迟而不直接断开依赖，确认链路通畅后再提高实验强度，避免把演练变成真实事故。
演练必须有回滚预案并避开业务高峰；在核心交易时段注入故障，等于人为制造一次生产事故。