L5.7 AI 系统事故响应与复盘
三维坐标
layer: L5（MLOps/LLMOps）｜level: Senior｜pillar: 训推框架L5.4 教你看指标与追踪；L5.2 教你怎么发布。本章教 出事了怎么办——AI 系统的事故与传统 Web 不同：服务可能「还在 200 OK，但答案已经错了」。我们沿四条主线展开：定级（SEV 分级与响应时限）、止血（MTTR 五阶段与 AI 事故止血手册）、复盘（blameless postmortem 五件套）、演练（Tabletop 桌面推演）——目标是把「救火靠英雄」变成「响应靠制度」。
学习目标
- 前置知识：读过 L5.2–L5.4；理解 RAG、模型 registry、灰度发布与回滚的基本概念；知道 SLI/SLO 是什么（L5.4 的 2.3 节）。无需 OnCall 实战经验。
- 学完产出：① 能列出 AI 系统至少 5 类独有故障模式，并解释为什么它们大多不触发传统可用性告警；② 能按 SEV1–SEV4 判定事故等级、给出对应响应时限，并处理「质量型故障没有硬宕机信号」的定级难题；③ 能把 MTTR 拆成 Detect → Triage → Mitigate → Resolve → Learn 五阶段，用数字算清「哪一段最值得投资」；④ 能写一份合格的 blameless postmortem（timeline / impact / root cause / action items / prevention），并说清 blameless 不是「和稀泥」而是一套激励机制设计；⑤ 完成一次 RAG 质量骤降的 Tabletop 演练，产出 timeline、mitigate 清单和 postmortem 草稿。
- 阅读姿势：盯住一条主线——Postmortem 的目标不是追责，是让同类事故在统计上不可能再发生。没有 action item + DRI + due date 的复盘等于没写；没有演练过的 runbook 等于没有 runbook。
背景与现状
先看两个真实感十足的业务症状，感受 AI 事故的「新形态」：
- 症状一：凌晨四点的告警风暴。值班手机连响 200 条告警——GPU 温度、P99、队列深度、KV Cache 全在叫，但没有一条告诉你根因。真正的问题是一台交换机端口降速导致 NCCL 通信退化，所有下游指标一起恶化。因为没有告警分级与拓扑聚合，值班人在噪声里刨了 40 分钟才找到那台交换机——这 40 分钟全算进 MTTR。
- 症状二：静默的报价事故。电商客服机器人某天开始把「满 300 减 30」的优惠券解释成「全场 3 折」。服务全程 200 OK、P99 完美、错误率为零——直到运营在社交媒体上看到用户晒截图。根因是前一天下午一次 prompt 模板改动删掉了「仅按知识库原文回答优惠信息」的约束。没有任何基础设施指标能发现这个事故，它只存在于「答案的正确性」这个维度里。
这两个症状指向同一个结论：AI 系统的事故形态与传统 Web 有系统性差异——
| 传统 Web 事故 | AI 系统独有事故 |
|---|---|
| HTTP 5xx 飙升 | Silent quality degradation（静默质量退化：200 OK，答案错） |
| DB 连接池耗尽 | Embedding 与索引版本不匹配（检索空间错位） |
| CPU 100% | Prompt injection / jailbreak 成功（安全边界被语言绕过） |
| 缓存穿透 | 上游 LLM API 限流导致降级模型悄悄上线（质量降级无告警） |
| 部署回滚 | 数据漂移导致检索失效（世界变了，索引没变） |
检测难点也随之改变：可用性告警是秒级的（up == 0 立刻可见），而质量指标（faithfulness、ragas 分数）通常依赖 5–15 分钟滚动窗口——告警触发时，用户往往已经受害 10 分钟以上。这就是为什么 AI 系统必须在传统监控之外补上合成探测（golden query set）：用固定的黄金问题集持续「自问自答」，把质量退化的检测从「等用户投诉」变成「主动巡逻」。
📅 时效说明（2026 年初）：从近两年的公开事故复盘与社区讨论看，LLM 应用的事故构成正在发生结构性变化——质量回退（模型/prompt/检索变更引入）、成本失控（token 用量或路由异常导致账单突增）、提示注入（prompt injection 造成越权或数据外带） 逐渐成为新的「三大事故类」，传统「服务宕机」型可用性事故的占比相对下降。这与技术栈成熟度一致：K8s + 多副本 + 自动扩缩容把「挂掉」变得罕见，而模型行为层的故障没有等价的成熟防线。本章的 SEV 分级与止血手册对这三类新事故均有对应条目，具体比例与工具生态请以当时实践为准。
原理与架构
2.1 SEV 分级与响应 SLA
事故响应的第一个动作永远是定级——级别决定拉谁、多快、用什么权限。定级宁可先高后降（可以从 SEV1 降到 SEV2），不要先低后升（升级往往意味着前 30 分钟白白流失）。
| 等级 | 定义 | 响应时限 | 示例 |
|---|---|---|---|
| SEV1 | 核心 API 全挂 / 数据泄露 / 越狱大规模成功 | 5 min 响应，全员 war room，冻结所有发布 | 推理集群全 RED；PII 泄露到日志；越狱 prompt 在社交平台扩散 |
| SEV2 | 单租户大量错误 / RAG 质量显著退化 | 15 min 响应，指定 IC，开事故频道 | faithfulness 5min 均值 < 0.7；某租户错误率 > 10% |
| SEV3 | 单模板劣化 / 个别模型 P99 超阈 | 1 hour 响应，正常工时处理 | 某 prompt 版本 regression；单模型长尾恶化 |
| SEV4 | 非用户 facing、内部工具 | 下一工作日 | 实验平台不可用；离线评估任务失败 |
三个定级要点：
- 响应时限指「有人认领并开始处理」的时间，不是解决时间。SEV1 的 5 分钟是「5 分钟内必须有 IC 在频道里说 I have it」。
- 质量型故障按「等效伤害」定级，不按基础设施信号定级：30% 的请求 返回错误答案，其伤害等效于 30% 的错误率——尽管 HTTP 层零错误（详见思考题 1）。
- 安全类事故自动升半级：涉及 PII 泄露、prompt injection 越权、数据外带的事故，即使影响面小，也因合规后果按更高等级处理，且必须拉入安全/法务。
2.2 MTTR 拆解：五阶段模型
- Detect（检测）：SLI 告警 + 用户反馈 + 合成探测（golden query set）。AI 系统的检测短板在质量维度——滚动窗口天然带来分钟级延迟。
- Triage（定位与动员）：确认 blast radius（影响面）、判定 SEV 等级、指定 Incident Commander（IC，事故指挥官）、建事故频道。IC 的职责是指挥而非亲自修——一个人同时敲命令和汇报，两件事都会做砸。
- Mitigate（止血）：优先 回滚最近变更（模型 / embedding / prompt / 索引）。止血和修根因是两件事：先让用户不再受害，再慢慢查为什么。
- Resolve（根因修复）：修根因、补测试、确认监控能看见同类问题。
- Learn（复盘）：48 小时内出 postmortem 草稿，7 天内完成 review——拖过一周，细节记忆衰减，timeline 就拼不出来了。
用户可感知的 MTTR = Detect + Triage + Mitigate（到止血为止，用户就不再受害了；Resolve 和 Learn 是内部债务）。这三段各自的耗时结构决定了改进投资该投向哪里——思考题 2 会用数字算一遍。
2.3 AI 事故止血手册（优先序）
止血动作按「见效快 → 见效慢」排序，从上往下尝试：
- 回滚 model registry 的 staging/production 指针（L5.1）——分钟级见效，适用于模型/权重变更引入的质量事故。
- 回滚 embedding 模型 + 确认 index version 匹配（L2.9）——embedding 与索引必须成对回滚，只回滚一边等于换了一种坏法。
- 切换路由到小模型兜底或静态 FAQ（L4.3）——适用于上游 API 限流或大模型不可用，用「降质量」换「保可用」。
- 关闭 Tool/MCP 外呼（Agent 路径）——适用于 prompt injection 或工具滥用类事故，先斩断「能造成外部影响」的手脚。
- 扩容——注意仅对容量型 SEV 有效；质量型事故扩容只会「更快地产出错误答案」。
口诀：变更引入的事故用回滚，容量引发的事故用扩容，安全类事故先断外呼。拿错药方比不吃药更糟。
2.4 Postmortem 五件套与 Blameless 原则
一份合格的 postmortem 必须包含五个部分：
- Timeline：UTC 时间线，精确到 分钟——从第一个信号到关闭事故。
- Impact：影响用户数、错误率、质量分变化、收入估算（哪怕是数量级估算）。
- Root Cause：用 5 Whys 追问到可行动的系统层——「某某手滑」不是根因，「系统允许该操作且缺少门禁」才是。
- Action Items：每条必须有 DRI（Directly Responsible Individual，直接负责人）+ due date + 优先级。
- Prevention：监控 / 门禁 / 自动化如何补洞，以及是否需要新增演练。
Blameless（无责）原则：写「系统允许 XX 操作缺少门禁」，不写「某某手滑」。这不是道德姿态，而是一套精确的激励机制设计——事故信息几乎全部掌握在当事人手里，追责文化会让当事人隐瞒细节、延迟上报，组织因此失去从事故中学习的原材料；无责文化用「说真话零成本」换来完整的 timeline 和真实的根因（机制的定量分析见思考题 3）。
动手实践：Tabletop 演练 — RAG 质量骤降
Tabletop（桌面推演） 是成本最低的事故演练形式：不动生产环境，全员围绕一个虚构但逼真的场景，口头/纸面推演每一步决策。它检验的不是系统，而是人和流程——runbook 是否可执行、定级是否有共识、IC 交接是否顺畅。
场景
RAG faithfulness 从 0.82 → 0.61（5 分钟滚动均值），用户 #42 率先反馈「回答不相关」。
你的任务
- 写出 0–30 分钟 timeline（含 IC 决策）
- 列出 3 条 mitigate 动作（按优先级）
- 完成 postmortem 草稿（五件套）
参考答案（先自己做，再对照）
Timeline 示例：
12:03 UTC 用户 #42 Slack 反馈「回答不相关」
12:05 ragas faithfulness 5min 均值 0.61，告警 InferQualityLow 触发
12:07 OnCall 确认 SEV2；开 #incident-20260627 频道；IC=@alice
12:08 查 deploy log：11:58 embedding 服务 v2.1 上线
12:09 查 index metadata：production index 仍为 embedding_v2.0 构建
12:11 Mitigate：回滚 embedding 服务至 v2.0
12:14 faithfulness 5min 均值回升至 0.80
12:25 SEV2 关闭；开启 postmortem 文档
注意这条 timeline 里的关键时效：检测花了 2 分钟（用户反馈先于告警——质量告警的滚动窗口延迟），定位只花了 4 分钟——因为第一反应是查最近 30 分钟的 deploy log，而不是去翻代码。
Root Cause（5 Whys 摘要）：
- 质量降因检索向量空间与索引不一致
- 因 embedding v2.1 上线但未触发 index rebuild
- 因 CI/CD 缺少「embedding 变更 → 强制 index version bump」门禁
- 因 registry 未把 index 列为 embedding 的 downstream dependency
- 因架构文档未将 index 纳入 model artifact 图
Action Items 示例：
| ID | 动作 | DRI | Due |
|---|---|---|---|
| AI-1 | CI 增加 embedding/model 变更必须附带 index rebuild job | @bob | 7d |
| AI-2 | Production index version 写入 MLflow tag index.embedding_version | @carol | 14d |
| AI-3 | 合成 golden query 每 5min 探针，faithfulness <0.75 页 OnCall | @dave | 3d |
Postmortem 模板（可直接复制）
# Postmortem: [标题] — YYYY-MM-DD
### Summary
一句话：发生了什么、影响多大、怎么修的。
### Timeline (UTC)
| Time | Event |
|------|-------|
| ... | ... |
### Impact
- 用户/租户：
- 持续时间：
- 质量/可用性指标：
- 业务影响（可选）：
### Root Cause
5 Whys + 技术根因一段。
### What Went Well / What Went Poorly
### Action Items
| ID | Action | Owner | Due | Status |
|----|--------|-------|-----|--------|
### Prevention
监控、门禁、演练计划。
踩坑预警
- 无变更日志：故障前 30 分钟内的发布最可疑——没有 deploy log，排障时间 ×2。
- 指标延迟：质量告警晚于用户感知——需 canary golden set 合成探测把检测提前。
- 责备文化：指名道姓 → 下次隐瞒 → 复发（机制见思考题 3）。
- Action items 无 DRI：等于不会被执行——复盘会开得再好也白开。
- 演练只做一次：Tabletop 的价值在重复——人员轮换、场景更新，每季度至少一次，否则 runbook 半年就腐化。
深入思考
下面三题每题先给题干，再用
<details>折叠一份图文并 茂的参考答案。建议先合上答案自己想 3 分钟，再展开对照。
思考题 1：没有宕机信号的事故怎么定级？
你的 RAG 客服机器人 faithfulness 从 0.85 跌到 0.60，抽样发现约 30% 的回答包含事实错误——但 HTTP 成功率 100%、P99 完美、没有任何基础设施告警。值班同学犹豫了：「服务没挂，算 SEV3 慢慢查吧？」结合 2.1 节的 SEV 分级表，你怎么反驳？请给出一个可以写进 runbook 的「质量型故障定级规则」，并说明 SEV1 与 SEV2 的核心差异到底是什么（提示：不仅是响应时间）。
展开参考答案（含质量型定级决策图 + 等效伤害算一遍）
结论：定级看的是「用户受到的伤害」，不是「基础设施发出的信号」。30% 的回答是错的，等效于 30% 的请求失败——按 2.1 节的表这明确落在 SEV2（RAG 质量显著退化）而非 SEV3；若错误答案涉及价格/医疗/法务等高风险内容，还要按「安全合规后果」升到 SEV1。质量型故障的定级规则必须写成「等效伤害折算」：把质量分下跌折算成错误率，再套用与可用性事故同一张 SEV 表——否则团队会系统性低估一切「没挂但错了」的事故。
用具体数字算一遍（等效伤害折算）：
| 事故 | 基础设施信号 | 用户视角 | 等效错误率 | 直 觉定级 | 正确定级 |
|---|---|---|---|---|---|
| A：某可用区宕机 | 5xx 飙升，告警爆炸 | 2% 请求失败（多副本兜住了） | 2% | SEV1？ | SEV2/SEV3 |
| B：本题质量退化 | 零告警，全绿 | 30% 回答含事实错误 | 30% | SEV3？ | SEV2 起步 |
事故 B 的等效伤害是事故 A 的 15 倍，但因为 A「场面吓人」而 B「静默无声」，未经训练的团队几乎总是把 A 定高、把 B 定低——这正是 runbook 需要「折算规则」的原因：先折算成等效错误率，再查表，不允许跳过折算直接凭体感定级。
SEV1 与 SEV2 的核心差异（不仅是 5 分钟 vs 15 分钟）：
- SEV1 是组织级动员：IC 有权调用任何团队、冻结全部发布、对外发 Status Page 公告、拉入法务/安全（泄露/越狱场景）。它买的是「组织的全部注意力」。
- SEV2 是服务级降级：仍有 partial 功能，通常租户级或质量级，不需 CEO 链路，但需 24 小时内启动 postmortem。
- 判断关键：blast radius 是否跨全体用户 + 是否存在合规/安全后果，而非单纯的错误率数字。30% 答案错误若只影响一个内部租户是 SEV2；1% 的回答泄露 PII 则直接 SEV1。
回链 2.1 节：这也解释了定级表里「安全类自动升半级」的设计——合规伤害不随请求占比线性缩放。
思考题 2：MTTR 的钱该花在哪一段？
你的团队季度复盘发现：过去 6 次 SEV2 的平均 MTTR（到止血）= 28 分钟，拆解为 Detect 12 min、Triage 6 min、Mitigate 10 min。现在有预算做一项改进，三个候选：① 上合成探测（golden query set），Detect 12 → 3 min；② 优化告警聚合与 runbook，Triage 6 → 3 min；③ 把回滚做成一键脚本，Mitigate 10 → 4 min。结合 2.2 节的五阶段模型，用「事故期间每分钟产生的坏答案数」算一算：哪项投资的收益最大？这个结论对「质量型事故为主」的 AI 系统有什么一般性启示？
展开参考答案（含 MTTR 分段投资对比图 + 坏答案总量算一遍）
结论：三项改进里，合成探测（压缩 Detect）收益最大——因为 AI 系统的质量型事故中 Detect 往往是最长的一段（滚动窗口延迟 + 依赖用户反馈），而事故伤害 ≈ 受害速率 × 受害时长，压缩最长的段就是压缩伤害的大头。一般性启示：传统 Web 的 MTTR 优化重心在 Mitigate（自动回滚、多活切换），而 AI 系统要把重心前移到 Detect——「更早知道出事了」比「更快按下回滚键」更值钱，因为质量事故的检测延迟天然比可用性事故长一个数量级。
用具体数字算一遍：
设事故期间流量为 2000 请求/分钟，其中 30% 受质量退化影响 → 受害速率 = 600 个坏答案/分钟。用户受害总量 = 受害速率 ×（Detect + Triage + Mitigate）：
| 方案 | MTTR（min） | 坏答案总量 | 相比基线削减 | 削减比例 |
|---|---|---|---|---|
| 基线（不投） | 12 + 6 + 10 = 28 | 600 × 28 = 16800 | — | — |
| ① 合成探测 | 3 + 6 + 10 = 19 | 11400 | 5400 | 32.1% |
| ② 告警聚合 | 12 + 3 + 10 = 25 | 15000 | 1800 | 10.7% |
| ③ 一键回滚 | 12 + 6 + 4 = 22 | 13200 | 3600 | 21.4% |
方案①削减的坏答案数是方案②的 3 倍、方案③的 1.5 倍。原因很朴素：它压缩的绝对分钟数最多（9 min），而每一分钟的价值是相同的 600 个坏答案。
两个追加洞察：
- 削减量只取决于压缩的绝对分钟数，与压缩哪一段无关——所以正确的决策方法是「哪段能压掉的分钟最多就投哪段」，而质量型事故中 Detect 几乎总是最长（本例占 43%）。这与 2.2 节强调「AI 系统检测短板在质量维度」一致。
- 但注意边际递减：把 Detect 从 12 压到 3 之后，下一笔预算就该投当时最长的 Mitigate（10 min）了。MTTR 优化是「打地鼠」：永远打当前最高的那一段，而不是无脑继续加码检测。
回链 2.2 节：这也是「用户可感知 MTTR = Detect + Triage + Mitigate」这个口径的价值——它把优化目标从模糊的「快点修好」变成了三段可测量、可对比投资回报的工程量。
思考题 3：Blameless 凭什么有效？
有工程师质疑：「复盘不点名，犯错没成本，大家不就更不小心了吗？」请从激励机制的角度反驳：为什么追责文化反而导致更多事故复发？结合 2.4 节的五件套，用一个简单的期望损失模型算一算：假设团队每季度实际发生 10 起值得复盘的事故，追责文化下只有 30% 被如实上报，未上报事故各有 20% 概率复发、每次复发损失 50000 美元——切换到 blameless（上报率 90%）后，期望损失差多少？再说明 blameless 如何同时提升 Action Item 的落地率。
展开参考答案（含两种文化的反馈回路图 + 期望损失算一遍）
结论：blameless 不是「对错误宽容」，而是承认一个信息经济学事实——事故的完整信息（真实 timeline、当时的判断依据、踩过的坑）几乎全部掌握在当事人手里，组织只能「买」不能「抢」。追责文化给说真话定了负价格（说了会被罚），于是当事人隐瞒、淡化、延迟上报，组织失去学习的原材料，同类事故按原概率复发；blameless 把说真话的成本降到零，换来高上报率与真实根因，Action Item 才能打在真正的系统缺陷上。惩罚的对象应该是「明知故犯与隐瞒」，而不是「在有缺陷的系统里犯了系统允许的错」。
用具体数字算一遍（期望损失模型）：
设每季度实际发生 10 起值得复盘的事故；被如实上报并复盘的事故，其根因会被修复（复发概率 ≈ 0）；未上报的事故各有 20% 概率复发，每次复发损失 50000 美元：
| 文化 | 上报率 | 被复盘 | 未上报 | 期望复发次数 | 季度期望复发损失 |
|---|---|---|---|---|---|
| 追责 | 30% | 3 起 | 7 起 | 7 × 0.2 = 1.4 | 1.4 × 50000 = 70000 美元 |
| Blameless | 90% | 9 起 | 1 起 | 1 × 0.2 = 0.2 | 0.2 × 50000 = 10000 美元 |
仅复发损失一项，blameless 每季度就少损失 60000 美元——而它的「成本」只是放弃了惩罚带来的心理满足感。这还没算追责文化的隐性代价：美化过的 timeline 让 Detect/Triage 数据失真（思考题 2 的 MTTR 分析直接建立在 timeline 可信之上）、资深工程师因怕背锅拒绝值班、以及「不敢回滚」——回滚等于公开承认自己的发布有问题。
Blameless 如何提升 Action Item 落地率（回链 2.4 节的五件套）：
- 根因指向系统而非人，Action Item 自然落在「加门禁 / 加监控 / 改流程」这类可执行、可验收的工程项上——「CI 增加 index rebuild 门禁」可以被 review 和关闭，「让某某下次小心点」永远无法验收。
- DRI 敢认领：在追责文化里认领 Action Item 等于认领「下次出事的锅」，人人推诿；无责文化里认领的是改进机会，postmortem review 会上抢着认。
- 形成正反馈：Action Item 落地 → 同类事故真的不再发生 → 团队亲眼看到复盘有用 → 上报意愿进一步上升。这正是 2.4 节那句「让同类事故在统计上不可能再发生」的机制学基础。
延伸阅读
1. 核心 Paper / 规范
- Google SRE Book — Postmortem Culture: Learning from Failure 一章是 blameless 复盘的权威源头；"Being On-Call" 与 "Emergency Response" 章节给出值班与 响应的组织设计。
- Google SRE Workbook — "Incident Response" 章提供 IC/OL/CL 角色分工的可落地模板，postmortem 模板可直接改造为团队标准。
2. 相关章节（本站内链）
- L5.2 流水线与发布 —— 回滚与金丝雀：止血手册第 1 条的技术底座。
- L5.4 可观测性与 SRE —— SLI/SLO/Error Budget：定级与检测的量化语言。
- L5.6 OpenTelemetry 追踪 —— Triage 阶段定位跨服务根因的核心工具。
- L2.9 流式 ETL 与 Embedding 管道 —— 理解 embedding/index 成对回滚的原因。
3. 优质实践参考
- PagerDuty 的开源 Incident Response 文档（response.pagerduty.com）—— 从定级、IC 职责到对外沟通话术的完整 SOP，可整体借鉴。
- 各大厂公开的 postmortem 汇编（如 GitHub/Cloudflare 的公开事故报告）—— 读真实复盘比读十篇方法论更能建立「什么算合格 timeline」的手感。
下一篇 → 回到 L5.4 可观测性与 SRE 的 SLO 体系，把本章的 SEV 定级规则接到你的告警路由上：告警分级与事故分级对齐，才能让「凌晨四点的 200 条告警」变成「一条带定级建议的聚合告警」。