随机系统的值班响应：为何你的 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 数量是否膨胀？→ 基础设施/检索问题。
