Linux故障排查作战地图：从告警分级到根因定位

凌晨两点十七分，手机在床头柜上震起来，声音不大，但足够让心脏猛地一抽。摸过手机一看，监控面板上红通通一片：某个核心节点的 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 查连接状态和数据包。这一轮的核心是顺着第一轮的线索，一步步缩小范围。

第三条是“后挖”。挖的意思是查完表象之后，还需要找到根因，否则半夜处理完，第二天还会再炸一次。比如发现磁盘是日志写满的，就要继续挖是哪个服务在疯狂打日志、为什么打、怎么从源头止住。挖根因通常要结合日志、内核信息、甚至最近变更，这部分往往最耗时，但也是真正能显示功力的环节。

这三条主线连起来就是一套完整的排查逻辑。任何时候告警响了，你先别急着用某个工具花式炫技，沿这三条走一遍，基本能把多数问题锁定在可控范围内。

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 按 CPU 使用率从高到低排序，先看看是哪个进程在吃 CPU。这里有个小习惯：我一般不看第一屏就下结论，而是按数字键 1 展开所有 CPU 核心，看看是所有核都在跑，还是只有个别核跑满。前者通常意味着进程并发度高，后者则可能跟中断处理、绑定核或单线程程序有关。

如果 top 里看不出明显凶手，但 load 就是很高，那就要考虑是不是不可中断睡眠的进程（D 状态）在堆积了。注意看 top 里的 %Cpu(s) 的 wa 值，如果 wa 拉满，说明是在等 IO。这时候别继续在 CPU 层面耗了，赶紧转去看存储。而如果 top 进程列表扫完没发现异常，可以上 mpstat -P ALL 1，把每个 CPU 核心的使用率单独打出来，确认是否是某个核不均衡。再往下就用 pidstat -p <PID> 1 观察具体进程的行为。

实际上，CPU 告警还有一个高频出现的隐蔽原因：热迁移后的性能劣化、或者同物理机上的邻居在抢占资源。如果指标看起来怪怪的，进程又没什么异常，别忘了往虚拟化层想一想，别在系统里绕圈圈。

2.2 内存告警 / OOM：free 只是起点，还得看谁在吃

内存告警是另一个半夜常客。第一反应是 free -g，看总体水位。但我想说的是，free 的输出有个特别容易误导新手的点：Linux 的 cached 和 available 不是一回事。cached 代表页缓存，回收它是很正常的事，没必要一看到 used 很高就紧张。真正该关注的是 available 这一列，它表示在不清空缓存、不 swap 的情况下还能给新程序分配多少内存。

free -g 看到 available 很低，才需要继续往下挖。下一步我会开 top -c 再按 M 键按内存排序，看进程级别谁排前面。但 top 只能看到 RSS，看不到共享内存里的陷阱，所以更细一步会用 ps aux --sort=-%mem 或者 smem 来看真实占比。处理 Java 应用的机器，还要考虑堆外内存、元空间等不在 RSS 里直接体现的部分，必要时还得结合 jstat 看堆内使用。

更要注意的是 OOM 的场景。机器内存耗尽，内核会启动 OOM Killer 杀掉进程，直接把业务干掉。这种情况下，最重要的不是先去 restart 进程，而是先看 dmesg -T | grep -i oom 或者 journalctl -k 里 OOM 的记录，搞清楚系统到底挑了谁下手、为什么挑它。OOM 的处理策略也值得提前看：cat /proc/sys/vm/overcommit_memory、cat /proc/sys/vm/panic_on_oom 这些参数平时就要了解，别等到出事才临时抱佛脚。

到了这一步，果断按顺序来：先确认水位 → 找出吃内存的进程 → 判断是泄漏还是突发 → 临时拉升可用内存（比如释放缓存、找空档重启）→ 白天再做根因修复。

2.3 磁盘告警：不只是 df -h，还有 inode 和 IO Wait

磁盘告警应该是最容易“看似好处理、实则埋坑”的类型了。最常见的操作是看一眼 df -h，找到使用率高的分区，然后删点大文件了事。但你有没有遇到过：“我删了 20 个 G 的文件，为什么使用率没下来？”如果有，大概率是有进程还占着被删除文件的句柄——这文件在磁盘上已经“看不见”了，但空间还被占用着。处理方式是 lsof | grep deleted，找到占用进程，重启它或让它释放句柄，空间才会真正被收回。

另外，df -h 显示的是块使用率，但很多 Linux 文件系统还有独立的 inode 区。当小文件数量暴增（比如日志轮转失败、邮件队列堆积、临时文件没人清理），inode 会先耗尽，表现为磁盘明明有空间，但报错“No space left on device”。所以检查磁盘时，我习惯 df -hT 和 df -i 一起看，两条命令缺一不可。

磁盘层面还有一个隐蔽的杀手：IO Wait 高但不一定有空间问题。如果你看到 top 里 wa 值长期超过 20%，这说明存储已经严重拖慢整个系统。建议立刻执行 iostat -x 1 看看磁盘的 %util、IOPS、await 等指标。如果某个磁盘的 %util 长时间接近 100%，而且队列长度（avgqu-sz）也特别大，说明存储是瓶颈。这时候你半夜能做的：确认是不是数据库大查询、日志过量写入、或者备份任务把磁盘拖挂了，优先止损，白天再讨论底层存储架构的问题。

围绕磁盘我还有一条经验：目录结构管不好，排查就是地狱。 平时养成分区规划的习惯，日志、数据库、临时目录都在独立分区，出现告警时定位范围直接缩小一大半。

3. 网络类告警排查：从 ping 不通到端口半开

3.1 第一反应：连通性、DNS、网关

网络告警和系统资源告警很不一样，它可能表现为“业务连不上”“某台机器丢包”“Zabbix 检测不到主机存活”。我的排查顺序，永远从最基础的连通性开始。

首先明确一点：不要一上来就 ping 域名。正确的顺序是先确认本机网络是通的：ip addr 看网卡是否 up、是否拿到了正确的 IP；再 ip route 或 route -n 看默认网关；然后用 IP 去 ping 网关，确认二层和三层的路径没有问题。网关能通，再 ping 目标 IP，通了说明链路没问题，这时才有必要用 nslookup 或 dig 检查 DNS 解析是否正常。

很多人遇到“域名不通但 IP 能通”的情况，马上会怀疑 DNS 配置。其实还有一种常见原因：使用的不带 +short 的解析命令，被系统的 search 域给绕晕了，解析出了一个你根本没想到的 IP。我习惯用 getent hosts <domain> 和 dig +short <domain> 交叉验证，避免被缓存迷惑。

然后要提示一个特别坑的点：云环境下的安全组或防火墙 ICMP 策略可能禁 ping。 如果在云上，网关通了、对端 IP 通，但 ping 丢掉甚至 100% loss，别急着断定是“对方宕机”。这时候改用 nc -vz <IP> <port> 或直接看业务端口是否可达，往往更靠谱。这一点，在现在几乎所有业务都跑在虚拟化和云平台上的环境下，特别重要。

3.2 端口与连接排查：ss、telnet、nc 的正确用法

确认基础连通性之后，下一步就是端口层面的排查了。半夜最常见的情况是：“服务监听了，端口看着也没问题，但业务就是连不上。”

第一件事是确认端口到底有没有在监听：ss -lntp 检查你想找的端口是否处于 LISTEN 状态。ss 比 netstat 更值得习惯化使用，输出快，而且能看到的信息更丰富。看到 LISTEN 后，再从客户端视角去测连通性：telnet <IP> <port> 或者 nc -vz <IP> <port>，注意这里一定是向外测试，别只在服务端自己测自己。

如果端口有监听、链路没问题，但连接还是进不来，就要考虑防火墙了。检查本机 iptables、firewalld、云安全组的放通策略。早期我踩过一个大坑：服务端口只监听了内网 IP，公网测试永远不通，折腾半天以为是安全组，结果发现是进程绑定了错误的地址。所以 ss -lntp 时，除了看端口和进程，还要看监听地址是 0.0.0.0 还是具体 IP，这决定了外部到底能不能访问到。

再往后就是连接数异常的场景。ss -antp 看当前 TCP 状态：如果 SYN_SENT 特别多，说明连接发出去没得到响应，原因可能在防火墙、目标 backlog 满了、或者对方的服务确实没在监听；如果 TIME_WAIT 大量堆积，多数是短连接并发太高，本质不算故障，但可能占满本地端口，导致新连接分配不到临时端口。配合 cat /proc/sys/net/ipv4/ip_local_port_range 看端口范围，基本能判断是不是这类问题。

3.3 tcpdump 抓包：什么时候该用、怎么快准狠

如果 ss 看不出异常，业务还是不通，那就只有上抓包工具一锤定音了。tcpdump 是排查网络类问题最权威的手段，但它也是一把双刃剑——抓多了很容易把自己淹没在包海里。我的习惯是：抓包之前必须先明确“我要证明什么”。

比如怀疑某个端口访问不通，我会抓入方向的包，看 SYN 包有没有到本机：tcpdump -i eth0 tcp port 8080 -nn -c 20。如果包没到，说明请求在链路中被丢弃；如果包到了但没回 SYN-ACK，那问题在本机的协议栈或服务状态；如果握手都能完成但业务没响应，那问题大概率在应用层。这一套判断逻辑，比盲目看几十 MB 的抓包文件高效得多。

另外，抓包时我会顺手用 -w /tmp/xxx.pcap 落地保留，再用 Wireshark 细看三次握手耗时和报文重传。这个习惯特别管用，因为你半夜可能一眼看不出问题，但留个现场文件，白天复盘时它就是最可靠的证据。不过注意别在核心入口网卡上长时间大流量抓包，容易被踩到 CPU 和磁盘性能的坑。

3.4 常见连接异常速查：SYN_FLOOD、连接池耗尽、代理层诡异现象

网络告警里有一类问题特别容易把人搞崩溃——从系统层看一切正常，但连接数一直在涨或连接质量很差。这时候要看的就不只是系统参数，还有业务结构。

怀疑 SYN_FLOOD 时，看 ss -s 里的统计，如果 SYN_SENT 和 SYN_RECV 的队列持续爆满，可以临时调大 net.ipv4.tcp_max_syn_backlog 和 net.core.somaxconn，但记住这只是缓兵之计，白天必须找到真实攻击源或连接风暴源头。怀疑连接池耗尽时，重点查应用的连接池配置和数据库的最大连接数，很多开发默认配置很低，流量稍微涨一点就会触发大量报错。

还有一类特别隐蔽的：七层代理后面那个 TCP 连接看起来一切正常，但应用进程卡住了，导致代理和后端之间一直维持着“半死”的连接。这种场景下，光靠端口和 TCP 状态是看不出问题的，必须结合应用日志、访问日志的响应时间一起来看。我的经验是：网络排查不要一条路走到黑，该切到应用层就切，该拉开发一起看就拉，一个人抱着 tcpdump 硬肛毫无意义。

4. 平台与监控体系的坑：Zabbix、告警屏蔽和证书告警

4.1 Webhook 告警接入：以 Zabbix 7.0 配钉钉/企业微信为例

半夜告警之前，其实还有一个容易出问题的环节：告警通道本身可能没配好。你在睡梦中收到的每一条有效告警，背后都有一套消息链路在支撑。这里拿 Zabbix 7.0 配置 Webhook 告警到钉钉或企业微信为例，这是目前最主流的告警推送方式之一。

Zabbix 7.0 的“媒介类型”已经内置了 Webhook 脚本模式。重点在于，你需要把钉钉/企业微信机器人的 Webhook 地址填进 Zabbix 的媒介配置里，然后配置告警动作时指定该媒介，并在用户那把这媒介关联到自己的账号上。很多人配完之后发现收不到告警，多半是漏了最后一步：告警动作里必须指定发送给谁，而接收用户必须勾选对应的告警媒介。

还有一个细节容易踩：钉钉/企业微信自定义机器人都需要加签或关键词校验。如果钉钉机器人的“安全设置”勾了“加签”，你就必须在 Webhook 里拼上 &timestamp=xxx&sign=xxx 这样的签名参数，否则消息根本发不出来。我见过太多次“配置没问题但收不到告警”，最后发现是签名没更新。另外，测试时要记得在 Zabbix 的“媒介”里点“发送测试”，不要在动作配置页面干等，测试消息不经过动作逻辑，能直接暴露媒介配置的问题，定位快很多。

4.2 告警屏蔽不生效、手动确认关不掉：排查思路

再说一个特别常见、但很多人会被绕晕的点：告警你明明屏蔽了，为什么还响？或者你在 Zabbix 里手动确认关闭了，为什么事件一直挂着？

以我常用的 FlashDuty 和 Zabbix 两个平台为例。告警屏蔽不生效，一般是这四个原因：屏蔽的时间窗口不正确（你设的是未来时间段，但当前告警在窗口外）；屏蔽规则的作用范围跟告警来源不匹配（比如你按主机名屏蔽，但告警实际是模板或者告警集带出来的，源对象对不上）；平台有“事件合并”机制，屏蔽栏跟事件合并的优先级互相干扰；以及最隐蔽的——多个事件同源聚合时，屏蔽规则只对其中一个有效，新到达的事件仍然触发。

手动确认关闭不了事件，大多数是权限问题或者状态机问题。Zabbix 7.0 里事件关闭是有状态流转的，如果这个事件关联的触发器和问题已经漂移（比如恢复了又复发），手动关闭会被新状态重新打开。遇到这种情况，最重要的是先看事件的完整时间线，别在“为什么关不掉”这件事上死磕，往往关不掉本身就是问题的提示。

4.3 证书状态告警：从 vSphere 到 HTTPS 证书过期

第三方平台的证书告警是很多运维半夜心态崩掉的来源之一，市面上最典型的就是 VSphere 证书状态告警。没错，虚拟化平台自身也会有一套证书体系，当 vCenter 或 ESXi 的证书快过期或已经过期时，平台会给告警。这类告警的可怕之处在于，它不是简单的系统性能问题，而是整个虚拟化管理层面的问题——你连 vCenter 都可能登不上。

处理这类告警第一步是确认证书的真实状态：openssl s_client -connect <vCenter-IP>:443 </dev/null 2>/dev/null | openssl x509 -noout -dates，直接读出证书的生效时间和到期时间。确认快过期后，别拖，赶紧走正式的证书更新流程——重新生成 CSR，把新证书导入 vCenter，并确保所有 ESXi 主机都信任新的证书链。我曾经在一个客户现场见过因为 vCenter 证书过期，导致所有 ESXi 主机无法正常纳管，整整一个晚上都在处理这个问题，所以现在我只要一看到证书相关的告警，优先级直接提到最高。

还有一类更普遍的证书问题是 HTTPS 证书过期。检查方法更简单，直接 curl -vI https://目标域名 2>&1 | grep -i 'expire\|certificate' 或 openssl s_client -connect 域名:443 即可。遇到这种告警，哪怕业务系统当前还能访问，也要尽快安排时间换证书，别等浏览器大面积拦截跳错——到那一步，用户会比告警先崩溃。

5. 应用进程与日志深挖：假死、OOM 与内核信息

5.1 进程还在但业务已死：看线程、看 GC、看调用栈

告警里最令人崩溃的，不是进程没了，而是进程还在，端口还在监听，业务却已经“假死”——请求全部超时，用户开始连环投诉。这种情况如果你只会在系统层看 CPU 和内存，基本无解，因为问题已经深入到应用内部。

第一步是找到进程现场的线程状态：top -Hp <PID> 看哪个线程占用 CPU 高，或者 ps -Lp <PID> -o pid,tid,pcpu,stat,comm 查出所有线程的 CPU 消耗。如果发现某个线程把 CPU 打满，用 gstack <PID> 或 jstack <PID>（Java 环境）把线程栈抓出来，看这个线程卡在什么代码上。对于 Java 应用，我还会顺手看一眼 GC：jstat -gcutil <PID> 1000，如果 FGCT 一直涨、FGC 频繁发生，说明堆内存已经压不住了，这往往是 OOM 的前兆。

抓线程栈是一个“一锤子买卖”，现场只有一瞬间，错过了就没了，所以建议平时就准备好脚本，告警一响立刻执行。

另一个模块：如果已经 OOM，进程直接没了，但 dmesg 里能看到 oom-killer 的记录。这时候别急着重启，先分析清楚是被杀前堆有多大、谁在吃内存，否则起来了还是会再次被杀。对于 Java 应用，生产环境务必在启动参数里加 -XX:+HeapDumpOnOutOfMemoryError 和 -XX:HeapDumpPath=/data/dump，让程序在内存溢出时自动留下堆转储文件，否则你根本无从分析。

5.2 dmesg 和 journalctl：内核日志是终极大杀器

很多故障排查到一定程度就卡住了，系统指标全正常，应用层也看不出问题，但业务就是有毛病。这时候我习惯把键盘切到内核视角：dmesg -T。它记录着内核自己说的话，包括硬件错误、文件系统异常、OOM、网络栈问题等。特别提醒，一定加 -T 参数把时间转换成可读格式，否则那些启动至今多少秒的计数根本没法用。

dmesg 里值得重点关注的信息包括：文件系统相关有没有 I/O error、报块损坏；网络相关有没有大量 nf_conntrack: table full；以及有没有硬件级别的告警，比如 ECC 内存纠错报警。尤其“连接断断续续”这类问题，很多时候 dmesg 里网卡驱动已经在报错或者重新协商速率了。

Systemd 平台的机器，我还会用 journalctl -p err -b 查看本次启动以来的错误级别日志，或者 journalctl -u <服务名> --since "10 minutes ago" 看指定服务近十分钟的日志输出。缺点是 systemd-journald 默认可能对日志大小有限制，高频应用很容易写满导致日志被截断，出现“日志追不到真凶”的情况。所以有条件的话，在关键服务的 Unit 文件里单独配 LogRateLimitIntervalSec=0 或者调整 Storage 参数，确保日志尽量完整。

5.3 strace、lsof 和性能剖析：这些“重武器”什么时候才用

排查到这一步，如果还没有锁定根因，就该上“重武器”了。这里的逻辑是：不到万不得已不要乱用，因为这些工具本身对生产系统有侵入性，用不好会加剧问题。

strace -p <PID> 可以查看进程正在执行什么系统调用。比如某个进程看起来卡住了，你可以通过 strace 看看它是卡在 read、write 还是 poll 上，进而判断瓶颈在 IO、网络还是锁。但注意，strace 会让被追踪的进程变慢，生产环境慎用，用的时候加 -f 追踪所有子进程，加 -t 打印时间戳，方便和业务日志对齐。

lsof 则是排查文件句柄问题的利器。前面提到的 lsof | grep deleted 找删除未释放的空间是一个用法；还有一个常见场景是进程能开的文件句柄数被打满：cat /proc/<PID>/limits 看限制，ls /proc/<PID>/fd | wc -l 看当前已打开的句柄数量，如果接近上限，就要考虑调整 ulimit -n 或者检查应用是否存在句柄泄漏——这通常会表现为连接反复超时和大量报错。

至于 perf、valgrind 这类更底层的性能剖析工具，我的建议是：白天专门做性能回归的时候再用，深夜救火现场除非你是该领域的资深专家，否则还是先保证止损，现场留好数据再说。

6. 常见问题速查表与经验总结

6.1 把高频坑都钉在一块“黑板”上

以下这些场景是我多年运维过程里反复遇到的，整理成表放在手边，比临时翻手册强得多。

这张表不是标准答案，而是一个起点。真正要紧的是每次故障后，你自己动手把“现象 → 排查路径 → 根因 → 处置方案”补进你自己的速查表里。半年后你手上就会有一张完全贴合自己业务环境的作战地图，比网上任何教程都值钱。

6.2 我的几条实操心得（半夜保命向）

以下这几条，算是我被凌晨的告警电话“教育”过无数次之后总结出来的保命经验，说给你听。

第一，平时就给命令写“快捷键”脚本。比如一键执行 load、CPU、内存、磁盘、IO、连接数、最近内核错误日志的集合命令。不要小看这个习惯，你在凌晨三点半敲命令的手是抖的，一两个字母的 typo 都可能让你在错误的输出上浪费十分钟。我自己的方案是专门放一个 ~/ops/diag.sh，里面编排好一套诊断输出，同时重定向到 /tmp/diag_$(date +%s).log，为后续复盘留底。

第二，告警分级必须从第一天就做好。不要把 SSH 登录失败和数据库主从断开混在一起推送，否则你会对告警产生免疫，真正严重时反而没人理。告警属于 P1/P2/P3 的哪一级、对应几分钟内必须响应、要电话还是钉钉群通知，这些规则要能写成文档并让新人也看懂。好的监控体系不追求零告警，而是让每一次告警都值得被响应。

第三，处理完故障后，强制自己写下 200 字复盘。不用长篇大论，只记时间线、现象、根因、处理和待办改进项。这条习惯坚持一年，你回头看会发现自己的排查速度和成功率都会有质的提升。很多看似玄学的问题，其实只是因为没记录，所以反复踩同一个坑。

6.3 最后再说两句实在的

这套“作战地图”说到底是用来帮你在“深夜告警炸裂”时稳住阵脚的。它不是把所有的可能性都罗列出来让你背，而是帮你建立一套从全局到局部、从表象到根因的排查节奏。你和我都知道，故障这东西永远会有新的花样，真正的底气不是来自背熟某条命令，而是来自每一次认真处理完故障后的复盘和积累。

应急响应只是当消防员，把根因修掉才算真正的“救火”。今晚你可以先按这套流程走一遍，等天亮了，别忘了把坑补上——把日志轮转配好、把监控项调准、把脚本脚本固化下来。这样下次告警再来的时候，你至少能更从容地翻个身，或者说，它根本就不会来打扰你了。