没人会写的 AI 系统 On-Call 运维手册

你的 p99 延迟刚刚飙升到了 12 秒。警报在凌晨 3:14 响起。你打开运维手册 (runbook)，看到如下指令：检查数据库连接池、验证负载均衡器、重启服务。你三样都做了。延迟依然居高不下。服务并没有宕机——它正在运行且有响应。但有些地方不对劲。事实证明，由于最近的一次提示词 (prompt) 变更无意中开启了“啰嗦”模式，模型生成的响应比平时长了三倍。运维手册里没有关于这一条的说明。

这是工程团队尚未准备好应对的新一类值班事故：系统正在运行，但模型表现异常。传统的 SRE 运维手册假设的是二进制的故障状态。AI 系统是以概率方式失效的，其症状看起来不像停机，而更像“漂移”(drift)。

为什么传统的运维手册在 AI 系统面前会失效

传统的运维手册是一种程序化的产物。它规定：当警报 X 触发时，检查 Y，然后执行 Z。这在故障是确定性的情况下是有效的。崩溃的数据库要么能启动，要么不能。内存泄漏要么导致 OOM，要么不会。你复现问题，应用修复，验证恢复。

LLM 系统从三个维度打破了这一模式。

故障是行为性的，而非运行性的。 模型可能完全可用，接受请求并以正常的吞吐量返回响应——但产出的内容却存在微妙的错误、过度谨慎，或逐渐偏离预期特征。服务健康检查通过了。模型却表现异常。传统监控对此无能为力。

复现是不可靠的。 当你复现一个软件 Bug 时，你会得到同样的 Bug。当你试图复现 LLM 输出故障时，由于温度 (temperature)、上下文窗口效应以及检索数据的差异，你往往无法重建完全相同的行为。你是在调试一个概率分布，而不是一个确定性函数。

因果关系不明显。 延迟飙升的原因可能是：模型生成了更长的输出（上游内容变更）、并发长上下文请求带来的 KV 缓存压力、提供商端的问题、检索层返回了更多文档，或者工具调用返回了出乎意料的大载荷。每种原因都需要不同的对策。传统的运维手册假设你可以直接观察到原因；而 LLM 运维手册需要从间接信号中进行推断。

真正重要的信号

有效的 AI 值班始于扩展你的测量指标。大多数团队监控延迟、错误率和吞吐量。对于 LLM 系统，这些指标只能告诉你故事的一部分。

输出长度分布。 跟踪响应长度随时间变化的均值和方差。平均输出长度的突然上升通常发生在延迟飙升之前——模型正在生成更多 token，这会消耗更多计算资源并增加实际耗时。输出骤减可能预示着过度拒绝，或者是由于损坏的提示词导致响应被截断。这两者都不会表现为错误。

拒绝率。 每一次拒绝都是一次未能给用户返回有用信息的请求。将此作为与错误率并列的一级指标进行跟踪。拒绝率飙升通常由三个原因之一引起：提供商端的內容策略变更、由于用户流量变化导致提示词更频繁地触及安全边界，或者防护栏 (guardrail) 配置过于激进。每种情况都需要不同的应对方式，但在延迟和错误率仪表盘上，这三者看起来是一模一样的。

工具调用错误率和耗时。 对于智能体 (agentic) 系统，工具故障往往是导致模型性能退化的真正根源。如果检索工具开始返回空结果，模型就没有推理的依据。如果一个 API 工具在 20% 的调用中超时，智能体就会不断重试并耗尽 token 预算。独立监控每个工具——哪些工具被调用、它们的失败频率以及 P95 耗时。

质量分漂移。 这是最难量化但最重要的信号。实时质量评估——无论是通过 LLM-as-a-judge、基于嵌入 (embedding) 的已知优质响应相似度分析，还是特定任务的指标——都能为你提供关于模型实际产出内容的持续信号，而不仅仅是它是否产生了内容。质量分下降 10% 通常是回归的第一个征兆，而这种回归不会出现在任何基础设施指标中。

单次请求的 Token 成本。 意外的成本飙升是模型行为变化的领先指标。如果平均单次响应的 token 数翻倍，说明某些东西变了——可能是提示词、模型版本、检索到的上下文或用户流量模式。这比质量评估的实现成本低得多，且通常最先发出警报。

AI 系统的事故分类法

在编写运维手册之前，你需要一套针对可能出现的问题的分类系统。AI 系统的故障模式无法完全映射到基础设施事故上。

模型回归。 模型输出质量相对于基准线有所下降。这可能是因为：上游提供商在同一个 API 端点下默默更新了模型版本；在未进行回归评估的情况下更改了提示词；或者流量转向了模型不擅长处理的输入分布。检测这需要将当前输出与存储的基准进行对比，而不是检查服务健康状况。

防护栏绕过或配置错误。 安全防护栏开始拒绝过多（过度拒绝，对用户表现为服务降级）或过少（拒绝不足，这属于安全事故）。这是两个相反的问题，需要相反的对策，但两者都会表现为异常的拒绝率。

成本飙升。 Token 消耗超出了预期范围。这通常是由于传递给模型的上下文变长（检索变更、对话历史 Bug）、触发了啰嗦响应的提示词或流量模式转变引起的。成本飙升在被用户察觉之前，可能已经在财务上造成重大影响。

延迟退化。 P99 响应时间升高。这有 AI 特有的原因：并发长上下文带来的 KV 缓存压力、由于输出长度增加导致的 token 生成速度变慢，或者工具调用增加了智能体管线的延迟。传统服务中常见的延迟与错误相关性在这里往往失效——服务仍有响应，只是很慢。

提示词注入或安全事故。 对抗性输入导致模型的行为超出了其预期的操作范围。这表现为异常的输出模式、意外的工具调用或违反对话策略的行为。大多数监控栈都没有针对此类的信号。

凌晨 3 点的排查真相

你收到了一个告警。以下是适用于 AI 系统的排查流程，按执行速度排序：

首先，检查发生了什么变化。 在动任何东西之前：模型版本是否升级了？提示词（Prompt）改了吗？功能开关（Feature flag）切换了吗？检索索引更新了吗？供应商的内容策略是否发生了变化？大多数 AI 事故都是由最近的变化引起的。在诊断任何问题之前，先将事故开始时间与发布历史、开关变更和供应商状态页面进行关联分析。

第二，刻画症状。 是延迟、质量、成本、拒绝（Refusals）还是错误？信号类型能显著缩小原因范围：

• 延迟激增但质量稳定 → 很可能是基础设施问题（KV 缓存、Token 吞吐量、工具超时）
• 质量下降但延迟稳定 → 很可能是模型或提示词回退（Regression）
• 拒绝率激增 → 很可能是护栏（Guardrail）或内容策略问题
• 成本激增 → 很可能是输出长度增加或流量构成变化
• 错误率激增 → 很可能是工具故障或 API 问题

第三，采样实际输出。 抽取一些最近请求的样本，查看模型产生的具体内容。质量下降、行为漂移和过度拒绝对于基础设施监控来说是不可见的，但当你阅读输出时，这些问题会立竿见影。大多数团队在处理事故时会跳过这一步，因为它不是自动化的——但它通常是找到根本原因最快的路径。

第四，按速度顺序采取缓解措施。 切换提示词版本或模型端点的功能开关比重新部署更快。保守的兜底方案（更简单的提示词、更小的上下文、缓存的响应）比分析根本原因更快。你在凌晨 3 点的目标是止血，而不是完美地理解病理。

为概率性系统编写 Runbook

AI 系统的 Runbook 不能只说“检查模型是否工作”。它需要说明“如果拒绝率在 10 分钟内超过 7 天滚动基准的 2 倍，请按此顺序检查这三件事”。

围绕具有明确概率分支的决策树来构建你的 AI Runbook：

信号 → 可能原因 → 排查步骤 → 缓解措施

对于每个信号，按可能性顺序列出最可能的原因、区分它们的特定查询或检查方法，以及每种情况的缓解措施。这不同于你按顺序执行步骤的确定性 Runbook；你正在构建的是一棵诊断树。

包含明确的升级（Escalation）标准。延迟事故何时演变为安全事故？质量下降何时触发回滚？这些阈值应该提前定义，而不是在凌晨 3 点的压力下临时决定。

记录回退（Fallback）状态。对于每个 AI 功能，定义保守配置：更小的上下文窗口、更简单的提示词、禁用工具使用或使用缓存响应。这些应该可以通过单个开关变更来激活。在事故发生前了解回退方案，意味着你可以果断执行而无需反复思量。

在 Runbook 旁边存储“已知良性”的输出样本。当你试图判断当前的输出是否代表回退时，你需要一个参考点。收集来自不同流量细分代表性的优质输出，其价值不亚于任何监控指标。

你真正需要的监控基础设施

传统的 APM 工具会给你延迟和错误率。对于 LLM 系统，你需要大多数团队尚未建立的额外监控手段：

带采样的单次请求输出日志。 记录完整请求-响应对的样本——而不仅仅是元数据。你无法仅通过 Token 计数来评估质量。即使在适度的流量规模下进行 1% 的采样，也足以让你检测到行为漂移并进行重放调试。

带漂移检测的行为基准。 对输出长度、拒绝率、工具调用模式和质量得分计算滚动统计数据。针对偏离基准的情况进行告警，而不是设定绝对阈值。什么算作异常拒绝率取决于你的应用；针对绝对拒绝率告警会让你淹没在误报中。

工具调用监控。 智能体（Agent）系统中的每个工具都应该发出包含耗时、错误状态、输入大小和输出大小的 Span。工具故障往往是导致模型看起来性能下降的隐形原因。

按功能和请求类型的成本归因。 你需要知道哪些功能、哪些用户群体以及哪些输入模式正在驱动 Token 消耗。当你能缩小来源时，成本激增会更容易诊断。

组织变革，而非仅仅是技术变革

最擅长诊断传统基础设施事故的工程师，往往最不擅长诊断 AI 事故——反之亦然。调试一个表现异常的模型需要阅读输出、理解提示词机制并对概率分布进行推理。这些不是标准的 SRE 技能。

成功实现 AI 系统工程化运营的团队通常做了两件事之一：对 SRE 进行 AI 特定故障模式的培训并赋予他们检查模型行为的工具，或者建立一种轮值机制，在 AI 事故期间让 SRE 与 ML 工程师搭档。这两种方法都不是免费的，但如果不在相应培训上投入而只是“让 SRE 处理”，会导致凌晨 3 点的事故拖上四个小时，因为值班工程师对他们所面对的情况没有心理模型。

你的 Runbook 的价值取决于阅读它的人。要为那些理解分布式系统但可能尚未内化模型回退与基础设施延迟问题之间区别的值班工程师编写。让“信号到原因”的映射变得明确，让缓解步骤变得具体。并且接受 Runbook 有时会出错——因为失效模式是概率性的，这意味着诊断也是概率性的。

目标不是一份完美的 Runbook。目标是让值班工程师能在 30 分钟而不是两小时内控制住 AI 事故，因为组织在凌晨 3 点告警触发之前就已经思考过这些问题。