Appearance
故障演练与预案专题
版本：
v1.4最后更新：
2026-07-09适用对象：正在建设 AI 系统事故预案、值班 runbook、Game Day、灰度回滚和人工接管机制的产品、平台、SRE、安全与业务 owner
很多团队写过事故预案，却没真正演过。等到 AI 系统真的出问题时，常见现场不是没人知道系统有风险，而是：
- 大家都感觉事情不对
- 但没人能在前五分钟说清楚先做哪一步
- 也没人确定谁有权拍板降级、回滚或切人工
AI 场景的故障演练，目标不是证明系统一定不会坏，而是证明团队在系统坏掉、行为漂移、知识污染或工具越权时，能够稳定止血、快速恢复、留下证据，并把经验沉淀回产品与流程。
根据 2026-07-09 可访问的 Google SRE Incident Response / Canarying Releases / On-Call / Alerting on SLOs，OpenAI Production best practices / Safety in building agents / Guardrails and human review，以及 Anthropic 关于高风险工具需人工确认的资料，一个更贴近现实的共识是：
AI 故障演练不只是练“服务挂了怎么办”，而是练“行为出问题时如何识别、止血、接管、回滚和复盘”。
1. 为什么 AI 系统的故障演练不能照抄传统系统
传统系统演练常围绕这些问题：
- 服务宕机
- 数据库不可用
- 网络延迟陡增
- 单机或单可用区故障
AI 系统还会多出一类更隐蔽的行为故障：
- 模型版本变更后特定场景准确率断崖式下降
- Prompt 或工具 schema 调整后调用参数变形
- 检索索引发布错误，导致大面积错误引用
- 审批策略或权限标签失效，高风险动作被漏放
- 后台 Agent 长任务堆积，回合失控，补偿链路被拖垮
这类故障的特点是：
- 不一定直接报 500
- 不一定能靠基础监控第一时间发现
- 很依赖回放、样例、trace、变更记录和人工判断
所以 AI 演练必须同时覆盖三类能力：
- 系统可用性恢复
- 行为正确性止损
- 组织决策链与人工接管
2. 故障演练到底在练什么
更实用的定义是：在真实事故发生前，预先模拟一组高风险失败模式，验证监控、分工、权限、工具、回滚、沟通和复盘链路是否真的可执行。
一场合格的演练至少要回答六个问题：
- 谁先发现异常。
- 谁来定级。
- 谁有权决定止损动作。
- 哪些动作可以立刻执行，哪些必须升级审批。
- 回滚或降级后怎么验证恢复。
- 演练暴露的问题如何进入修复闭环。
如果预案只写“出现问题联系相关同学”，那不是预案，只是一个模糊提醒。
3. 四类最常用的演练方式
3.1 桌面推演
桌面推演适合先把流程和角色跑通，不直接动生产或仿真环境。常见形式是按时间线给材料，让值班、平台、算法、业务和安全角色依次做决策。
适合优先验证：
- 事故定级是否一致
- 升级路径是否清晰
- 谁负责拍板是否明确
- 通知模板和沟通口径是否统一
3.2 Game Day
Game Day 更接近真实事故，重点不是讨论“理论上应该怎么办”，而是要求团队像真事故那样执行 runbook、看指标、发通知、做切换。
更适合验证：
- 值班响应速度
- 回滚动作是否真的能做
- 多角色协作是否会卡住
- 生产近似环境是否能复现关键链路
3.3 Chaos / Fault Injection
Chaos 演练强调通过受控注入故障验证韧性，例如注入网络抖动、依赖服务失败、资源耗尽、消息积压、数据库切换、缓存失效。
适合验证：
- 自动重试和断路器是否合理
- 自愈、补偿和降级策略是否生效
- 告警是否能及时触发
- 故障是否会跨链路放大
3.4 回滚与切人工演练
AI 业务里非常关键的一类演练，不一定要做复杂故障注入，而是专门验证：
- 模型回退能否在限定时间完成
- Prompt 版本是否支持快速切换
- 检索索引是否能回到上一稳定版本
- 工具权限是否能快速收缩
- 自动流程是否能强制切为人工审批或人工接管
很多团队真正失败的地方，不是在“发现问题”，而是在“知道要回滚，但没人敢动或没人会动”。
4. AI 场景优先级最高的演练清单
建议优先从高影响、可复现、和现有架构强相关的场景开始，而不是一上来追求全覆盖。
4.1 模型与 Prompt 相关
- 新模型切换后关键任务成功率下降
- Prompt 改版导致工具参数结构变化
- 安全提示被绕过，敏感输出增多
- 推理长度异常上升，延迟和成本一起失控
4.2 知识库与检索相关
- 错误文档批量入库
- 权限标签打错，越权内容被召回
- rerank 配置变更后高频问答错引
- 索引构建失败但旧索引已被替换
4.3 Agent 与工作流相关
- 长任务回合数异常膨胀
- 工具超时触发重试风暴
- 补偿链路只执行一半，状态不一致
- 人工纠偏工作台积压，升级链条断裂
4.4 安全与审批相关
- 高风险工具被误开放
- 审批链断裂，自动流程越过人工节点
- 风险分层路由失效，高风险请求误走自动通道
- 外部依赖异常，审计日志缺失
5. 建议采用统一的事故分级
演练前就应该约定统一分级，否则现场最常见的争议就是“这到底算不算事故”。
可采用一个简单的四级模型：
| 等级 | 典型影响 | 响应要求 | 典型动作 |
|---|---|---|---|
S1 | 大面积用户受影响，存在安全、合规、资金或高风险操作外泄 | 立即升级，进入战时指挥 | 全量降级、回滚、切人工、冻结变更 |
S2 | 关键功能明显退化，但仍可部分服务 | 分钟级响应 | 局部回滚、关闭高风险工具、限制流量 |
S3 | 单一场景或单租户退化，可控 | 小范围处置 | 定向修复、影子验证、加强监控 |
S4 | 潜在风险或近失误，无直接用户影响 | 纳入治理 | 更新规则、补样例、补告警 |
AI 场景里尤其要承认一种事故：系统没挂，但行为已不可接受。这种情况通常至少应按 S2 起步，而不是因为“接口成功率正常”就降级处理。
6. 演练中的角色要提前钉死
Google SRE 的 incident response 实践强调要明确指挥角色，避免所有人同时排查、同时拍板。放到 AI 系统里，至少建议固定这些角色：
Incident Commander：统一定级、节奏、优先级和对外口径Operations / SRE：负责值班、监控、降级、流量和基础设施动作AI Platform / Agent Owner：负责模型、Prompt、工具、路由、Agent 策略调整Safety / Security Owner：负责越权、敏感内容、安全审批和审计判断Business Owner：确认业务影响、灰度范围、暂停策略和客户沟通Scribe：记录时间线、关键决策、证据和待办
如果团队规模小，可以一人兼多角，但不能省略职责定义。
7. 一份可执行 runbook 的最小字段
预案不怕短，怕写了也执行不了。建议每个高风险场景至少包含这些字段：
| 字段 | 说明 |
|---|---|
| 场景名称 | 例如“模型升级后客服问答准确率大幅下降” |
| 触发信号 | 告警、业务指标、人工投诉、抽检、trace grading 结果 |
| 影响范围判断 | 哪些租户、渠道、工作流、模型路由受影响 |
| 事故分级规则 | 到什么程度算 S1/S2/S3 |
| 决策人 | 谁有权发起回滚、降级、切人工 |
| 止损动作 | 关闭工具、切旧模型、切只读、降级提示、冻结发布 |
| 回滚动作 | 回哪一层，顺序是什么，前置条件是什么 |
| 验证动作 | 看哪些核心指标和样例确认恢复 |
| 升级路径 | 谁接谁，多少分钟未恢复必须升级到谁 |
| 沟通模板 | 内部同步、业务同步、客户同步的简版模板 |
| 证据清单 | trace、请求样例、变更记录、日志、审批记录 |
| 复盘要求 | 何时复盘，谁出 RCA，修复项如何跟踪 |
最关键的一点是，runbook 必须映射到真实动作，而不是只写原则。
8. 推荐把止损动作拆成四层开关
AI 系统事故响应里，止损动作越抽象，现场越容易拖延。更推荐按层准备明确开关：
8.1 入口层
- 暂停新流量
- 对高风险租户或功能限流
- 将高风险请求强制转人工
8.2 路由层
- 切回旧模型
- 切回旧 Prompt 版本
- 关闭新策略或新实验组
8.3 工具层
- 关闭写操作工具
- 收紧工具参数白名单
- 提升人工审批阈值
8.4 知识与状态层
- 回退检索索引
- 冻结知识库增量发布
- 停止后台长任务继续扩散
这样做的好处是，故障现场不再是“要不要回滚整个系统”，而是能做局部止血。
9. 一场演练的推荐时间线
9.1 演练前
- 明确演练目标，只选 1 到 2 个核心能力
- 确定演练类型，是桌面推演、Game Day 还是 Chaos
- 选定成功标准，例如 15 分钟内完成模型回退
- 明确停止条件，避免演练本身扩大风险
- 准备注入方式、观察面板、联系人和回退脚本
9.2 演练中
- 由主持人注入事件或逐步释放线索
- 值班人员自行判断是否升级，不提前给答案
- 记录每个关键动作的时间点
- 观察监控、日志、trace、样例、审批记录是否足够支撑判断
- 在触发停止条件时立即终止演练并恢复
9.3 演练后
- 先确认系统恢复，不带问题散会
- 24 小时内完成时间线整理
- 72 小时内产出复盘和行动项
- 行动项进入真实跟踪系统，不留在会议纪要里
9.4 演练前最好先定义 blast radius 和 kill switch
很多团队做演练时最危险的地方不是故障本身，而是：
- 演练影响范围没有提前封住
更稳的做法通常是在演练前明确两件事：
blast radius最多影响哪些租户、哪些流量、哪些功能。kill switch一旦触发停止条件，谁有权立刻终止演练并恢复。
这一步非常关键，因为 AI 演练经常会碰到：
- 模型路由切换
- 检索索引回退
- 工具权限收缩
- 人工接管强制打开
如果这些动作没有预先约定 blast radius，很容易从“验证韧性”变成“扩大事故”。
10. 桌面推演、Game Day、Chaos 的边界不要混
三者都叫“演练”，但目标不同：
| 类型 | 主要验证对象 | 是否动系统 | 更适合什么问题 |
|---|---|---|---|
| 桌面推演 | 分工、定级、升级、沟通 | 否 | 组织链路和预案是否清楚 |
| Game Day | 团队实际执行能力 | 通常会动近生产环境 | runbook 是否真能跑通 |
| Chaos / Fault Injection | 韧性、自愈、告警和恢复机制 | 会注入受控故障 | 架构是否能承受故障 |
如果团队还没有稳定 runbook，先做桌面推演更划算；如果 runbook 已有但从未执行，优先做 Game Day；如果系统已经上线并且高度依赖自动恢复，再持续加入 Chaos。
11. AI 专属的证据采集要求
AI 事故和传统事故不同，很多关键证据不是 CPU 和错误码，而是行为与上下文。
建议在演练中固定采集这些证据：
- 原始 request / trace id
- 新旧模型或 Prompt 版本
- 检索候选与最终引用
- 工具调用记录
- 审批链记录
- 风险标签和 guardrail 命中情况
- 人工接管和回滚操作日志
没有这些证据，很多演练最后只能停留在：
- “感觉当时应该是这个原因”
11.1 证据对象最好按“请求、轨迹、版本、决策、动作”五层保存
很多团队虽然会留日志，但演练复盘时依然会卡住，原因通常是：
- 证据散在不同系统里，无法拼回一条完整时间线
更稳的采集心智通常是按五层整理：
request layer请求样例、trace id、用户输入、租户范围。trajectory layer检索候选、工具调用、审批链、handoff 轨迹。version layer模型、Prompt、索引、策略、grader、guardrail 版本。decision layer谁定级、谁拍板、为什么回滚、为什么切人工。action layer实际执行了哪些开关、脚本、回退动作和恢复验证。
这样复盘时你才不只是知道：
- 系统坏了
而是能回答：
- 它是怎么一步步坏的
- 团队是怎么一步步止血的
12. 为什么人工接管也必须演练
很多团队的预案默认：
- 真出问题了再切人工
但现实里最容易出事的是：
- 切人工入口没人知道在哪
- 人工容量根本接不住
- 切人工后上下文没传过去
所以至少要演过：
- 谁触发切人工
- 切人工后谁接
- 接手时能看到哪些上下文
- 自动链路恢复后如何切回
13. 为什么回滚演练要和灰度机制一起看
很多“会回滚”的团队，实际只会：
- 理论上回滚
真正有用的是验证：
- 灰度暂停能否立刻生效
- 新流量能否立即回到旧版本
- 新旧索引或模型切换是否存在缓存残留
- 回滚后能否快速验证恢复
所以灰度和回滚最好一起演，不要分开写、分开想。
13.1 回滚验证最好分成“止血成功”和“行为恢复”两段
很多团队一回滚就默认：
- 问题已经解决
但 AI 系统里更稳的验证通常要分两段：
stabilization check是否已经止血，例如高风险工具被关、错误流量被挡住、人工接管已生效。behavior recovery check是否真的回到可接受行为，例如关键问答恢复、引用正确、审批时延恢复、近失误消失。
如果只做第一段，你很容易得到一个假象：
- 系统看起来稳定了
但实际上：
- 行为仍然偏
- 只是影响被暂时藏起来了
14. 哪些指标值得跟着演练一起看
建议至少跟踪：
- 发现时长
- 定级时长
- 止损完成时长
- 回滚完成时长
- 人工接管生效时长
- 恢复验证时长
- 复盘行动项关闭时长
这些指标能帮助你判断：
- 团队是真的具备处置能力，还是只是知道理论步骤
14.1 演练指标最好再补两类：沟通时效和证据完整率
很多团队只盯技术动作指标，例如：
- 发现多久
- 回滚多久
但真实事故里还有两类很影响结果的指标：
communication latencyevidence completeness
前者帮助你回答：
- Incident Commander 多久拉齐相关人
- 业务 owner 多久收到升级信息
- 对外沟通是否拖慢了止损
后者帮助你回答：
- 这次演练结束后，是否真的能支撑 RCA
- 关键 trace、版本、审批、工具证据是否都采全了
如果这两类指标缺失，团队很容易在下次事故里重复踩坑。
15. 常见反模式
- 预案写得很全，但从没演过
- 演练只看服务可用性，不看行为正确性
- 演练中不保留 trace、引用、工具和审批证据
- 没有明确 Incident Commander
- 知道要回滚，但没人有权动或没人会动
- 演练后不出真正的行动项
16. 近失误和影子故障也值得单独演练
很多团队只在“已经造成影响”的故障上做演练，但 AI 系统里更值得提前抓住的，常常是近失误：
- 模型建议已经明显偏离，但还没真正执行
- 审批节点差点被跳过，但被人工补救回来了
- 影子流量里已经出现退化，但还没放量到生产
这类事件最大的价值在于：
- 代价还没真正落到用户和业务上
- 但系统性的薄弱点已经暴露出来了
更稳妥的做法通常是把以下对象也纳入演练与复盘素材池：
- shadow / canary 中发现的异常样例
- 人工纠偏成功拦截的样例
- 高成本、高延迟但尚未触发事故的样例
- 安全 guardrail 差点漏放的 near miss
16.1 为什么 near miss 很重要
NIST AI RMF 和 Google SRE 的共同思路都在强调：
- 风险管理不应只等真实伤害发生后才开始学习
所以 AI 演练不仅要练“事故怎么处置”，也要练：
- 差一点出事时，组织能不能及时升级和改规则
16.2 shadow / canary 发现的异常最好单独沉淀成演练剧本
很多团队做 shadow 或 canary 时，发现过不少奇怪但没真正放大的问题，例如：
- 新模型在长尾桶里明显更差
- 新 Prompt 让工具参数更脆
- 新 guardrail 误拦截比预期高很多
这些问题如果只是临时修一下，价值会浪费掉。
更稳的做法通常是把它们写成标准演练剧本，至少保留：
- 异常样例
- 当时的版本上下文
- 本可造成的业务影响
- 当时为什么没有放大
- 下次应该怎样更早发现
这样 shadow / canary 就不只是“发布前的一次观察”，而是会真正反哺故障准备体系。
17. 演练最好有评分表，而不是“感觉这次还行”
很多团队演练结束后，只会得到一种模糊结论：
- 大体上能处理
这对长期改进帮助很有限。
更可执行的做法通常是给演练定义一张简单评分表，至少覆盖：
- 发现是否及时
- 定级是否一致
- 止损动作是否按 runbook 执行
- 回滚 / 切人工是否在目标时限内完成
- 证据采集是否完整
- 复盘行动项是否明确
17.1 评分表最适合怎么用
- 不拿来“考核个人”
- 而拿来找流程最脆的环节
如果一次演练分数不高，最有价值的不是追责，而是回答：
- 下次怎样让同类故障更快、更稳、更少争议
18. 推荐搭配阅读
19. 重点官方资源
以下资源已按 2026-07-09 复核到当前正式入口；其中少数站点对脚本探测可能受限，但浏览器入口仍可正常打开：
- Incident Response
- Canary Release: Deployment Safety and Efficiency
- What it Means Being On-Call?
- Alerting on SLOs
- Production best practices
- Safety in building agents
- Guardrails and human review
- Computer use tool - Claude Platform Docs
20. 落地检查清单
- 是否覆盖了行为故障而不只是服务宕机
- 是否为高风险场景准备了可执行 runbook 和分级规则
- 是否能快速执行止损、回滚和切人工
- 是否在演练中保留了 trace、引用、工具、审批等 AI 专属证据
- 是否把演练结果真正回写到值班、灰度和发布机制里