定期做集群故障注入测试是为了提前暴露问题，核心是验证关键SLA指标（如订单成功率、P99延迟等），聚焦三类高频故障，自动化闭环执行，并依据结果更新配置或代码以实现确定性加固。
定期做集群故障注入测试，不是为了“搞垮系统”，而是让系统在出问题前先暴露问题。关键不在频率高低，而在每次测试是否真能验证核心链路的韧性。
明确每次测试要验证什么
别一上来就 kill -9 或断网。先锁定业务最关键的 SLA 指标：比如订单写入成功率、查询 P99 延迟、服务自动迁移时间、数据最终一致性窗口。每个测试场景必须对应至少一个可观测指标，否则就是无效演练。
用最小扰动覆盖高频故障类型
不需要每次都模拟“全集群崩塌”。日常演练聚焦三类最常发生的故障：
- 节点进程意外终止（如
kill -9mysqld / datanode / namesrv） - 网络临时中断（用
tc netem或iptables DROP模拟单向丢包或延迟） - 关键服务卡死或响应超时（如 mock 数据库连接池耗尽、etcd leader 切换卡顿）
每次选 1–2 种组合，控制在 5–10 分钟内完成注入 + 观察 + 恢复闭环。
自动化执行 + 自动校验，避免人工判断偏差
把测试脚本和验证逻辑打包成可重复运行的单元：
- 启动前快照关键状态（如
pvecm status、md5sum核心配置、journalctl -n 50 -u pve-ha-lrm） - 注入后轮询健康接口（如
/health,/metrics），等待恢复信号 - 自动比对日志关键词（如 “failover completed”、“new leader elected”、“recovered from partition”）
- 失败时自动截图日志、保存监控曲线、触发告警通知
每次演练后必须做一件事：更新应急预案
不是写文档，而是改代码或配置：
- 如果发现某节点宕机后迁移超时，就调小
ha-migration-timeout参数 - 如果网络恢复后数据不一致，就补上
wsrep_sync_wait=1或调整raft-election-timeout - 如果监控没报警，就加一条 Prometheus alert rule 或 Zabbix trigger
让每一次故障都变成一次确定性的加固动作。
不复杂但容易忽略
