Linux故障排查实战指南：从告警定性到根因定位的完整链路

凌晨两点多，手机震动把我从梦里拽出来，监控大屏刷了十几条告警：内存使用率飙到93%，某个核心接口成功率掉到50%，磁盘IO延迟翻了快三倍，工作群里已经有人在@全员。这种场面，干过运维和SRE的朋友大概率都不陌生。说实话，故障排查最大的难点从来不是缺命令，而是告警一多你就被牵着鼻子走，东看一眼西摸一下，最后半小时过去连故障域都没锁死。我这几年处理过上百起生产环境事故，越来越确信一件事：手里有没有一张清晰的Linux故障排查“作战地图”，直接决定你是十分钟恢复还是折腾到天亮。

这篇内容不是Linux命令大全的堆砌，而是把高频故障按存储、网络、进程资源、内核安全几个域拆开，每一类都给出从现象判断、命令定位到最终处置的完整链路。适合刚接手服务器的新人，也适合想把自己的排查流程体系化的运维和SRE朋友。照着这张图走一遍，至少能保证你在告警炸锅的时候，手脚不乱。

1. 告警响起的头10分钟：先定性，再动手

1.1 五类高发故障的特征速判

告警铺天盖地时，最忌讳的是直接盯着某一条看。我的习惯是先花两三分钟给故障定性。你不需要立刻知道根因，但你得知道它大概在哪个层。下面这张表基本覆盖了我遇到过的大多数情况：

注意load average这个数字，它是最容易被误读的指标。很多人看到load到了四五十就以为CPU爆了，其实load统计的是处于可运行状态和不可中断睡眠状态的进程总数，也就是说，一个进程卡在磁盘IO等待上，同样会拉高load。后面我在进程资源那部分会细讲怎么区分。

1.2 现场快照：故障在线时抢下来的数据才有复盘价值

我见过太多人，一上来就急着重启服务。服务是恢复了，可告警的根本原因永远成了悬案。正确的姿势是在动手之前，先做一次现场快照。所谓快照，就是一组能反映系统当前状态的命令合集，按顺序跑一遍，输出重定向到文件里，这就是之后复盘和定位的第一手证据。

我的固定流程大概是这样的：

bash复制date >> /tmp/syscheck/$(date +%F_%H%M).log
{
echo "===== load ====="; uptime
echo "===== mem ====="; free -h
echo "===== disk space ====="; df -hT | grep -v tmpfs
echo "===== inode ====="; df -i | grep -v tmpfs
echo "===== top process ====="; top -bn1 | head -30
echo "===== io stat ====="; iostat -x 1 3
echo "===== network ====="; ss -lntp
echo "===== log tail ====="; dmesg -T | tail -30
} >> /tmp/syscheck/$(date +%F_%H%M).log

有人会问，这不就是几条命令拼在一起吗？对，但关键在于，这套动作必须在心态还能稳住的时候提前固化好，真到告警炸裂的深夜，你不需要思考，直接执行脚本就行。排错和做手术是一个道理，先保证“病人”的真实状态被记录，后面不管怎么折腾，都不至于没有回头路。

2. 存储子系统：磁盘满、inode耗尽与“假满”的区分

2.1 df -h 正常却报 No space？先查 inode 与挂载点

存储类故障是深夜告警的重灾区，但坑也最多。最常见的一种情况是，服务端明明报了“No space left on device”，你跑完 df -h 却发现每个分区都还有不少剩余空间。这时候很多新手就懵了，其实问题常常出在两个地方：inode耗尽，或者你查的分区和服务实际写入的分区不是同一个。

inode是文件系统用来记录文件元数据的索引节点，每个文件或目录都要占用一个。如果分区里的小文件特别多，比如日志切割、邮件队列、PHP session临时文件，inode是会用完的。判断方法很简单，一条命令的事：

bash复制df -i

如果IUse%飙到100%，