故障排查实战手册：按图索骥，精准定位

在IT运维的日常中，故障往往如同不期而至的风暴。面对告警风暴和业务中断的压力，运维人员如果仅凭记忆和直觉“盲人摸象”，极易陷入“头痛医头，脚痛医脚”的困境。本手册旨在沉淀体系化的排查逻辑，按高频故障场景分类，提供“思路+命令”的实战指南，助你按图索骥，精准定位。

场景一：网络连通性故障

排查思路：遵循OSI模型自底向上排查，遵循“本机网卡 -> 本地网关 -> 目标IP -> 目标端口 -> 应用层”的路径，逐步缩小故障范围。

1. 检查本机网络接口

确认网卡是否启用，IP地址、子网掩码是否配置正确。


ip addr show  # 或 ifconfig，查看IP及网卡状态(UP/DOWN)

2. 测试链路与网关

先Ping网关，确认本机到网关的二层/三层网络是否通畅；再Ping目标IP，若不通，需通过路由追踪定位断点。


ping -c 4 <网关IP>         # 测试网关连通性
traceroute <目标IP>        # 追踪路由跳数，定位丢包位置
mtr -rwbz <目标IP>        # 结合Ping与traceroute，动态查看各跳丢包率

3. 检查端口可达性

网络通不代表服务通，需确认目标端口是否对外开放且被监听。


telnet <目标IP> <端口>     # 传统探测方式
nc -zv <目标IP> <端口>     # 更轻量级的探测工具，支持超时设置

4. 抓包分析（终极杀器）

当网络时断时续或应用层报错（如TCP重传、RST中断）时，需抓包分析。


tcpdump -i eth0 -nn port <端口> -w /tmp/capture.pcap
# -i指定网卡，-nn不解析域名和端口名，-w保存为文件供Wireshark分析

场景二：CPU/内存等系统资源耗尽

排查思路：先定性（是CPU还是内存瓶颈？），再定位（哪个进程作祟？），最后分析（进程内部在干什么？）。

1. 全局资源概览

快速查看系统负载及资源使用率，关注load average（1/5/15分钟负载）及us/sy/wa（用户/内核/IO等待）占比。


top  # 动态查看，Shift+P按CPU排序，Shift+M按内存排序
uptime  # 快速查看系统负载

2. CPU高负载排查

若us高，多为应用代码死循环或计算密集；若sy高，多为系统调用频繁或锁竞争；若wa高，说明CPU在等磁盘IO。


pidstat -u 1 3  # 每秒输出一次CPU使用情况，共3次，精准定位高CPU进程
perf top        # 实时分析CPU在哪些函数上消耗时间（需安装perf）

3. 内存不足排查

关注free -m中的available列，而非free列（Linux会将空闲内存用作缓存）。


free -m
ps aux --sort=-%mem | head -10  # 按内存占用倒序取Top 10进程

若发生OOM（Out of Memory），需检查系统日志。


dmesg -T | grep -i oom  # 查看内核日志中的OOM Killer记录

场景三：磁盘I/O与空间异常

排查思路：磁盘故障通常表现为两类：一是空间满导致服务无法写入；二是I/O瓶颈导致响应极慢。

1. 磁盘空间排查

不仅检查块空间，还要检查Inode（索引节点）空间，小文件过多会导致Inode耗尽，表现为空间有剩余但无法创建文件。


df -h     # 查看块空间使用率
df -i     # 查看Inode使用率

2. 大文件与隐藏占用定位

若df显示满，但du显示有剩余，通常是已删除文件但进程仍持有句柄未释放导致。


du -sh /* | sort -rh | head -10  # 从根目录逐级查找大文件
lsof | grep deleted               # 查找已删除但仍被进程占用的文件（重启进程可释放）

3. 磁盘I/O性能排查

当系统响应卡顿，top中wa居高不下时，需排查I/O。


iostat -dx 1 3  # 查看各磁盘的%util和await，%util接近100%说明磁盘饱和
iotop           # 类似top，按I/O使用率排序查看进程
pidstat -d 1    # 查看具体进程的读/写速率

场景四：应用服务启动失败

排查思路：遵循“看状态 -> 查日志 -> 查端口/权限 -> 查配置”的闭环逻辑，切忌一上来就改配置重启。

1. 查看服务状态

通过系统服务管理器获取进程退出码和标准错误输出。


systemctl status <服务名>  # 关注Active状态及底部输出的错误信息

2. 查阅应用日志

状态信息有限时，必须深入日志。先找错误日志路径，再使用过滤工具。


journalctl -u <服务名> --since "10 min ago" -n 50  # 查看systemd管理的近10分钟日志
tail -200f /var/log/<服务名>/error.log             # 动态追踪应用报错日志
grep -i -C 5 "error\|exception" /path/to/log       # 搜索日志中的异常及前后5行上下文

3. 检查端口与权限

服务启动失败常因端口冲突或权限不足。


ss