52 篇博文 含有标签「sre」

有一种故障模式，在一切为时已晚之前，任何监控面板都看不到它：你的生产系统正在悄然劣化——某个次要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)、检索管道 —— 以及四种值班人员从未接受过识别培训的故障形态，这些故障不会出现在他们习惯查看的仪表盘上。

当 agent 在生产环境中第一次失控时——它删错了行，给错误的客户发了邮件，在单个任务上烧掉了 400 美元的推理费用，或者对受监管的用户说了法律风险极高的话——团队打开日志，却发现他们实际上拥有的是：一串参数被截断的 CloudWatch 工具调用名，一个只捕获了最新一轮对话的“用户提示词”字段，而且没有记录实际运行的是哪个模型版本。供应商在两周前滚动更新了别名。系统提示词存在于一个没有快照的配置服务中。由于框架默认值是 0.7 且“人尽皆知”，因此没有记录温度。触发错误操作的工具结果超过了日志行大小限制，并被截断为“...”。

你无法重现决策过程。你只能猜测。六个月后，你堆积了一堆无解的“它为什么这么做”的报告，团队开始像对待天气一样对待 agent——把它当作一种发生在你身上的事情，而不是你可以调试的东西。

飞行记录仪准则（Flight recorder discipline）是你为了防止这种情况所能交付的最廉价的东西，但如果你等到第一次事故发生才开始，它也将是你交付的最昂贵的东西。以下字段是最低要求，存储形式不容商量，采样和隐私边界必须同步设计，而不是事后修补。

你的智能体平台连续一年每季度都达到了 99.9% 的“响应成功率”SLO。但工单量增加了 40%。受智能体引导的用户群体的留存率却在下降。轮值运维感到无聊，产品经理在恐慌，而管理层评审一直在问，为什么仪表盘显示一切正常，而支持队列却显示情况一团糟。仪表盘没有撒谎。它只是衡量了错误的东西 —— 因为编写 SLO 的 SRE 将成功定义为“模型 API 返回了 200”，而这正是遥测系统最初唯一能表达的成功定义。

这是智能体可靠性工程的核心问题：成功的信号不是状态码。它是一种关于智能体是否针对特定任务做了正确事情的判断，而这种判断在请求时是无法获得的，通常在会话时也无法获得，有时只有在几天后，当用户提交工单、修改输出或悄无声息地流失时，才能揭晓。你无法在一个尚不存在的列上标记“200 对比 500”的布尔值。

常见的反应是等待获得基准真相（ground truth）后再宣布 SLO。这是错误的。可靠性工作不会在你构建标注流水线时暂停。正确的做法是针对你明知不完美的代理指标（proxies）编写错误预算，将它们命名为代理指标，设定团队在指标触发时的响应策略，并在产生基准真相后将其回填到计算中。这篇文章将探讨如何在不自欺欺人的情况下做到这一点。

页面告警在凌晨 2:47 响起。智能体（Agent）正向客户支持工单发送语气错误的回复，延迟仪表盘显示平稳，错误率正常，而且由于过去 12 小时内没有进行过任何部署，没有任何东西可以回滚。值班工程师打开了运维手册（runbook），滑过了“重启工作线程池”和“扩容队列”，直到翻到底部，也没发现任何能与眼前告警相匹配的内容。他们在凌晨 3:04 开始阅读系统提示词（system prompt）。到凌晨 3:31，他们仍在阅读。

这是全新的故障形态。那些为“高延迟意味着重启 Pod，5xx 错误增加意味着回滚部署，队列深度增加意味着扩容工作线程池”而设计的轮值制度，已无法应对此类问题。第一直觉——回滚部署——是错误的，因为根本没有部署：模型在版本化别名（versioned alias）后静默升级了，第三方工具的响应结构发生了偏移，提示词版本在不同区域间出现了偏差，或者评估集在几周前就已失效，而回归问题一直在持续累积。告警是真实的。运维手册却保持沉默。AI 值班现在已经成为一门独立的学科，试图将其强行套入现有的轮值体系，只会产生那种在告警发生时，所有人第一步都是在通话中相对无言、第一次开始阅读提示词的方案。

关于编程智能体（coding agents）的讨论总是陷入二元对立：自主还是受监督，YOLO 模式还是手握方向盘，--dangerously-skip-permissions 还是“批准每一次按键”。这种构想框架本身就是一个范畴错误。编程智能体执行的并非“一个动作”，而是一系列动作，其成本跨越了至少七个数量级 —— 从读取文件（免费、可撤销、无副作用）到合并至主分支（不通过 revert PR 则不可逆），再到向集群发布二进制文件（六位数成本级别的事故）。用一个自主性开关来处理如此广泛的范围，就像是为停车场和高速公路设置统一的限速一样。

如果团队在发布“无所不能的智能体”时，没有将每个动作映射到其爆炸半径（blast radius），那么只需一个带有提示词注入风险的 GitHub 评论，就足以引发一场事后复盘 —— 事实上，我们已经有了这种失败模式的公开案例。Anthropic 的 Claude Code 安全审查、Google 的 Gemini CLI Action 以及 GitHub Copilot Agent 在 2026 年都被证实可以通过精心设计的 PR 标题和 issue 正文被劫持，研究人员将这种攻击模式命名为“评论并控制”（Comment and Control）。这些智能体并非在抽象意义上损坏了，而是因为自主性层级悄无声息地将低信任输入抹平为“一视同仁”，从而基于这些输入执行了高阶动作（如推送代码、开启 PR）。

接下来需要建立的规范是：针对每个动作的曲线、随层级扩展的闸门、与爆炸等级匹配的回滚速度，以及一个测试工具组合升级而非单一动作失败的评估程序。

当 Agent 平台第一次崩溃时，事后分析报告（Postmortem）通常包含这样一句话：“周五我们还有八周的冗余容量。到了周一下午，我们已经达到了已配置容量的 140%。”没有人撒谎。容量模型本身是正确的，只是被应用到了一个它从未被设计用来应对的工作负载上。传统的容量规划假设需求沿着一条平滑曲线增长，周季节性是主导信号，最坏的情况是可以提前六个月规划的“黑色星期五”。Agent 工作负载彻底打破了这一假设。

Agent 需求的形态不是曲线，而是悬崖。有三件事造成了这种悬崖效应，并且它们会产生复合影响。一个企业级客户的入驻，就能根据你已经签署的合同通知，在通宵之间将基线移动 10 倍。一个 Agent 循环可以将微小的用户活动增长放大为扇出倍增的浪潮，对推理端的冲击比面向用户的图表显示的要高出 30 倍。单个产品变更——例如启用工具调用、延长上下文、切换到更大的模型——可以在用户数量不变的情况下，将单个任务的 Token 消耗提高一个数量级。

如果你的容量规划以 QPS 为单位，且你的冗余预算是“75% 的利用率是健康的”，那么你不是在规划。你是在赌这三个“悬崖”不会在同一个星期降临。