Azure SRE Agent：Agent 自动化运维，人类做决策

如果工程师能把时间花在构建和优化系统上，而不是维护它们，会怎样？

凌晨 3 点，告警响起。SRE 在多个仪表盘和诊断工具之间来回切换，努力判断把他叫醒的是不是真实事故、自己是不是处理这件事的合适人选，或者是否需要叫醒其他人。他在监控工具、部署历史、事故系统和团队 runbook 中翻找——还可能追着一条关于根本原因的错误理论跑——最终无法足够快地响应，以阻止更多客户受到影响。

或者想象一下，当 SRE 加入事故桥时，Azure SRE Agent 已经分析完了监控数据、找出了根本原因，并准备好了修复方案供审批和部署。

Azure SRE Agent 的首席工程师之一 Sanchit Mehta 告诉 The New Stack："[Azure SRE Agent] 开始分析遥测数据，并关联爆炸半径、部署变更、最近变更、最近上线等因素，试图告诉工程师'好的，这就是导致问题的原因。'"它甚至会越来越频繁地主动为那个修复方案创建 PR。

这种支持在正常工作时间同样有用。在 InEight，关联数以万计 Azure 资源的遥测数据可能需要数天甚至数周。当一份支持工单报告性能下降但没有指明具体产品时，工程师必须确定公司 14 款产品中哪一款受到了影响，然后检查多个可观测性和可靠性工具。

InEight 分享说，在他们首次使用 Azure SRE Agent 处理事故期间，Agent 迅速识别了受影响的产品、将性能问题追溯到其根本原因，并建议扩展 Redis。而 DevOps 团队此前一直在考虑扩展应用服务作为临时修复方案。

主动介入，生产运行中

在微软，这种帮助正在成为新常态。超过 3000 个服务团队已经在使用 Azure SRE Agent 调查问题、执行根本原因分析、响应事故、修复代码、启用自动缓解、支持主动检测、分析数据和大规模报告。Azure SRE Agent 已在微软内部处理了超过 180 万次事故，其中许多在几分钟内就得到了缓解。

该团队还使用 Azure SRE Agent 来开发和改进服务本身，为代码审查、部署、评估和监控构建了自定义 Agent。这种 Mehta 所称的"Agent 驱动的工程"方法，让团队能够利用 AI 模型的持续进步。这包括主动发现问题，比如影响部署的配额问题，并自动创建支持工单来解决它们。他说，Agent 最近在变更到达第一个区域时就识别出了导致综合测试失败的变更的根本原因。

"它说：'好的，这是一个上游 PyPI 包破坏了你的依赖；你需要为它添加测试；你应该立即回滚；这是你修复这个问题的方法。'"

Mehta 说，这类主动监控很难用确定性查询来处理。"你需要一定程度的智能来判断大型生产负载何时正在部署，以及它是否有可能导致降级。"

对于一些内部团队，超过一半的事故由 SRE Agent 自主管理，不需要任何人工干预，Azure SRE Agent 的首席项目经理 Shamir Abdul Aziz 补充道，因为这些是他所说的"安全"操作和缓解措施：重启、扩展或回滚服务，或者客户提出的升级变更单请求。

"人类做了治理、制定了指南、给 Agent 一些指导，然后它进入自动模式完成整个工作流，"Abdul Aziz 说。

Agent 已准备就绪

SRE 们已经在重复性苦差事中溺水，而编码 Agent 又增加了工作负载。Azure SRE Agent 的首席 PM 之一 Vyom Nagrani 告诉 The New Stack，Agent 运维现在已经足够强大，可以提供帮助。

"随着代码越来越多地由 Agent 编写，需要另一个 Agent 来运维它，"Nagrani 说。"但为什么要等？如果 Agent 能够管理其他 Agent 编写的代码，为什么不能管理人类编写的代码？"

"随着代码越来越多地由 Agent 编写，需要另一个 Agent 来运维它。"

"推理循环已经成熟到 Agent 现在可以自动开始解决许多这类复杂问题，尤其是在关联多个数据源方面——这一直是人类最难做的事情，"Nagrani 说。

然而，强大的模型还不够，自建的自动化不会具备平台所能提供的生产级治理、验证、评估、遥测和控制。

最先进的技术已从提示工程发展到上下文工程——将 AI 根植于你的基础设施、代码和机构知识——现在又发展到 Harness 工程。"这正是让你能够大规模运行 Agent、控制它们并治理它们的东西，"Abdul Aziz 说。

"当你把所有这些能力与验证、审计、评估、从系统中获取真实遥测和指标的能力结合起来时——Agent 声称它做了某件事——你就能够验证 Agent 的说法，"Abdul Aziz 说。

你不再面对一个无法解释其决策的非确定性黑箱，而是可以追踪和学习 Agent 的推理过程，这样你就可以一次性纠正错误，而不是反复纠正。"这就是为什么企业现在愿意采用它，"Abdul Aziz 说。"因为当你尝试同样的事情十次时，你会得到相同的输出。"

"你不会简单地打开 Agent、给它完全访问权限、让它解决一切问题。"

在构建了两年可信赖、可审计、可验证的企业级系统之后，云原生 SRE 的下一步可以是具有自主能力的 Agent 运维——但你仍然需要知道如何采用它，Abdul Aziz 警告说。"你不会简单地打开 Agent、给它完全访问权限、让它解决一切问题。"

上下文与连接

Azure SRE Agent 为 Azure 构建，但不受限于 Azure 平台。该 Agent 提供对 Azure 服务的原生访问，如 Azure Monitor、Application Insights、Log Analytics 和 Azure Resource Graph。将 Agent 连接到你的订阅、遥测数据和源代码，就赋予了它理解你工作方式所需的运维上下文和机构知识。

在 Azure 之外，Azure SRE Agent 通过托管连接器与 Azure DevOps 和 GitHub 集成，还有 MCP 连接器，可以访问 Google Drive、Confluence、Cursor、Claude Code 等外部知识源及其他第三方系统。

把所有这些知识放入代码库中的 Markdown 文件，连同 Agent 在你的系统上（包括第三方和本地服务）采取行动所需的技能和工具。这给了你 Agent 可以版本化管理、审查、测试、重用和更新的产物。

当你想定制如何处理事故——检查什么、按什么顺序检查、发布什么，甚至如何格式化报告——你可以创建一个自定义 Agent，可以利用现有 runbook，也可以与 Agent 一起处理事故然后保存那个技能。使用 Agent 来改进 Agent 是让 Azure SRE Agent 越用越有用的捷径。本质上，保存 Agent 在事故期间学到的东西有助于改进它们未来的响应。

指南与护栏

治理涵盖身份、基于角色的访问控制（RBAC）和工具访问策略。这些控制决定了哪些操作被允许、阻止或需要逐步审批，以及 Agent 是自主运行还是需要人工审查。

使治理既灵活又强大的是钩子，基于提示或确定性命令，在工作流的不同阶段触发，捕获边缘情况，例如允许 Agent 删除 SQL 数据库中的索引但绝不能删除表。

指标向你展示治理是否有效。新的实时报告显示缓解时间、工具可靠性、Agent 自主行动的频率以及每个结果的成本，一目了然。InEight 的指标很有代表性：事故调查时间和构建失败分类时间均减少 80%，Bug 调查所需工作量减少 67%，成本减少 84%。

要获得这些结果，你需要触发器来自动启动 Agent，而不是等待人工打开聊天窗口。

将技能和自定义 Agent 绑定到特定告警类别，以便它们能够首先响应事故。通过管道、Webhook 或工作项启动 Agent，以自动化交付工作流。安排定期检查、审查和审计，并让 Agent 自动更新它们的产物。

Agent 运维；你保持控制

通过减少重复性任务和技术性苦差事，Azure SRE Agent 让工程师能够专注于更有趣和更有创新性的项目。正如采用网站可靠性工程有一个众所周知的成熟度模型一样，你不会直接跳到让 Agent 而不是人类来处理运维。当你给 Agent 关于你的基础设施的上下文后，你可以开始将它们用于调查。

"如果你给 Agent 对你的源代码、遥测数据和资源的读取权限，达到根本原因的时间会从小时或天缩短到分钟，"Abdul Aziz 指出。"每个客户都从那里开始。"

一旦你对得到的答案满意，你可以在仍需审批个别步骤的同时给 Agent 更多权限，他说。"一旦你理解了问题，修复就很容易了。通常是更改配置、写一段代码或重启服务。"

"一旦你理解了问题，修复就很容易了。通常是更改配置、写一段代码或重启服务。"

当你扩展到其他运维任务时，在授予更多自主权之前完善 Agent 的产物、指标和治理：Abdul Aziz 建议道："比如当我们知道某个版本有回归时回滚发布、重启服务、删除 SQL 表上的损坏索引，或扩展服务。"

对于更复杂的问题，Agent 可以交付整个修复方案，准备供审批。管理 Azure SRE Agent 产品的 Azure SRE Agent 每晚查看异常、错误、事故、Teams 对话、电子邮件和 GitHub 问题，然后吐出 PR。

通过让 Agent 部署、测试、测量并将结果包含在 PR 中来避免代码审查瓶颈。使用持续评估来构建一个准确遵循你现有工作流的自我学习系统。

"Agent 可以自我改进，因为 Agent 在不断学习，"Abdul Aziz 说。"你可以配置定时任务来识别哪些评估分数较低，并自动改进自定义 Agent、自定义技能，甚至你的知识文档——因为知识管理也是一种苦差事。Agent 可以自动化所有这些。"

正确的起步方式

Azure SRE Agent 现在提供 30 天试用体验，没有常开费用。通过从一些常见错误中学习来充分利用它：

这不是魔法！打开 Agent 并不意味着你不用再做 DevOps 了。不要把它当作聊天机器人，也不要只把它连接到你的可观测性系统。你需要给 Agent 它需要的上下文、做好工作所需的工具，以及告诉它何时行动的有意触发器。否则，它可能会在低价值工作上花费精力，或者生成与你环境不符的输出。

不要把自己限制在 Agent 开箱即用的功能上：自定义 Agent 技能、工具、连接和逻辑以适应你组织的工作方式，并为特定任务构建自定义 Agent。

不要用 Agent 来做一行代码就能完成的工作：用它们来探索确定性的结构化数据以发现异常是一种昂贵的浪费，只会用 Agent 自己能写的那行代码来填充上下文窗口。"编排，不要计算，"正如 Nagrani 所说。如果你被警报淹没，用自动化来过滤噪音，只将需要智能分析的警报发送给 Agent。

不要固守你一直以来的做法或照搬你的组织结构图：最有效的 Agent 对系统有完整的了解，所以它们需要所有上下文，即使它跨越两个团队。这可能意味着跨越边界、协调谁有专业知识谁需要授予访问权限，或者重新思考组织的工作方式。

"如果 Agent 有正确的上下文，它们会最小化苦差事，真正让运维成本更低，"首席产品经理 Deepthi Chelupati 指出。这样你就能更快地行动、更主动，让工程师有更多时间创新，减少他们担心的维护工作。

立即开始：sre.azure.com