5 篇博文 含有标签「postmortem」

你与模型提供商签订了合同。你的运行手册（runbook）处理了该提供商降级的情况。当他们的仪表板变黄时，你的状态页订阅会向你发送告警。你觉得万无一失。然后，在某个周三下午，你提供商运行的基础云区域开始出现局部降级，你提供商的故障转移区域也受到了影响，因为他们为了控制单位经济效益而整合了容量。由于签署合同时上游两层的供应商决策，你的产品在 90 分钟内处于半瘫痪状态。

第二天早上，客户的事后分析（postmortem）请求出现在你的收件箱里。他们想要找到根本原因。根本原因存在于你的状态页无法看到的层级，也是你的合同无法约束的层级。这一层级正是所谓的第四方风险——它不是一个采购复选框，而是一个无形的依赖层，它会向上层传导故障，只会衰减而不会被吸收。

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

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

用户提交了一个工单。智能体告诉一位付费客户，他们的退款将在 7 小时内处理，而文档中记录的 SLA 是 7 天。附带了截图。你调取了追踪记录，找到了准确的提示词（prompt）、准确的工具调用、准确的模型和种子值（seed）。你进行了复现。模型说是 7 天。你再次复现。7 天。你复现了 100 次。其中 98 次说是 7 天，2 次说是“今天结束前”，但从未说过 7 小时。截图是明确无误的。复现结果却不一致。周五截止的复盘报告现在有一个“根本原因”栏，但你却填不出任何根本原因。

这就是大多数进入复盘阶段的 AI 事故的形态。不是那种明显的宕机——那些会有堆栈追踪和 500 错误率图表，并以每个 SRE 都受训过的方式恢复。棘手的是那些产生了一个错误输出、留下了受害者、在退出时抹除了自身条件，且在你召唤它时拒绝再次出现的单次事件。你使用过的每一个复盘模板都假设存在一个可复现用例。但智能体并不给你提供这些。

当你第一次用经典的 SRE 复盘（Postmortem）模板来分析 LLM 事故时，模板赢了，而事故输了。时间线、诱因、缓解措施、预防措施 —— 每个字段都填好了，每个复选框都勾选了，但在文档的最后，没人能回答唯一重要的问题：究竟是哪个变量发生了变动？不是部署事件。不是基础设施故障。不是代码变更。而是 Prompt 的修订、路由选择的模型切片、未触发报警的 Eval 评分所用的 Judge 配置、质量投诉发生时的检索索引状态、规划器（Planner）正在组合的工具 Schema 版本，或者是异常时间段内的流量组合。这些在模板里都没有对应的一行。

SRE 模板并不是为那些“事实来源是观察到的行为而非代码路径”的系统设计的。在 LLM 技术栈中默默变动的变量，正是模板从未需要列举的变量。强行借用模板，只会产生那种被归类为“持续调查中”的“我们不知道发生了什么变化”的复盘报告。

你的 LLM 功能开始返回胡言乱语。值班工程师呼叫 ML 团队。他们看了看输出，和提示词本应产生的结果对比了一下，不到一小时就关闭了工单："提示词有问题——已调整并重新部署。"事件关闭，事后复盘完成，行动项：改进提示词工程流程。

两周后，同类故障再次发生。不同的提示词，不同的功能——但是同样隐性的根因。

"修提示词"的反射动作，是 AI 工程领域版本的"甩锅给最后一个碰过这个文件的开发者"。它给事后复盘一个干净的结局，却无需任何人真正理解到底是什么出了问题。而与传统软件不同——那里这种反射动作只是懒散——在 AI 系统中，它在结构上是危险的：因为非确定性系统的失败方式，是提示词修改无法解决的。