FFFire小火深夜两点半，手机连续震动，钉钉、企业微信、短信一起涌进来，同一台 Linux 服务器的告警一条接一条往外冒：CPU 持续 90%+、load 冲到 20 多、磁盘使用率超过 90%，还没看完，进程存活告警也亮了。这种“告警炸裂”的场景，只要做过几年运维都躲不过。新人容易慌，挨个点开所有告警，结果连主机都登不上去；老人通常先看五分钟，想明白是哪一类故障，再按系统层、进程层、应用层逐层往下查。
这篇文章算是我这些年处理 Linux 故障的经验沉淀。它不是给你贴一堆 man 手册，而是整理出一套“收到告警后可以照着做”的排查地图：从告警分级、系统指标拆解、进程定位、日志取证，到监控侧自愈与复盘，全程都有真实命令和踩坑教训。适合刚接手服务器运维的同学，也适合后端开发想快速定位线上问题的人，哪怕只记住其中几条命令，下次半夜应该也能少走弯路。
1. 告警不炸裂：收到消息后先分级定位，再动手处理
1.1 告警分级：先确定这台机器是“快不行了”还是“还能撑住”
告警轰炸带来的最大问题不是告警本身，而是你的注意力被分散了。同一台机器的告警经常互相联动：磁盘满了会引发应用日志写不进去，应用写日志失败可能表现为大量报错，报错多了进程被健康检查杀掉，又触发存活告警。如果你从最末端的进程告警开始查，逻辑上是反的。
所以我收到告警后会先做一个快速分级，把消息按“紧急度”排序，只问三个问题：
- 主机是不是已经失联？如果 SSH 登不上、Ping 不通，这是最高优先级，先解决可达性。
- 核心业务是否已经不可用？比如端口不通、接口超时、进程退出。
- 当前是资源过载还是资源耗尽？过载可能只是变慢，耗尽则意味着随时会宕机。
这套分级对应的处理策略完全不同。失联优先走带外管理或者云平台控制台重启，很多时候拔电源是最快的恢复手段；业务不可用就要看是进程崩溃还是依赖的外部组件挂了；资源问题则分 CPU、内存、磁盘、网络一项项拆解。
有一点必须说清楚：告警多的机器，不一定是故障最重的机器。有可能是监控系统自身的问题，比如某个采集项误报，或者某个指标阈值设置得太激进。所以我的习惯是先登录主机确认一次实际状态，而不是全信面板上的红点。
1.2 黄金 5 分钟行动表：登录后第一轮必跑命令
确定主机还能登录之后，我一般会花 5 分钟跑一轮基础命令，把当前快照留下来。为什么强调“先留快照”？因为线上机器状态是动态的，很多现场稍纵即逝，比如一个占用 CPU 的进程可能几秒钟后自己就下来了，如果你没先记录下来，后面想分析就没依据了。
这一轮命令不要多，目标只有四个：看负载、看进程、看磁盘、看内存。
bash复制uptime
top -bn 1 | head -30
free -h
df -hT
iostat -x 1 3
我还会顺手加一条 date，把所有命令的输出都带上时间戳。很多人排查到一半发现日志里的事件时间对不上，就是因为机器时区不一致或 NTP 同步有问题，后面白忙活半小时。
如果这轮命令里 load 和 CPU 同时飙高，大概率是计算密集型任务在跑；如果 load 很高但 CPU 不高，多半是 I/O 等待或者 D 状态进程卡住了；如果磁盘容量没满却一直写文件，就要考虑 inode 耗尽或者文件句柄泄露。先做判断再深入，后面 90% 的问题都能少走弯路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统层指标逐项拆解：从负载到磁盘，每个数字都要能读懂
2.1 先看负载与 CPU：别把“很忙”和“有问题”划等号
uptime 里的三个 load average 是最容易被误读的指标。很多新手看到 load 超过 CPU 核数就拉响警笛，实际上 load 高只代表系统里有任务在排队，不代表一定是坏事。比如一台 8 核机器跑一个编译任务，load 到 8 左右是正常的；但如果 load 冲到 16、24 且告警持续，才说明队列已经堆积到 CPU 处理不过来了。
更好的做法是先看 top 的进程列表，确认是单进程吃满还是多进程并行。单进程吃满通常是一个 Java 线程陷入死循环或者某个离线任务在跑；多进程同时吃满则是典型的业务高峰、定时任务并发或者其他负载叠加。
我还习惯用 mpstat -P ALL 单独看每个逻辑核的情况：
bash复制mpstat -P ALL 1 5
这个命令能告诉我负载是均匀分布在所有核上，还是集中压在某几个核上。如果是后者，应用层大概率是单线程瓶颈，比如有些中间件没有利用好多核，这时候你单纯加机器可能都没用。
top 里还要特别关注进程状态列。如果大量进程处于 R 状态且 CPU 高，说明在抢 CPU；如果很多进程是 D 状态，即不可中断睡眠，那是典型的 I/O 问题，这时候 CPU 可能反而不高，但 load 会特别高。很多人只看 CPU 就下结论，结果在系统运维群里问“CPU 不高为什么机器卡死”，大概率就是 D 状态在堵。
2.2 上下文切换与软中断：CPU 高但找不到进程时的隐形杀手
有一种场景特别恼火：CPU 整体占用很高，但 top 里没有任何一个进程的 CPU 占用特别明显。这种情况我遇到过好几次，最后基本都是上下文切换过频、软中断风暴或者 CPU 被某个内核线程占掉。
排查时用两条命令配合着看：
bash复制vmstat 1 5
cat /proc/softirqs
vmstat 输出里的 cs 列是每秒上下文切换次数。如果这个数字居高不下，比如几万甚至几十万，说明系统在频繁切换进程或线程。这时候再用 pidstat -w 1 看每个进程的上下文切换情况，找出是哪个进程在捣乱。
软中断层面我会比较 /proc/softirqs 里各个 CPU 的计数变化，特别是 NET_RX 和 NET_TX。如果某个网卡的软中断集中在某一个 CPU 上，很可能是网卡多队列没开启或者 RPS/XPS 没配置好，流量一大那个 CPU 直接被拖死，表现为整机 CPU 高但业务进程都在等待。
这里有个实战经验：处理软中断风暴时，短期的做法是先调大 /proc/sys/net/core/netdev_budget 和 net.core.dev_weight，但真正要解决还是得把网卡队列、中断亲和性配好。具体参数要看网卡驱动和内核版本，所以我一般建议现场先记录，别再自己瞎调，调错了可能把网络直接调崩。
2.3 内存与 SWAP：available 才是真正能用的内存
很多人看内存只会用 free -h，而且只盯着 free 那一列。这是大坑。Linux 的内存管理很聪明，会把空闲内存用作 page cache，这个 cache 在应用需要时可以被内核回收，所以真正能用的内存是 available，不是 free。
如果 available 已经很低，但在 top 里找不到占用特别离谱的进程，我会主动检查一下是不是 page cache 过大导致内存回收压力升高。有个快速验证方法：
bash复制sysctl vm.min_free_kbytes
cat /proc/buddyinfo
内存耗尽最怕的是触发 OOM Killer，内核会挑一个进程杀掉。所以排查内存问题时，建议第一时间用 dmesg -T | grep -i -E 'oom|killed process' 看看有没有 OOM 记录，避免等到业务反馈“进程莫名其妙没了”才想起来查。
SWAP 的使用也容易被误读。Linux 默认使用了 swap 也不代表内存不足，因为内核可能把一些不活跃的匿名页换出去了。但如果 swap 的 si 和 so 两列持续出现大量换入换出，说明内存真的不够用了。解决办法不是立马加内存，而是先找到内存泄漏源，很多 Java 应用堆外内存没管理好，就是典型的高发区。
2.4 磁盘容量、inode 与文件系统：空间够却报警的隐形原因
磁盘告警在半夜告警里占比相当高，而且大部分并不是磁盘真的满了。我会按顺序检查三件事：容量、inode、文件系统状态。
容量层面用 df -hT，但如果机器上跑着大量容器，注意 OverlayFS 的 /var/lib/docker 目录占满 / 的情况非常多。
inode 的问题排查起来比较隐蔽，表现为 df -h 明明还有空间，但应用就是无法创建新文件，报 “No space left on device”。用 df -i 一看才发现 inode 用光了。常见原因是某个目录下产生了海量小文件，比如临时文件目录、邮件队列、未正确清理的 session 文件。
文件系统层面如果出现只读挂载，这是大事件。我遇到过物理机因为硬件故障或者文件系统错误导致文件系统变为只读的情况，此时所有写操作都会报错，应用跟着一堆错误日志，后续还可能连带出存活告警。排查命令：
bash复制mount | grep -E 'ext4|xfs'
dmesg -T | grep -i -E 'ext4|xfs|error|remount'
查到文件系统报错后不要直接重启，如果文件系统认为有异常，重启后可能起不来，还可能要 fsck 修复。我的建议是先备份能备份的数据，联系有经验的人或者硬件厂商介入。很多夜间的文件系统灾难，都是因为有人在 fsck 还没跑完的时候强行中断导致的二次损坏。
3. 进程与应用层定向排查：从“系统怪怪的”到“锁定肇事者”
3.1 用三张报表锁定进程：CPU、内存、线程各自排序
系统指标异常只是现象，最终都要落到进程排查上。平时我的终端习惯不是只在 top 里按 P 看 CPU，还会跑三条排序命令把结果快照留存：
bash复制ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%cpu | head -20
ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%mem | head -20
top -H -p <PID> -bn 1
第一屏解决 CPU 大户，第二屏解决内存大户。进程在哪个用户下跑、启动命令是什么、父进程是谁，这三项信息能帮你判断它是被 systemd 拉起来的服务，还是被人手动执行的任务，又或者是被监控系统拉起来的巡检命令。
有一次我们排查一台数据库备机 CPU 飙高，top 里始终是一个 mysqld 进程在消耗 CPU，以为是主从复制压力大。后来用 pidstat 加上线程维度的命令才发现，真正高的是某个存储过程在夜里跑全表扫描，刚好和备份任务撞在一起。所以记住：进程定位只是第一步，线程和 SQL 往往才是元凶。
3.2 定位线程级别的卡点：Java 应用查堆栈的实操姿势
Java 应用占满 CPU 或者出现无响应告警时，我们的目标是快速拿到线程堆栈。先找到进程 PID，再用 top -Hp <PID> 找到 CPU 占用最高的线程：
bash复制top -H -p 12345 -bn 1
然后拿到线程 ID，转成十六进制：
bash复制printf '%x\n' 12346
再用 jstack 抓堆栈，在文件里搜索这个十六进制的 nid：
bash复制/usr/local/jdk/bin/jstack 12345 > /tmp/jstack_$(date +%F_%H%M%S).log
grep -A 20 'nid=0x303a' /tmp/jstack_*.log
jstack 抓出来的内容里，nid 后面的十六进制就是线程 id。找到对应堆栈后，一眼能看到它是卡在锁等待、数据库连接池获取、还是某个 while 循环里。这里要注意：jstack 一次只能抓一瞬间的线程状态，如果每次都抓不到现场，建议连续抓几次，间隔 3 到 5 秒。
处理 Java 服务的线程问题时，还有一个容易踩的坑：容器里执行 jstack 可能报 Unable to open socket file，这是因为 /tmp 下的 .java_pid 文件被容器隔离了，需要在启动参数里加上 -XX:+PerfDisableSharedMem 或者以 root 权限执行。第 5 台机器遇到这个问题时，我当场以为 JDK 坏了，实际上只是容器环境限制。
3.3 堆内内存与 OOM:别傻等到进程被 Kill 才开始抓堆
Java 进程的无响应告警并不一定都是线程问题，很多时候是堆内存快满了导致频繁 Full GC，应用一直在做 GC 反而没有资源处理请求。所以我通常会配合看 GC 日志：
bash复制jstat -gcutil <PID> 1000 10
输出中重点看 Full GC 的次数和时间。如果 Full GC 频繁且时间很长，基本可以断定堆压力过大或者存在内存泄漏。这时候我会用 jmap -dump:live,format=b,file=/tmp/heap.bin <PID> 导一次堆快照，但注意这命令会触发一次 Full GC，线上高峰期执行要谨慎，建议先和团队确认再做。
如果已经发生了 OOM，dmesg 里记录的是内核 OOM Killer 的行为，而应用自身的 OOM 异常则要去应用日志里找 java.lang.OutOfMemoryError。还要看错误类型是 Java heap space 还是 Direct buffer memory。后者对应堆外内存，常规堆dump看不到问题，需要结合 NMT（Native Memory Tracking）来排查。
经验之谈：生产环境一定要提前开启 -XX:+HeapDumpOnOutOfMemoryError，并指定 dump 文件路径。否则等进程被 Kill 之后，你想分析原因会发现现场啥都没留下，只能对着监控曲线猜。
3.4 日志风暴：进程活着但把磁盘写满的常规操作
另一种常见告警很诡异——应用进程正常运行、CPU 不高、内存正常，但磁盘在半小时内从 20% 涨到 95%。这种十有八九是“日志风暴”。
日志风暴的典型特征是：某个请求触发了异常分支，应用开始疯狂打日志，而且打印的内容包含完整的堆栈或者性能很差的 SQL 导致速度慢，反过来让更多请求超时，超时又继续打日志，形成恶性循环。定位方法最快的是：
bash复制du -sh /var/log/* 2>/dev/null | sort -rh | head
du -sh /usr/local/app/*/logs/* 2>/dev/null | sort -rh | head
find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null | head
找到最大的日志文件后，再用 tail 看日志内容是否在重复刷某一条错误。临时止血的手段是先把日志级别调高，比如从 DEBUG 调到 ERROR 甚至 OFF，等业务低峰再慢慢解决根因。但别忘了修改完日志级别，要确认应用配置会自动加载还是需要重启，有些系统重启一次代价很高，得先评估。
真正治本还是得靠日志框架的异步 Appender、滚动策略和归档清理。我见过不少项目线上跑的 logback 配置还是默认的无限写文件，这是给自己埋雷。必须确保单个日志文件有大小限制、历史日志有保留策略，哪怕归档到磁盘也要定期清理，否则时间一长，又一个深夜告警在等着你。
4. 日志与系统状态取证：让看不见的元凶现形
4.1 dmesg 与内核日志：OOM、磁盘错误和硬件问题的第一现场
如果告警来得特别突然，比如某台机器 23:59 还好好的，00:00 整机卡死，那我会第一时间去翻内核日志。平时用 dmesg 直接输出，因为内容是滚动的，最好加 -T 把时间戳转成可读格式，再用 grep 过滤关键字：
bash复制dmesg -T | tail -100
dmesg -T | grep -i -E 'error|warn|oom|kill|ext4|xfs|nf_conntrack'
内核日志里能看到 OOM Killer 具体杀了哪个进程、磁盘 I/O error 发生在哪个设备、以及 TCP 连接表满后内核发出的报错。很多应用层告警的根因其实都在内核日志里躺着，但大部分人都不会先看这一层。
有一次我们收到大量端口无法建立的告警，应用日志里全是 Cannot assign requested address，看内核日志是 nf_conntrack: table full, dropping packet。问题出在 conntrack 表满了，新建连接全部被丢弃。这种问题靠看应用代码基本是无解的，必须回到内核日志才能定位。
4.2 journalctl 的正确打开方式：按时间、单元、级别过滤
现在主流发行版都用了 systemd，服务的标准输出和错误都归 journald 管理。比起在一堆应用文件里翻日志，我更习惯先用 journalctl 拉出服务最近的行为：
bash复制journalctl -u my-service.service --since "10 minutes ago" --no-pager
journalctl -u my-service.service -p err -b
-p err 只显示 error 及以上级别的消息，适合快速过滤噪音。-b 是只看当前这次启动的日志，能避开历史启动的干扰。如果怀疑服务反复重启，还可以加上 -r 按时间倒序查看。
systemd-coredump 也是排查应用崩溃的好帮手。如果服务进程段错误崩溃，systemd 会默认抓 coredump，用 coredumpctl list 能看到崩溃记录，coredumpctl info <PID> 能看到触发崩溃的可执行文件和信号。这比靠用户截图“进程不见了”要可靠得多。
一个常见的坑：journald 的日志默认是持久化到 /var/log/journal/，但没有配置上限时，它会一直占用磁盘。很多机器的 / 分区无故升高，查完才发现是 journald 攒了 20G 日志。建议提前在 /etc/systemd/journald.conf 里配置 SystemMaxUse=500M，改完记得重启 journald。
4.3 时间线取证：把监控告警、应用日志、内核日志拼在一起看
排查复杂故障时，最重要的不是单个日志片段，而是把时间线拼起来。我通常在故障复盘时做一张简表，把“告警事件、负载监控、应用日志、内核日志”四列按时间排好，然后找因果关系。
比如某核心服务在 01:30 崩溃，如果你只盯着应用日志看到 OutOfMemoryError，可能误以为是堆配置太小。这时候拉出内核日志发现 01:29 机器的内存监控曲线已经异常，而且同一时间段有另一个批处理任务在跑，占用了大量内存，才是真正原因。
团队协作排查时，建议第一时间把时间相关的信息统一：确认各台机器时间是否一致、有没有发生过时间跳变。NTP 同步故障导致时间漂移，会让监控告警时间和日志时间对不上，排查方向直接跑偏。我曾经遇到一个实际问题，因为时钟快了 8 分钟，日志里看起来服务崩溃先于故障出现，后来才发现只是时间源不准。
5. 监控侧联动：别只当“接盘侠”，告警源头也要自检
5.1 告警配置本身也会骗人：先从监控数据源校验
凌晨的告警排查看多了，你会发现不少“炸裂”是监控系统自己的问题。比如模板给所有机器套了同一组阈值，大促期间流量一高，几十台机器同时在报警；又比如某个采集脚本因为依赖的 Python 包升级后，获取到的指标全变成 0，直接触发一堆“低于阈值”的误报。
所以登录业务机器排查之前，我会花半分钟在监控面板里拉一下主机原始数据曲线。对比监控数据源和实际命令输出的差异，很多问题就水落石出了。监控面板显示 CPU 100%，但 top 里只有 30%，不用怀疑，肯定是监控采集有问题，常见的是读取了 /proc/stat 的第一行快照错误，或者采集器进程自身被卡住了。
排查思路要反过来：先排除监控误报，再去追业务故障。我见过有人因为监控误报，大半夜愣是把一台正常运行的机器重启了，最后发现是抓取组件版本兼容问题。重启机器对业务影响可不小，这个锅背得很冤。
5.2 Zabbix 7.0 Webhook 告警配置：为什么通知会走到“炸裂”这一步
既然标题里提到了告警，那也顺带聊聊告警通知链路。很多人搭建了 Zabbix 7.0，发现默认的媒介只有邮件，半夜告警发到邮箱没人看，于是开始折腾钉钉 Webhook。Zabbix 7.0 里新增的 Webhook 媒介类型可以直接把告警事件 POST 到一个 URL，不需要自己写脚本。
配置这一步有两个关键点：
- 钉钉机器人安全设置里如果选了加签，需要把 Secret 计算出来的 sign 放到请求头里，很多人忘在这里导致 310000 错误。
- 告警消息模板里引用的宏要对，比如
{EVENT.NAME}、{HOST.NAME}、{ITEM.VALUE1}，一旦引用了不存在的宏，Zabbix 发送时会直接失败。
配置好 Webhook 后，测试通知可能收到一条正常消息，但真实故障时通知又发不出去。原因通常是 Zabbix 服务器访问外网不通，或者对端 Webhook 地址做了来源 IP 限制。所以不要只测“发送成功”，还要在故障时看 Zabbix 的审计日志，确认消息链路真的通了。
5.3 告警风暴的“降噪”手法与手动关闭的正确姿势
告警多了以后就得降噪，否则同事半夜被频繁打扰，后面反而对真告警麻木。降噪手法主要有四种：一是合理设置阈值与持续时间，比如 CPU 持续 5 分钟超过 90% 才报警，而不是瞬时值超过就报；二是维护窗口期，比如定时备份、批量任务期间主动屏蔽无关告警；三是关联告警合并，同一个主机上的同系列指标做成一个触发器；四是把恢复通知单独收件人，避免和故障通知混在一起。
Zabbix 里手动关闭告警也是一个常用操作，很多人没找到入口。在“监测-问题”页面打开某条告警记录，右侧详情里就能看到“手动关闭”按钮，点完之后事件状态会变成已关闭。但要注意，如果触发条件仍然满足，这个告警可能还会重新生成。如果只是个别误报想关闭，手动关没问题；如果是一批类似告警在刷屏，手动关闭是治标不治本，得赶紧查阈值和监控。
我在团队里还会强制要求一条：任何手动关闭告警的操作，必须在群消息里附带一句原因，哪怕只是“误报，采集脚本问题，已修复”。没有原因的手动关闭，等于给后面的复盘埋了一颗雷。
6. 高频命令速查与排查小抄：值班时能救命的那几行
6.1 百试百灵的高频排查命令组合
这里整理一份我值班时会贴在终端旁边的“救火命令速查”，全是长期验证过的高频组合，分场景列出：
| 排查场景 | 推荐命令 | 重点关注 |
|---|---|---|
| 系统整体负载 | uptime、top、vmstat 1 5 |
load 趋势、r 队列、cs 切换 |
| CPU 单核热点 | mpstat -P ALL 1 5 |
单核是否打满、软中断分布 |
| 进程定位 | ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%cpu |
进程启动时间、父进程、CPU 排序 |
| 内存现状 | free -h、cat /proc/meminfo |
available、Buffer/Cache、Swap 换入换出 |
| 磁盘容量 | df -hT、df -i |
容量、inode 双维度 |
| IO 压力 | iostat -x 1 3 |
%util、await、svctm |
这套命令不需要背，关键是每次排查都按同一套顺序跑，久而久之就能形成肌肉记忆。我新带人时最常说的一句话：你先按这个顺序跑出来，再决定下一步干什么，不要一上来就看 dmesg。
6.2 我自己常用的“一次性诊断脚本”
排查次数多了，我写了一个所谓的“快照脚本”，本质上就是把上面这些命令全部执行一遍，输出到带时间戳的文件里。遇到复杂问题，这个脚本会在我和同事之间传，保证两个人看到的是同一个现场的完整快照。
每次只需要执行一次：
bash复制#!/bin/bash
TS=$(date +%F_%H%M%S)
DIR=/tmp/diag-$TS
mkdir -p "$DIR"
uptime > "$DIR/uptime.txt"
top -bn 1 | head -40 > "$DIR/top.txt"
vmstat 1 5 > "$DIR/vmstat.txt"
free -h > "$DIR/free.txt"
df -hT > "$DIR/df.txt"
df -i > "$DIR/df-i.txt"
iostat -x 1 3 > "$DIR/iostat.txt"
ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%cpu | head -30 > "$DIR/ps-cpu.txt"
ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%mem | head -30 > "$DIR/ps-mem.txt"
ss -s > "$DIR/ss.txt"
dmesg -T | tail -100 > "$DIR/dmesg.txt"
echo "诊断快照保存目录: $DIR"
那个脚本里的 ss -s 我特别建议值班时保留一份，它可以快速看到当前系统的 TCP 连接统计，包括 timewait、established、syn_recv 的数量。遇到连接数异常、端口耗尽类问题时，这个输出能帮你判断是正常的连接高峰还是连接泄漏。
6.3 与团队、平台协作排查时的几个提醒
大型故障往往不是一个人闷头查就能搞定的。排查过程中，有一些容易被忽视的“软性协作细节”，实际比命令更能救命。
第一，变更记录要先问。你查了一小时发现服务还是起不来，结果一问，同事十分钟前刚改过网络配置或者升级过内核，这个信息能直接改变排查方向。所以线上故障时，第一个动作除了跑命令之外，还应该在群里同步一句“这台机器最近一小时有没有动过”，别不好意思问。
第二，现场保存。上面那套诊断脚本的输出，建议故障结束后打包归档到临时目录，哪怕问题已经恢复，后续复盘还需要这些数据。很多人现场不保留，等人走了才想起来要分析，只能对着监控曲线猜。
第三，不要单打独斗。排查线上问题时，一个人在终端里输入命令很容易陷入死胡同。哪怕是拉个同事在边上帮你看一眼输出，有时候就能指出一个你忽略的方向。我遇到过一个人盯着日志看了20分钟没头绪，同事路过问了一句“这个文件怎么一直在增大”，马上想到是磁盘写满导致的服务异常。
故障处理完，记得把当时的排查路径和结论补丁一样记到团队文档里，下次再遇到问题，可能只需要搜一下，五分钟就结束了。
最后再说一个小习惯：我每次线上故障处理后，都会顺手清掉终端里那些临时创建的文件，同时把 jstack、heap dump、诊断输出按照日期归档到一个独立目录。半夜排查时人本来就疲惫，所有文件命名必须一眼能看出日期和用途，否则第二次复盘时你会面对一堆莫名其妙命名的日志，那才是最让人头疼的。