5.2 排障树：从告警到根因

5.2 排障树：从告警到根因

本节摘要：告警响后的三分钟最值钱，而多数团队在这三分钟里在做随机搜索：翻日志、问群、重启试试。本节把第 5.1 节的四类故障各展开成一条排障路径，合成一棵从告警直达根因的决策树：每个节点只回答一个是非题（"llm.call 段占比高吗""当天有变更吗"），每个分支指向下一个视图或动作——先看什么（span 树、三本账、TopN、版本标签）、下一步往哪走。然后是一则完整案例复盘：某客服功能成本提醒线告警，从 15:10 告警到 15:35 确认根因（新 prompt 版本导致工具输出解析失败、工具层无上限重试形成循环），全程只用前半立好的四件工具——span 树、三本账、TopN、版本标签。最后给无责复盘五问模板（Google SRE 方法论，社区公认）：时间线、根因、五问、行动项四件套。

学习目标

• 沿排障决策树把一条告警走到根因，每个节点知道先看什么视图
• 掌握四条路径的关键分叉：慢看段占比、错看责任层、坏看版本对齐、贵看三本账
• 会用"当天有变更吗"这个最高杠杆的单一问题
• 会写无责复盘：时间线、五问、行动项

一、排障决策树

告警（已按 5.1 归类）
│
├─ 慢（P95/TTFT 越带）
│   ├─ llm.call 段占比高？
│   │   ├─ 是 + TTFT 恶化 ──▶ 上游容量/排队 ──▶ 切轻量模型、限流排队（7.2）
│   │   └─ 是 + 生成段变长 ──▶ 输出变长 ──▶ 查输出长度信号与 max_tokens
│   ├─ retrieve 段占比高？──▶ 检索慢 ──▶ 降篇数、查索引
│   └─ tool 段占比高？──▶ 工具超时/重试 ──▶ 查 tool span 状态码（责任层：工具）
│
├─ 错（错误率/429/5xx 越线）
│   ├─ 多模型同时错？──▶ 供应商区域故障 ──▶ 切备用、看状态页做旁证
│   ├─ 只有 429？──▶ 限流额度打穿 ──▶ 查 TPM/RPM 用量（7.2）、分池扩额
│   └─ 单点错且伴随发布？──▶ 编排/网关变更 ──▶ 回滚、查网关是否剥 usage
│
├─ 坏（裁判分/点踩率/四信号异动）
│   ├─ 当天有变更？（prompt/模型/检索库三方版本标签，2.2）
│   │   ├─ 有 ──▶ 版本回归 ──▶ 回滚最近变更（最快路径）
│   │   └─ 无 ──▶ 模型快照静默漂移？──▶ 抽同时段样本对比、联系供应商
│   └─ 拒绝率↑ + 新主题份额↑？──▶ 输入分布变化 ──▶ 补知识库，不回滚
│
└─ 贵（三线告警/TopN 异常）
    ├─ 三本账哪本涨？（3.1 口径）
    │   ├─ 账二涨 ──▶ 输出失控/循环 ──▶ TopN 会话 → trace 看 pipeline 重复模式 → 熔断
    │   ├─ 账一涨 ──▶ 输入膨胀 ──▶ 查多轮历史/few-shot/记忆注入
    │   └─ 账三变 ──▶ 缓存失效 ──▶ 查前缀改动、命中率曲线
    └─ 单会话集中？──▶ agent 循环或刷量 ──▶ 熔断 + 限速；分散涨 ──▶ 版本回归或用量增长
​

树的用法三条：节点只问是非题，不问开放式问题（"为什么会慢"是下钻之后的事）；每走一步先看视图再动手（视图 = span 树、三本账、TopN、版本标签）；"当天有变更吗"是全树最高杠杆的问题——三方版本标签（第 2.2 节）在手的团队，坏答案类故障的定位通常不超过十分钟。

二、四条路径的三个共同纪律

1. 先止损后根因：树上每条叶子都写了止损动作，根因没查清也可以先执行（熔断、回滚、降级）——用户与账单不等人；
2. 下钻必到 span 层：任何"感觉是 XX 的问题"都要用第 2.1 节的分层验证（问题有固定住址），否则复盘会上全是猜测；
3. 全程留痕：走的每条分支、看的每个视图截图（或 trace_id 列表）记进时间线——复盘的第一手材料在现场，不在记忆里。

三、案例复盘：25 分钟的一次成本爆炸

背景（示意案例，数字为示意）：客服问答功能，日均 12 万次调用，预算三线已按第 3.3 节配好；周三 14:30，prompt v7 上线（工具输出的 JSON 格式约定变更，灰度 100%——这是伏笔）。

时间线（示意）
15:10  提醒线告警：客服功能消耗速率达日预算 1.9 倍（3.3 消耗速率法）
15:12  按分类表归"成本爆炸"；开 TopN 会话视图
       → 会话 s-88xx 已耗 61,000 token（常态约 6,000）
15:15  拉 s-88xx 的 trace：pipeline 层 11 轮 llm.call+tool 循环，
       每轮 tool 返回 200 但编排层日志有"解析失败，重试"×11
15:17  三本账核对：账二暴涨（每轮都重新生成完整过程说明）
15:18  版本标签核对：s-88xx 起始于 14:47，prompt_ver=v7 ── 与上线时间对齐
15:20  决策：v7 全量回滚到 v6；熔断 s-88xx 与同类 3 个会话（SessionCap 复位流程）
15:26  消耗速率回落至 1.1 倍；漂移面板输出长度均值开始回归
15:35  根因确认：v7 改了 JSON 字段名，工具返回仍是旧字段；
       编排层解析失败后无上限重试 → agent 视角"工具没成功"继续循环
​

根因链：变更（v7 字段改名）→ 解析失败（编排层）→ 无上限重试（编排层）→ 循环烧 token（账二）。注意责任层判定：第一嫌疑是"模型变笨了"，但 span 树显示每轮 llm.call 本身正常——根因在编排侧，不在上游。这条判定救了团队两小时的"换模型试试"弯路。

复盘会（次日，无责）：只对事不对人，产出四件套——时间线（上文）、根因（如上）、五问（下文模板）、行动项（下表）。

四、无责复盘五问模板

Google SRE 的无责复盘（blameless postmortem，社区公认方法论）落到 LLM 应用就是五个问题：

1. 什么坏了：现象、影响面（多少用户、多少美元、多久）——数字来自三支柱，不是形容词；
2. 为什么没能更早发现：哪个信号该亮没亮？阈值太松还是根本没埋？（本例：解析失败静默，无信号）；
3. 为什么会发生：根因链，到机制层为止（"人不仔细"不是根因，"流程允许 100% 直上"才是）；
4. 怎么能更快恢复：从告警到止损的实际用时，树上哪步可以再短？
5. 怎么防止再发：行动项必须带责任人与验收方式，且在下一次复盘开场先检查上一次的完成情况——没有回头检查的复盘是仪式，不是机制（第 1.2 节第 20 问的答案）。

⚠️ 两个反模式：把复盘开成追责会（下次没人再留真时间线）；把行动项写成"加强意识"（不可验收 = 不会发生）。

本节要点回顾

• 排障树：节点只问是非题，每步先看视图（span 树、三本账、TopN、版本标签）再动手，叶子全是止损动作。
• 四条路径口诀：慢看段占比、错看责任层、坏看版本对齐、贵看三本账；"当天有变更吗"是最高杠杆的问题。
• 三纪律：先止损后根因、下钻必到 span 层、全程留痕。
• 无责复盘四件套：时间线、根因（到机制层）、五问、带验收的行动项——行动项要回头检查。

至此，从信号到根因的完整链路闭环了。但全书立过的零件还散落在各章：tracer 在第 2 章、账本在第 3 章、探针在第 4 章、告警线在第 3.3 节。第 6 章做总装——一个约 170 行的纯标准库脚本，让三支柱真正跑在一个进程里。