随机系统的值班响应：为何你的 AI 运行手册需要重写
凌晨两点，你被告警叫醒。延迟上升，错误率飙升。你 SSH 进去，查看日志——什么都没有。没有指向错误部署的堆栈跟踪，没有第 247 行的空指针异常。只有一串模型输出，这些输出在细微之处、以不可预测的方式出了问题——只有当你连续读了 50 条之后，才能意识到这一点。
这就是 LLM 驱动系统中故障的样子。而传统的"告警-分类-修复"循环根本不是为此而生的。
标准值班手册有三个前提假设：故障是确定性的（相同输入，相同的错误输出）、根因是可定位的（某段代码改了，某项资源耗尽了）、回滚是直接的（还原部署，搞定）。这三点在随机 AI 系统中都不成立。同一个提示词会产生不同的输出。根因通常是一个概率分布，而不是某行代码。而且，你根本无法"回滚"一个第三方提供商昨晚悄悄更新的模型。
解决这个问题需要在每个层面重新思考运行手册：如何告警、如何分类、如何撰写事后分析。
为什么传统告警方案会失效
在传统系统中，你对可以精确测量的指标告警：HTTP 5xx 率、p99 延迟、队列深度。这些指标边界清晰——出了问题，数字就会变动。
LLM 的降级通常是渐进的、多维度的。一个已经漂移为冗长、含糊输出的模型不会触发延迟告警（它实际上可能更快），也不会触发 5xx 告警（API 成功返回 200）。真正降级的是质量——而质量没有内置的指标。
结果是，传统告警会造成两种失败模式：
噪音带来的告警风暴。 LLM 输出天然存在差异。如果你对任何与质量相关的信号（词数、输出长度、特定短语的出现）设置静态阈值，你会在正常波动中持续触发告警。研究表明，云系统中 75-95% 的可观测性告警是误报；对于使用朴素质量告警的 LLM 系统，这个比例更糟。
真实问题上的静默降级。 模型提供商在不通知的情况下更新模型。提示词随着功能开关悄然改变。随着向量索引偏离文档语料库，RAG 检索质量下降。这些在基础设施仪表盘上都不会显示。
解决方案是一个四层指标方案，清晰地分离关注点：
基础设施指标 — 传统的 SRE 层：延迟、吞吐量、token 消耗、错误率、每次请求的成本。这些应该已经在你的仪表盘中了。
API 层指标 — 特定于 LLM API 行为：速率限制（HTTP 429）率、认证失败率、每个端点的模型可用性、重试频率。这些告诉你提供商何时出现问题。
行为指标 — 这是新的一层：拒绝率（模型拒绝回答合法请求的比例是多少？）、格式合规率（输 出是否符合预期的 JSON schema 或结构化格式？）、输出长度方差（模型是否突然生成了 4 倍长的回复？）。这些指标可以确定性地廉价计算，并能对提示词或模型漂移提供早期信号。
质量指标 — 成本最高的一层：通过 LLM-as-judge 评分测量的幻觉率、与黄金测试集预期输出的语义相似性、用户反馈信号。这些需要评估基础设施，但是捕捉真实质量降级的唯一可靠方法。
对基础设施指标使用标准阈值告警，对 API 层和行为指标使用中等灵敏度告警。仅在有足够样本区分信号和噪音时才对质量指标告警——使用基于趋势的告警而非基于阈值的告警，这样质量分数持续下降 10% 会触发告警，而单次请求的波动则不会。
非确定性故障的分类决策树
当告警触发时，值班工程师面临一个在传统系统中不存在的决策问题：故障几乎肯定位于三个截然不同的地方之一，而每个地方的诊断证据都相互重叠。
三个故障域是：
模型提供商问题。 API 返回错误、超时或速率限制。这实际上是最容易的情况，因为它通常会在基础设施指标中显现。关键指标：HTTP 5xx 错误、429 速率限制、认证失败、区域可用性下降。应对措施：在提供商的状态页面上确认，检查 API 密钥有效性和配额余量（包括每分钟 token 数和每分钟请求数限制），实施到备用提供商或更小/更廉价模型的自动故障转移，并对重试应用带抖动的指数退避。
提示词或模型问题。 API 返回 200，但输出是错误的。这是难处理的情况。关键指标：在没有提供商错误的情况下拒绝率升高、格式合规失败（模型忽略 JSON schema 指令）、评估集上质量分数漂移、与提示词变更或提供商模型更新同时出现的行为变化。应对措施：首先，对当前模型运行你的评估测试集，并将分数与之前的基线进行比较。如果分数在提示词部署后出现偏差，就回滚。如果在没有任何内部变更的情况下出现偏差，说明提供商更新了模型——检查他们的更新日志，提交支持工单，如果 API 支持，考虑锁定到特定模型版本。
基础设施和检索问题。 模型本身没问题，但上游或下游某处已经降级。关键指标：延迟升高而质量分数稳定、token 消耗增加（模型获得了更长或噪音更多的上下文）、多步骤智能体管道中的级联故障、检索返回陈旧或不相关的片段。应对措施：检查你的 RAG 管道——检查向量索引的新鲜度、嵌入覆盖率、已知查询的检索召回率。检查编排层中的智能体间通信。检查功能开关的变更是否改变了智能体接收的工具或上下文。
决策树归结为三个诊断问题，按顺序：
- 提供商 API 是否返回错误或速率限制？→ 提供商问题。
- 质量分数是否下降？我们的提示词、上下文组装或检索是否有任何变化？→ 提示词/模型问题。
- 延迟是否升高但质量稳定？token 数量是否膨胀？→ 基础设施/检索问题。
在每次分类过程中，将最近的一批输入通过你的评估套件运行。没有这一步，你只是在猜测。有了它，你就有了客观证据。
无噪音告警
告警疲劳是一个复合问题：当值班工程师开始因为大多数告警是误报而忽略它们时，真正的故障就会淹没在噪音中。对于 LLM 系统，自然输出方差很高，这是对你的可观测性计划的生存性威胁。
三种有效的实践：
使用动态阈值，而非静态阈值。 LLM 使用模式具有强烈的季节性——某些查询在一天或一周中的特定时间更复杂，这会影响延迟和质量基线。根据峰值时段行为校准的静态阈值会在非高峰时段持续触发。基于历史模式的阈值自适应——2025 年代的可观测性平台开箱即用地支持这一功能——能显著降低误报率。
对持续趋势告警，而非单个数据点。 单次低质量回复是噪音。一个在 30 分钟内持续下降的滚动平均质量分数是信号。将质量指标告警配置为仅在趋势在有意义的样本窗口内持续后才触发。
在告警前关联信号。 单纯的延迟峰值不应该在凌晨两点叫醒某人。但在同一个 10 分钟窗口内，延迟峰值加上拒绝率上升再加上质量分数下降，就是一个故障事件。多信号关联——将相关告警分组为单个带上下文的故障事件——可以减少告警量，并给值班工程师一个比"延迟很高"更丰富的起点。
谷歌的 SRE 实践将此编成规范：协调、沟通、控制。事故指挥官的角色之所以有效，正是因为它从噪音中过滤出信号，给值班团队一个单一的协调点，而不是一洪水般独立告警。
随机系统的事后分析模板
标准事 后分析模板是为确定性系统设计的。它们问"什么代码变更导致了这个问题？"以及"我们如何防止它再次发生？"对于 LLM 故障，这两个问题都更难回答。
适配后的模板在标准字段之外需要四个补充：
检测方法。 你是如何发现故障的？自动化质量评估告警？用户投诉？业务指标下降（转化率、任务完成率）？这个字段很重要，因为它揭示了你的可观测性中的盲点——如果你是从用户投诉中得知的，你需要更好的自动化检测。如果告警是误报触发的，你需要更好的阈值调优。
非确定性确认。 该指标的正常方差范围是什么？降级是否明显超出该范围，还是存在关于这是否是真实故障的模糊性？LLM 事后分析有时会得出"我们不确定这是否真的是个问题"的结论——这没关系。明确地记录下来。
评估覆盖盲点。 你的评估测试集是否覆盖了受影响的用例？大多数 LLM 故障都会揭示黄金测试集中的盲点——团队没有想到要包含的案例。行动项通常是"在下次发布前将这些案例添加到评估套件中"。
回滚能力评估。 你本可以更快地回滚吗？你有锁定的、可部署的之前模型版本吗？是否有一个功能开关可以禁用 LLM 功能并回退到基于规则的系统？对于许多团队来说，在第一次故障时答案是否定的——行动项是在下次故障之前实现这些能力。
无指责的事后分析实践对 AI 系统比对传统系统更重要，因为"模型产生了幻觉"很诱人作为根本原因，但几乎从来都不准确。模型不会无缘无故地产生幻觉。它们产生错误输出是因为：提示词中上下文不足、检索不充分、训练分布偏移、模型版本更新改变了边缘案例的行为，或者对输出缺少约束。其中之一才是根本原因。事后分析应该找到它。
运行手册实际上应该说什么
LLM 故障的运行手册需要足够清晰，以便没有构建该系统的人也能执行。这意味着要规定具体的命令和查询，而不是一般性的指导。
具体而言，每个 LLM 功能的运行手册应该指定：
- 如何获取过去 24 小时的质量评估分数，包括确切的仪表盘链接或查询
- 如何将当前评估分数与部署前基线进行比较
- 当前激活的是哪个模型版本，以及如何锁定或回滚到之前版本
- 切换到哪个备用提供商，以及如何重定向流量
- 如何完全禁用 LLM 功能并激活降级行为（基于规则的响应、降级模式或功能开关关闭）
- 如果分类决策树无法解决问题，应该升级给谁——具体来说，是叫醒 ML 工程师还是基础设施 SRE
为每次 LLM API 调用添加丰富的元数据：提示词版本标识符、功能开关状态、用户细分以及任何 A/B 实验分配。当故障发生时，这些元数据将在无差别日志中的搜索变成有针对性的调查。
纪律鸿沟
LLM 可观测性的工具现在已经成熟——评估框架、持续质量监控、提供商故障转移、多信号告警关联。大多数组织缺少的不是工具，而是纪律：在第一次故障之前定义"正常"是什么样的，在第一次告警之前编写运行手册，在真正降级之前运行混沌测试。
处理 AI 故障好的团队，都做了乏味的前期工作：他们知道自己的基线质量分数，他们有一个代表真实生产流量的测试集，他们有一个已配置并经过测试的备用提供商，他们有一个由构建系统的人编写、并由没有参与构建的人审查的运行手册。
AI 功能的值班轮次并不比任何其他复杂分布式系统的值班轮次本质上更难。它只需要一个不同的心智模型——在这个模型中，"我无法复现这个故障"是预期的起点，而不是出了严重问题的信号。
