7.10.7 典型高可用故障演练与复盘
本节聚焦Web服务高可用场景下的典型故障演练与复盘方法，形成“预案—演练—复盘—改进”的闭环，通过可执行示例验证Nginx与Web服务的故障响应能力与系统韧性。
一、演练目标与范围（含示例SLO定义）
- 验证高可用架构在真实故障下的可用性与容错能力
- 检验监控告警的准确性、及时性与降噪策略
- 评估应急预案与团队协作机制的可执行性
- 发现配置、变更、发布与容量规划中的薄弱环节
示例：定义SLO与阈值（用于验收）
SLO:
- Web首页可用性 >= 99.95%
- 5xx错误率 <= 0.2%
- P95响应时间 <= 300ms
- MTTD <= 1分钟, MTTR <= 5分钟
二、原理草图：高可用故障演练结构
flowchart TD
U[用户] --> LB[VIP/负载均衡]
LB --> NG1[Nginx-1]
LB --> NG2[Nginx-2]
NG1 --> APP1[App-1]
NG2 --> APP2[App-2]
APP1 --> DB[(MySQL)]
APP2 --> DB
MON[监控/告警] -->|指标/日志| NOC[值班响应]
三、典型故障场景设计（含注入方法）
1）负载均衡实例宕机
- 目标：验证自动切换与业务不中断
- 注入：停止Nginx服务或断开VIP
2）后端服务不可用
- 目标：验证上游健康检查、重试与熔断
- 注入：停止后端应用或阻断端口
3）配置误改/误发布
- 目标：验证回滚效率与配置校验
- 注入：错误路由或证书过期
4）突发流量
- 目标：验证限流与队列保护
- 注入：压测或流量回放
5）依赖故障
- 目标：验证降级策略与超时配置
- 注入：DNS异常、数据库连接超时
四、演练流程与关键动作（可执行示例）
1）预案准备
- 明确SLO/SLA、演练窗口、回滚策略
- 配置Nginx健康检查与上游
# /etc/nginx/conf.d/upstream.conf
upstream backend_app {
server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;
server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;
keepalive 64;
}
server {
listen 80;
location / {
proxy_pass http://backend_app;
proxy_connect_timeout 3s;
proxy_read_timeout 5s;
}
}
解释：
- max_fails/fail_timeout：触发健康失败判定
- proxy_*_timeout：控制故障超时与快速失败
2）演练实施：模拟上游不可用（502/504）
# 在后端应用机器停止服务
systemctl stop app.service
# 或模拟端口不可达
iptables -A INPUT -p tcp --dport 8080 -j DROP
# 验证Nginx返回状态
curl -I http://<VIP或NginxIP>/
预期效果：
- 日志出现502/504
- 健康检查触发后切流到可用后端
3）演练实施：模拟Nginx实例宕机
# 在Nginx-1停止服务
systemctl stop nginx
# 客户端连续访问
for i in {1..10}; do curl -s -o /dev/null -w "%{http_code}\n" http://<VIP>/; done
预期效果：
- 服务不中断或短暂抖动
- 监控告警触发，切换成功
4）演练实施：突发流量与限流
# 使用ab进行压测（示例100并发，1万请求）
ab -n 10000 -c 100 http://<VIP>/
# Nginx限流配置
# /etc/nginx/conf.d/limit.conf
limit_req_zone $binary_remote_addr zone=req_limit:10m rate=50r/s;
server {
location /api/ {
limit_req zone=req_limit burst=100 nodelay;
proxy_pass http://backend_app;
}
}
预期效果：
- 429出现但核心接口仍可用
- 后端不被压垮
5）演练实施：配置误改与回滚
# 错误配置模拟
echo "proxy_pass http://wrong_upstream;" >> /etc/nginx/conf.d/upstream.conf
# 检查并提示语法错误
nginx -t
# 回滚配置（示例：使用git或备份）
cp /etc/nginx/conf.d/upstream.conf.bak /etc/nginx/conf.d/upstream.conf
nginx -t && systemctl reload nginx
预期效果：
- nginx -t阻止错误上线
- 回滚后恢复访问
五、监控与排错（含关键命令解释）
- 快速定位错误码与响应耗时
# 查看实时日志与5xx
tail -f /var/log/nginx/error.log
awk '$9 ~ /5../ {print}' /var/log/nginx/access.log | tail -n 20
- 检查上游可达性
curl -I http://10.0.0.11:8080/health
nc -zv 10.0.0.11 8080
- 检查连接与资源
ss -s
top -H -p $(pidof nginx | tr ' ' ',')
解释：
- tail/awk：快速定位错误请求
- curl/nc：验证上游健康与端口
- ss/top：判断连接耗尽或CPU瓶颈
六、演练指标与验收标准（含记录模板）
记录项:
- 故障注入时间:
- 首次告警时间:
- 定位完成时间:
- 修复完成时间:
- 恢复验证时间:
- 业务影响(错误率/P95):
- 自动切换是否成功:
验收标准：
- MTTD <= 60s，MTTR <= 5min
- 核心接口可用性 >= 99.9%
- 自动切换成功率 >= 99%
七、复盘报告模板要点（带示例结构）
事件概述:
- 背景/目的:
- 影响范围:
时间线:
- 10:00 注入故障
- 10:01 告警触发
- 10:03 定位完成
- 10:05 回滚恢复
根因分析:
- 技术原因:
- 流程原因:
处置评价:
- 关键决策:
改进计划:
- 短期(1周内):
- 长期(1个月内):
八、常见改进方向（带可执行动作）
- 增加关键路径监控：新增/api/health、/login监控探针
- 强化自动化回滚：Nginx配置变更必须过CI校验
- 优化限流与重试：设置合理超时与熔断策略
- 建立容量基线：定期压测记录P95、P99
- 完善变更流程：变更需审批与灰度
九、练习与作业
1）在双Nginx环境中模拟Nginx-1宕机，记录MTTD与MTTR。
2）为/api路径添加限流，压测后比较错误率变化。
3）模拟错误配置导致502，完成回滚并更新复盘报告。
4）编写一份演练脚本（含故障注入、验证与回滚步骤）。
通过持续演练与复盘，形成标准化的高可用应急体系，确保Web服务在复杂故障场景下保持稳定与可恢复性。