AI 学习笔记（十八）：LLM 故障演练（Game Day）最小实践

发表于 更新于 分类于 阅读次数： Changyan： 本文字数： 4k 阅读时长 ≈ 4 分钟
把故障演练从“开会讨论”变成可执行工程流程：场景注入、观测看板、止血回滚验证和复盘评分，确保 incident 方案在真实事故前就被验证。

上一篇我们把 Incident Response 的最小闭环搭起来了。
但线上体系能不能真的扛住故障，不是看文档写得多完整，而是看你有没有做过故障演练（Game Day）。

这篇继续生产运维实践第四部分：
把“事故响应方案”提前在可控环境里反复演习，验证它在真实压力下是否可执行。

先说结论：

  • 没演练过的 runbook，等于没验证过
  • 没做过场景注入，就不知道你的监控是否真的能报警
  • 没做回滚验收，就不知道“恢复”是不是只是表面恢复

这篇仍然只讲最小可落地版本，目标只有三个：

  1. 用一套固定脚本复现高风险故障场景
  2. 在演练中验证止血与回滚动作是否生效
  3. 把演练结果沉淀成可追踪的改进清单

1. Game Day 的目标不是“演戏”，而是验证系统能力

很多团队把故障演练做成了“流程走读会”：大家口头说一遍，最后结论是“理论上没问题”。
这对 LLM 系统几乎不够，因为真正风险点往往在动态行为里：

  1. provider 波动下路由是否及时切换
  2. prompt 发布后质量退化是否能被监控捕获
  3. 检索层异常时是否会触发只读/人工兜底
  4. 工具调用异常时是否能阻断副作用

所以 Game Day 要明确一个核心目标：

  • 验证生产能力，不验证个人反应速度

换句话说，演练要测的是机制，不是“谁更会救火”。

2. 先选 3~4 个高价值场景，不要一上来铺太大

最小实践建议先固定 4 类场景，每次挑其中 2 类演练：

  1. Provider Degradation
    主 provider 延迟升高或错误率飙升，验证 fallback 与熔断
  2. Prompt Regression
    新 prompt 版本导致结构化输出失败率升高，验证发布回滚
  3. Retrieval Corruption
    检索命中率下降或返回脏证据，验证降级到缓存/只读
  4. Tool Side Effect Risk
    自动化写操作异常，验证开关切只读与人工审批接管

场景选择原则只有两条：

  1. 对真实用户影响大
  2. 你当前确实有对应工程开关可操作

没有开关就先补开关，再演练。不要靠“临场改代码”救场。

3. 先把演练契约写成一个场景清单文件

建议把每个场景都收敛成统一结构，方便复用和审计：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# game-day-scenarios.yaml
- id: GD-001
  name: provider-timeout-spike
  trigger:
    type: inject
    target: provider.primary
    config:
      timeoutRate: 0.35
      durationMinutes: 12
  expected:
    detectWithinMinutes: 2
    fallbackActivated: true
    p95RecoveredWithinMinutes: 8
  rollback:
    featureFlag: route.safe_mode
    verify:
      errorRateBelow: 0.05
      p95BelowMs: 2800

- id: GD-002
  name: prompt-regression-structured-output
  trigger:
    type: deploy
    target: prompt.chat.v5
    config:
      schemaViolationRate: 0.22
  expected:
    detectWithinMinutes: 5
    releaseFrozen: true
    rollbackToVersion: prompt.chat.v4
  rollback:
    featureFlag: prompt.version
    verify:
      schemaSuccessRateAbove: 0.95

这样做的好处是：

  1. 场景可重复执行
  2. 验收标准可量化
  3. 每次演练结果可以横向对比

4. 演练前 30 分钟只做准备，不做“临时优化”

建议固定一个 T-30 检查清单：

  1. 冻结变更：暂停非必要发布，避免噪音干扰
  2. 确认版本：记录当前 provider 路由、prompt 版本、检索配置
  3. 检查开关：fallback、只读模式、写操作禁用开关可用
  4. 确认观测：关键仪表盘与告警规则在线
  5. 明确角色：指挥官、注入人、记录人、执行人

一个常见误区是“演练前先偷偷修几个点”。
如果演练前改了核心策略，但没有基线记录，演练结果很难解释。

5. 注入故障时，优先用配置和开关，不要直接破坏数据

最小策略：

  1. 在 staging 或隔离租户做注入
  2. 通过 feature flag / mock layer / traffic shadow 注入
  3. 禁止直接改生产持久化数据做演练

例如可以有一个简单的注入器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
interface FaultInjectionConfig {
  providerTimeoutRate?: number;
  providerErrorRate?: number;
  retrievalEmptyRate?: number;
  toolWriteDenyAll?: boolean;
}

export function withFaultInjection<T>(
  operation: () => Promise<T>,
  config: FaultInjectionConfig
): Promise<T> {
  if (config.toolWriteDenyAll) {
    throw new Error("fault_injection: tool_write_denied");
  }

  // 用概率注入模拟 provider 抖动，验证路由与重试策略
  if (config.providerTimeoutRate && Math.random() < config.providerTimeoutRate) {
    return Promise.reject(new Error("fault_injection: provider_timeout"));
  }

  return operation();
}

代码不是重点，重点是：

  • 注入机制可开可关
  • 注入范围可控
  • 注入动作有日志可追踪

6. 演练中的核心时间线：发现、止血、回滚、验收

我更推荐现场只盯 4 个时间点：

  1. T_detect：从注入开始到告警触发
  2. T_mitigate：从告警触发到止血动作生效
  3. T_rollback：从止血到版本/配置回滚完成
  4. T_verify：从回滚完成到关键指标恢复稳定

如果你记录了这四个时间点，就能得到两个关键指标：

  • MTTD（Mean Time To Detect）
  • MTTR（Mean Time To Recover）

这两个指标比“演练参与人数”更能说明体系成熟度。

7. 回滚验收要有硬门槛，不能只看“服务恢复了”

很多演练失败都发生在这一步：接口能返回了，但质量和副作用还没回到安全区。
建议回滚验收至少包含 5 条：

  1. 错误率回到阈值以下（例如 < 5%）
  2. P95 延迟回到阈值以下
  3. 结构化输出成功率回到基线区间
  4. 工具写操作保持受控（必要时仍为只读）
  5. 关键用户路径做过最小冒烟验证

只要其中一条没过，就不应该宣布“恢复完成”。

8. 每次演练后必须产出 Scorecard，不要只写感受

最小 Scorecard 可以很简单：

1
2
3
4
5
6
7
8
9
10
11
Game Day: GD-001 provider-timeout-spike
Date: 2026-03-25
Result: Partially Pass
MTTD: 3m (Target <= 2m)  [Fail]
MTTR: 14m (Target <= 10m) [Fail]
Fallback Switch: Success [Pass]
Rollback Verification: schemaSuccessRate 93% (<95%) [Fail]
Top Gaps:
1) provider timeout alert threshold too loose
2) rollback runbook missing prompt schema check step
3) read-only switch ACL not explicit for batch job

输出必须包含三类信息：

  1. 是否通过（Pass/Partial/Fail）
  2. 关键指标是否达标
  3. 明确到 owner 的改进动作

如果没有 owner 和截止时间，演练结论通常会在一周内失效。

9. 一周内可落地的 Game Day 最小推进节奏

如果你要把这篇直接变成行动清单，可以按下面节奏推进：

  1. Day 1：选 4 个高风险场景，定义场景契约与验收阈值
  2. Day 2：补齐 fallback、只读、回滚等必要开关
  3. Day 3：接入注入器与关键观测指标
  4. Day 4：执行一次小范围演练并记录时间线
  5. Day 5：完成复盘与改进项分配，更新 runbook

做到这里，你的 incident 体系就从“有文档”升级为“可验证”。

总结

LLM Game Day 的核心价值，不是模拟一个漂亮流程，而是提前暴露系统的真实薄弱点。
最小可落地版本只需要抓住四件事：

  1. 用场景契约固定故障注入
  2. 用时间线指标衡量发现与恢复效率
  3. 用回滚验收阈值保证不是假恢复
  4. 用 Scorecard 和 owner 追踪改进闭环

如果你现在只能先做一件事，我最推荐的是：

先把“回滚验收阈值”写清楚并纳入每次演练，不要只凭“看起来恢复了”做判断。

参考资料

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-game-day-fault-drill-minimal-practice/