文章目录
一、问题背景
今日，某台部署在私有云环境下的物理服务器（node）连续发生 4 次异常宕机重启，导致托管的虚拟机频繁迁移，业务运行受影响。
二、问题排查
常规运维经验告诉我们：系统出问题，日志应该最先提示线索。但本次故障让我“毫无头绪”，因为：
在宕机的时间点，系统 message 日志突然中断，无 kernel panic、无 call trace、无软硬件告警。
这意味着，系统 来不及说话 就 嘎了。
三、问题分析
我们从三条线索入手，逐步排查，从 没有异常 中找异常
1. 软件层排查（OS日志）
- 查看
/var/log/messages：日志突然停止 - 无异常内核信息，无应用层异常输出
- 说明 宕机发生在内核以下，OS无法感知。
2. 带外排查（BMC/iBMC）
- 使用带外管理查看 SEL 日志；
- 无温度、电压、电源、电扇等硬件异常；
- 说明：不是传统硬件部件引起的问题。
3. 平台侧排查（云平台告警）
- 云平台无相关报错日志
- CPU/内存/IO 等资源使用平稳；
- 确认不是高负载、资源争用引发的异常。
四、核心判断
为什么日志中无告警？结合厂商反馈和经验明确：
宕机日志缺失的根本原因是：
CPU 本体在某一瞬间发生硬故障（如核心锁死、内部通道失效），OS 根本未收到中断信号，也就来不及写日志。
这在业内被称为silent failure，即沉默的故障，常见于以下情况：
- CPU 缓存控制器异常
- 多核一致性崩溃
- 微码缺陷未修补
- CPU核心热崩，但热保护未触发
所以，日志中没有异常本身就是异常！
五、处理方案
| 步骤 | 操作说明 |
|---|---|
| 1 | 联系厂商，提交日志、序列号等数据 |
| 2 | 厂商分析 BIOS 版本过低，缺失 CPU 补丁（当前为 6.55） |
| 3 | 初步判断为 CPU 本体故障，建议更换 CPU 并升级 BIOS |
| 4 | 实施操作： 虚拟机从 node 迁出 - 停机 - 更换两颗 CPU - BIOS 升级 |
| 5 | 恢复上线后持续观察，宕机未复现，系统稳定运行 |
六、经验总结
日志没报错不代表没问题，尤其是底层硬件故障，系统常常来不及上报
关于BIOS固件更新，新版本BIOS经常会更新cpu微码，修复隐藏bug
带外监控不能代替主动巡检，带外管理只能检测报的出来的问题
“没有告警”的服务器问题，是运维中最难处理的一类故障。
日志之外，还有真相；症状之外，要靠逻辑。
希望这次 CPU 故障排查记录对你有帮助。如果你在日常运维中也遇到类似“无预警宕机”问题，欢迎留言交流。