验证高可用系统自愈能力的核心是真实故障场景下无需人工干预、预期时间内恢复服务且不丢数据不中断业务；需覆盖节点级、服务级、网络异常、资源耗尽四类故障，端到端量化可用性、一致性、收敛时间及副作用，并结构化执行fmea式验证流程。
验证高可用系统的自动自愈能力，核心不是“看它有没有重启”，而是在真实故障场景下，系统能否不依赖人工干预、在预期时间内恢复服务且不丢数据、不中断业务。关键在于主动制造可控故障，并观察响应是否符合设计预期。
故障注入要贴近真实风险点
不能只 kill -9 一个进程就完事。需覆盖常见失效模式：
- 节点级故障：关闭某台服务器电源、拔网线、模拟宿主机宕机（对容器平台尤其重要）
- 服务级故障：强制终止主数据库进程、阻塞 Redis 主节点写入、让 Kafka broker 失联
- 网络异常：用 tc 工具模拟延迟、丢包、分区（如断开集群中两个分片间的通信）
- 资源耗尽：触发 OOM Killer、填满磁盘、压满 CPU 导致探针超时
例如，在 Kubernetes 环境中，直接删掉一个 Pod 是弱验证；而用
kubectl drain驱逐整个 Node，或关掉该节点物理网卡，才能测出多副本调度、拓扑分布、Service 流量剔除是否真正生效。
观察指标必须端到端可量化
不能只看“Pod 起来了”或“哨兵日志说切换成功”。要确认：
- 服务可用性：从客户端视角，HTTP 请求成功率是否在 30 秒内回到 100%，P99 延迟是否未突增
- 数据一致性：切换前后关键业务数据（如订单号、库存值）是否完整、无重复、无丢失
- 状态收敛时间：从故障发生到系统稳定（所有探针通过、流量完全切回、监控无告警）的精确耗时
- 副作用检查：是否有连接泄漏、事务卡住、消息重复投递、缓存雪崩等次生问题
比如 Redis Cluster 故障转移后，不仅要查
CLUSTER NODES看主从关系是否重建，还要用INFO replication确认新主节点的connected_slaves和master_repl_offset是否正常推进，再比对客户端写入计数与从节点同步偏移量是否一致。
验证流程需结构化、可回放
建议按 FMEA（失效模式与影响分析）思路建清单，每次演练前明确：
- 当前验证的是哪个组件的哪类故障（如 “MySQL 主节点磁盘只读”）
- 预期触发哪条自愈路径（如 “MHA 自动提升从库 + 应用层重连”）
- 具体观测项和阈值（如 “切换时间 ≤ 25 秒，期间最多丢失 1 条 binlog event”）
- 回滚方式与失败兜底动作（如 “若 60 秒未恢复，手动执行 VIP 切换”）
这样每次验证都有记录、可对比、能归因。线上事故复盘时，也能快速定位是设计缺陷（比如没考虑磁盘只读）、配置偏差（如探针 timeout 设太短），还是代码 Bug（如连接池未处理 connection reset）。
不复杂但容易忽略。
