文章探讨了AI智能体在运维中的兴起，旨在自动化事件响应、诊断根因并解决问题。它强调了应用上下文的重要性，并建议工程师在评估时注重调查能力、上下文质量和集成深度，将其视为能力增强工具。
译自：AI DevOps vs. SRE agents: Compare AI incident response tools
作者：Fahmid Kabir
如果你最近关注了关于运维的新数据，你可能会注意到一个新类别正在兴起：AI智能体，它们承诺接管事件干预、诊断根本原因，甚至自行解决问题。AWS 宣布了一个。Microsoft 也有一个。数十家初创公司正在创建它们。
坦率地说，术语使用混乱：AI DevOps工程师、AI站点可靠性工程（SRE）智能体、AIOps平台。这些是同一个东西吗？还是不同的东西？只是营销噱头？我花了一些时间深入研究这些系统实际做了什么、它们有何不同以及在评估它们时什么最重要。以下是我的发现。
为什么这个类别现在存在
让我们从这里开始：运维团队正在“溺水”。微服务架构的复杂性急剧增加。例如，一个用户的请求可能会触及三个云中的15个服务。当凌晨2点出现故障时，你需要查看来自六种不同工具的仪表盘，并匹配日志、指标和追踪，试图将它们全部连接起来，而Slack上则充斥着“网站是否宕机？”的消息。
传统监控让你看到实际发生了什么。它不告诉你原因，也不告诉你如何行动。正是这种“看到”和“行动”之间的鸿沟，催生了AI运维智能体。其卖点很明确：AI智能体无需你花费45分钟来找出问题发生的原因，而是在几分钟内建立连接，揭示可能出错的根本原因，并提出解决方案。有些更进一步，在你同意后实施修复。
这些智能体实际做了什么
抛开营销宣传，AI DevOps工程师遵循一套通用方案。它们连接到你的可观测性堆栈——Datadog、Splunk、CloudWatch以及你正在运行的任何工具——并消费遥测数据。它们与你的CI/CD管道和源代码控制软件集成，因此它们知道刚刚部署了哪些代码。它们与PagerDuty或ServiceNow等工单系统挂钩，以查看事件历史。如果出现问题，它们会在这些系统中关联信号。
因此，它们会创建一个时间线：这次部署发生了，延迟开始上升，错误开始出现，然后这个下游服务开始失效。它们绘制你的基础设施拓扑结构，以解释服务依赖关系，并理解调用链中的故障。更优秀的智能体能从过去的错误中学习。它们识别模式：“上次我们看到的错误特征，根本原因是环境变量配置错误。”它们将这些上下文浮出水面，以便你更快地修复问题。
一些智能体保持建议性——它们调查并推荐行动方案，但由人类来执行。另一些则倾向于自动化，在适当的防护措施下执行补救工作流。
AI DevOps工程师 vs. AI SRE智能体
主要区别在于营销和工作范围。SRE关注可靠性、可用性和错误预算。DevOps着眼于更广泛的交付生命周期。实际上，大多数AI运维智能体两者兼顾。它们管理事件——SRE的范畴——并改进管道或构建基础设施即代码（IaC）——DevOps的范畴。底层技术是相同的：基于运维数据、自然语言训练的机器学习（ML）模型，以及连接到你的工具链的接口和集成框架。不要担心供应商如何称呼其产品。评估它实际做了什么。
云提供商如何响应AI运维
AWS DevOps Agent于去年推出预览版，值得了解，因为它展示了云提供商如何看待这个问题。
AWS构建了一个智能体，可以关联CloudWatch、第三方监控工具和CI/CD系统中的数据。它绘制你的基础设施拓扑结构，跟踪部署，并在发生事件时生成建议。它与工单系统集成，在警报触发时自动响应。
该智能体对调查非常有用。它深入理解AWS资源——EC2实例、Lambda函数、EKS集群，整个产品目录——并且能够追踪它们之间的关系。
有一个区别：AWS考虑的是资源，而不是应用程序。它知道你有一个带有特定Pod的Kubernetes集群。但它本质上并不知道这些Pod构成了你的结账服务，这与你的库存服务是不同的，后者有不同的所有者和不同的风险承受能力。
这种以资源为中心的视图决定了智能体可以安全地做什么。如果没有明确的应用程序边界，自动化修复会带来风险。如果扩展一个服务级联到另一个服务怎么办？如果回滚影响了你不想触及的组件怎么办？
这就是为什么AWS DevOps Agent强调调查和建议，而不是自动化操作。这是一个深思熟虑的设计选择，而不是局限。Microsoft的Azure SRE Agent也采用了类似的方法。
真正的区别：应用程序上下文
上下文。这是我认为最重要的一点：智能体操作的抽象程度。那些在基础设施层面操作的智能体知道它们拥有哪些资源以及它们之间的关系。它们擅长回答“发生了什么”，但对于“我们应该怎么做？”则非常谨慎。
一些平台还提供明确的应用程序边界作为首要概念。如果一个智能体知道这些容器、这个数据库和这些队列，每个都形成一个具有明确所有权的应用程序，那么对其进行操作会更容易；它可以更容易地限定操作范围。回滚保持在安全限制内。扩展决策不会波及不相关的服务。这解释了从建议性到自动化之间的范围。没有上下文的自动化是危险的（反之亦然）。它创建了清晰的边界，并允许智能体随机应变。
工程师在评估智能体时应考虑什么
如果你正在评估AI运维智能体，以下是我会考虑的几点：
- 从调查开始，而不是自动化。 在你赋予智能体任何更改权限之前，让它证明它理解你的环境。逐步建立信任。
- 上下文质量至关重要。 这些智能体的效能取决于它们能够访问的数据和结构。良好标记的资源、清晰的服务所有权和明确的应用程序边界能显著提高智能体的效率。
- 集成深度差异很大。 一些智能体与流行工具深度双向集成。另一些则连接较浅，限制了它们能看到和能做的事情。针对智能体如何与你的特定堆栈配合工作提出深入问题。
- 这并不能取代专业知识。 AI智能体增强了工程能力。它们不能替代你对系统的理解、做出判断或设计可靠性。将它们视为倍增器，而不是替代品。
未来走向
这个类别正在快速成熟。来自云提供商、可观测性供应商和专注的初创公司的竞争：结果是快速创新和价格下降。是的，这对工程团队来说机会是真实存在的。一个好的智能体可以减少解决问题的平均时间，减轻随叫随到（on-call）的负担，并让工程师能够专注于构建弹性系统，而不是疲于救火。
但炒作也确实存在。评估智能体不应基于其演示文稿，而应基于它们在你的环境中、在实际上下文中的表现。现在认真进行实验的团队，将会在这些工具成为运维堆栈标准部分时处于最有利的位置。
在DuploCloud，我们正在积极构建旨在执行真实DevOps和云运维工作流的AI智能体。在我们的沙盒中，你可以与专门构建的智能体进行交互，这些智能体在云基础设施、Kubernetes管理和可观测性方面运行——在真实环境中诊断问题、应用更改并自动化日常操作。
