43 篇博文 含有标签「incident-response」

事故排查会议（incident bridge）安静得有些异样，这意味着大家都卡住了。一份支持工单显示，智能体（agent）告诉客户其退款已获批准，而事实并非如此。你有完整的追踪记录：提示词（prompt）、检索到的账户记录、工具调用、模型的推理过程以及最终的消息。你重放了一遍，智能体的操作是正确的。你又重放了一遍，依然正确。十次中有九次，产生该事故的追踪记录反而生成了正确的结果。会议上终于有人提出了那个复盘模板（retro template）无法处理的问题：那么，根本原因是什么？

根本没有。至少不是模板所指的那种。五个为什么（five-whys）的链条是这样运作的：“智能体告诉了客户错误的信息” → “因为模型生成了批准” → “因为它采样了一个断言批准的 Token 序列” → “因为……这是概率分布所允许的。”最后一个“为什么”最终以耸耸肩告终。“模型采样了一个错误的 Token”在技术上是正确的，但在操作上毫无用处。它没有指明修复方案，没有分配负责人，也没有弥补差距。你可以把它写进报告，但每个读到它的人都知道，你记录的是一个巧合，而不是一个原因。

传统的混沌工程建立在一个默认的假设之上：如果你两次注入同样的故障，你会得到两次同样的失败。停掉 pod，观察故障转移，修复漏洞，再次停掉 pod 以进行确认。整个学科——假设、爆炸半径、稳态指标——都假定系统具有足够的确定性，使得实验是可重复的。

智能体系统从根本上打破了这一假设。在智能体运行过程中注入工具超时，模型会重新规划路径——有时它会重试，有时它会换一个工具，还有时它会自信地编造一个从未获取到的结果。针对相同的提示词运行相同的故障，你最终会得到不同的轨迹，因为故障路径是通过一个随机规划器（stochastic planner）运行的。上周二你在生产环境中看到的故障永远不会以完全相同的形式再次发生。而这恰恰就是你必须对其进行演练的原因。

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

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

传呼机在凌晨 2:14 响起。结账服务正抛出 500 错误，收入在流失，而你是值班工程师。你调出故障模块并开始阅读。代码很整洁——函数命名规范，结构合理，甚至还有几处有用的注释。然而你完全不知道它是干什么的。代码不是你写的。你团队里的任何人都没真正写过它。四个月前，一个智能体（agent）生成了这段代码，它通过了评审，测试通过了，并从此在生产环境中运行。现在它出故障了，而那个理应修复它的人却是第一次见到它。

这就是理解债（comprehension debt）：你的组织运行的代码量与人类实际理解的代码量之间日益扩大的差距。它不会显示在仪表盘上。当一切看起来都健康时，它在默默累积，并在最糟糕的时刻——在事故期间，当你对自己系统的理解不足其代价是以停机时间来衡量时——到期偿还。

弃用通知在某个周二送达，停用日期定在六个月后。你的平台团队将其记录在依赖跟踪器中，贴上 “Q3 切换” 标签，并标记为黄色严重度。它与队列中已有的另外两个迁移任务汇合。三周后，供应商在同一个 URL 下修改了日期，没有 diff，没有收件箱通知，只有一段悄悄更新的文字，将停用日期提前了 60 天，直接挪到了你的代码冻结期中间。

你视为规划文档的生命周期页面，其实一直是一个合同闹钟。唯一改变的是它控制着哪个团队的日历——而拥有这个日历的团队并不是你的。

报警在当地时间 02:17 响起。值班 SRE 在手机上打开智能体运行手册，阅读第一步：“检查智能体的工具调用追踪，寻找异常的工具使用情况。”他们打开链接，却遇到了一个他不属于的工作区的 SSO 登录提示。第二步说要检查提示词构建日志；同样碰壁。第三步说回滚到上一个提示词版本，但部署权限被限制在了一个他不在的团队中。等他弄清楚该向哪个 Slack 频道上报，并叫醒 AI 团队的产品经理时（因为她是 02:17 唯一能找到的人），九十分钟已经过去了，而客户可见的回归故障仍在持续给出错误答案。

事后分析会将权限鸿沟确定为直接原因。而更深层的不适感在于，这份运行手册在白天读起来很顺畅，但在深夜执行时却被封锁，因为编写手册的人拥有执行者所不具备的权限。

运维手册上写着“禁用代理”。值班人员照做了。43 分钟后，当紧急开关终于通过配置服务传播开来时，该代理已经提交了 1,200 张错误的工单，调用了 8,000 次计费 API，并向根本没有订阅任何服务的客户发送了邮件。运维手册是正确的，但它也是徒劳的，因为没有人衡量过当代理每秒钟都在造成破坏时，“禁用代理”实际上需要多长时间。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E5%B8%A6%E6%9C%89%E5%BB%B6%E8%BF%9F%E9%A2%84%E7%AE%97%E7%9A%84%E7%B4%A7%E6%80%82%E5%BC%80%E5%85%B3%EF%BC%9A%E4%BD%A0%E7%9A%84%E6%95%85%E9%9A%9C%E5%A4%84%E7%90%86%E4%BB%8E%E6%9C%AA%E8%BE%BE%E6%A0%87"]

大多数 AI 功能都配有紧急开关，就像大多数建筑都配有灭火器一样：有人签字确认它的存在，却没人计时到达它需要多久。合规审查会问“是否有紧急开关？”，答案是肯定的。而故障现场会问“止血有多快？”，答案则取决于底层管道恰好需要的时间——团队中从未有人针对该功能造成破坏的速度测量过这个数字。

这种不匹配正是问题的核心。一个遏制时间长于其破坏扩散时间的功能，交付的只是“遏制剧场”（Containment Theater）。

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

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

第一次智能体导致我们团队出现真正的停机事故时，复盘报告的作者打开模板，划过时间线，盯着“根因”字段沉思了良久，然后输入：“队列阻塞恢复的操作指南 (runbook) 有误。” 但实际上操作指南没问题。智能体阅读了指南，认定队列的症状符合另一种场景，并针对该场景运行了恢复脚本。那份文档产生的改进措施——“细化操作指南用词”、“在恢复脚本中增加确认提示”——对于实际的故障模式完全无用。实际情况是一个推理系统推导错误，而模板中没有任何字段知道该如何表达这一点。

自那以后，我看到同样的失败在不同团队中反复上演。模板是为确定性系统设计的。代码做错了，你就修复代码；配置设错了，你就修复配置。复盘文档的模式 (schema) 就是团队关于故障理论的模式，当这个理论无法表达“智能体的计划错了”时，文档就会将实际故障强行降维成模板能表达的最接近的事物——通常是文档缺失或缺乏护栏——从而导致改进措施试图用确定性的修复方案去解决概率性的故障。然后，同一类事故会再次发生，团队下次依然会以同样的方式记录它。

发布标志运作完美。你在它后面发布了 AI 摘要生成器，在两周内将其比例从 1% 提高到 10%、50%，最后达到 100%，紧盯仪表盘，一切正常。季度末，平台团队的标志清理机器人发起了一个 PR，删除了这个已经多余的入口。你批准了。该 PR 与其他过期标志清理工作一起合并，代码库精简了 200 行。六周后的凌晨 2 点，供应商滚动更新了一个新的模型快照，你的摘要生成器开始信誓旦旦地在法律文件中编造条款，而你的值班工程师发现没有快速关闭它的手段 —— 只能重新部署。

标志完成了它的工作。但标志是错误的保留产物。发布标志回答的是“这条新代码路径是否应该是可达的？”一旦大家达成共识，删除它就是正确的清理举动。而紧急开关（Kill switch）回答的是“上游模型今天表现正常吗？” —— 这个问题永远不会过期，因为上游模型永远在变化。将它们放在一起清理，就像把烟雾报警器当作建筑许可证一样，是范畴错误：建筑物建成后，许可证会被归档，但报警器的接线必须永远保持连接，因为由于它所监控的情况仍然可能发生。

故障复盘进行得非常顺利，直到遇到了一个没人能回答的问题。下午 2:14，结构化输出错误激增，某个收入工作流停滞了 90 分钟。时间线还原得很清晰：三周前，有人修改了系统提示词（system prompt），多加了几个关于“对话语气”的词，这在特定输入下悄悄导致模型偏离了 JSON 契约。修复方法很简单，只需一行代码回滚。但接下来的部分很难：有人问是谁做的改动，谁审核的，以及未来哪个团队负责维护这个提示词。房间里陷入了沉默。没有 Pull Request，没有审核人。改动是某个人在晚上 11 点通过厂商控制面板操作的，而那个人已经不记得这回事了。

那种沉默才是真正的事故。JSON 契约的失效只是症状。根因在于，系统中杠杆率最高的一处行为逻辑，竟然没有负责人，没有变更历史，也没有走任何管理其他生产环境变更的流程。模型没有出错。模型完全按照指令行事。失败之处在于，“指令”本身完全脱离了变更管理。

这是目前最常见的生产环境 AI 事故之一，而且几乎从未被正确命名。复盘报告在根因栏写下“提示词退化（prompt regression）”然后就此揭过。但“提示词退化”描述的是代码表现。真正的根因是组织架构图上的一个漏洞。

值班轮换制度是建立在一个承诺之上的：故障是可以复现的。警报触发，你重新运行请求，观察 Bug 发生，找到错误的提交 (commit)，然后回滚部署。这个循环的每一个环节都假设了确定性 (determinism)。同样的输入产生同样的输出，而输出要么是对的，要么是错的，其方式一目了然。

Agent 集群悄无声息地打破了这条链条上的每一个环节。故障发生了一次，其采样温度 (sampling temperature) 你无法重现，所处的上下文窗口 (context window) 也早已被垃圾回收。这里没有“错误的提交”，因为代码从未改变 —— 改变的是模型，或者是检索到的文档，再或者是用户措辞的方式超出了所有人的预料。你回滚了部署，但部署从来都不是问题所在。

于是警报发出了，一名工程师接手了。他们发现了在生产环境中运行 Agent 最令人不安的事实：他们拿到手的是一个无法单步执行 (single-step) 的系统，而摆在他们眼前的运行手册 (runbook) 却是为另一种完全不同的机器编写的。