nginx高可用应急预案演练核心是用真实故障验证容灾能力，需聚焦主节点崩溃、宕机、网络分区及上游批量不可用四类场景，完成配置同步、健康检查脚本、监控日志、验证工具四项准备，并量化vip漂移延迟、rto等指标，最后闭环复盘与自动化沉淀。
实现 Nginx 高可用架构的应急预案演练，核心是“用真实故障验证容灾能力”，而不是仅检查配置是否在线。关键在于模拟典型中断场景、观察自动切换行为、记录恢复时效，并暴露配置或流程中的断点。
明确要演练的故障类型
不是所有故障都需同等强度演练，应聚焦对业务影响最大、发生概率较高的几类：
- 主节点 Nginx 进程崩溃：如 kill -9 主节点 nginx worker 或 master 进程，测试 Keepalived 是否触发 VIP 漂移
- 主节点服务器宕机：直接关机或断电（物理/虚拟环境均可），验证备节点能否在 3 秒内接管 VIP 并响应请求
- 网络分区（脑裂）模拟：在主节点上临时禁用 VRRP 通信端口（如 iptables -A INPUT -p vrrp -j DROP），观察 Keepalived 状态日志与 VIP 行为
- 上游服务批量不可用：停掉全部后端应用节点，验证 Nginx 的 proxy_next_upstream 机制是否生效，错误页是否按预期返回
演练前必须完成的准备动作
未做准备的演练等于无效测试。以下四项缺一不可：
- 配置完全同步：主备节点的 /etc/nginx/nginx.conf、/etc/keepalived/keepalived.conf 必须 md5sum 一致；尤其注意 upstream 块、健康检查参数、vrrp_instance 中的 virtual_router_id 和 auth_pass
- 健康检查脚本就位且可执行：例如 /etc/keepalived/check_nginx.sh 需返回 0（正常）或非 0（异常），并被 vrrp_script 正确引用；建议加入超时控制（timeout 2 curl -s --max-time 2 http://127.0.0.1/health）
- 监控与日志通道畅通：确保能实时查看 keepalived 日志（journalctl -u keepalived -f）、Nginx error.log、VIP 绑定状态（ip addr show | grep "inet.*192.168"）
- 验证工具就绪：准备一个持续请求脚本（如 while true; do curl -s -o /dev/null -w "%{http_code}\n" http://$VIP/ --connect-timeout 2; sleep 0.5; done），用于观测服务中断窗口
演练过程的关键观察点
不能只看“是否切过去了”，要量化关键指标：
- VIP 漂移延迟：从主节点失联（或进程终止）到备节点 ip addr 显示 VIP 的时间，理想值 ≤ 3 秒（由 advert_int + 3×fail_count 决定）
- 服务恢复时间（RTO）：从故障发生到客户端收到首个 200 响应的时间；需排除 DNS 缓存干扰，直连 VIP 测试
- 连接中断数：在切换窗口内，curl 请求返回 000、Connection refused 或超时的数量，反映平滑性
- 日志一致性：切换后，新请求是否写入备节点的 access.log？旧主节点重启后，是否避免双写冲突？
演练后的闭环动作
一次演练的价值取决于复盘深度：
- 记录所有告警与日志片段：特别是 keepalived 的 “Master received advert from backup”、“Becoming master” 等关键事件时间戳
- 对比基线数据：将本次 RTO 与上次演练或 SLA 要求（如 ≤ 5 秒）比对，偏差超 20% 即需分析
- 更新应急预案文档：若发现原步骤中缺少“检查 upstream server 状态”或“切换后手动验证后端连通性”，立即补充进 SOP
- 自动化演练脚本沉淀：将故障注入（如 systemctl stop nginx）、状态采集（ip addr、curl）、结果判断（HTTP 状态码统计）封装为可重复执行的 Bash/Python 脚本，纳入 CI 流水线定期运行
