Linux 日常排查：从现象到根因的五步法

服务器出问题时，最怕凭感觉乱改配置。先把现象固定下来，再按一条固定路径收敛，往往能更快定位。下面这套方法适合日常值班和个人排障，核心是先分层、再取证、最后才动手改。

一、先定性：是全挂，还是局部慢

先确认影响面：只有一台机器、一个服务，还是多台同时异常。可以用 curl 测接口，用 ping 测网络，用日志看最近一次成功的时间。影响面越大，越要先看共性变更，例如刚发布的版本、刚改的配置、刚到期的证书，而不是逐台重启。把“什么时候开始、谁受影响、报错原文是什么”写下来，后续每一步都有对照。

二、看资源：CPU、内存、磁盘、连接数

很多“服务变慢”其实是资源先到瓶颈。先看负载和内存，再看磁盘空间和 inode，最后看连接数和文件句柄。

uptime
free -h
df -h; df -i
ss -s

如果磁盘满了，先清理日志和临时文件，不要直接删数据库或业务数据；如果内存持续上涨，要看是缓存、泄漏，还是某个进程在不断创建连接。资源指标正常，再往应用层走。

三、看日志：从报错时间点往前倒推

日志不要只看最后一行。先锁定第一次报错的时间，再往前找十分钟内的警告和变更记录。应用日志、系统日志和反向代理日志要对照着看：应用说超时，可能是数据库慢；代理说 502，可能是后端进程已经退出。

journalctl -u nginx --since "30 minutes ago" | tail -n 100
tail -n 200 /var/log/app/app.log

把关键报错复制下来搜索时，要去掉时间戳、进程号和随机 ID，只留稳定的错误短语，这样更容易找到真正相关的讨论和文档。

四、做隔离：一次只改一个变量

定位到可疑点后，不要同时改三个地方。先做最小复现：换一台机器、换一个账号、绕过缓存、直接访问后端，看问题是否还在。能复现的问题才值得修，不能复现的“重启好了”往往还会再来。每次改动前先备份配置文件，改完记录时间和结果，方便回滚。

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
nginx -t && systemctl reload nginx

五、做收尾：修复、验证、留记录

修好之后不要立刻收工。先用原来的复现步骤验证一次，再看五分钟内的错误日志是否清零，最后把根因、改动、验证方法和预防措施写成一小段记录。下次再遇到类似现象，直接按记录里的检查顺序走，就不用从头猜起。日常还可以把磁盘、证书到期、服务存活做成定期检查，多数半夜告警其实都能提前发现。

总结一句话：先定影响面，再看资源和日志，然后一次只改一个变量，最后验证并留记录。排查速度不是来自经验玄学，而是来自固定顺序和可复现的证据。