运维与故障处理

变化在哪里

事故处理分两半：查清哪里出了问题，以及采取措施。AI 对这两半的影响方向相反。

诊断是读。一个对根因假设排序、或指出可疑变更的智能体，没有向生产环境写入任何东西。它错了，人只是在一条错误线索上浪费些时间。这个阶段测量得最好的结果都属于这一类。阿里云的 BiAn 在十个月里把运维人员定位网络事故根因的时间缩短了 20.5%（SIGCOMM 2025，T2）；Google 报告说，其 Incident Hypothesis 工具在一次 A/B 测试中把平均缓解时间（MTTM）缩短了 10%（Google SRE，T3）。两者都仍由人来决定、由人来行动。

但在独立基准上，智能体很少能把根因完全找准。OpenRCA 2.0 测试了 11 个前沿模型，在 500 个案例中平均只有 20.7% 找回了完整准确的根因集合。模型在 76.0% 的案例中至少找到一个正确的根因服务，但其中只有 61.5% 有经过验证的因果路径作支撑。ORCA-bench 的标准答案由资深 SRE 签字确认；五个前沿智能体中最好的一个，在中等难度任务上准确率为 25.3%，在困难任务上为 10.0%，而最弱的模型「在 40% 的事故报告中幻觉出一个不合理的根因」。

五次里对一次的输出，作为一份由人核对的排序清单仍然有用；但它不能作为行动的依据。

缓解是写入生产环境。在交付流程的其他环节，一个变更要先经过分支、评审和流水线，用户才会看到。运维操作没有这道关口：引流、重启任务或删除存储卷，本身就是变更；智能体的凭证够得着什么，它就能立刻改动什么。PocketOS 的生产数据库和备份，毁于一个正在处理预发布环境任务的智能体之手。Replit 的智能体在宣布代码冻结期间删除了一个生产数据库。在亚马逊的 Kiro 事件中，FT 的说法是智能体选择了「删除并重建环境」，亚马逊则归咎于「访问控制配置错误」；两种说法都把访问范围放在核心位置。在每一起事件里，实际授予的权限都设定了一个没有人选择过的级别：这就是成熟度模型的规则 2。

所以，这两半以不同的速度攀升。诊断能升多快，取决于你能多快测出它的准确率。行动只能升到其后果仍可撤销的位置，而且只能在一个智能体无法自行扩大的边界之内。

本阶段的阶梯

下面的标准与成熟度模型网格中的运维一行完全相同。本节补充每一格在实践中意味着什么，以及它背后的证据有多薄。

测得的价值集中在 L1。Meta 的 AI 辅助根因分析系统为一次调查给候选代码变更排序。只用每次调查开启时已有的信息做回测，「这些调查中有 42% 的根因出现在前五个建议的代码变更里」。比这个数字更重要的是设计选择：系统会扣下低置信度的答案，以覆盖率换精确率，因为 AI「可能给出错误的根因，误导工程师」。正是置信度把关，让一个 L1 工具可以放心摆在疲惫的值班工程师面前。

L2 由封闭集合定义，而不只是由审批定义。对智能体敲出的任何东西点「批准」，是很弱的控制；成熟度模型记录过 Anthropic 针对自家产品给出的数字：用户批准了 93% 的权限提示。Google 的 SRE 演示是公开资料中对更好做法最清晰的设计（Google Cloud 博客，2026 年 1 月 22 日）。它从一套词汇出发——「一个明确的、封闭的标准缓解措施类别集合（例如引流、回滚、重启、扩容）」——再在外面加五层防护。智能体「不写随意的 bash 脚本，而是从严格类型化的工具中选择（通过 Model Context Protocol）」。每个工具定义都带有其潜在影响的元数据（「安全、可逆、破坏性」）。策略层检查上下文（「高峰流量期间禁止全局重启」或「需要两人批准」）。CLI 强制一步确认：「智能体提出变更，但由 Ramón 授权。」每一次提议和批准都留有日志。

L3 有一个严肃的设计，却没有结果数据。Google 的 SRE 页面描述了一个 AI Operator：它「对关键操作」要求「由人类 SRE 审查并接受缓解建议」（它的 L2），并「将对轻微事故安全地自主执行缓解措施」（它的 L3）。Google 的编号在这里恰好与本书一致（见对照表）。让这个设计可信的，是它的退路，见下文「护栏」一节。该页面没有公布自主类别的错误率或 MTTM，所以它说明 Google 确有 L3 运维，却没有说明它比 L2 更好。

L4 除了失败案例，空无一物。没有任何组织公布过针对一个枚举告警类别、附有验证记录的 LLM 自动修复。这一格里的三起事件都是事实上的 L4：无论团队自认为处在哪一级，凭证都允许了无需逐项批准的不可逆操作。

案例：阿里云 BiAn

级别：运维，L1–L2。系统对可疑设备排序；运维人员决定并行动。

BiAn 是公开记录中测量得最好的运维结果，而它是一个诊断结果。阿里云构建它来定位生产网络中的故障：LLM 流水线对最可能出错的设备排序，运维人员从这份清单着手调查。论文作者来自南京大学、阿里云、上海纽约大学和北京大学，经 ACM SIGCOMM 2025 同行评审。

让它与众不同的是方法。团队没有去数「处理了」多少起事故，而是把借助 BiAn 的调查与「完全人工」完成的调查作比较，并加入微软 RCACopilot 的一个变体作为第二组对照。值班运维人员安排了「两个影子运维角色来做根因定位」，一个用 BiAn，一个用 RCACopilot，并「尽力」分派「专业水平相当的运维人员」。定位根因的时间从调查开始算起，到确定根因和故障设备为止。核心结论是：BiAn「已在我们的网络基础设施中部署 10 个月……将定位根因的时间缩短了 20.5%（高风险事故为 55.2%）」，在 17 个月的真实案例上准确率比基线高 9.2%。

论文里有一个细节，说明了收益为何落在诊断上。一旦知道了根因和设备，缓解只需「相对固定的时长（约 2 分钟）」。在那个网络里，从告警到恢复的时间几乎都花在弄清哪里出了问题上。诊断更快，事故就更短；把这两分钟的缓解自动化，省不了多少，却要承担按错误诊断行事的风险。这是一个系统的比例，不是定律；但在把自家事故的最后一步自动化之前，这正是该问的问题。

它没有说明什么。没有说明智能体可以被信任去行动，因为根本没有智能体行动过。没有说明它能迁移到应用层事故，那里的根因包括部署、配置和功能开关。也不是一个受控结果：运维人员是「尽力」匹配的，作者也承认「绝对的公平很难做到」。

反面的证据。独立研究说明了为什么仍需由人核对这份清单。滑铁卢大学团队的 FORGE 2026 研究（T1）让六个开源模型跑了 48,000 个故障场景，发现最常见的推理失败是编造证据和证据不足；随着智能体工作流变复杂，表现跌到「不如瞎猜」的水平，较小的模型尤其如此。另一项在 OpenRCA 上的 1,675 次智能体运行发现，曲解数据的幻觉和探索不完整「出现在所有模型中」，而且单靠提示词工程修不好（Kim 等人，T1）。一家厂商 Traversal 认为，OpenRCA 的部分标注无法从遥测数据中还原，所以这些基准低估了真实表现。就一个基准而言这一点说得有理，但它出自一家销售 AI SRE 产品的公司，也动摇不了 ORCA-bench 由专家签字确认的标准答案。

Google 的 A/B 数据应与 BiAn 并列。Google 写道，其规模「提供了对 Incident Hypothesis 这类 SRE 实践做 A/B 测试所需的统计严谨性」，而「仅凭信息辅助，就让平均缓解时间（MTTM）缩短了 10%」。这是本书证据库中唯一一个经 A/B 测试的 MTTM 结果。同一页面还称，其 Investigation Dashboards 带来了「对受支持的事故，MTTM 大约缩短 44%」，没有方法说明，而且只针对一个挑选过的子集。

这个阶段的产品宣称都是厂商自报，没有一项公布方法。

值得带走的比较，是自报数据与基准之间的比较，而不是厂商之间的比较。宣称 MTTR 减半的产品，与只有五分之一概率找准根因的独立智能体并列。如果厂商统计的是狭窄、重复的事故类别，两者可以同时成立；这正是为什么一个数字必须先说明它对应哪类事故，才能拿来用。请按经济学一章的规则读这些数字：看方向，不看幅度。

迁移步骤

下面每一步攀升都针对一个具名的事故类别或任务类型，并按成熟度模型规则 3 的要求记录：写成「运维：无状态服务的容量类事故 L2；其余 L1」，而不是「运维：L2」。

L0 → L1：先测量诊断，再信任它。

1. 给工具只读权限，访问遥测数据、运行手册、近期变更和过往事后复盘。它持有的任何东西都不应能写入。
2. 上线前先回测，像 Meta 那样：只用每起已关闭事故开启时已有的信息重放，记录真实根因出现在前一、前三或前五的频率。
3. 按置信度把关。定好一个阈值，低于它工具就不出声，并接受覆盖率随之下降。
4. 做影子对比，像阿里云那样：在一段时间内，一位响应人员用这个工具，另一位不用（或用现有工具），按事故类别比较定位根因的时间。

风险较低的起点，是从事故中学习，而不是响应事故。Zalando 两年来一直用 LLM 分析其事后复盘（Zalando Engineering，2025 年 9 月）。早期的小模型「在摘要和分析阶段出现幻觉的概率高达 40%」，于是由人审校每一份摘要，「直到幻觉的影响降到 15% 以下」，然后改为审校「随机抽取的 10%–20% 摘要」。分析得出的一个洞见促成了一项校验，它「能为我们挡住 25% 的后续数据存储事故」。Zalando 同样坦率地说，「从事后复盘中……可靠地提取数值数据……并未做到」。这就是一次攀升的缩影：测出错误率，设定阈值，再转为抽样审查，并老实写明模型做不到什么。

L1 → L2：在智能体提出任何建议之前，先写好目录。

1. 列出你们已经在手工使用的缓解措施类别。Google 的清单（引流、回滚、重启、扩容）是个起点；你们的清单来自自己的运行手册。
2. 把每一项都做成带风险标签和撤销路径的类型化工具。没有撤销路径的，要么不开放，要么标为破坏性。
3. 在工具前面加一层懂上下文的策略：时段、流量水平、一个操作涉及多少实例，以及是否需要两人批准。
4. 每个操作都强制由人确认，并记录提议了什么、批准了什么、执行了什么。
5. 让智能体以自己的身份运行。Google 的页面说得直白：「智能体身份必须与人类用户区分开」。如果智能体借用值班工程师的凭证，它就继承了那位工程师能做的一切。

下面的示例展示了这样一份目录的样子。它是本书的提案，依据 Google 演示中的五层防护构建；条目和限额仅作示意，不取自任何组织。

Illustrative mitigation catalogue (the book's proposal; no organisation).
Built from the five layers in Google's SRE walkthrough.

tool               risk tag      undo path         max level  policy
drain_traffic      reversible    undrain           L3         one cell at a time
restart_task       reversible    none needed       L3         rate-limited per task
add_capacity       reversible    remove_capacity   L3         quota cap per incident
rollback_release   reversible*   roll forward      L2         *check intervening changes
change_config      reversible    revert_config     L2         2-person approval
delete_volume      destructive   none              never      not exposed to the agent

Every call: typed tool only; logged as proposed / approved / executed;
runs under the agent's own identity, scoped to one environment.
Downgrade L3 -> L2 on: elevated risk score, anomalous production state,
any policy denial, or a health signal moving the wrong way after the action.

有两处选择值得一提。回滚放在 L2，因为 Google 警告，当之后又有其他修复落地时，「简单地二元回滚到『最后已知良好』版本会变得风险很高」：原则上可逆，但如果撤掉了别人的修复，就是破坏性的。另外，破坏性工具根本不在智能体的词汇表里。智能体无法滥用一个从未拿到的工具，这比任何审批提示都更可靠。

L2 → L3：只选一个轻微事故类别，并先把退路建好。

1. 选一个类别：它的缓解措施在目录中标为 L3，它的事故按你们自己的严重度标准属于轻微。Google 划的是同一条线：「对轻微事故」自主，「对关键操作」由人批准。
2. 先建降级，再谈升级：由机器强制执行的条件，满足时 L3 请求退回 L2 并呼叫人。
3. 建一个停止控制，能一次性暂停智能体所有进行中的操作并撤销 L3，并在演练日实际演练。
4. 加上智能体专属的速率限制和熔断器，让一个糊涂的智能体没法一个任务接一个任务地重启整个舰队。
5. 满足成熟度模型的 L3 标准，包括在至少 90 天内把智能体缓解的事故与人工基线对比。Google 没有公布过这样的对比；你将产出别人还没有的证据。

L3 → L4：没有公开的路径可循。如果你要尝试，L4 标准全部适用：一个枚举出的、可逆的告警类别，一份验证记录，带急停开关的持续监控，以及一位签署了风险接受书的具名负责人。对大多数团队来说，针对一个狭窄类别的 L3 就是上限，而且是合理的上限。

护栏

运维中最要紧的护栏与模型无关，而是智能体能用的那组凭证；记录在案的每一起事故都说明，这组凭证比任务更宽时会发生什么。

PocketOS：预发布任务，生产令牌。2026 年 4 月，一个 Cursor 智能体「据报运行 Anthropic 的 Claude Opus 4.6，在处理一项预发布环境任务时，通过 Railway 删除了 PocketOS 的生产数据库和卷级备份」，用的是「一个范围宽泛的 API 令牌」（AI 事件数据库）。OECD 的事件监测记录为九秒钟，以及约 30 小时的中断。未经一手来源证实的二手报道补充了机制：该令牌原本是为管理自定义域名而创建，后来在一个无关文件中被找到；备份就放在它所保护的那个存储卷上；事后 Railway 把 API 删除改成了 48 小时软删除。让它酿成灾难的每一个事实都属于环境：一个够得着生产的凭证，一个无法撤销的 API，以及位于爆炸半径之内的备份。

L4 一格中的另外两起事件指向同样的修复。Replit 的智能体在代码冻结期间删除生产数据库后，Replit 把开发和生产数据库分开了；其文档如今写明智能体「碰不到」生产环境（Replit 文档，截至 2026 年 10 月）。Kiro 事件之后，对 FT 关于起因和时长的说法持异议的亚马逊，增加了「生产访问须经强制同行评审」（亚马逊，2026 年 2 月 20 日）。案例研究完整讲述了 Replit 和 Kiro 两个案例，Kiro 的两方说法并列呈现。两家公司的修复都不是换个更好的模型，而是改变了什么能够触及生产环境。

从这些事件和 Google 的设计中，可以得出五条护栏，各自从所标级别起向上适用。

• 按环境限定的智能体身份（L1 起）。智能体有自己的身份；处理某个环境中的任务时，只持有该环境的凭证。Google 的页面说：「AI 智能体不会从第一天起就被授予完整的生产访问权限。」要审计智能体能读到的文件和环境变量里的凭证，而不只是你发给它的那些。按二手报道，PocketOS 的令牌是被找到的，而不是被发放的。
• 备份放在爆炸半径之外（L2 之前）。智能体能删除的任何东西，都不应能删掉你要拿来恢复的那份副本。
• 不可逆即不具备资格（L2 起）。没有撤销路径的操作，要么不进智能体的目录，要么置于两人批准之后。成熟度模型的风险上限已经排除了任何不可逆操作上的 L4；在运维中，要逐个工具地套用这条检验。
• 自动降级和停止控制（L3）。Google 的做法就是模板：「如果智能体请求 L3（高度自动化）执行，但检测到风险评分升高或生产状态异常，它会自动把请求降级为 L2（部分自动化），拦截执行，并把审批请求转给人类 SRE。」以及：「紧急『红色按钮』端点，让 SRE 能立即暂停所有进行中的智能体操作、阻止新操作，或在全舰队范围内撤销 L3 权限」。第 17 章《衡量成效，以及何时回退》会把它作为预先接好线的级别降级模型再次讨论。
• 速率限制与熔断器（L3）。「系统必须实施严格的、智能体专属的速率限制和自动熔断器。」一个被快速重复的错误操作，会比正在缓解的那起事故更大。

运维还继承了CI/CD 与发布一章讨论的工具链风险：一个持有特权令牌、又在读取他人所写文本的智能体，就是一条数据外泄通道，而告警载荷、工单和日志正是他人所写的文本。按级别划分的完整权限边界，以及每一行背后的事件，见安全、权限与爆炸半径。本站在人在回路、急停开关、撤销与可逆性和 DevOps 与 SRE 智能体中讲解了具体机制，并在智能体 CVE 是授权缺陷一文中详细论证了权限这一点。

指标

关于运维中 AI 的公开数字大多是计数：处理了多少事故、跑了多少次调查、省了多少工时。没有一个能告诉你一次攀升是否成功。请采用可信案例用过的指标，并给每个速度指标配上一个能发现智能体把事情弄糟的指标。

• 按事故类别、对照基线的 MTTM。Google 的 A/B 设计就是模板。如果做不了随机分组，就按类别做前后时间窗对比，并说明这一点。绝不要报告跨类别混合的单一 MTTM：一个快速清掉大量简单事故的智能体，可以拉低平均值，而困难事故丝毫没有改善。
• 对照影子对比的根因定位时间，像 BiAn 那样测量，并定义清楚起点和终点。
• 回测得出的 top-k 准确率，像 Meta 那样测量，每当模型或提示词变化时重新跑一遍。
• 抽样得出的编造证据率。随机抽取智能体写的事故报告，把其中引用的每一行日志、每一个指标和每一处变更与原始来源核对。FORGE 发现编造证据是最常见的失败。Zalando 以 15% 为阈值、从全量审校转为抽样审校，示范了如何把这个比率变成一项决定。
• 配对的稳定性指标：由智能体操作引发或加重的事故。统计被回退的缓解操作、之后出现进一步恶化的缓解操作，以及被人推翻的缓解操作。上面方框里没有一家厂商公布这个数字。
• 降级与停止控制事件。L3 请求退回 L2 的频率及原因。比率上升说明风险模型看到了什么；连续几个月为零，可能说明它根本没在看。

不要把「自主处理的事故数」或节省的工时当作成功标准。它们衡量的是量，不是结果；而唯一一组公开的节省工时数据，在不到一个月内从 20,000 多小时跳到 50,000 多小时，没有任何解释。停机统计也需要同样小心：本站的分析为什么十分之一的停机与智能体无关，说明了一个全行业的事故占比是如何被误读为关于智能体的证据的。关于错误预算如何约束智能体的操作，见 SLO 与错误预算。

反模式

• 为窄任务配宽令牌。PocketOS 的智能体在处理预发布环境任务，它的凭证却够得着生产环境。
• 把指令当边界。Replit 的代码冻结是在对话中宣布的。智能体凭证可以无视的冻结，只是请求，不是控制。
• 按一个自信的根因行事。一个既诊断又缓解、两步之间没有人或确定性检查的智能体，会把一次错误的猜测——ORCA-bench 和 FORGE 都表明这并不少见——变成一次生产变更。
• 靠调提示词修诊断。Kim 等人发现，单靠提示词工程修不好主要的根因分析失败，而更丰富的智能体间协议把通信失败最多减少了 15 个百分点。要改的是智能体能看到什么，并让人守住结果。
• 以为回滚总是安全的。撤掉中间修复的回滚，本身就是一起新事故。
• 只有自主，没有退路。没有自动降级、也没有经过演练的停止控制的 L3，就是少了些文书的 L4。
• 把量当结果报。「处理了数千起事故」说明不了其中有多少被弄得更糟。

当智能体本身成为事故时，本站的智能体事故响应介绍了如何应对。