配套：本栏目工具总览表中的「架构 & 运维工具」分类；方法论见《成长体系》的稳定性章节。
排障的本质：快速缩小「问题空间」
线上故障的可怕之处不是难，而是黄金时间里的慌乱。没有工具链，每个人都在凭感觉猜；有了工具链，才能把「猜测」变成「二分定位」。
我的排障链路固定五步：告警发现 → 指标定位 → 日志取证 → 链路追踪 → 复现验证。每一步都有对应工具，缺一环就得多花十分钟。
第一步：告警——先回答「发生了什么」
告警的价值不在于多，在于可行动。踩过的坑：
- 告警疲劳：规则建了 50 条，天天半夜响，值班同学选择无视——等于没有告警。后来收敛到 10 条以内，每条都有明确处置预案。
- 指标告警的滞后：CPU 高是结果不是原因，等 CPU 告警响，事故已经发生了。要告警的是业务指标（成功率、延迟、积压量），资源指标只能当辅助。
工具：Prometheus + Alertmanager（规则收敛）、Grafana（面板）。
第二步：指标——把故障「切」到服务或资源维度
告警响了之后，先在 Grafana 上做三个动作：按服务切、按接口切、按时间对齐。多数故障在这一步就能定位到「哪个服务的哪个接口」。
踩坑记录：有一次 P99 恶化，所有人盯着应用服务查了半天，最后发现是日志组件的磁盘写满拖慢了全链路——如果一开始就按「基础设施 vs 应用」分维度看，能省 40 分钟。排障第一刀，永远是先切维度，再钻细节。
第三步：日志——取证，别猜
定位到接口后，去日志里找具体的报错样本。这里的工具坑是「日志散落」：多实例部署后，日志分布在几十台机器上，靠 ssh 一台台 grep 会崩溃。
解决：统一采集（Loki / ELK）+ trace_id 贯穿。每个请求带一个 trace_id，日志、指标、追踪全用它关联——这是排障效率的分水岭。
踩坑记录：早期日志没打 trace_id，故障时只能按「时间 + 用户 ID」模糊拼凑调用链，三次事故里有两次拼错。后来强制全链路透传 trace_id，排障时间平均下降 60%。
第四步：链路追踪——看到「慢在哪一跳」
OpenTelemetry + Jaeger/Tempo，把一次请求的每一跳（网关 → 服务 A → 缓存 → 服务 B → DB）的耗时可视化。P99 高的时候，追踪能直接告诉你慢在第三跳的 Redis 还是第四跳的 MySQL——这是指标和日志都给不了的答案。
坑：采样率默认全量会撑爆存储。我的经验：线上 10% 采样 + 错误请求全采样 + 手动强制采样入口，成本与可观测性平衡。
第五步：复现——压测验证假设
定位到根因后，修复前先复现：用 k6/wrk 回放真实流量（或构造边界条件），确认假设成立；修复后再压一遍确认问题消失。没有复现验证的「修复」，只是把故障推迟到下一次。
一整套「排障工作流」的沉淀
工具链之外，更要沉淀的是流程：
- 先止血再定位（回滚 / 限流 / 降级），别在故障中慢慢「欣赏」。
- 一切动作留痕（命令、变更、时间点），复盘才有材料。
- 复盘输出改进项，绑定到人，下个迭代必须闭环。
工具就这么多，真正难的是流程——发现、止血、定位、复现，每一步都要有纪律。我在另一篇复盘里写过一次完整的实战过程，那篇比这篇更能说明问题。
事故之后的复盘模板：故障复盘模板。