AgentSRE：用于在AWS上实现自主故障修复的可组合AI代理。

耗尽SRE整日精力的事件处理循环

站点可靠性工程师的大部分时间都耗费在这样一个重复的循环中：警报触发，有人着手处理，找出根本原因，实施修复措施，随后关闭工单。每个步骤都需要时间，因此问题解决的平均时间（MTTR）可能从几分钟延长到几小时。随着云环境规模的扩大，这种手动操作流程便成了瓶颈。

AgentSRE是AWS上专为解决这一瓶颈而设计的自主式事件管理平台。它通过可组合的AI代理将事件从检测阶段处理到解决阶段，这些代理各自专注于不同类型的修复任务。该设计将问题解决视为一系列协同工作的小型代理，而非单一的自动化脚本，具体原因如下所示。

典型事件的处理过程

想象这样一个CloudWatch警报：它检测到数据库的读取延迟过高。值班工程师会收到通知，打开控制面板，查看各项指标并阅读慢查询日志，最终发现是缺失的索引导致了全表扫描。于是他们编写并执行CREATE INDEX语句，确认问题已解决后更新工单。

所有这些步骤都是必要的，但其中大部分属于机械性操作。工程师并非在解决新的难题，而是在遵循熟悉的诊断与修复流程，而这无疑会耗费大量时间。在不同界面之间切换、操作控制面板以及手动执行查询，都会在故障处理时间过长时进一步增加工作负担。

如果能够理解诊断模式并明确修复方案，整个流程就可以实现自动化，但仍需有人来审批变更。AgentSRE将整个事件生命周期分为五个阶段：检测、调查、决策、执行和关闭。

其独特之处在于执行方式的组织形式。原本那种试图尝试所有可能修复方法的庞大脚本已被按类别划分的专用代理所取代：用于SQL修复的数据库代理，以及用于处理消息问题的队列代理。每个代理都是独立的状态机，因此可以单独构建、测试和发布，而且新增的代理类型无需修改现有代理即可使用。可组合性是该平台的核心设计原则，它体现了实际运维团队如何将问题分配给不同专家处理，同时也使得平台能够随着新的修复方法的出现而不断发展。

架构概览

该平台完全基于AWS托管服务运行，这降低了运营成本并实现了自动扩展。

在架构图中，一切从左侧开始：CloudWatch警报触发事件驱动的流程。SNS主题负责分发通知，相应的Lambda函数会创建ServiceNow工单，而AWS DevOps Agent则会自动开始调查。调查结果会显示在React前端界面中，该界面分为聊天、工单和报告三个板块。底部的三种拓扑视图则向操作人员展示每起工单的可视化情况。因此，一个图表便涵盖了从检测到可视化的整个流程，且没有任何环节需要人工干预。

检测

第一个信号是 CloudWatch 发出的异常警报，例如读取延迟过高、连接数耗尽或不断增长的死信队列。该警报会被发布到 SNS 主题中，进而触发相应的 Lambda 函数，后者会立即在 ServiceNow 中创建工单，并启动 AWS DevOps Agent 的调查流程。此阶段完全不需要人工干预。

调查

AWS DevOps Agent 是一项托管服务，能够自主执行调查工作。它会查看 CloudWatch 指标、RDS 性能分析数据以及慢查询日志，根据警报内容自行判断哪些数据是重要的。随后，一个异步运行的 Lambda 函数会收集这些调查结果并将其写入 DynamoDB。

Amazon Bedrock运行Claude后，会将分析结果汇总为简短的根本原因说明、影响评估以及推荐的缓解措施。该摘要显示在调查视图的顶部，完整分析内容则位于其下方。

截图展示了调查结果视图，首先是摘要，随后是详细内容。

决策与管控

在应用任何更改之前都会进行安全检查。防护机制会逐一审查每条SQL语句，拒绝那些具有破坏性的操作，比如删除表或在没有WHERE子句的情况下删除行。此类操作会被赋予风险等级，并提交给人工进行审批。确认对话框会列出具体的命令、目标资源以及回滚方法。

设置人工审核步骤是有意为之。虽然完全自动化非常高效，但生产环境中的更改仍需人工判断，尤其是那些风险较高的操作。

上述对话框显示的是操作员在需要确认修复方案时所看到的内容。

将修复任务分配给合适的处理人员

一旦修复方案获得批准，协调器会对其类型进行分类，并将请求发送给对应的处理人员。这正是组合性优势的体现。

该图详细展示了修复流程。当有人批准解决方案后，协调器便会接管并执行三项任务：确定根本原因、应用SQL安全防护措施，同时将请求转交给相应的专家，并在DynamoDB中记录操作日志。之后流程会分为两个分支。在数据库端，Amazon Bedrock AgentCore上的LangGraph状态机会与AI分析工具一起验证SQL语句，通过VPC中的网关Lambda将其作用于数据库，最后将结果连同审计记录一起写入Jira。在队列端，处理诸如清空死信队列或将消息发回原处等任务时也采用相同的方式。

没有哪个代理会直接访问资源。每个代理都会调用网关工具：数据库代理使用用于连接RDS的网关函数，而队列代理则使用用于执行SQS操作的网关函数。这样的设计使得各个代理的规模保持较小，同时实现了对资源访问的控制与追踪。无论哪个分支的处理完成，共享的结果处理流程都会将结果存储在DynamoDB中，在ServiceNow上添加备注，关闭相关工单，并更新拓扑结构，从而确保无论哪个代理负责处理，每个问题都能得到一致的处理结果。

分类机制的工作原理

实现这一功能的智能组件位于协调器中。当AWS DevOps Agent完成处理后，它会以自然语言生成根本原因分析报告，协调器会读取该报告并在任何代理开始运行之前为其分配相应的修复类别。

分类过程分为两步。首先，结构化解析器会在分析结果中查找预定义的修复模块，该模块会说明修复类型、目标资源以及计划采取的操作。如果找不到此类模块，协调器则会转而使用 Amazon Bedrock 上的语言模型分类器，该分类器会读取自由格式的故障原因以及原始报警上下文，从而确定分类类别。报警上下文有助于将症状与对应的修复措施联系起来。较高的读取延迟表明需要添加数据库索引，连接数耗尽则意味着需要终止阻塞查询，而不断增长的死信队列则提示需要清理或重新处理这些消息。

一旦类别确定，路由规则就会是确定的：数据库任务会发送给数据库处理代理，队列任务则发送给队列处理代理。将分类与执行分离的做法使得后续添加新类别变得十分简单，因为只需为新的类别对应一个新的处理代理，路由逻辑无需更改。

两个生产环境处理代理

AgentSRE 提供了两个生产环境处理代理，每个代理都专为某一类修复任务设计。它们均在 Amazon Bedrock AgentCore 上以容器化形式运行，并采用相同的内置架构：由若干定义明确的节点构成的 LangGraph 状态机，每个节点都配有监控机制，可记录其执行时间和结果。

数据库处理代理

该代理负责处理所有基于 SQL 的修复任务。其设计遵循真实的数据库操作工作流程，以状态机形式组织，并通过路由层根据当前状态决定下一步的操作。

当收到请求时，代理首先从相关事件中获取目标数据库以及建议的SQL语句。接下来是验证阶段，由运行在Bedrock上的AI分析器检查该语句，确认其格式正确且安全。这一语义检查会与调度器已设置的确定性防护机制一起发挥作用，从而使有缺陷或危险的查询面临第二道防线。

验证通过后，代理并不会直接执行该语句，而是调用VPC内的网关Lambda函数，该函数通过IAM身份验证连接到目标RDS实例。这样一来，数据库凭证和网络访问权限都被限制在单个受控组件中，而代理本身由于无需直接连接数据库而保持轻量级。

同一个处理流程可应对多种问题。该代理能够创建缺失的索引以解决读取延迟，终止那些持有锁并耗尽连接资源的阻塞查询，或根据需要执行其他修复指令。之后它会记录处理结果，包括受影响的行数及执行时间，并创建相应的 Jira 记录以及完整的审计日志。由于所有 SQL 操作都由相同的验证、执行和审计流程处理，因此要实现新的数据库修复方式无需更改该代理的结构。

队列代理

队列代理负责处理消息相关问题，最常见的情况是已堆积大量失败消息的死信队列。它同样遵循验证、执行和审计这三个阶段，但采用了针对队列的特定逻辑。

验证机制阐明了为何安全性对自主队列代理而言至关重要。在采取任何可能造成破坏的操作之前，它会先通过检查ARN格式，再向其网关工具查询队列属性，来确认目标队列确实为死信队列。如果该队列并非死信队列，代理会立即停止操作并报告安全故障，而不会冒险使用正常的生产队列。清除错误的队列会毁掉正在传输中的消息，因此必须进行专门的验证以避免此类后果。

验证成功后，会执行以下两种操作之一。清除操作会将死信队列中所有累积的消息全部删除，这些消息被视为无法恢复的无效数据。重新发送操作则将这些消息送回源队列以便再次尝试处理，同时设有可配置的速率限制，以避免下游消费者被大量消息淹没。此外还提供状态检查功能，可用于监控正在进行的重新发送操作。

与数据库代理类似，队列代理也会通过自身的网关函数来处理所有操作，该函数负责执行boto3 SQS调用，并记录所有操作以供审计。它既可以接收结构化请求，也可以接收普通文本，并能从中提取出相应的操作类型和队列ARN。

设计上的独立性

这两个代理彼此之间互不知情。每个代理都拥有针对自身领域定制的状态机、网关工具和验证机制。只有协调器能够看到这两个代理，而它的功能仅限于对信息进行分类和路由。

这种独立性正是组合性在实践中的体现。用于重启容器、轮换凭证或更改扩展策略的第三个代理也会遵循相同的流程：通过LangGraph状态机完成验证、执行和审计操作，并配备自己的网关工具。它会在协调器中以新的类别注册，而原有的代理则不会受到影响。系统的扩展是通过添加新组件来实现的，而非对现有组件进行修改。

报告与关闭

任务完成后，代理会报告操作是否成功、更改了多少行数据以及耗时多少。结果会被保存到DynamoDB中，并作为工作记录添加到ServiceNow的事故处理单中，若操作成功则无需进一步输入即可关闭该工单。所有步骤都会被记录下来，从而形成从首次报警到问题解决的完整审计轨迹。

操作界面

虽然自动化工具负责执行任务，但操作人员仍需要一个地方来监控、指导并了解整个过程。AgentSRE拥有一个使用React构建并托管在AWS Amplify上的定制网页界面，可作为整个事故处理生命周期的统一操作平台。该界面通过Microsoft Entra ID实现单点登录，由组织的身份验证服务来控制谁有权使用操作控件。该界面分为三个区域，各自满足不同的需求。

聊天功能

聊天功能是 AWS DevOps Agent 的对话式前端界面。操作员可以用通俗的语言询问特定数据库的运行状况、是否有警报触发以及问题调查的进展。输入事件编号即可直接在聊天界面启动全面调查。该界面能够保留多条消息之间的对话上下文，并通过后台重试来应对响应缓慢的情况，从而确保操作员得到答案而非错误提示。

截图显示的是聊天界面。

事件

“事件”板块是用于日常操作的仪表板。每个事件都会显示其状态、是否已有人员进行调查以及是否已应用修复措施。操作员可从此处启动调查，查看根本原因、了解系统拓扑结构并开始采取修复措施。修复操作只需点击一次，随后会弹出确认对话框，在执行前显示具体的更改内容。

这是事件控制面板。

报告

报告功能可提供所有事件的各项分析数据：调查次数、解决率、平均修复时间，以及按优先级和资源分类的统计信息。它能够将单个事件的数据转化为随时间变化的运营洞察。

报告视图如上所示。在调查视图中，界面还提供拓扑可视化功能（详见下文），该功能可将复杂的分析结果转化为交互式图表，便于一目了然地了解情况。

与ServiceNow的集成

一个无视现有IT服务管理系统的独立平台只会带来更多问题而非解决问题。因此AgentSRE直接与ServiceNow集成，这样它处理的每个事件都会反映在运营团队已依赖的记录系统中。

在整个生命周期中，信息会双向流动。当 CloudWatch 警报触发时，负责警报处理的 Lambda 会自动在 ServiceNow 中创建一个工单，预先填入警报详情、优先级和类别等信息，同时会先查找已存在的未处理工单以避免重复。这样从一开始工单就已存在，无需任何人手动创建。

随着工单的处理进展，AgentSRE 会向工单中添加更新内容。调查结果会以工作笔记的形式记录下来，这样查看工单的任何人都能在具体上下文中看到完整的根本原因分析。当修复措施执行完毕后，其结果——包括所采取的行动、最终结果以及时间戳——也会作为另一条工作笔记存入。一旦修复成功，平台会将工单状态改为“已解决”，并附上解决说明。

这样就在 ServiceNow 中形成了完整的、可审计的记录，完整呈现了整个自动化工作流程。团队可以继续使用他们熟悉的工具进行工作，而自动化则承担繁重任务；遵循现有流程使得该平台能够被企业采用，而非成为需要人们另行学习的独立系统。

这是平台更新后的 ServiceNow 工单。

查看事件经过：拓扑视图

了解事故发生时的情况几乎与解决问题同样重要，而图片比冗长的文字更能传达信息。AgentSRE 提供三种拓扑视图，每种都以交互式图表的形式呈现。

调查拓扑

该视图展示了影响范围：哪些资源受到了影响以及它们之间的关联方式。根本原因对应的资源会以特殊颜色标出，而动画线条则会追踪问题扩散时的故障路径。该图表是根据调查结果动态生成的，因此不同的事故会形成不同的拓扑结构，因为每张图表都反映的是检测工具实际发现的情况。

上方的视图展示的是一种调查拓扑结构。

基础设施拓扑

该地图显示了完整的架构：包括每个API网关、Lambda函数、检测工具、数据库、队列及监控组件，以及它们之间的连接关系。它能让操作人员全面了解系统的部署情况以及请求的传输路径。

基础设施地图展示的也是同一系统。

可组合检测工具拓扑

该视图会逐步展示修复流程：用户触发、协调器分类、代理调用、网关工具调用、资源变更，以及最终结果上传到ServiceNow。每个节点代表修复过程中实际调用的组件，因此这种可组合架构不再只是抽象概念，而是操作人员能够看到并验证的实际内容。

代理拓扑图展示了一次修复执行过程。

该拓扑图是通过混合方法提取的。当故障符合已知模式时，基于规则的提取工具会立即免费生成图表；对于未知情况，系统则会让Bedrock Claude从调查文本中提取拓扑结构。常见案例处理速度快，特殊案例也能得到妥善处理。

为何可组合性如此重要

将修复机制构建为可组合的代理而非单一整体，能带来诸多实际优势。

• 可扩展性。新增的修复类别，如重启容器、调整扩展策略或轮换凭证，只需构建一个代理并将其注册到调度器中，现有代理便不会受到影响。
• 可测试性。具有明确输入和输出的单一状态机可以独立进行测试，因此一个代理的变更不太可能破坏其他代理的功能。
• 可观测性。每个代理都遵循既定的状态机，因此其执行过程可以被追踪和可视化，而可组合代理的拓扑结构正是基于这一设计形成的。
• 可重用性。一个代理可以处理多种故障。例如，数据库代理无需修改即可处理索引创建、查询终止及其他SQL相关问题。

技术架构

该平台将各类AWS服务与开源框架按功能分类整合在一起：

• 监控与警报功能来自Amazon CloudWatch，事件驱动的编排则由Amazon SNS结合AWS Lambda实现。
• 问题调查工作由AWS DevOps Agent负责，而Amazon Bedrock与Claude则承担推理、总结及拓扑结构提取的任务。
• Amazon Bedrock AgentCore用于托管各类代理程序，LangGraph则为它们提供状态机功能。
• Amazon DynamoDB用于存储状态数据与审计记录，ServiceNow则负责管理工单的整个生命周期。
• 前端界面采用React搭配React Flow构建，拓扑图也由React Flow生成，所有内容均部署在AWS Amplify平台上。

实际效果

自动化处理这一流程能带来显著成效。手动处理时，从问题发现到解决可能需要1到4小时，而AgentSRE则能在不到10分钟内完成从报警到解决的整个过程。问题调查通常需要3到5分钟，而经过确认的修复方案则在30秒内即可完成。

不仅速度提升，一致性也得到了改善。所有故障都会经过同样细致的调查、安全检查以及操作日志记录，因此响应质量不再取决于值班人员名单。

未来发展方向

这种可组合的基础架构为多种发展方向打开了可能。更多智能体可以通过 Systems Manager 或 Terraform 处理基础设施层面的问题。审批流程可通过 Microsoft Teams 等协作工具进行管理。知识层则能整合过往事故的经验，从而为未来的解决方案提供更有针对性的建议。由于这种智能体模式并不局限于某一种云平台，因此同样的方法也可应用于多云环境。

架构要点

只要遵循正确的原则——自主调查、可组合的修复智能体、人工审批以及丰富的拓扑视图——自主式事故管理不仅具备可行性，而且十分实用。这些要素共同作用，能够在确保安全性和完全可追溯性的同时，大幅缩短问题解决时间。

关键要点在于架构设计。将修复工作拆分为多个可组合的专用代理，而非依赖单一自动化流程，这更符合运维团队的实际工作方式，同时能让系统保持可扩展性，并使每项操作都清晰可见。随着云环境日益复杂，这是实现人工智能驱动运维的可扩展路径。