AI 辅助故障响应：为你的值班 Agent 提供运维手册

在 2025 年，工程组织的运维琐事上升到了 30% —— 这是五年来的首次增长 —— 尽管在 AI 工具上的投入创下了纪录。原因并非 AI 失败了。原因在于团队部署 AI Agent 时，并没有采用像对待人类值班工程师那样严格的标准：没有 Runbook，没有升级路径，没有影响范围（Blast-radius）限制。Agent 可以对日志进行推理，但没有人告诉它它被允许做什么。

“能够诊断的 AI”与“能够安全缓解故障的 AI”之间的差距，并不是模型能力问题。这是一个系统工程问题。解决这个问题需要 SRE 团队已经应用在人类操作员身上的同样纪律：结构化的 Runbook、分层权限和强制性的升级点。

尴尬的中间地带：为什么 AI 增加了工作量而不是减少了工作量

承诺是简单直接的：AI Agent 将对警报进行分级、关联日志并执行修复 —— 从而缩短平均修复时间（MTTR），并将工程师从凌晨 3 点的传呼中解放出来。在实践中，69% 的 AI 驱动决策仍需要人工验证。团队增加了一个 AI 层，但并没有移除手动层，创造了从业者所说的“尴尬的中间地带”。

发生这种情况是因为大多数团队将 AI 事件响应视为一个分类问题：给 Agent 喂警报，让它弄清楚该做什么。但事件响应不是分类。它是在时间压力下的一系列受限动作，每一个动作都有其影响范围，每一分钟的停机都在耗费资金。

受客户影响的事件同比增长了 43%，每起事件的损失约为 80 万美元。当数据库正在崩溃时，一个还在消耗 Token 推理可能出了什么问题的 Agent 不仅毫无用处，反而是一种干扰。

解决方法不是“更好的模型”。解决方法是给 Agent 提供你给新值班工程师同样的东西：一份 Runbook。

Agent 的 Runbook 到底长什么样

人类的 Runbook 是半结构化的文档：“如果你看到警报 X，检查仪表盘 Y，然后运行命令 Z。”它们假设人类可以在每一步行使判断。Agent 的 Runbook 需要更加明确，因为 Agent 没有机构记忆，也没有关于什么“看起来很奇怪”的直觉。

一个有效的 Agent Runbook 是一个具有三个属性的动作有向图：

• 类型化的输入和输出：每一步都精确指定它消耗什么数据（指标查询、日志模式、服务名称）以及它产生什么。不要有自由文本形式的“调查情况”步骤。结构化输出将 LLM 调用转变为更接近类型化函数调用而非文本生成任务的东西，这极大地降低了幻觉风险。
• 明确的决策点：分支条件是具体的阈值，而不是感觉。“如果错误率在 3 分钟内超过 5%”是一个决策点。“如果情况看起来很糟”则不是。
• 每步的限定权限：每个动作都声明它涉及哪些基础设施以及需要什么级别的审批。日志查询自动运行。重启 Pod 需要通知。数据库故障转移需要明确的人工审批。

有用的 Agent 和危险的 Agent 之间的区别不在于智能，而在于约束。

三级自治模型

最有效的团队并不是在“完全自主的 Agent”和“只写摘要的 AI”之间做选择。他们使用的是一种直接对应风险的分级自治模型：

第 1 级 —— 仅建议。 Agent 摄取警报，收集上下文（最近的部署、日志异常、指标趋势），并在事件频道中发布诊断结果和建议操作。人类执行所有操作。这是每个团队都应该开始的地方。它在不危及生产环境的情况下验证了 Agent 的推理质量。

第 2 级 —— 需审批的执行。 Agent 提出具体的行动建议 —— 重启服务、扩展副本、回滚部署 —— 并在 Slack 或你的事件工具中以审批卡的形式发布。值班工程师点击“批准”或“拒绝”。Agent 执行批准的动作并监控结果。如果修复措施在定义的窗口期内没有改善指标，它会自动回滚并升级。

第 3 级 —— 有条件的自治。 对于一小部分预先批准、低风险的 Runbook，Agent 独立行动。在凌晨 3 点重启一个在 5 分钟内崩溃循环了三次的无状态服务，不需要人工参与。但第 3 级的范围应该是刻意缩小的，并且只有在安全指标证明其长期表现一致且低风险时才扩大。

关键的洞察是，这些级别不是 Agent 的属性。它们是动作的属性。同一个 Agent 在清理缓存时可能处于第 3 级，在重启服务时处于第 2 级，而在触及数据库的任何操作时处于第 1 级。风险分级是针对每个动作的，而不是针对每个 Agent 的。

护栏架构

护栏不是可选的安全表演 —— 它们是使 Agent 驱动的事件响应变得可行的承重结构。在生产环境中有效的模式有四个层级：

身份和访问控制。 每个 Agent 都有自己的服务账号，具有基于角色的访问权限（RBAC），并限定在特定的工具和基础设施中。Agent 永远不会直接访问基础设施 —— 它通过安全的工具 API 进行交互。凭据是短期的且自动轮换。这与人类操作员的最小特权访问原则相同，只是应用于自动化系统。

影响范围检查。 在执行任何修复之前，Agent 会评估影响范围。在拥有 50 个 Pod 的部署中重启一个 Pod，与重启唯一的 Pod 是不同的。Agent 必须理解拓扑结构 —— 哪些服务依赖于当前服务，它处理流量的百分比是多少，是否存在冗余。如果没有拓扑感知，即使是“安全”的重启也可能演变成级联故障。

Agent 行为的断路器。 如果 Agent 反复采取相同的动作，如果它生成了异常的 API 调用模式，或者它的信心评分降至阈值以下，断路器就会跳闸并升级给人类。这捕捉到了 Agent 进入修复循环的故障模式 —— 重启一个立即再次崩溃的服务，一遍又一遍，同时忽略了根本原因。

强制性的审计追踪。 每一个决策、Agent 考虑的每一项证据、它采取或提议的每一个动作 —— 所有这些都会以事件后回顾（Post-incident review）可以消耗的格式记录下来。这不仅仅是为了合规。这是你调试 Agent 本身的方式。当 Agent 做出错误判断时，你需要该会话的完整执行记录，因为 Agent 事件通常是由分布在多个步骤中的分散原因引起的，而不是单一的局部故障。

为什么 “调查此告警” 是一个危险的提示词

在部署 AI 进行事件响应（Incident Response）时，最常见的错误就是给 Agent 一个非结构化的指令：“这是一个告警，找出问题并修复它。” 这等同于给一个新员工 root 权限，然后说 “网站挂了，祝你好运”。

非结构化提示词会导致三种特定的故障模式：

• 幻觉诊断。如果没有受限的调查路径，Agent 会生成听起来合理但却是虚构的根本原因。它可能会自信地报告内存泄漏，而实际问题是负载均衡器配置错误。矛盾的是，更大的上下文窗口反而会让情况变得更糟 —— 更多的数据意味着更多发现虚假相关性的机会。
• 不安全的操作。一个自由思考 “该尝试什么” 的 Agent 可能会认为删除数据库缓存、杀死进程或修改安全组是合理的下一步。如果没有明确的权限边界，Agent 的动作空间是无界的。
• 危机期间的时间浪费。没有运行手册（Runbook）的 Agent 会把 Token 花在探索上 —— 查询无关的指标、检查无关的服务、推敲可能性而不是遵循已知的诊断路径。它花在探索上的每一分钟都是停机时间。

解决方案是在 Agent 遇到问题 之前，将你最常见的事件类型映射到结构化的运行手册中。审计你最近的 50 次事件。识别出前 10 个模式。对于每个模式，定义诊断步骤、决策标准和允许的修复操作。然后把这些运行手册交给 Agent，而不是给它开放式的权限。

衡量你的 Agent 是否真的有帮助

显而易见的指标是 MTTR（平均恢复时间）的降低，部署了结构化 Agent 运行手册的团队确实看到了实际的收益 —— 对于符合预定义模式的事件，解决时间缩短了 30% 到 70%。但仅凭 MTTR 无法反映全貌。

还需要同时追踪以下指标：

• 诊断准确率：Agent 的初始诊断中有多少比例与事后回顾（Post-incident Review）中确定的实际根本原因一致？如果这一比例低于 70%，那么 Agent 增加的是噪音而非信号。
• 建议采纳率：当 Agent 在 Level 2 提出操作建议时，值班工程师有多大比例会批准？采纳率低意味着 Agent 的运行手册与你团队的实际运作方式不匹配。
• 自主解决率：在无需人工干预的情况下，Agent 在 Level 3 解决了多少比例的事件？大多数团队的第一年目标是 10–30%。过早追求更高的比例通常意味着风险分类过于宽松。
• 值班满意度：如果工程师报告说 Agent 创造的工作（验证错误的建议、清理错误的操作）比它节省的还要多，那么无论 MTTR 数据如何，这次部署都是负向的。

反馈循环与指标同样重要。人工修正 —— 即工程师覆盖 Agent 操作的情况 —— 应该带上记录好的推理过程反馈给系统，成为未来 Agent 版本的测试用例。

从严开始，逐步扩展

在事件响应中从 AI 获得实际价值的组织都有一个共同点：他们从狭窄的范围和高度的约束开始，然后有意识地扩展。他们没有部署一个无所不知的 Agent 并寄希望于一切顺利。他们选择一个服务、一种事件类型、一本运行手册。他们在咨询模式（Advisory Mode）下运行 Agent 数周，将其诊断结果与人类诊断进行对比，并调整运行手册，直到采纳率稳定在 80% 以上。

只有在那之后，他们才针对该特定运行手册转向 Level 2。在经过数月清白无误的执行后，他们才会考虑在那个范围内对风险最低的操作尝试 Level 3。

这很慢。但这也是唯一有效的方法。另一种选择 —— 部署广泛的 AI 自动化并清理烂摊子 —— 会让你陷入尴尬的境地：尽管拥有 “AI 驱动” 的事件管理系统，你 78% 的工程师仍会将 30% 的时间花在手动琐事（Manual Toil）上。

给你的 Agent 一本运行手册。先从只读模式开始。在它赢得信任时再给它晋升。工具已经准备就绪。大多数团队缺乏的是纪律。