4.10.1 故障排查流程与方法论

故障排查应遵循“影响优先、证据驱动、最小变更”的原则，先保障业务恢复，再定位根因与防止复发。整体流程：事件确认与分级 → 快速止血 → 范围界定 → 证据采集 → 假设验证 → 修复验证 → 复盘改进。要求记录完整时间线与操作回溯。

一、事件确认与分级（示例与命令）
目标：确认影响面与优先级。
示例：Web 502 错误率升高，确认是全站还是部分接口。

# 1) 统计近5分钟 5xx 比例（Nginx）
tail -n 5000 /var/log/nginx/access.log | awk '$9 ~ /^5/ {c++} END{print "5xx:", c}'
# 预期：5xx 数量显著上升，进入 P1/P0 级别

# 2) 查看最近告警（系统层）
journalctl -p err -S "10 min ago" --no-pager
# 预期：是否存在系统级错误或服务崩溃日志

二、快速止血（优先恢复）
优先使用回滚、降级、限流、隔离节点等最小变更手段。

# 1) 临时隔离故障节点（示例：从负载均衡摘除）
# 假设 Nginx upstream 中下线一台
sed -i 's/server 10.0.0.12:8080;/#server 10.0.0.12:8080;/' /etc/nginx/conf.d/upstream.conf
nginx -t && nginx -s reload
# 预期：故障节点不再接收流量，服务恢复部分可用

# 2) 限流（示例：临时启用限流配置）
# /etc/nginx/conf.d/limit.conf
# limit_req_zone $binary_remote_addr zone=perip:10m rate=5r/s;
# 在 location 中加入：limit_req zone=perip burst=10 nodelay;
nginx -t && nginx -s reload

三、范围界定与影响面定位（示例与命令）
目标：确定是系统层、中间件层或应用层问题，定位到具体服务。

# 1) 系统层快速检查
uptime
free -m
df -h
# 预期：负载、内存、磁盘是否异常

# 2) 端口与连接数检查
ss -lntp | head
ss -s
# 预期：监听端口是否存在，连接数是否异常激增

# 3) 单机内热点进程
top -b -n 1 | head -n 20
# 预期：CPU/内存占用最高的进程

四、证据采集（示例与命令）
避免重启覆盖现场，优先采集日志、指标、堆栈。

# 1) 关键进程堆栈（示例：Java 进程）
jps -l
jstack -l <PID> > /tmp/jstack_$(date +%F_%H%M).log

# 2) IO 现场
iostat -x 1 3 > /tmp/iostat_$(date +%F_%H%M).log

# 3) 日志截取
grep -E "ERROR|Exception|timeout" /var/log/app/app.log | tail -n 200 > /tmp/app_err.log

五、假设验证与定位（示例与命令）
提出可验证假设：CPU 饱和、IO 等待、依赖超时、连接耗尽。

# 假设1：CPU 饱和导致请求变慢
pidstat -u 1 5
# 预期：某进程CPU持续高位

# 假设2：磁盘IO等待过高
iostat -x 1 5
# 预期：%util 接近 100 或 await 很高

# 假设3：依赖超时（检查下游）
curl -s -o /dev/null -w "time_total:%{time_total}\n" http://downstream.service/health
# 预期：时间明显高于正常基线

六、修复与验证（示例与命令）
修复分为临时措施与根因修复，验证关键指标恢复。

# 临时措施：重启异常进程（谨慎）
systemctl restart app.service
sleep 5
systemctl status app.service --no-pager

# 验证：关键指标恢复
curl -s -o /dev/null -w "status:%{http_code} time:%{time_total}\n" http://localhost/health
# 预期：HTTP 200 且响应时间恢复至基线

七、复盘与改进（示例模板）

# 故障复盘模板（示例）
时间线：
- 10:03 告警触发
- 10:05 定级 P1
- 10:08 流量切换完成
- 10:20 根因定位为磁盘IO瓶颈

影响范围：
- 30% 用户请求超时，持续 17 分钟

根因：
- 日志写入突增导致磁盘IO饱和

改进项：
- 增加IO告警阈值
- 限制日志速率
- 引入异步日志

方法论补充（结合场景）
- 三明治排查法：入口指标（Nginx）→ 中间层（缓存/数据库）→ 出口依赖（外部API）。
- 变更优先原则：对比最近发布/配置变更记录（git/tag、变更单）。

# 变更检查示例
git -C /opt/app log -1 --oneline
# 预期：最近提交是否与故障时间一致

练习
1. 构造高负载：使用 stress 模拟 CPU 占用，验证排查流程。
2. 使用 iostat 与 pidstat 采集证据并写出简要结论。
3. 写一份 10 行以内的复盘模板，包含时间线、影响、根因、改进。