systemctl status 服务服务相关问题的第一站：是 active、failed 还是没起。
Linux 问题排查总流程
约 1462 字大约 5 分钟
2026-05-14
前面的模块讲的是“某一层的知识”，这个模块讲的是“遇到问题怎么把这些知识串起来用”。而串联的方法，就是一套固定的排查流程：现象 → 范围 → 证据 → 假设 → 验证 → 修复。它不依赖你记住多少命令，而是让你不慌、不乱猜、不越查越乱。
阅读导览
Linux 问题排查总流程
建立一套通用排查框架：先描述现象、再缩小范围、用命令收集证据、提出并验证假设，最后才动手修复并复盘。
- 先描述现象，别急着动手
- 每条命令都为验证一个假设
- 改之前先收集和保留证据
- 修复后复盘并记录
命令速查
排查起手式
不慌、不乱猜journalctl -u 服务 -n 100状态告诉你成没成，日志告诉你为什么。
df -h / free -h / uptime三条命令快速扫一眼磁盘、内存、负载是否异常。
ip a / ss -lntp网络相关问题先看本机地址和监听端口。
六步排查框架
不管遇到什么问题，按这六步走，不会乱：
| 步骤 | 你要做的 | 关键点 |
|---|---|---|
| ① 现象 | 把问题描述清楚 | 是什么报错、什么时候开始、影响谁 |
| ② 范围 | 缩小到一个点 | 是单文件、单用户、单服务，还是整机 |
| ③ 证据 | 用只读命令收集 | 状态、日志、资源、配置——先看不改 |
| ④ 假设 | 基于证据提一个可能 | 一次只提一个，别堆一堆 |
| ⑤ 验证 | 用一条命令验证它 | 只改一个变量，结果支持就继续，不支持就换假设 |
| ⑥ 修复 | 改动 + 复盘 | 改前备份、改后验证、记录原因 |
新手最容易跳过 ①②③ 直奔 ⑥——“先重启试试”“先 chmod 777 看看”。这恰恰是越查越乱的根源。
第一步：把现象说清楚
“服务挂了”不是一个可排查的现象。可排查的现象是：“api.service 从 10:05 起进入 failed 状态，curl localhost:8080 返回 connection refused，大约同时上线了一个配置变更。”
说清楚现象，往往问题已经解决一半——它顺便回答了“什么时候开始的”（→ 去翻那个时间点的日志、那个时间点的变更）。
第二步和第三步：先缩范围，再收证据
缩范围：是所有用户还是某一个？所有机器还是这一台？所有请求还是某个接口？范围越小，要查的东西越少。
收证据：这一步的铁律是只用只读命令。systemctl status、journalctl、df、free、ss、ls -l——它们只看不改。把关键输出记下来（PID、端口、时间戳、错误信息原文）。别在还没看清的时候就动手改，那会同时改变问题本身，让你失去判断依据。
第四步和第五步：一次一个假设
证据看够了，提一个具体的假设：“可能是配置文件里端口写错了”。然后用一条最直接的命令去验证它——grep port config.yml。
要点是一次只验证一个假设，只改一个变量。同时改三样东西然后好了，你根本不知道是哪样起了作用，下次还得重来。假设被否定也是收获——它排除了一个方向。
第六步：修复要克制，还要复盘
确认了根因再动手。动手时：
- 改前备份——配置文件
cp一份，便于回滚 - 选影响最小的方案——能 reload 不 restart，能改一个参数不重装
- 改后验证——确认现象消失，且没引入新问题
- 复盘记录——把“现象 → 根因 → 怎么修的”写下来，下次同样的问题不用从头摸
“先重启试试”是排查的敌人
重启、chmod 777、kill -9、删文件——这些“先试试”的动作有个共同问题：它们在你还没理解问题的时候就改变了现场，既可能碰巧掩盖问题(下次复发更难查)，也可能直接造成新的事故。正确的顺序永远是：先用只读命令看懂，再动手改。这个模块后面每一篇具体场景，走的都是同一套“看懂再动手”的流程。
常见误区
| 误区 | 更稳妥的做法 |
|---|---|
| 跳过现象、范围、证据，直接“重启试试” | 先用只读命令看懂，再动手 |
| 一次提一堆假设、改一堆东西 | 一次一个假设、一次只改一个变量 |
| 排查途中就动手改，破坏了现场 | 收证据阶段只用只读命令，保留现场 |
| 修好了就完事，不复盘 | 记录现象、根因、修法，把一次排查变成可复用经验 |
实践清单
练习清单
- 1回想一次你解决过的问题，用“现象→范围→证据→假设→验证→修复”六步重新复述一遍。
- 2下次遇到问题，强制自己在动手改之前，先只用只读命令收集证据。
- 3练习把模糊的“X 坏了”改写成带时间、范围、报错原文的具体现象。
- 4为一次排查写一份简短复盘：现象、根因、怎么修的、怎么预防。
重点总结
要点回收
- 排查是固定流程：现象 → 范围 → 证据 → 假设 → 验证 → 修复，不靠记命令靠靠流程。
- 收证据阶段只用只读命令，别在没看懂前动手改，那会破坏现场。
- 一次只验证一个假设、只改一个变量；修复要备份、要复盘。
版权所有
版权归属：Shuo Liu