高可用性测试怎么测

“高可用性（High Availability，HA）测试”的目标是验证系统在部分组件故障、网络异常、负载激增等异常情况下，仍能持续对外提供服务，且数据不丢失、体验可接受。下面按方法论 → 测试类型 → 具体怎么做 → 常用工具 → 验收标准来讲。

一、先明确：高可用测什么？

通常关注 4 个维度：

1. 可用性：服务是否一直可访问（如 99.95%）
2. 容错性：单点故障能否自动恢复
3. 数据一致性：故障切换后数据不丢、不错
4. 恢复能力：故障恢复时间（RTO / RPO）

二、常见高可用测试类型

1. 故障注入测试（最核心）

人为制造故障，看系统反应。

典型故障：

• 杀掉进程 / 容器
• 关机、断电
• 网络中断、延迟、丢包
• 磁盘满、CPU 打满
• 依赖服务不可用（DB、Redis、MQ）

做法示例：

• kill -9 应用进程 → 看健康检查 & 重启
• 拔网线 / iptables 禁端口 → 看切换
• 关闭主数据库 → 看是否切到从库

2. 冗余与切换测试

验证“多副本是否真有用”。

• 主备切换（MySQL MHA / Redis Sentinel）
• 多可用区（AZ）故障
• LB 剔除不健康节点
• Kubernetes Pod 重建

关注点：

• 切换是否自动
• 有无脑裂
• 客户端是否感知

3. 负载与容量下的高可用

高负载时是否还能“稳”。

• 正常流量 + 故障叠加
• 突发流量 + 节点宕机
• 限流 / 熔断是否生效

4. 滚动发布 / 升级测试

• 灰度发布中断
• 版本回滚
• 配置错误重启

5. 灾难恢复（DR）测试

• 整个机房不可用
• 跨地域切换
• 备份恢复演练

三、高可用测试怎么做（步骤）

步骤 1：定义 SLA

例如：

• 可用性：99.95%
• RTO < 30s
• RPO = 0

步骤 2：梳理架构与单点

• 是否有单点？
• 依赖哪些服务？
• 超时、重试、降级策略？

步骤 3：设计故障场景

用表格管理：

步骤 4：执行 + 监控

• 实时监控：QPS、错误率、延迟
• 日志 & 告警验证
• 用户视角验证（真的能用吗）

步骤 5：恢复 & 复盘

• 恢复时间统计
• 是否数据一致
• 改进项

四、常用工具

• 故障注入：Chaos Mesh、Litmus、Gremlin、Toxiproxy
• 监控：Prometheus + Grafana、Zabbix
• 压测：JMeter、k6、Locust
• 容器：Kubernetes、Docker
• 网络：tc、iptables

五、验收标准（示例）

✅ 单节点故障无用户感知
✅ 自动切换 < 30s
✅ 数据零丢失
✅ 告警准确触发
✅ 恢复后状态一致

如果你愿意，可以告诉我：

• 是 云原生 / K8s / 传统架构？
• 测 应用 / 数据库 / 微服务？
• 想偏 面试 / 实战 / 方案设计？

我可以直接给你一份可执行的测试方案或用例模板。