定期做集群故障注入测试是为了提前暴露问题，核心是验证关键sla指标（如订单成功率、p99延迟等），聚焦三类高频故障，自动化闭环执行，并依据结果更新配置或代码以实现确定性加固。

定期做集群故障注入测试，不是为了“搞垮系统”，而是让系统在出问题前先暴露问题。关键不在频率高低，而在每次测试是否真能验证核心链路的韧性。

Hedra

Hedra是一款用于生成说话角色、口型同步和角色视频的 AI 视觉创作平台。

下载

明确每次测试要验证什么
别一上来就 kill -9 或断网。先锁定业务最关键的 SLA 指标：比如订单写入成功率、查询 P99 延迟、服务自动迁移时间、数据最终一致性窗口。每个测试场景必须对应至少一个可观测指标，否则就是无效演练。

用最小扰动覆盖高频故障类型
不需要每次都模拟“全集群崩塌”。日常演练聚焦三类最常发生的故障：

• 节点进程意外终止（如 kill -9 mysqld / 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
  让每一次故障都变成一次确定性的加固动作。

不复杂但容易忽略