故障排查的第一目标是恢复服务
线上故障发生时，第一目标不是立刻找到根因，而是控制影响范围并尽快恢复服务。根因分析可以在恢复后继续做，但如果排查过程中不断尝试高风险操作，可能会扩大故障。
第一步：确认影响范围
先回答几个问题：
- 是所有用户受影响，还是部分用户受影响。
- 是所有接口异常，还是某个接口异常。
- 是一直异常，还是间歇性异常。
- 是刚发布后出现，还是没有变更也出现。
- 是否和某个地区、运营商、浏览器或账号类型有关。
影响范围越清楚，排查路径越短。比如只有登录接口慢，重点看认证服务、数据库用户表、验证码服务；如果全站 502，优先看网关、应用进程和上游健康状态。
第二步：保留现场证据
不要一上来就重启。重启可能恢复服务，但也可能清掉关键现场。至少先收集下面信息：
date
uptime
free -h
df -h
ss -lntp
systemctl status 服务名
journalctl -u 服务名 --since "30 minutes ago"如果使用容器，还要看容器状态和最近日志：
docker ps
docker logs --tail=200 容器名第三步：建立时间线
时间线能帮助判断故障是否与变更相关。建议记录：
- 故障首次出现时间。
- 最近一次发布、配置修改、证书更新、数据库迁移时间。
- 监控指标开始异常的时间。
- 用户反馈集中出现的时间。
如果异常时间和发布高度重合，优先回滚或灰度关闭新功能；如果没有变更，重点检查资源、依赖服务和外部网络。
第四步：按链路分层检查
Web 服务可以按这个顺序排查：
- DNS 是否解析正确。
- 服务器端口是否开放。
- Nginx 是否正常监听。
- 上游应用是否存活。
- 应用日志是否有异常。
- 数据库、缓存、对象存储等依赖是否正常。
不要跳着查。比如用户看到 502，可能是 Nginx 到应用不通，也可能是应用处理超时。先从网关日志确认错误发生在哪一层。
常见场景：接口超时
接口超时通常从三处查：
- 应用层：是否有慢方法、线程池耗尽、外部接口等待。
- 数据库层：是否有慢查询、锁等待、连接池耗尽。
- 网络层：是否有 DNS 慢、上游服务不可达、跨区域延迟。
排查时同时看接口耗时、数据库慢查询和应用日志。只看其中一个，容易误判。
常见场景：502
502 表示网关没有从上游拿到有效响应。常见原因包括应用进程挂掉、端口错误、反代配置错误、应用启动慢、上游超时。检查顺序：
sudo nginx -t
sudo systemctl status nginx
ss -lntp | grep 业务端口
curl -I http://127.0.0.1:业务端口
journalctl -u 业务服务 --since "30 minutes ago"第五步：恢复和复盘分开
恢复动作可以是回滚版本、重启异常进程、扩容、降级非核心功能、切换备用服务。恢复后要继续复盘，至少写清：
- 根因是什么。
- 为什么监控没有提前发现。
- 为什么故障会影响这么大。
- 如何防止再次发生。
- 需要补哪些告警、限流、熔断或回滚能力。
故障排查靠的不是某个神奇命令，而是一套稳定流程。每次故障后把流程补充完整，下一次处理速度就会更快。
评论