45 篇博文 含有标签「sre」

你的可用性仪表盘显示 99.95%。你的用户却说回答在句子中间停住了。两者都是正确的，而这正是问题所在。

HTTP 时代的可靠性技术栈建立在一个假设之上：状态码在请求结束时到达，并总结其命运。200 意味着成功。5xx 意味着重试。负载均衡器计算比例，SLO 仪表盘进行聚合，告警则根据消耗率（burn rate）触发。技术栈的每一层都会读取并信任这个 Header。

流式传输（Streaming）反转了这一假设。当你的服务器刷新第一个 token 的那一刻，它就已经承诺了一个 200 状态码。在那之后发生的任何错误 —— 在第 400 个 token 时的供应商超时、段落中间触发的内容审查过滤、TCP 连接断开、格式错误的工具调用（tool-call）片段 —— 都是在结果已经判定且无法撤回之后发生的。请求失败了，但状态码却说它成功了。而你的可靠性工具中没有任何一部分是为了察觉这种差异而构建的。

你的状态页显示为绿色。你的错误率为零。你的 p95 延迟看起来比上周略好。而在上周二，eval-on-traffic 指标在悄无声息中下降了四个点，整整九天都没人发现原因。因为当质量回退最终突破告警阈值时，已经有四个交织在一起的根因叠加在一起，团队已经无法分辨是哪一个最先引发了下滑。

这是 2026 年成熟智能体系统的主要故障模式，它不是任何单一组件的 bug。它是团队刻意构建的防御栈——那些出于好心、一个接一个添加的安全网——所产生的累积效应。主模型返回了垃圾内容；重试成功了。重试失败了；更便宜的回退（fallback）模型给出了答案。回退模型的输出格式错误；包装器（wrapper）将其重写为看起来合理的形状。包装器记录了一个软告警（soft warning）。没有人针对软告警设置告警。用户收到一个看似正确、交付流畅，但实际上比系统设计初衷要差的答案。

鲁棒层起作用了。质量表现却崩塌了。而告警机制是为鲁棒层存在之前的世界构建的。

这种说辞听起来很负责任。“我们别在各处硬编码 OpenAI —— 我们在前面加一层薄薄的抽象，这样以后如果需要，我们可以随时更换供应商。”两年后，那个“薄薄的抽象”变成了一项拥有自己部署流水线、SRE 值班表、拦截糟糕 Prompt 的评估门控、每年节省七位数资金的语义缓存、带有针对特定供应商退避机制的重试策略、所有仪表盘都依赖的可观测性架构，以及一个存放着六家模型厂商凭证的密钥库的服务。公司里的每一个 AI 功能最终都汇聚于此。

它也几乎是在无意间，成为了整个技术栈中爆炸半径最大的单点故障（SPOF）。当主要 LLM 供应商宕机时 —— 2025 年，OpenAI 自 1 月以来被记录了 294 次停机事件，而 Anthropic 仅在 12 月就记录了 184.5 小时的总客户影响 —— 网关会自动绕过它，大多数用户甚至察觉不到。而当网关本身挂掉时，每个产品中的每个 AI 功能都会同时停止工作，原本应该触发的故障转移根本没有机会执行，复盘报告的开头往往是：“我们为了隔离供应商宕机影响而构建的抽象层，本身成了那场宕机。”

传呼机在凌晨 3:02 响起。你眯起眼睛盯着手机，预料着那些常见故障：数据库故障转移、CDN 边缘节点失联，或者是某个八个月没人碰过的服务出现了 500 报错峰值。然而，警报显示的是：summarizer.eval-on-traffic.helpfulness rolling-1h: 4.21 → 4.05 (Δ -0.16)。没有 HTTP 错误。没有延迟峰值。没有服务宕机。系统在过去一小时内处理的每一个请求都返回了 200，并且响应体解析正常。然而，情况显然比午夜时分变糟了，而值班轮换要求你查明原因。

这种值班任务是标准的运维手册中从未提及的。出故障的东西并没有“坏掉”——它只是退化（regress）了。你多年来追踪的错误预算是以可用性和延迟来衡量的，而触发此次报警的故障模式在两者中都不可见。报警是真实的，客户受到的影响也是真实的，而你通常的诊断循环——检查部署日志、检查依赖图、查找错误的发布版本、执行回滚——在你意识到那个“错误的发布”可能只是昨天下午 4 点上线的一个 30 行系统提示词（system-prompt）的修改时，便碰了壁。在代码审查中，那次修改看起来完全无害。

你的 SRE 团队非常擅长运行微服务。他们精通蓝绿部署、金丝雀发布、分布式链路追踪、SLO 消耗率告警以及复盘文化。接着，有人发布了一个由 LLM 驱动的功能，不到一周就发生了一起上述实践都无法处理的故障：模型开始生成听起来很合理但结构错误的内容，没有日志报错，没有健康检查失败，用户在任何人注意到之前已经默默地接收了四个小时的垃圾信息。

这不是技能差距，而是架构差距。运行 LLM 服务是一门与运行微服务截然不同的运维规范。如果你不明确地识别出那些无法迁移的实践，它们将会让你的团队陷入困境。

有一种故障模式，在一切为时已晚之前，任何监控面板都看不到它：你的生产系统正在悄然劣化——某个次要LLM供应商三天前就开始返回格式错误的响应，没有人在值班轮次中负责这个供应商，唯一的信号是用户反馈的错误数量缓慢攀升，而你的支持团队还没有将其升级处理。你得知这件事，是因为一位客户取消了订阅。

这不是模型质量问题，而是运维规范问题。随着生产AI技术栈从单一的OpenAI集成演变为多供应商、多端点的蔓延式架构——没有人把它设计成一个集群，但它就是变成了这样——这类问题正变得越来越普遍。

想象一下这个场景：凌晨 2:14，值班工程师的手机嗡嗡作响，你旗舰产品中的 AI 功能正自信地告诉企业客户，他们的账号是“西红柿汤”。模型供应商推送了一个路由变更，你的提示词被静默升级的分词器截断了，或者是检索索引针对一个损坏的 Parquet 文件重新生成了——原因现在还不重要。重要的是，距离有人截图输出并发布到 LinkedIn 只剩 10 分钟。

如果你唯一的对策是“回滚部署并等待 CI”，那你已经输了。标准的流水线回滚从报警到恢复需要 20 到 40 分钟，而糟糕的输出不会在绿色对勾渲染时礼貌地暂停。等到新容器恢复健康时，截图已经在信息流里传开了，支持信箱里塞满了 50 个工单，而你花了 6 个月建立的信任正被那些从未使用过该产品的人审查。

那些能在 5 分钟而不是 5 小时内控制此类事件的团队并不是靠运气。他们在需要之前就构建了一个紧急开关（Kill Switch）——这是一个允许值班工程师在几秒钟内禁用 AI 路径的原语，无需部署，无需合并，也无需任何人触碰生产环境的二进制文件。这篇文章将探讨这种专门针对 AI 功能的原语是什么样的，为什么确定性软件的版本不足以应对，以及在事故发生前的一天必须具备什么条件，才能让响应在事故发生的当晚奏效。

当产品团队第一次需要针对每个用户的智能体（agent）行为时，通常会有人说“我们应该进行微调”或“让我们接入持久化内存”。一周后，他们拥有了向量数据库、反馈循环流水线，以及监控学习状态漂移的路线图项。他们构建了一个机器学习系统来解决一个在十有八九的情况下其实只是配置文件的问题。

看看用户真正想要的是什么：更简洁的回答、要点列表而非散文、免责声明中包含我的公司名称、默认使用我偏好的模型、100 美元以下不要转接到人工、这是我本周正在处理的项目、永远不要使用表情符号。这些都不需要模型去学习任何东西。它需要的是设置（settings）。Dotfile 模式——一个版本化的、声明式的、针对每个用户的配置库——在四十年前就为 shell、编辑器和 CLI 解决了这个问题，而这正是 2026 年 AI 智能体的正确形态。

第一次事故很少表现为系统宕机。它通常是来自客户成功团队的一条 Slack 消息：“嘿，我们还好吗？在过去的一小时里，有五个客户升级了工单，这些工单在‘待审核’状态下已经躺了超过一天了。”你检查了模型延迟仪表盘。绿色。你检查了智能体（Agent）的成功率。绿色。你检查了单次调用成本图表。健康。你监测到的一切指标都正常。出故障的是一个你的监控栈根本不知道其存在的队列，负责该队列的人员其日历不在你的容量规划器的读取范围内，而管理它的 SLA（服务等级协议）甚至从未被书写下来。

那个队列就是你的人机回圈（human-in-the-loop, HITL）升级路径。你在三个月前为了“安全起见”添加了它——当智能体在极少数情况下置信度较低或操作风险较高时，它会将案例移交给人工审核员。上线之初，它每天可能只处理十几个条目。运维团队在处理其他任务的间隙就能搞定它们。它曾是一个兜底方案，而不是一个系统。如今，它正在处理数千个条目，解决时间的中位数翻了三倍，排队等待的客户正在悄无声息地流失。HITL 路径本身并没有失效。它只是不再被当作生产环境来对待了。

打开你的 AI 功能延迟和质量看板，眯起眼睛仔细看。曲线大部分时间是平缓的，偶尔会有一些峰值，你的团队几个月来一直称之为“噪音”或“供应商异常”。现在，按小时和星期几来拆分这些数据。噪音显现出了真面目：在东部时间每个周一上午 9 点到 11 点之间，你的 p95 延迟比周六晚上高出 30–60%，缓存命中率下降 10–20 个点，重试率翻倍，每个任务的 token 支出也在悄然攀升。看板没有撒谎，它只是在做平均。

大多数团队发现这种模式的方式就像发现缓慢漏水一样：通过回溯没人能解释的季度账单。直觉是将其归结为供应商的不稳定性，给推理厂商提个工单，然后就此作罢。但这种模式其实与你的 LLM 供应商无关。事实是，你的 AI 功能现在构建在一堆共享的、对时间敏感的系统之上——模型 API、embedding API、你的 agent 调用的 SaaS 工具、接收 webhook 的客户自身基础设施——而其中每一个系统的周期性负载模式都会发生叠加。你继承了整个依赖链的昼夜曲线，而你的看板向你展示的是所有这些曲线的平均值。

针对糟糕的代码部署，标准流程是在一分钟内完成回滚。针对错误的配置推送，标准流程是亚秒级的开关切换。而针对糟糕的模型升级，应对方案则是值班工程师在早上 09:14 临时想出的法子，而且通常需要耗时 7 小时才能完成。在这 7 小时内，性能倒退持续累积——错误的答案被发送给客户，支持工单堆积如山，而监控面板显示的只是缓慢的倾斜曲线，而非迅速回归绿色的断崖式好转。

差距之所以长达 7 小时，并非因为团队动作缓慢，而是因为模型升级的“回滚”与代码的“回滚”并非同一种原语。它更接近于数据库模式（schema）迁移：局部的、滞后的，且无法通过按下你希望存在的那个按钮来撤销。围绕“一个按钮”编写事故应对方案的团队，并不具备实际回滚所需的控制能力。

这篇文章将探讨这些控制能力具体是什么样的，为什么必须提前为此付出代价，以及当你第一次尝试在负载下回滚模型时，你会对你的平台有哪些新发现。

一位拥有 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)、检索管道 —— 以及四种值班人员从未接受过识别培训的故障形态，这些故障不会出现在他们习惯查看的仪表盘上。