爬一手好线杆凌晨两点十七分，手机在床头柜上震起来，声音不大，但足够让心脏猛地一抽。摸过手机一看，监控面板上红通通一片：某个核心节点的 CPU 使用率拉满，load average 飙到比核心数还高好几倍，同时磁盘空间告警也在闪。整个人瞬间清醒。这种“告警炸裂”的深夜，相信每个干过 Linux 运维的人都经历过。我最早遇到这类情况时，也是手忙脚乱——先开两个终端，一边敲 top 一边敲 df -h，看两眼就慌，不知道该先救哪边，最后只能靠重启解决一切，等天亮再被业务方追着问原因。
后来踩的坑多了，慢慢总结出一条经验：告警能炸成一片，多半是根本没有一套固定的排查顺序。 你东打一枪西打一棒，不仅效率低，还容易被表象带偏——比如明明是磁盘写满引发的连锁告警，你却盯着 CPU 使用率查了一小时。这篇文章就是想把我这套折腾出来的 Linux 故障排查“作战地图”完整摊开来讲，从告警分级、系统层三大件（CPU、内存、磁盘）的排查顺序，到网络、进程、日志的深挖方法，再到 Zabbix、证书告警这类平台层面的问题，按真实作战逻辑串起来。适合刚入行没两年的运维新手，也适合那些虽然能干活、但遇到复杂故障还是会慌的后端开发。看完之后，你至少能知道告警响了先干嘛、后干嘛、什么情况可以放心睡回去。
1. 先把“作战地图”摊开：故障排查的整体思路
1.1 告警来了别慌，先把五个问题问一遍
很多人在深夜被告警炸醒后的第一反应是“赶紧看告警详情”，然后一头扎进监控面板里。我的习惯恰恰相反：先强制自己在脑子里跑一遍五个问题，边穿拖鞋边想清楚。
这五个问题分别是：影响范围有多大？是所有机器都在告警，还是就这一台？是纯性能问题，还是业务真的有报错？有没有最近变更（发版、改配置、扩容缩容）？以及，现在是不是真的需要立刻处理，还是可以等早上？
为什么要问这五个问题？因为告警往往不是单一原因造成的，而是多个问题叠加后的结果。比如一台机器 load 飙升，你看到的是 CPU 告警，但底下的原因可能是日志把磁盘写满了，而日志写满是因为某个应用出现了异常死循环。如果一上来就死磕 CPU 跑满，不从全局判断，很容易在错误的层面浪费时间。夜间作战，时间最值钱，方向正确远比你敲命令的速度重要。
我见过不少同事，一听到告警就进入“灭火模式”，把所有工具都打开，top、free、df、netstat 全敲一遍，屏幕铺满了输出，但看完更焦虑。这本质上是因为没有先定位问题边界。当你先把“影响范围”“是否变更”“紧急程度”这三件事问明白，再决定下一步做什么，整个人的节奏就稳下来了。
1.2 把告警分成三类：系统层、应用层、基础设施层
问完五问，下一步是分类。我一般把告警分成三大类：系统层、应用层、基础设施层。这个分类看起来简单，但实际能救不少命。
- 系统层：CPU 使用率、系统负载、内存使用、磁盘空间、inode 耗尽、SWAP 波动等。特征是告警直接来自操作系统指标，跟业务代码没关系。
- 应用层：进程假死、接口响应时间飙升、连接数被打满、Java 应用抛异常、日志报错频率上升等。特征是得进到应用里去查，光看系统指标往往不够。
- 基础设施层：VSphere 证书状态告警、Zabbix agent 失联、数据库主从延迟、负载均衡后端异常、告警通道本身出问题等。特征是问题往往不在你正在排查的这台机器内部，而是外部依赖或平台机制出了问题。
分类的目的，是帮你决定排查时往哪个方向走。系统层告警优先看操作系统的指标和日志；应用层告警得结合系统层数据，再往进程、线程、日志里钻；基础设施层告警要第一时间跳出单机视角，去看平台、看网络、看链路。很多新手最容易犯的错，就是把基础设施层的证书告警当成系统故障来查，在错误的机器上折腾半天。
1.3 作战地图的三条主线：先看、再查、后挖
我把整个排查过程抽象成三条主线，也推荐你把它当作自己脑海里的“作战地图”：
第一条是“先看”。看的意思是快速扫描，用系统自带的轻量命令，在 1 到 2 分钟内判断当前机器整体的健康状态。uptime 看一眼 load，top 看一眼 CPU 和内存的大盘，df -hT 看一眼磁盘，free -g 看一眼内存水位。这一轮不求精细，只求有个整体轮廓。
第二条是“再查”。查的意思是带着问题去精准定位。比如 load 高了，就用 mpstat 和 pidstat 查到底是哪个 CPU、哪个进程在消耗；磁盘告警了，就用 du 和 lsof 查是哪个目录、哪个文件占着空间；网络告警了，就用 ss 和 tcpdump 查连接状态和数据包。这一轮的核心是顺着第一轮的线索，一步步缩小范围。
第三条是“后挖”。挖的意思是查完表象之后，还需要找到根因，否则半夜处理完，第二天还会再炸一次。比如发现磁盘是日志写满的，就要继续挖是哪个服务在疯狂打日志、为什么打、怎么从源头止住。挖根因通常要结合日志、内核信息、甚至最近变更，这部分往往最耗时，但也是真正能显示功力的环节。
这三条主线连起来就是一套完整的排查逻辑。任何时候告警响了，你先别急着用某个工具花式炫技，沿这三条走一遍，基本能把多数问题锁定在可控范围内。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统层排查“三板斧”：CPU、内存、磁盘
2.1 CPU 使用率飙升 / load 高：从 top 到 mpstat 再到 pidstat
系统层告警里，CPU 和 load 告警出现频率极高。第一步我永远是 uptime，看 load 的绝对值——注意，load 高低不是看大小，而是要看跟 CPU 核数的相对关系。比如 8 核的机器 load 到 8 还能接受，到 16 已经明显过载；但如果是 2 核的机器，load 到 4 就该紧张了。
看完 load，立刻跑 top -c 按