在日常运维中，大多数线上问题都可以归类为：资源类（CPU/内存/磁盘）、网络类（连通性/丢包/延迟/端口）、服务类（进程挂了/端口占用/依赖不可用）。
本文提供一套“从现象到定位再到验证”的排查路径，并给出常用命令与判断标准，帮助你把故障处理从“猜”变成“可复现、可回滚”。

一、排查总流程（建议照这个顺序做）

1. 先确认影响面

   • 影响哪些业务/实例/用户区间？
   • 是全量还是局部？
   • 发生时间是否与发布、定时任务、扩容缩容、网络变更相关？

2. 再确认是否为资源问题

   • CPU 飙高？内存耗尽？磁盘满了？IO 慢？
   • 使用率高不等于故障，但“异常波动 + 同时伴随告警”才是强信号。

3. 检查网络与端口

   • 端口是否监听？是否可达？是否出现大量 TIME_WAIT/连接失败？
   • 常见：安全组/防火墙变更、路由问题、DNS 问题、上游端口不通。

4. 定位到具体进程/服务

   • 进程是否崩溃重启？日志是否出现关键错误？
   • 依赖（数据库/Redis/中间件/对象存储）是否不可用或连接耗尽？

5. 验证修复是否真正解决

   • 观察指标恢复（CPU/内存/IO/RT/错误率）
   • 回放请求/压测验证
   • 检查是否存在“修复后延迟恢复/缓存未热”等问题

二、CPU 异常：从“谁在耗 CPU”到“为什么耗”

1）快速看全局

bash

topuptimempstat -P ALL 1vmstat 1

判断要点：

• CPU 飙满通常伴随：应用线程忙循环、GC 过频、加密/压缩异常、慢查询导致的计算放大、死锁重试等。
• vmstat里如果看到大量r（run queue）持续升高，说明 CPU 压力确实存在。

2）定位进程级别

bash

ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head -n 15

3）定位到线程/函数（可选但很快）

• 使用pid后可进一步：

bash

top -H -p <pid>

• 若能用perf（生产建议谨慎）：

bash

perf top -p <pid>

输出思路：
找到“最高 CPU 进程/线程”→ 对照日志/发布变更 → 结合慢点业务（查询、批处理、编码解码、加解密）进一步确认。

三、内存异常：从“是否 OOM”到“谁占用了谁没释放”

1）快速查看

bash

free -hvmstat 1dmesg -T | grep -i -E "oom|killed process"

2）找进程

bash

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head -n 20

3）排查系统层面：缓存/页回收

bash

cat /proc/meminfo | egrep 'MemTotal|MemFree|Buffers|Cached|SwapTotal|SwapFree'

判断要点：

• 是否发生 OOM Killer（dmesg很关键）
• 如果 swap 频繁使用且响应变慢，通常是内存不足/泄漏/缓存失控。
• Java 服务关注：GC 日志、堆使用、Metaspace、Direct Buffer（容器场景常见）。

四、磁盘/IO 异常：从“满了”到“慢了/写不动”

1）磁盘容量

bash

df -hT

2）找目录占用（最常见）

bash

du -sh * | sort -h | tail -n 20du -sh --max-depth=1 /var/log | sort -h | tail -n 20

3）找写入瓶颈/IO 等待

bash

iostat -x 1iotop -oPaqqq

常见事故：

• 日志未轮转导致磁盘满
• 临时目录（/tmp）爆满
• 数据库/队列落盘异常导致 IO 飙高

五、网络问题：连通性、延迟、丢包、端口与 DNS

1）连通性测试（目标从远到近）

• 从本机到网关：

bash

ping <gateway>

• 从本机到对端：

bash

ping <ip>

• 测延迟与抖动：

bash

mtr -rwzbc 200 <ip>

2）端口可达性

bash

nc -vz <ip> <port>telnet <ip> <port>

3）确认监听与端口占用

bash

ss -lntup | grep <port>lsof -i :<port>

判断要点：

• 端口监听但请求失败：多半是应用逻辑/鉴权/上游依赖
• 端口不通：优先排查防火墙、安全组、路由、DNS、服务是否在正确网卡监听

4）DNS 问题排查

bash

nslookup <domain>dig <domain> +trace

六、服务类故障：进程挂了、端口占用、依赖超时

1）看进程是否存活与重启频率

bash

systemctl status <service>journalctl -u <service> -n 200 --no-pager

2）查看端口是否仍被占用（常见：服务未完全退出）

bash

ss -lntup | grep <port>

3）看日志关键词（按优先级）

建议先搜这些关键词：

• Exception/ERROR/CRITICAL
• timeout/connect/refused
• OOM/out of memory
• 业务关键错误码（按你们系统定义）

bash

grep -Rin --color -E "ERROR|Exception|timeout|refused|OOM" /var/log/<app> | tail -n 200

七、Nginx / 反向代理常见故障速查（运维高频）

1）配置与重载

bash

nginx -tsystemctl reload nginx

2）看日志

bash

tail -n 200 /var/log/nginx/error.logtail -n 200 /var/log/nginx/access.log

3）快速判断：502/504/499

• 502：上游返回异常/上游连接失败（常见后端挂了、协议不匹配）
• 504：上游超时（常见慢查询/下游抖动）
• 499：客户端提前关闭（常见超时/网关策略/压测流量过大）

八、复盘方向

故障现象：（错误率/延迟/告警/时间点）
影响范围：（哪些实例/哪些接口）
初步判断：（资源/网络/服务/依赖）
关键证据：（top/free/df/日志/链路）
定位过程：（命令与结论）
修复方案：（重启/扩容/回滚/清理日志/调整参数）
验证结果：（指标回落、请求成功率恢复）
复盘改进：（告警补齐、阈值优化、限流、日志策略）