9 篇博文 含有标签「on-call」

几乎每起事故的前 15 分钟都是机械式的。拉取每个人都会拉取的那四张图表。对比事故开始时的部署差异。检查今天翻转了哪些功能标志（feature flags）。在运行手册（runbook）维基中搜索错误字符串。这些都不需要判断力——它只需要你保持清醒，而在凌晨 3 点，你的值班工程师正把这些时间花在找笔记本电脑、加入语音会议（bridge），以及回忆哪个仪表盘才是真正有用的那个。在人类解锁屏幕之前，智能体（agent）就可以完成这一切。

然而在大多数组织中，关于 AI 在事故响应中应用的讨论往往止于一个段子：“我们听说有个团队的自动修复脚本搞垮了生产环境。”于是，整个想法就被禁绝了——不是限制范围，不是分阶段实施，而是直接禁绝。这是一个范畴错误。那些恐怖故事讲的是自主权阶梯的最顶层，而团队的反应却是拒绝踏上最底层。在最底层，智能体没有任何写入权限，它能做的最坏的事情也就是在 Slack 里发了一段错误的话。

一次真实的回归在生产环境中持续了两天。告警（Page）已经触发了。它触发得完全正确，阈值准确，严重程度也恰当。三周前，值班轮值（On-call rotation）为该告警族添加了一条静默规则，因为该系列中的每一条告警到目前为止都以同样的注释结案：“无须操作，调查中”。复盘（Post-mortem）无法诚实地将这种静默行为称为错误。这是对一系列值班人员没有 Playbook（运行手册）可循的告警流所做出的理性适应。那个重要的回归就在一个被静默的频道中发布了，因为团队的监控栈产生的信号无法指导具体行动，而团队唯一的应对方式就是：停止倾听。

这并不是一个告警 Bug。这是当团队沿用旧有的 Playbook 对 AI 功能进行埋点时，产生的一种结构性特征。延迟、错误率、拒绝率、输出 Schema 符合度、Judge-eval 漂移——每一个都是合理的指标。每一个触发时都带有同样模糊的“模型行为改变”措辞。但它们都没有告诉值班工程师该做什么，因为没有人写过将每个信号映射到具体动作的 Runbook，因为大多数情况下，信号并不能对应到具体的动作。值班轮值吸收着噪音，直到噪音盖过了信号，然后值班人员就会绕过产生这些信号的频道。

AI 平台团队有四名工程师。他们七个月前发布的内部 Agent 现在每天为 200 名员工回答问题。在第一个月，创始工程师亲自处理了每一个 Slack 消息——周二晚上 11 点，周日上午，甚至公司团建的晚上。随后，她因推动采用率方面的贡献而晋升为资深工程师（Staff Engineer），三周后，她在下午 6 点后就不再查看频道了，因为那是资深工程师该做的。原本打算取代她的值班轮换（on-call rotation）从未正式化，因为运营模式总是打算在“试点之后”再解决。

当 Agent 针对四分之一的用户静默降级的那天——一个悄然落后的检索索引，或者改变了拒绝行为的模型版本切换，或者是架构轮换后现在返回空数组的工具——投诉并不会降临到平台团队的传呼机（pager）上。它们落在帮助台队列中，由那些无法访问 Agent 追踪（traces）、不知道什么是系统提示词（system prompt）、并且被 IT 部门告知该 Agent “由 AI 团队负责”的人员处理。从第一个用户投诉到第一位工程师查看 trace，中间过去了 16 个小时。平台团队没有人玩忽职守；只是根本就没有人在执勤。

警报在凌晨 02:14 响起。运维手册（runbook）写着“呼叫工程师”。工程师的名字关联到了一个值班轮值。该轮值指向一个 Slack 频道，这是团队在六个月前建立的统一分诊界面。频道中的第一条消息是告警。十九秒后发布的第二条消息是一段冷静的三句总结：告警服务、失败的依赖项、最后一次部署。它写得很好，最后以“已确认（Acknowledged）”结尾。

事故指挥官在床上看着手机，读到“已确认”后便翻身继续睡去。然而，并没有人确认。作为一线分诊助手的智能体（Agent）订阅了该频道，它向频道复述了告警内容，并以频道中其他读者习惯用来表示“我已掌握处理此问题的上下文”的动词收尾。这起事故在无人接手的情况下运行了 41 分钟，直到一张客户工单通过另一个界面唤醒了另一位工程师。

凌晨两点，你的客服智能体呼叫一位真人。那位真人已经请假一周了。休假自动回复就躺在智能体正在读取的同一个邮箱里。智能体仍然 ping 了过去。自动回复弹了出来。智能体礼貌地道了声谢，然后又 ping 了一次——因为回复里没有它在等的那个工单解决码。十二个循环之后，另一支团队的人偶然发现这个未读会话已经堆了六十条消息，才手动去把值班的人叫醒。

智能体完全照着 prompt 说的做了。Prompt 让它升级给一个人。这个"人"在它眼里只是一个字符串，不是一个角色。这个字符串不知道什么叫 PTO。

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

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

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

当一个智能体因为循环处理一个格式错误的告警信号，在一小时内给你的值班人员发了四次传呼时，领导层终于意识到安全团队早已知晓的一件事：“工具访问权限”与“创造人工任务的能力”其实是同一种权限，而你在没有进行安全审查或产品归属权审查的情况下就授予了它。没有人关注“谁被允许在凌晨 3 点打扰人类”这个问题，因为根本没人把它当作一个问题。它被描述为一个 Slack 集成。

2026 年的智能体技术栈让这种故障模式的发生门槛变得极低。Anthropic 的 MCP 服务器、OpenAI 的 Agents SDK，以及各种厂商提供的操作工具，极大地缩短了“模型决定做某事”与“人类被吵醒”之间的距离。大多数团队部署这些集成的方式与部署数据库客户端如出一辙：定义一个 Token 作用域，引入 SDK，写一段系统提示词，然后发布。数据库客户端的爆炸半径是受影响的行数。PagerDuty 客户端的爆炸半径则是一个人的睡眠。

当一名 on-call 工程师第一次以“模型刚才又表现得有点怪”为由关闭告警页面时，团队就已经悄然越界了。这句话同时表达了三层意思：它宣告了问题不可调查，它将未来类似的告警归类为噪音，并免除了轮值人员记录事件经过的责任。一周后，同样的特征再次触发告警，另一个人看到“之前已经关闭过一次”，于是真正的回归（regression）便会一直潜伏在生产环境中，直到有客户在 Twitter 上发帖投诉。

这种模式并不是因为懒惰。它是将标准的 SRE 直觉运行在一个不再表现出确定性的系统上所产生的必然结果。经典的 on-call 培训教导工程师将“输入相同但输出不同”的情况视为可观测性堆栈中的 Bug——这不可能是系统本身的 Bug，因为系统不会那样运作。但基于大语言模型（LLM）的系统正是在每一次请求中都以这种方式运作，这是其设计使然。如果建立 on-call 轮值机制时没有内化这一点，系统就会滑向两个极端：要么是瘫痪（每一个随机波动都是 P2 级事故），要么是虚无主义（模型总是很奇怪，别再给我发告警了）。