谈国平深夜告警炸裂？这份Linux故障排查“作战地图”请收好
凌晨两点半，手机连续震了六七下，监控大屏一片红。作为一个被Linux服务器告警支配过无数次的人，我太熟悉这种心跳加速的感觉了。CPU 100%、磁盘满、进程挂掉、端口失联……每一条告警背后都意味着一台机器正在拉响警报，而你要在最短时间内判断“这到底是不是事故”“影响面多大”“要不要立刻叫醒别人”。
这篇文章就是一份Linux故障排查“作战地图”。它不会教你背命令，而是告诉你：收到告警后第一件事做什么、第二件事做什么、什么情况该优先救火、什么情况可以先深挖根因。适合所有被Linux告警追着跑的运维、后端开发、SRE和刚入行的系统管理员。即使你现在还没遇到“炸裂”的深夜，也建议先收藏，等真出事的时候，你会感谢这份地图。
1. 告警响应的第一原则：先恢复，后排查
很多人一收到告警就冲进服务器，top、free、df一顿敲，恨不得马上找到“罪魁祸首”。这个方向没错，但顺序容易出问题。要知道，凌晨两点的告警，KPI永远只有一个：让业务先恢复正常，再考虑“为什么”的问题。
1.1 收到告警后，先回答这三个问题
在我眼里，任何告警都是一道三选一的判断题：
- 这是不是真的故障？有些告警是误报，比如监控项阈值设得过低、vSphere证书状态告警到期、zabbix采集器自身卡死，业务其实稳如泰山。这类告警的典型特点是：只有监控平台在喊，业务无感，登录服务器看各项指标都正常。
- 影响范围有多大？单机影响还是集群整体？一个节点挂了，有负载均衡兜底，你可以从容处理；如果是数据库主库告警，那就得立刻评估是否需要切换。
- 能不能快速止血？重启服务、重启机器、回滚版本、摘流量，哪一步最快能恢复业务？先做，再慢慢复盘。
这三点想清楚，你就知道自己处在“救火模式”还是“排查模式”。救火模式下的原则是：不做任何可能让情况恶化的操作。比如机器负载极高时不要贸然重启，除非你确认手里的重启操作能带来正面效果。
1.2 建立你自己的“告警速查手册”
我自己有一个习惯：每处理完一次故障，就把告警内容、登录后第一眼看到的指标、根因、处理动作、验证方式压缩成三五句话，记到本地笔记里。时间久了，这本手册就成了个人“作战地图”的核心。
举个例子，某次vSphere证书状态告警，我第一次遇到时还去查ESXi证书体系，折腾了半小时。后来手册里多了一行：证书告警不等于系统故障，登录vCenter确认过期时间和影响范围，通常可以顺延处理。再遇到同类告警，三分钟就能定位。这个习惯在深夜告警场景下特别值钱——凌晨的大脑本来就不如白天清醒，有一份现成的速查记录，能帮你少走很多弯路。
1.3 认清告警背后的“系统画像”
不同角色的服务器，故障优先级完全不同。数据库服务器的CPU飙高，可能引起雪崩；而一台离线计算节点的磁盘告警，大概率可以等到天亮再处理。所以排查之前，先问自己：这台机器在我架构里是什么角色？它挂了会影响哪些服务？有没有冗余？这个问题决定你后续每一步的节奏。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. CPU与负载异常：先从load average读起
负载类告警是所有Linux告警里最频繁的。我见过太多人一看“load average 20”就慌了，其实负载高不一定代表CPU忙，也可能是磁盘在拖后腿。
2.1 看懂uptime输出的三组数字
uptime 是最快的体检工具，它会告诉你系统当前时间、运行时长、登录用户数，以及最近1分钟、5分钟、15分钟的平均负载：
bash复制uptime
# 输出示例： 14:32:10 up 128 days, 3:42, 2 users, load average: 8.50, 4.30, 2.10
这里的load average是“可运行线程数+不可中断睡眠线程数”的滑动平均。1分钟8.5、5分钟4.3、15分钟2.1，说明负载正在快速上升，属于突发情况；反过来，如果1分钟2.1、15分钟8.5，说明高峰已经过去，系统正在恢复。
判断负载是否“过高”，不能只看绝对值，要看CPU核数。8核机器跑8.5的负载，其实还在临界边缘；2核机器跑8.5，那已经是严重超载。我习惯用 nproc 或 grep -c processor /proc/cpuinfo 先确认核数，再对比负载数值，否则很容易误判。
2.2 用top和mpstat区分“真忙”还是“假忙”
负载高之后，立刻敲 top，按大写P把进程按CPU使用率排序，找到最耗CPU的进程。但我建议你再多走一步，用 mpstat -P ALL 1 3 看每个CP