深色模式
排查通用套路
摘要：故障排查的核心不是"猜"，而是用结构化方法快速缩小范围。本文给出自顶向下、自底向上、二分法三条通用路径，以及一套可复制的现场动作清单，帮助新手在没有头绪时也能按部就班推进。
适用环境
bash
cat /etc/os-release
uname -r
systemctl --version | head -1
date -u1
2
3
4
2
3
4
排障步骤
第 1 步：先定界，再定位
用一句话写清故障：什么服务、什么时间、影响谁、表现为何。定界不清会导致定位方向反复横跳。
bash
# 统一时间基准，避免跨机日志对不上
date && date -u && uptime1
2
2
第 2 步：自顶向下（从用户可感知处往下剥）
适合"现象明确、链路长"的场景：入口 → 应用 → 进程 → 主机。
bash
# 应用层：服务是否还在响应
curl -sS -o /dev/null -w 'code=%{http_code} total=%{time_total}s\n' http://127.0.0.1:8080/health
# 进程层：进程存活情况与线程状态
systemctl status app --no-pager
ps -eLo pid,tid,pcpu,stat,comm | head -30
# 主机层：资源是否被打满
top -b -n 1 | head -201
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
第 3 步：自底向上（从资源指标往上查）
适合"现象模糊、告警先响"的场景，按 USE 方法看使用率、饱和度、错误。
bash
top -b -n 1 | head -12 # Utilization
cat /proc/loadavg
vmstat 1 5 # Saturation：运行队列、等待 IO
dmesg -T --level=err,warn | tail -20
journalctl -p err -S -30min --no-pager # Errors1
2
3
4
5
2
3
4
5
第 4 步：二分法（对半砍范围）
把链路切成两半，在中间点验证，一次排除一半，比逐层查快得多。
bash
# 例：客户端 -> LB -> 网关 -> 服务 -> DB
curl -sS -o /dev/null -w '%{http_code}\n' http://<service-ip>:8080/api # 判上下半段
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/<db-ip>/3306' && echo db-port-ok1
2
3
2
3
第 5 步：记录"假设 → 命令 → 结论"
每轮只验证一个假设并留痕，避免同一条路走三遍，也方便交接和复盘。
验证
bash
curl -sS -w '\n' http://127.0.0.1:8080/health # 现象是否消失
uptime # load 是否回落
journalctl -p err -S -10min --no-pager | tail -51
2
3
2
3
常见坑
一上来就改配置
未定界就改参数会破坏现场，还会叠加第二个变量。先保存证据（日志、栈、快照），再动手。
只看平均值
平均响应时间正常不代表没问题，长尾请求才常是投诉来源。同时看 P99 与错误数。
忽略"刚刚变更过什么"
多数故障由变更引发。排查同时并行确认最近的发布、配置、证书、扩容操作。
在生产执行来源不明的"一键脚本"
这类脚本常含重启、清理、强制删除等副作用。任何命令先在预发或只读模式下确认语义。