一、排障先问三个问题

服务出问题，先别急着敲命令。先问自己三个问题：现象是什么、影响范围有多大、从什么时候开始的。现象要具体到可以验证的描述，比如“接口返回超时”就比“系统坏了”有用得多；范围决定你要去看哪台机器、哪个服务；时间点决定你要查哪一段日志。把这三点记下来，后面每一步都有据可查，也不会在错误的方向上浪费时间。

二、看服务状态，再看日志

先确认服务本身是不是在运行：

systemctl status nginx
journalctl -u nginx --since "1 hour ago"

状态是 stopped，说明服务没起来，先看启动报错；状态是 running 但请求失败，重点就转到日志。日志要按时间倒着看，先找报错行，再看报错之前发生了什么。不要一上来就翻全量日志，范围越小，定位越快。

三、看资源够不够用

很多“突然变慢”其实是资源耗尽：内存满了、磁盘满了、连接数满了。常用的三组命令够用了：

free -h
df -h
ss -s

内存看可用量，磁盘看根分区剩余量，连接数看总量和异常增长。磁盘满了，先清理日志再谈其他；内存满了，先看哪个进程占得多，再决定重启还是扩容。

四、看网络通不通

服务正常、资源够用，但请求还是失败，就查网络。先在本机上看端口有没有监听，再从客户端测到服务端的连通性：

ss -tlnp
curl -I 127.0.0.1:8080
ping 192.168.1.10

端口没监听，是服务配置问题；端口监听但连不上，先查防火墙，再查安全组；能连上但是慢，要看链路和对方服务。

五、记一个排障清单

养成习惯：每次排障结束，把现象、查过的命令、根因和处理办法记成几行。半年下来，这份清单就是你自己的故障手册。下次再遇到类似现象，先翻清单再动手，多数问题半小时就能定位。把清单沉淀下来，团队新人也能少走弯路。