📌 转载说明：本文首发于微信公众号《闫工的算力工具箱》 原文链接：https://mp.weixin.qq.com/s/5CVjC9R8qVRwQVAwphXzBA
我是闫工，数据中心搬砖的CCIE。
前两弹聊的都是工具（SN剪贴速记、硬盘擦除）。这弹换个口味——不卖工具，卖教训。
第一篇实战，讲个我印象最深的故障：凌晨3点，一台8卡GPU服务器，没了。
现场：它死透了，但没死绝 #
凌晨3点，手机震醒。
监控大屏上一片红：集群里一台8卡GPU节点失联，训练任务中断。SSH连不上，ping不通——硬掉线。
那一瞬间脑子里闪过的念头很真实：炸了？这么贵的GPU设备，大半夜的……
但我没往机房跑。因为这台机器虽然"死"了，主板上还住着一个独立供电、独立网络的小东西——BMC。它还在线。
登录BMC网页，第一眼就翻它的系统事件日志（SEL，相当于服务器的"黑匣子"）。里面反复出现这么几行：
SEL #123 | Power Unit | Power off/down | Asserted
SEL #124 | Power Unit | Power off/down | Deasserted
SEL #125 | Power Unit | Power off/down | Asserted
SEL #126 | Power Unit | Power off/down | DeassertedAsserted = 掉电，Deasserted = 恢复。交替出现，反复横跳。
翻译成人话：机器的供电在"抖"——掉一下、回来、再掉一下、又回来。不是软件崩了，是电没供稳，主机被物理拽停。
图：电源页面拉出来一看——PSU3 紧急、PSU4 轻微，另外两块正常
OK，有方向了。接下来一步步查。
查证：一步步锁定真凶 #
第一步：确认是哪块电源模块出了问题
GPU服务器通常配4到6个电源模块（GPU功耗大，冗余必须拉满）。用 ipmitool 扫一遍PSU状态：
ipmitool -I lanplus -H 192.168.x.x -U admin -P '******' sdr list | grep -i psu输出：
PSU1 Status | ok
PSU2 Status | ok
PSU3 Status | failure
PSU4 Status | okPSU3 状态是 failure，其他三块正常。这台机器是4电源冗余配置（N+N或N+1），坏一块按理说还能撑住。但SEL里显示的是反复掉电恢复，说明不止是"坏了一块"那么简单——剩下的PSU在负载波动时也扛不住了，或者坏的那块在反复尝试上线又失败，把整路电都拖得不稳。
第二步：排除软件层面
掉电第一反应是"是不是系统里有人触发了关机"？查操作系统日志：
journalctl --since "2:00:00" | grep -i "shutdown\|poweroff\|thermal"干干净净，啥也没有。dmesg 里也没有温度过高的告警。说明关机不是操作系统主动触发的，是硬件层直接被拽断了。
第三步：排查机房供电环境
电源冗余的机器，如果PDU有一路在闪断，SEL里也会出现类似的"掉电/恢复"交替记录。让机房值班同事帮忙看了一眼那台机器所在的PDU端口指示灯——正常亮着，没有闪烁。电源线也重新插拔了一遍，确认没有虚接。
线索收束：PSU3硬件故障 + 负载波动时供电不稳 → 机器被反复拽停。
图：BMC 告警面板拉满——PSU3 紧急（电源输入丢失）、HDD0 严重（驱动器故障），电源和存储同时报警
顺带挖出第二颗雷 #
那晚顺手打开了BMC的远程KVM（就是隔空看屏幕），想确认机器死的时候屏幕上有没有留下什么。
结果看到了一个 kernel panic 界面：
RIP: 0010:ceph_set_page_dirty+0x1ba/0x1c0 [ceph]
---[ end trace f6f982abafac13ee ]---
CR2: 0000000000000070旁边 nvidia_uvm、nvidia_drm 这些NVIDIA驱动模块还挂在 Tainted（内核污染）列表里。
意思很明确：这台机器除了电源隐患，还埋着另一颗雷——NVIDIA驱动和内核/Ceph存储I/O有兼容性问题。高负载下自旋锁死锁（日志里能看到 native_queued_spin_lock_slowpath），驱动崩了连带kernel一起panic。电源抖是"导火索"，驱动不稳是"体质问题"。
真要长治久安，驱动版本和内核得对齐，Ceph客户端的I/O压力也得调。
真凶找到了，怎么救？ #
短期止血：
- 远程冷重启（Power Cycle）——先把业务拉起来，训练任务恢复
- 锁定PSU3，不让它再上线（有故障的电源模块反复尝试接入反而会拖累整路电）
- 排期更换掉PSU3硬件
图：锁定 PSU3、更换掉之后——四路电源全部恢复正常，电压/功耗/温度/转速一目了然
长期根治：
- GPU服务器电源冗余配置要留足余量，别让PSU额定功率贴着峰值功耗跑
- PSU状态必须上监控告警，不能等关机了才翻SEL——坏一块就应该报警
- 机房供电波动也要纳入告警范围（部分数据中心支持PDU级别的电压/电流监控）
- 驱动版本和内核版本对齐NVIDIA官方兼容矩阵，别用"能跑就行"的版本凑合
那一晚踩的四个坑 #
坑一：操作系统日志干干净净，差点误判
系统日志里啥异常都没有——因为掉电是硬件层的事，OS层面的日志根本来不及写。真相只在BMC SEL里。
教训：服务器"无故关机"，第一反应别查/var/log，先查带外。
坑二：以为SSH能看现场，结果机器硬掉线
人在被窝，唯一能戳到机器的就是BMC的KVM/SOL/远程Power Cycle。没配带外管理的机器，大半夜只能跑机房。
坑三：SOL连上黑屏啥也没有
SOL（Serial over LAN）能把服务器的串口重定向到你这端，BIOS、启动信息都能远程看。但连上黑屏，根因在被控端没配全：
- 没开串口服务：
sudo systemctl enable --now serial-getty@ttyS0.service（状态得是active (running)） - GRUB没把启动输出导向
ttyS0 - 控制端命令少了
-I lanplus——SOL必须走lanplus通道，用默认lan连上就是黑屏 - 防火墙没放行UDP 623端口
四缺一就黑屏，查了一遍才发现是第三项。
坑四：电源"冗余"被当成免死金牌
一只PSU悄悄failure，系统靠其他几只硬撑，平时根本发现不了——直到负载一高剩下的也扛不住，才彻底宕机。
冗余保的是"不瞬间死"，不保"你不用管"。PSU状态得上监控告警，别等关机了才翻SEL。
结尾 #
这台8卡GPU节点的那一夜，是我对"带外管理"最刻骨铭心的一课：主机会死，但BMC记下了它怎么死的。 半夜把你叫醒的从来不是机器，是没配好的监控。
下篇不聊故障了，换个话题——一台裸金属服务器，MAAS 死活不认 Rocky Linux。我不改 MAAS，从头 Packer 打包了一个镜像，硬塞进去。
关注我，下期见。