在运维虚拟机的时候，谁还没碰上过几次蓝屏、卡死、网络不通的问题？老张昨天下午就遇到一台 CentOS 虚拟机突然 SSH 登不进去，Ping 也通不了。他第一反应是重启，结果一重启，数据丢了半截。后来翻来覆去查日志，才意识到——早该有一份清晰的故障处理文档。
故障发生时，先记下这五件事
很多人一出问题就开始猛操作，修好了算运气，修不好连怎么坏的都说不清。正确的做法是：先暂停手，打开记事本，把以下信息一条条记下来：
- 故障发生的具体时间（精确到分钟）
- 现象描述（比如“无法SSH登录”“磁盘使用率突然飙到98%”）
- 影响范围（是单台虚拟机还是整个集群？业务是否中断？）
- 最近有没有做过变更（比如升级内核、修改网络配置、扩容内存）
- 相关日志片段（/var/log/messages、dmesg 输出、vCenter 告警）
这些不是走形式，而是为了下次再遇到类似问题，能快速定位是不是“老毛病复发”。
模板长什么样？直接上例子
下面是一个真实的处理记录片段，适用于 KVM 环境下的 Linux 虚拟机：
故障编号：VM-20240415-001
发生时间：2024-04-15 14:22
虚拟机名称：webapp-prod-03
宿主机：kvm-host-07
现象：SSH连接超时，控制台显示系统无响应
排查步骤：
1. 登录 vCenter 检查资源使用情况 → CPU持续100%，内存无异常
2. 查看 dmesg 日志 → 发现大量 ext4 文件系统错误
3. 尝试进入救援模式执行 fsck → 修复成功
处理结果：重启后恢复正常，挂载检查无误
后续建议：增加每日 fsck 计划任务，监控文件系统健康状态这种格式不用花里胡哨，关键是信息完整、可追溯。团队新人看了也能照着操作。
别等出事才想起写
很多公司都是“出了大事”才想起来要补文档，其实平时就得养成习惯。每次处理完一个异常，哪怕只是改了个 IP 地址导致网断了，也该随手记一笔。把这些小记录存到共享知识库，比如 Confluence 或飞书文档，加个标签 #虚拟机故障，以后搜索“SSH 连不上”就能蹦出一堆参考案例。
你写的每一份故障处理文档，都是给未来自己的一封救命信。
让文档活起来
写完不是终点。建议每个月抽半小时，翻翻最近的故障记录，看看有没有重复出现的问题。比如连续三周都有虚拟机磁盘满，那就不只是“清一下空间”的事了，得考虑自动清理策略或者告警阈值调整。
文档写得好，不仅能救火，还能防火。