故障排查实战手册：从场景到命令的精准狙击

在IT运维的日常中，故障往往不期而至。面对告警风暴和业务中断的压力，运维人员如果仅凭直觉“盲人摸象”，极易在浩如烟海的日志和指标中迷失。高效的故障排查本质上是一个“现象 -> 假设 -> 验证 -> 定位”的逻辑闭环。本文提炼了四大高频故障场景，提供标准化的排查思路与实战命令，助你在危机时刻精准狙击。

场景一：网络连通性异常

排查思路：遵循OSI模型自底向上排查，从物理链路到路由，再到端口与防火墙，最后看应用层DNS。

  1. 链路与ICMP层：确认网卡状态及基础连通性。
  2. 路由层：确认数据包能否正确到达目标网段。
  3. 传输层：确认目标端口是否开放且可达。
  4. 应用层：确认域名解析是否正常。

实战命令：


# 1. 检查本机网卡状态、IP及路由信息
ip addr show
ip route show

# 2. 基础连通性测试（加 -c 限制发包数，避免长时间挂起）
ping -c 4 <目标IP>

# 3. 路由追踪，定位丢包位置
traceroute <目标IP>  # Linux
tracert -d <目标IP>  # Windows

# 4. 端口连通性测试（比telnet更优，支持超时设置）
nc -zv -w 3 <目标IP> <目标端口>

# 5. 抓包分析（终极杀器，确认包是否发出及返回）
tcpdump -i eth0 -nn port <目标端口> -w capture.pcap

# 6. DNS解析验证
dig @<DNS服务器> <域名> +short
nslookup <域名>

场景二：系统负载飙升/CPU打满

排查思路：先看整体负载与平均负载，再定位到具体进程，最后下钻到线程或代码级别。

  1. 宏观定位：确认是CPU密集型（us高）还是I/O密集型（sy高/wa高）。
  2. 微观定位：找到消耗CPU最高的进程。
  3. 深度剖析：如果是Java等应用，需查看具体线程在执行什么代码。

实战命令：


# 1. 查看系统整体负载（重点关注1/5/15分钟均值，是否超过CPU核数）
uptime

# 2. 实时监控CPU上下文切换及中断（wa高代表磁盘慢，sy高代表内核开销大）
vmstat 1 5

# 3. 全局查看CPU占用排行（Shift+P按CPU排序）
top

# 4. 快速找出CPU占用最高的Top 5进程
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -6

# 5. 针对特定进程，查看其最高消耗的线程
top -Hp <PID>

# 6. 将异常线程ID转换为16进制，配合jstack/strace抓取堆栈（Java应用经典排查）
printf "%x\n" <线程ID>
jstack <PID> | grep <16进制线程ID> -A 30

# 7. 动态追踪系统调用（无源码时的神器）
strace -cp <PID>

场景三：磁盘空间不足与I/O瓶颈

排查思路：空间不足不仅要看可见文件，还要警惕已删除但未释放的句柄；I/O瓶颈需区分是读写量大，还是磁盘响应慢。

  1. 空间排查：定位大文件与隐藏占用。
  2. Inode排查：有时空间有剩余，但Inode耗尽（小文件过多）同样无法写入。
  3. I/O性能排查：看等待时间和队列长度。

实战命令：


# 1. 查看各挂载点空间使用率
df -hT

# 2. 查看Inode使用率（解决"No space left on device"但df -h有空间的诡异常）
df -i

# 3. 交互式定位当前目录下最大的文件/目录（需安装ncdu，极其好用）
ncdu /

# 4. 传统方式找大文件（按大小排序当前目录下前10个文件/目录）
du -sh * | sort -rh | head -10

# 5. 查找已删除但未释放空间的文件（重定向清空而不要rm日志文件！）
lsof | grep deleted

# 6. 实时监控I/O使用情况（关注 %util 是否接近100%，await 是否过高）
iostat -xz 1 5

# 7. 查看哪个进程在疯狂读写磁盘（类似top的I/O版）
iotop -oP

场景四：服务启动失败或运行异常

排查思路：服务异常通常伴随配置错误、端口冲突或依赖组件（如DB/Redis）断连。遵循“看状态 -> 查日志 -> 查端口/依赖”的步骤。

  1. 状态确认：利用系统服务管理器获取错误码。
  2. 日志挖掘：从系统日志和应用日志中提取Error信息。
  3. 环境验证：确认端口监听状态及外部依赖连通性。

实战命令：


# 1. 查看服务状态及最近的报错片段
systemctl status <service_name>

# 2. 查看该服务的完整系统日志（-u指定unit，-f持续跟踪）
journalctl -u <service_name> -f --no-pager

# 3. 检查端口是否被冲突占用
ss -tulnp | grep <端口号>

# 4. 检查应用配置文件语法（以Nginx为例，很多服务启动失败源于配置写错）
nginx -t

# 5. 测试依赖组件连通性（如数据库、缓存）
mysql -h<DB_IP> -u<user> -p<pass> -e "select 1"
redis-cli -h <Redis_IP> ping

# 6. 强制前台运行（排查Daemon模式启动即闪退的问题，剥离后台机制看输出）
<服务启动命令> -f  # 前台运行模式，或去掉 systemd 的守护参数

总结：故障排查的“心法”

命令只是武器，真正的运维高手靠的是心法：

  1. 先恢复再排查：业务中断时，优先通过重启、回滚、切换灾备恢复服务，保留现场（如dump、日志）后再慢查。
  2. 控制变量：每次只改动一个变量，避免叠加变更导致问题复杂化。
  3. 敬畏生产：绝不使用可能破坏数据的命令（如 rm、未限速的 dd、直接清空大文件），高负载下慎用重度抓包。
  4. 复盘沉淀：每一次故障都是资产，将排查过程沉淀为SOP，完善监控告警，让同类故障无处遁形。