不同虚拟化平台的产品名称和界面会变化，但故障现象高度重复。虚拟机卡顿、迁移失败、存储断连、主机失联，最终都要回到资源、链路、服务和时间线。相比记住每个按钮，建立固定排障顺序更可靠。

READING NOTES

本文要点

  • 先问业务影响，不要一上来就重启服务
  • 把计算、存储、网络和管理面信号对到同一时间线
  • 每个恢复动作前后都留证据，并提前写回退条件

01｜先把“卡”问清楚

用户反馈虚拟机卡顿时，需要继续确认：是一台还是一批、操作系统卡还是应用卡、从几点开始、是否做过变更、同主机或同存储上的其他虚拟机是否正常。几分钟内确认影响范围，通常比先登录平台翻告警更省时间。

如果只有一台虚拟机异常，先检查来宾系统和虚拟硬件；同一主机多台异常，就检查主机和上联；跨主机但同一存储异常，应重点检查存储路径与阵列；只有管理页面异常，则先区分管理面和业务面。

02｜四层证据怎么收

建议在工单里固定四个检查分类。计算层关注 CPU 调度、内存交换、NUMA 和硬件事件；存储层关注时延、队列、容量与路径；网络层关注丢包、错包、MTU、VLAN 和聚合；管理面关注服务、任务、证书、数据库和集群状态。

故障时间 T0
├─ 计算：CPU ready / steal / swap / NUMA / hardware
├─ 存储：latency / queue / path / capacity / rebuild
├─ 网络：drop / error / MTU / VLAN / bond
└─ 管理：service / task / certificate / database

03｜怎样判断告警是不是根因

一台主机存储断连时，平台可能同时报告数据存储不可达、虚拟机暂停、迁移失败和 HA 异常。告警数量最多的项目不一定是根因。应按时间排序，寻找最早出现且能解释其他现象的信号。

同时进行交叉验证：平台报告网络中断，就检查交换机端口和主机网卡计数；平台报告磁盘变慢，就检查阵列端口和其他主机；平台报告资源不足，就检查业务监控是否在同一时间出现响应升高。至少两类证据指向同一方向后，再开始修改配置。

04｜恢复不是“点一下看看”

重启管理服务、迁移虚拟机、切换路径都可能让故障暂时消失，但也可能破坏现场。执行前应写明动作目的、影响对象、成功标准和回退条件。能够先收集日志就不要急于重启，能够隔离测试就不要直接修改生产环境。

  • 动作前：保存事件、性能图、日志时间范围和当前拓扑。
  • 动作中：一次只改一个变量，记录执行人与准确时间。
  • 动作后：同时验证业务、虚拟化平台和底层设备。
  • 未达到成功标准：按预定条件回退，不连续试多个高风险动作。

05｜复盘要能被下一位工程师直接使用

复盘不能只写“重启后恢复”。一份有用的复盘至少要有现象、范围、时间线、证据、根因、恢复、验证和预防八项。暂时找不到根因时，应明确标注“当前推断”和“缺少的证据”，不要把猜测写成结论。

重复出现的问题应补充监控；需要多人反复协作的问题应整理成 SOP；只有命令和判断规则稳定后，才适合继续做成脚本或 AI Ops 工具。