09-故障演练与降级、熔断、回滚¶

目标：把“我知道系统会出问题”升级成“我知道系统出问题时如何有序止血”。

图源：Google Cloud 白皮书 Data incident response process 第 7 页 Figure 3 “Incident response workflow”。当前图片为原始 PDF 页面渲染图，用于解释识别、协调、处置、关闭与持续改进闭环。

一、为什么故障演练对 AI 岗位很有区分度¶

AI 系统的故障来源，比传统 Web 服务更复杂：

模型版本切换后质量突然下降
检索链路劣化，但接口依然返回 200 OK
Agent 工具连续失败后进入错误循环
Token 消耗异常上升，成本失控
GPU 池抖动，导致排队和尾延迟同时恶化

所以高质量回答不能只说“我们会监控”。你要能说明：

出了问题先怎么止血
什么情况下该降级，什么情况下该熔断
什么时候必须回滚
平时如何通过演练提前暴露脆弱点

二、先分清四个动作：降级、熔断、回滚、演练¶

动作	核心目标	典型例子
降级	保住核心服务，牺牲部分体验或能力	关闭 reranker、缩短上下文、从大模型切到小模型
熔断	避免异常继续放大	下游向量库异常时停止重试；工具连续失败时直接短路
回滚	尽快回到已知稳定版本	回滚模型版本、Prompt 配置、路由规则或索引版本
演练	在真事故前验证系统韧性	主动注入超时、缓存失效、单节点故障

一句话记住：

降级是“少做一点，但别彻底停”
熔断是“先停危险链路，别继续扩大损失”
回滚是“回到上一个稳定版本”
演练是“在真实事故来之前先发现问题”

三、AI 系统里最值得演练的场景¶

场景	演练目标	重点观察指标
向量库超时或抖动	验证检索超时保护、降级回答和缓存兜底	P99、失败率、降级成功率
GPU 节点异常	验证模型池切换和排队控制	可用性、队列深度、回滚耗时
Prompt / 路由配置变更失误	验证灰度门禁与一键回滚	质量指标、成本指标、异常样本率
Agent 工具故障	验证最大步数、失败短路和人工接管	任务成功率、错误循环率
缓存整体失效	验证成本和延迟保护策略	缓存命中率、单请求成本、P99
安全策略误拦或漏拦	验证告警分级和人工复核链路	误杀率、漏放率、人工审核吞吐

这里最容易丢分的点是：只讲基础设施，不讲 AI 特有的质量和行为故障。

四、一份最小可用的演练模板¶

Markdown

## 演练名称

- 目标：
- 假设故障：
- 影响范围：
- 预期保护动作：
- 观察指标：
- 止损条件：
- 回滚方式：
- 演练结果：
- 后续改进项：

这个模板不需要写成长文，但至少要让团队能回答：

我们预期系统会怎么坏
系统坏了以后哪些保护动作应该自动发生
哪个指标先报警
哪一步需要人工介入

五、面试里怎么讲这类题¶

一个结构化回答通常分 4 步：

先说明你关注的故障类型
再讲对应的止血动作：降级、熔断、回滚
补上触发条件和关键指标
最后说明演练后补了什么监控、Runbook 或门禁

可以直接这样说：

Text Only

我会先把故障分成基础设施故障、质量故障、行为故障和成本故障。
遇到问题时，优先用限流、降级和熔断控制影响面；
如果问题来自高风险变更，就立刻回滚到已知稳定版本。

平时我不会等事故来了再学习系统怎么坏，而是会对向量库超时、模型池抖动、缓存失效和工具故障做定期演练，
并把演练结果沉淀成 Runbook、告警规则和灰度门禁。

六、自检清单¶

我能说出至少 3 类 AI 系统特有故障场景
我能区分降级、熔断、回滚、演练四个动作
我知道每种动作由哪些指标触发
我有一份最小可用的演练模板
我知道演练结束后要补哪些监控、流程和门禁

结论¶

故障演练的价值，不在于“制造故障”，而在于让你提前知道系统会怎么坏，以及你能不能在几分钟内把影响面控制住。

对 AI 系统设计题来说，会不会讲“止血路径”和“演练闭环”，往往比会不会背几个模型名更能拉开差距。

⚠️ 核验说明（2026-03-29）：本页图片与故障响应阶段表述已按公开资料重新核对。你所在团队若使用不同的事故等级和回滚纪律，请以团队制度为准。

最后更新日期： 2026-03-29