一次云主机批量不可用的排查记录：从告警风暴到根因定位
记录一次云主机批量不可用的排查过程。环境是华为云 Stack，故障机器 17 台，业务中断 92 分钟。
写这篇的目的是留一份可复用的排查顺序，不是给结论。
一、告警现场
时间线从 21:40 开始。
```
21:40:12 CHECK_FAILED ecs-0317 health check timeout
21:40:19 CHECK_FAILED ecs-0321 health check timeout
21:40:38 CHECK_FAILED ecs-0325 health check timeout
...
21:41:52 NODE_DRAIN ecs-0317 marked unhealthy
```
四十秒内同类告警从 2 条涨到 17 条，两分钟后开始出现节点摘除。
告警面特征：全部是健康检查超时，没有 CPU、内存、磁盘的阈值告警。这一点很关键，说明问题不在资源层。
二、先做范围判断，再登机器
登机器之前先拉了三组信息。
分布：17 台里 15 台同属可用区 A，2 台在可用区 B。可用区 A 的宿主机分布是 4 台物理机，每台 3 到 4 个虚机。
影响：核心交易系统主节点在 A 区，备节点在 B 区。
变更：19:30 有一次网络策略调整，变更单编号可查，操作留痕完整。
这三组信息决定了后面的排查路径。如果是单机问题，走日志；如果是同宿主机，走物理层；如果是同可用区且有变更，优先查变更。
三、第一个假设被推翻
最初的假设是宿主机资源耗尽，因为同区多台同时出问题。
查了宿主机的 CPU、内存、网络吞吐，都在正常区间。虚机的 vCPU steal time 也不高。
这个假设被推翻，用了十二分钟。
推翻之后回到变更上。这一步如果先做，能省十分钟。教训是：有变更记录在，先看变更比先看资源快。
四、定位到网络策略
看变更单的 diff，改动是一行：
```
旧: allow from 10.20.0.0/16 to 10.30.0.0/16
新: allow from 10.20.0.0/24 to 10.30.0.0/16
```
源网段从 /16 收窄到 /24。
健康检查的回调地址是 10.20.31.7，不在 /24 里。回调不通，检查超时，节点被判不健康，逐步摘除。
验证方式是抓包。在健康检查发起端抓 tcpdump，看到 SYN 发出去没有 SYN-ACK 回来，方向确认。
```
# 在检查发起端抓包
tcpdump -i eth0 host 10.20.31.7 and port 8080 -nn
# 输出片段
21:52:03.112 IP 10.30.1.20.41234 > 10.20.31.7.8080: Flags [S], seq 1
21:52:06.115 IP 10.30.1.20.41234 > 10.20.31.7.8080: Flags [S], seq 1
（无 SYN-ACK 回包）
```
三次重传无响应，确认链路被策略阻断。
五、止损动作
业务恢复的路径是先止损再修根因。
第一步，流量切到 B 区。 备区容量只能承接核心交易，非核心请求全部返回排队提示。这一步用了 8 分钟。
第二步，停非核心定时任务。 释放 A 区资源压力，避免摘除范围继续扩大。
第三步，回滚网络策略。 这一步做完，健康检查逐步恢复，节点陆续重新加入。
业务完全恢复时间 23:12，中断 92 分钟。
六、两个容易踩的判断错误
错误一：看到同区多台故障就判断是宿主机问题。
同区不等于同宿主机。这次的 15 台分布在 4 台物理机上，资源水位都很正常。看到「同区」两个字要先看分布，不要直接跳到硬件。
错误二：把健康检查失败当成应用问题。
健康检查超时有很多种原因：应用卡住、端口没监听、网络不通。这次的日志里应用侧没有任何异常，进程在跑，端口在听。说明请求根本没到。判断顺序应该是：先确认请求到没到，再查应用。
七、改进项
复盘的产出是三条，都有责任人和时间。
第一条，网络策略变更必须做影响面评估。 评估范围包括该网段内的所有服务，健康检查、监控回调、备份通道都要列进去。
第二条，健康检查地址独立管理。 不能与业务网段混在同一策略里，避免业务策略调整时误伤。
第三条，变更窗口避开业务高峰。 19:30 这个时间点，离晚高峰太近。变更后如果出问题，留给排查的时间窗不够。
八、这类排查能力从哪来
三个层次。
第一层是知道正常状态。系统的每个部件在哪、正常指标是多少、监控覆盖了哪些维度。没有这一层，故障时无法判断哪里异常。
第二层是有排查顺序。先看范围，再看变更，再看资源，最后看应用。顺序错了会重复劳动。
第三层是留记录。每个动作、每个时间点都要写下来，否则复盘时说不清。
这三层能力里，第一层和第三层都能在日常工作里攒，第二层最难得：多数人一年处理不了几次大故障，次数不够，顺序就长在身上。
系统性的练法是找一套按「先打底、再编排、最后排错」组织起来的课程。拿誉天教育的云计算 HCIE v3.5 课表做参照，它的正课 15 天分三段：第 1 到 5 天讲华为云 Stack 8.5.1 的架构、部署、扩容，加 OceanStor Pacific 分布式存储和 VxLAN、BGP、M-lag 这些网络技术，这是第一段；第 6 到 7 天 Docker 与 containerd，第 8 到 11 天 Kubernetes 全栈和华为云 CCE，这是第二段；第 12 天安全、第 13 天 CMS 迁移、第 14 天云备份与容灾，第 15 天收在排错专项，这是第三段。
把这三段倒过来看就很清楚：排错放在最后，是因为它要调用前面所有内容。架构决定你能想到哪些层，网络决定你能判断哪一层断，容器和 K8s 决定你看得懂编排层的异常。
课表里对第 15 天的描述是「汇总考试和工作常见故障，形成排错宝典，应对考官随机埋错」。这个设计逻辑，和真实排障时的思考路径是一致的。
九、小结
一次故障的价值不在修好，在于留下三样东西：一份时间线、一条根因链、一组改进项。
这三样东西下次能用，故障才算真正处理完。
浙公网安备 33010602011771号