你的值班轮换需要 AI 素养作为前提，否则不要在凌晨 2 点给任何人发报警

一位拥有 8 年事故响应经验的平台工程师打开了一条凌晨 2 点的报警信息：“AI 助手性能下降 —— 错误率 12%”。她检查了模型延迟仪表盘：绿色。检查了模型 API 状态页：绿色。检查了部署日志：过去 72 小时内没有任何变更。她做了任何称职的值班人员接下来会做的事 —— 呼叫 AI 团队。AI 工程师醒来，打开了平台工程师甚至不知道存在的追踪 (trace) 仪表盘，发现一个检索工具在过去 4 小时内一直超时，原因是一个下游搜索索引丢失了一个副本，并在 11 分钟内解决了事故。AI 工程师在凌晨 3:14 重新入睡。第二天早上的复盘记录写道：“AI 功能故障，由 AI 团队解决”。没有人写下真正的教训：如果这位值班工程师曾被教导过 AI 功能的故障面 (failure surface) 长什么样，她本可以在 5 分钟内完成分流 (triage)。

这是 AI 功能在过去两年中，向我合作过的每一个工程团队悄悄征收的“轮换税”。曾经完美适用于无状态服务堆栈和几个数据库的共享值班轮换，在其中一个“服务”变成由 LLM 驱动的功能时就会崩溃。你的 SRE 团队通过十年的事故复盘建立的值班手册，是为一个“某处出错了”可以分解为 CPU、内存、网络、部署和依赖超时的世界而校准的。AI 功能增加了三个维度 —— 模型、提示词 (prompt)、检索管道 —— 以及四种值班人员从未接受过识别培训的故障形态，这些故障不会出现在他们习惯查看的仪表盘上。

你现有的值班培训从未建模过的故障维度

当传统服务降级时，值班人员会走一条窄小且熟悉的决策树：部署 → 基础设施 → 上游依赖 → 吵闹邻居 (noisy neighbor) → 错误 (bug)。每个分支都有一个仪表盘。每个仪表盘都有一份操作手册 (runbook)。AI 功能迫使增加了三个大多数轮换手册尚未命名的分支：

模型行为降级，但模型延迟显示为绿色。 供应商推送了底层模型的一个静默补丁版本 —— 拒绝行为改变了，结构化输出格式漂移了，昨天还起作用的工具调用参数今天变成了空值。延迟仪表盘一切正常。如果你只计算 HTTP 5xx，错误率仪表盘也一切正常。真正的信号隐藏在评估 (eval) 通过率中，或者用户点踩数量翻倍的尖峰中，而这些都没有接入警报。正如一篇可观测性分析报告所说：“LLM 功能可能会在所有 SLO 指标保持绿色的情况下逐渐退化 —— 这种故障可能是行为上的，而不是功能上的。”

伪装成模型故障的工具依赖故障。 智能体的检索工具超时了，所以模型在空的上下文窗口中进行推理，并生成了言之凿凿的错误答案。追踪显示一个干净的模型调用返回了一个干净的响应。值班人员看到“AI 功能损坏”并将警报向上路由。实际的修复工作是一个 5 分钟的数据库副本故障切换，平台值班人员本来在梦中都能完成 —— 只要他们被告知过，追踪分析包含一个应该首先检查的工具层。

来自 AI 团队未发布的特性标志 (feature flag) 的提示词层回归。 增长实验将一个个性化变量切换到了系统提示词的上下文中。模型行为改变了。AI 团队没有发布任何东西。增长团队没意识到他们的标志位于 AI 功能的上游。值班人员看到“AI 功能在 14:00 UTC 后降级”并呼叫 AI 团队，后者花了 90 分钟对比提示词差异，最后才有人想到去检查特性标志。

这三种形态占据了非工作时间 AI 警报的很大一部分。它们都可以由全栈值班人员分流，但前提是轮换制度已经培训了该值班人员去识别它们。大多数轮换制度还没有做到。

“AI 素养”对值班工程师来说究竟意味着什么

“AI 素养”这个词在人力资源的 PPT 里被当作毫无意义的流行语使用。但对于值班轮换来说，它是一份具体的技能清单。接听 AI 功能警报的值班人员应该能够在不呼叫任何人的情况下完成以下五件事：

1. 端到端地阅读模型追踪 (trace)。 识别提示词、模型及其版本、按顺序排列的工具调用、工具响应以及最终的助手响应。这与阅读 HTTP 追踪不是同一种技能。Token 边界、消息角色 (roles) 和工具调用 ID 都很重要。
2. 区分模型层、工具层和检索层。 在任何没有特意按层拆分的仪表盘中，一层的故障在表面上看起来与另一层完全相同。
3. 阅读评估 (eval) 结果。 通过率、与前一个提示词版本相比的回归增量，以及哪个切片失败了。如果你的评估对值班人员来说是个黑盒，那么评估信号在最需要的时候就会被浪费掉。
4. 对比提示词清单 (prompt manifest) 的差异。 找到最后一次修改提示词、系统指令、工具描述或检索器配置的提交。大多数 AI 功能回归都发生在模型上游的配置文件中。
5. 识别针对你特定产品的五大 AI 事故形态，并附上每个事故的仪表盘 URL 和第一步分流步骤。通用的 AI 培训在这里没有帮助；操作手册必须具体到你的 AI 功能实际执行的操作。

这就是全部。五项技能。两到四个小时的专注培训，外加一份值班人员在昏昏沉沉时也能阅读的书面操作手册。没有做到这一点的组织，正在为 AI 团队不断跳动的传呼机付出代价。

告警正悄无声息地要求你进行的仪表板维护投入

一个显示 “AI 助手性能下降 (AI assistant degraded)” 的页面无法告诉值班人员该调查哪一层。这相当于在 “服务崩溃” 时触发告警 —— 这是一个标签，而不是信号。在将 AI 功能纳入职责范围之前，任何轮班制度的首要投入都应该是拒绝发布这种粒度的告警。

最小可行重构：每个 AI 功能的告警标题都必须标明故障层。“AI 助手：工具层 (搜索) — 12% 错误率。” “AI 助手：模型层 — 拒绝率激增。” “AI 助手：检索层 — 索引新鲜度 > 4 小时。” 看到告警标题的值班人员知道该打开哪个仪表板，以及该遵循操作手册 (runbook) 的哪一部分。这是仪表板维护，而不是仪表板创新，然而在过去的一年里，我审计了三个不同组织的值班流程，他们都在使用单一的、没有分层归因的综合 “AI 功能健康度” 指标来触发告警。这些轮班中的每一次传呼最后都会升级到 AI 团队，因为值班人员别无选择。

第二项投入，稍复杂一些：一个值班人员可以从告警直接跳转到的工具级健康仪表板。包括工具调用超时、工具调用错误率、工具结果新鲜度和工具依赖状态。如果你的智能体 (agent) 有六个工具，你需要一个能在 30 秒内回答 “这六个工具中是否有任何一个目前性能下降” 的仪表板。一旦 AI 功能进入共享轮班，这个仪表板就不再是可选的，而是先决条件。

共同值班阴影期：比员工倦怠更廉价的选择

将 AI 团队的隐性知识转移到更广泛的轮班人员中的最快方法，也是值班手册中最古老的技巧：见习 (shadowing)。在工程师加入包含 AI 功能的轮班的首月，每当 AI 功能的告警触发时，系统也会同时通知一名有 AI 经验的工程师作为见习陪同。见习人员不负责处理告警；他们观察值班人员的操作，只有在值班人员请求时才介入。

成本是真实存在的，但也是有限的。AI 工程师的睡眠会被打断，但他们不必采取行动 —— 他们大多只需观察，然后回去睡觉。收益则是复利的：每一次有见习陪同的告警都会培养出一名更懂 AI 的值班人员，并且通常会产出一份操作手册更新，记录下 AI 工程师原本会采取的隐性操作。对于典型的故障模式，三四次见习陪同通常足以让一名对 AI 生疏的值班人员变得能胜任 AI 相关工作。

如果没有这一点，轮班就会进入一种已知的反模式：AI 团队在凌晨 2 点被传呼去处理值班人员本可以分诊 (triage) 的问题，AI 团队的倦怠感上升，两名工程师在六个月内以值班负担为由离职，剩下的人轮班频率被迫收紧，恶性循环加速。这种轨迹在 SRE 文献中已有详尽记载，它并不需要 AI 功能才能启动；AI 功能只是给它装上了一个更快的引擎。

针对五大常见 AI 事故类型的操作手册结构

泛泛的值班培训粒度是错误的。值班人员真正需要的是针对你产品的特定前五名事故清单。这里有一个我发现对各个团队都有效的模板：

针对前五大 AI 事故类型中的每一种：

• 触发的告警标题 (使用值班人员将看到的字面字符串)
• 确认或排除诊断的单一仪表板 URL
• 值班人员应运行的前三个查询 (SQL 或追踪查询) 及其预期输出
• 不需要 AI 团队参与的缓解措施 —— 重启工具、故障转移索引、禁用功能标志、切换到备用模型
• 升级标准 —— 传呼 AI 团队是正确做法的具体触发条件

这种纪律是残酷的：如果你写不出某个 AI 事故类型的操作手册，值班人员就无法分诊它，而你发布的这项功能负担最终会落在 AI 团队的睡眠上。编写操作手册的过程正是强制要求仪表板维护、层级归因和缓解工具存在的原因。

做得好的团队最终得到的操作手册看起来出奇地平淡。“工具：搜索索引 — 如果错误率 > 5% 持续 10 分钟，使用此仪表板按钮切换到只读副本，然后验证通过率是否恢复，最后提交一个 INC 工单供 AI 团队在工作时间内调查根因。” 最后一句话才是精髓。它区分了 “值班人员缓解了故障并回去睡觉” 与 “值班人员升级了问题而 AI 团队被迫起床”。前者是每一项 AI 功能值班投入的目标。

组织失效模式的实际代价

未针对 AI 功能进行更新的轮班制度不会大张旗鼓地宣告失败。它会以三种微妙的方式失败，并反映在错误的仪表板上。

AI 团队的值班频率看起来比其他工程部门更高。领导层将其解读为 “AI 很难” 或 “AI 功能不成熟” 并据此制定预算 —— 这意味着会为 AI 团队增加更多的人力编制，而不是采取成本更低的干预措施，即提升现有轮班人员的技能。平台值班频率看起来平淡无奇，因为他们本应处理的告警都被绕过并路由到了别处。

AI 团队的留存率看起来比其他工程部门更差。离职面谈将值班负担列为主要因素。组织认为这是在 AI 领域开展业务的成本。实际成本是轮班制度未能适应一类值班培训中未命名的故障模式。

客户感知的 AI 功能可靠性比 AI 团队自己的仪表板显示的要差。从通用值班人员到 AI 值班人员再到实际修复的 90 分钟升级链在 SLO 仪表板上是隐形的，但对客户来说却非常明显。组织得出的结论是 AI 功能天生就不稳定。实际的结论是，轮班的平均修复时间 (MTTR) 正被不必要的交接所拖累。

AI 素养的先决条件是一项政策，而非一个愿景

如果你认为 AI 素养会自然而然地产生——工程师会通过潜移默化学会、全工程部门的午餐分享会（brown bags）能填补空白、AI 团队的文档最终会被阅读——那么它永远不会发生。我观察过每一个尝试这种“自然发生”方式的组织，都看到 AI 团队的报警率（pager rate）在悄然增长，直到某位高管查看 On-call 仪表盘并质问，为什么一个团队要处理 40% 的报警。

干预措施是在轮值政策中加入一项书面的先决条件。在你加入包含 AI 功能的轮值之前，必须完成 AI On-call 入职模块。该模块耗时 2 到 4 小时，以针对一个真实的（匿名的）历史故障进行配对练习结束，并由一名具有 AI 经验的工程师签字确认。轮值的第一个月是影子轮值（shadowed）。前五类常见 AI 事故形态的运维手册（runbook）存放在与平台运维手册相同的代码库中，并每季度进行评审。

这是并不光鲜的基础设施工作。它不会出现在路线图上，也不会出现在发布演示稿中。这种工作的回报体现在人才留存、平均修复时间（MTTR）以及 AI 团队交付下一个功能的能力上，而不是让他们在凌晨 2 点调试上一个功能。那些将其定义为“工作”并为其投入资源的组织，才能让其 AI 功能像其他生产系统一样被对待——而这是实现规模化的唯一途径。

架构层面的认知虽小但影响深远：AI 功能并不神秘。它们是具有不同故障面（failure surface）的生产系统，如果轮值制度不根据这一故障面更新培训，就是在做一个未计算成本的人员配置决策。这个代价最终会体现在 AI 团队的职业倦怠率上。等到离职面谈揭示出这一点时，这种轮值安排已经“透支”了一年之久。