排查信息收集与三板斧
大多数排查时间浪费在“信息不全就开始动手”上：不知道影响多少用户、不知道几点开始、不知道中间改了什么。本章把信息收集拆成三件事——影响面、时间线、三板斧，并给出一份可以直接抄进故障工单的《故障信息清单》。
第一件事：界定影响面
影响面决定了处置力度。影响 3 个内部用户和影响全站支付，处置手段完全不同。
| 要问的问题 | 收集方式 | 为什么关键 |
|---|---|---|
| 哪些接口报错 | 网关/APM 按接口维度的错误率与延迟 | 决定是否整体回滚还是单接口降级 |
| 多少用户受影响 | 错误请求数 × 去重用户数、客服工单量 | 决定是否触发对客公告 |
| 哪些地域或机房 | 按实例、按可用区分组的指标 | 定位是全局还是本地问题 |
| 是完全不可用还是变慢 | 超时率与 P99 延迟 | “慢”和“挂”根因往往不同 |
| 新用户还是老用户 | 登录/注册成功率、鉴权错误码 | 快速区分是账号还是系统问题 |
一句话原则：影响面靠指标算，不靠感觉猜。
第二件事：对齐时间线
T-30min 发布/配置变更/DDL/数据订正/证书更换/依赖方升级（逐条列出来）
T-5min 监控曲线拐点：QPS 突增？P99 抬头？错误率归零又反弹？
T0 第一个告警或第一通用户投诉（取更早的那个）
T+5min 你的第一个处置动作（摘流量/回滚），以及动作前后的指标对比
时间线的价值在于对照：曲线拐点与变更时间如果相差不到几分钟，几乎可以确定因果关系，不必再去主机上翻火焰图。
第三件事：三板斧的顺序
看监控（发生了什么） → 看日志（错在哪一步） → 看链路与主机（为什么慢/满）
顺序不能颠倒。先看监控可以避免在错误的实例上浪费时间；先看日志可以避免拿着 TraceID 去猜；只有前三步都指向主机资源，才需要登录机器敲 top。
| 步骤 | 入口 | 能回答的问题 | 常见坑 |
|---|---|---|---|
| 监控 | 大盘：QPS、P99、错误率、水位 | 什么时候开始、范围多大 | 只看均值，忽略分接口曲线 |
| 日志 | 应用日志、Nginx 日志、系统日志 | 错误类型与首个异常栈 | 只 grep 关键字，漏掉 TraceID |
| 链路 | Trace、慢调用 TopN | 哪一跳慢、慢在自身还是下游 | 采样率过低，看不到异常请求 |
| 主机 | CPU、内存、磁盘、网络、句柄 | 资源是否饱和 | 一上来就登机器，查错对象 |
三板斧的具体敲法
# 1. 监控：先确认是全局还是单实例（Prometheus 风格查询，用你自己的面板等价替换）
# sum(rate(http_requests_total{status=~"5.."}[1m])) by (instance)
# 2. 日志：按时间窗口一次性捞出，不要逐条 grep
journalctl -u myapp --since "10 min ago" --no-pager | tail -200
grep -c "TimeoutException" app.log
awk '{print $9}' access.log | sort | uniq -c | sort -rn | head # Nginx：状态码分布
# 3. 链路：找出最慢的接口与最慢的下游
# 按 P99 排序的前 10 个接口 → 逐个看 Span 拆解
# 4. 主机：确认资源水位（仅在前三步指向主机时执行）
uptime; free -h; df -h; df -i; ss -s
关键字检索：日志里的五个抓手
| 关键字 | 含义 | 排除方向 |
|---|---|---|
OutOfMemoryError / oom-kill | 内存耗尽或被杀 | 看 dmesg -T、容器内存上限 |
Connection refused | 对端没在监听 | 依赖方进程挂了或端口写错 |
Connection timed out | 网络或对端过载 | 看依赖方负载与网络丢包 |
Too many open files | 句柄耗尽 | lsof -p <pid> | wc -l、ulimit -n |
No space left on device | 磁盘或 inode 满 | df -h 与 df -i 都要看 |
同一类异常如果在 3 分钟内持续刷屏，直接去看第一个异常栈，后面的往往都是它的连锁反应。
一份可直接抄的《故障信息清单》
【影响面】
接口： 受影响接口与错误率
用户量： 受影响用户数 / 请求数 / 工单数
范围： 全量 / 单机房 / 单实例 / 单租户
形态： 不可用 / 变慢 / 数据错误
【时间线】
开始时间： 精确到分钟，发现途径（告警 or 用户反馈）
变更记录： 近 24 小时发布、配置、DDL、依赖变更清单
处置动作： 时间 + 动作 + 动作前后关键指标
【现象】
关键指标： QPS / P99 / 错误率 / 饱和度 的当前值与基线值
日志证据： 首个异常栈、错误码分布
链路证据： 最慢 Span 与下游耗时占比
主机证据： load / CPU / 内存 / 磁盘 / 句柄
【结论】
根因： 直接原因与根本原因分开写
恢复时间： 用户可用时间
遗留风险： 临时补丁的失效条件与回滚方式
沟通与记录
- 指定唯一指挥人，负责决策止血动作；其他人只负责取数据。
- 固定节奏同步，例如每 5 分钟一句：影响面、已做动作、下一步。
- 所有临时改动当场记录，故障结束前逐条回退或转正，避免留下幽灵配置。
- 不要在生产群里贴大段日志，贴 3 行关键输出 + 文件路径即可。
预防与巡检
- 告警必须带接口维度与实例维度，只有全局平均值等于没有告警。
- 变更记录集中可查，并且包含时间戳与操作人，否则时间线对不上。
- 每次故障都用同一份信息清单填写归档，三次之后自然形成排查肌肉记忆。
小结：先算影响面再动手，用时间线把曲线拐点与变更记录对齐，然后严格按“监控、日志、链路与主机”的顺序查；三板斧之外，一份结构化的故障信息清单能把排查从个人经验变成团队可复用的流程。