很多排障失败，不是因为命令不会，而是因为顺序错了：上来就改配置、重启服务，最后把现场信息覆盖掉。
这篇给你一套可以直接照抄的流程：先保留现场，再缩小范围，最后验证根因。
一、先定边界：到底坏到什么程度
先回答三个问题：
- 影响范围：全量用户，还是部分请求？
- 起始时间：从什么时候开始异常？
- 变化事件：故障前是否有发布、配置变更、机器重启？
这一步的目的不是“找答案”，而是避免盲查。
二、先看现象，再看原因
排障建议固定顺序：
- 服务状态：进程是否存活，是否频繁重启
- 错误日志：先抓最近 100~300 行错误
- 上游依赖：数据库、缓存、外部 API 是否超时
- 资源瓶颈：CPU、内存、磁盘、句柄是否打满
三、常用命令清单（可直接复制）
1) systemd 服务
systemctl status your-service --no-pager
journalctl -u your-service -n 200 --no-pager
journalctl -u your-service --since "30 min ago" --no-pager
2) Nginx / Web 服务
tail -n 200 /var/log/nginx/error.log
tail -n 200 /var/log/nginx/access.log
grep -E " 5[0-9]{2} " /var/log/nginx/access.log | tail -n 50
3) Docker 容器
docker ps --format "table {{.Names}} {{.Status}}"
docker logs --tail 200 your-container
docker inspect your-container --format '{{.State.RestartCount}}'
四、把“报错”翻译成“可验证假设”
例如日志里出现：connection timeout。
不要直接下结论“网络有问题”，先拆成可验证假设：
- 假设 A：下游服务不可达
- 假设 B：DNS 解析异常
- 假设 C：连接池耗尽
然后逐条验证：
# 连通性
nc -zv downstream-host 5432
# DNS
getent hosts downstream-host
# 本机连接数
ss -s
关键原则：每次只验证一个假设。
五、两个最常见的误区
误区 1：一上来就重启
重启可能暂时恢复，但会丢失现场，后续很难复盘。
正确做法：先抓日志和状态，再决定是否重启。
误区 2：一次改三四处配置
这样即使恢复了，也不知道哪一项真正生效。
正确做法：单点变更 + 记录变更前后结果。
六、值班可用的 10 分钟排障模板
- 记录故障开始时间与影响范围
- 保存当前状态（status/log/top）
- 抓最近错误日志并标注首个异常时间
- 列 2~3 个假设，按成本从低到高验证
- 只做一处最小变更并观察
- 记录结论：根因、处理动作、预防项
结语
排障能力的核心不是“背命令”，而是用可复现的方法缩小不确定性。
把这套流程固化成团队模板，下一次故障处理速度会明显提升。