正文 · AI 翻译
本文由 Circle K 的云 DevOps 工程师 Marek Klatowicz 共同撰写。许多 DevOps 团队都熟悉这样的事件分诊流程：警报触发后，在任何人能够解决问题之前，工程师要花 45–60 分钟弄清楚发生了什么。他们会调取日志、检查服务运行状况，并在多个工具之间关联各种症状。所有这些工作都发生在开始修复之前。在 Circle K，这一挑战随着业务增长而扩大。该公司在 27 个国家经营着超过 17,200 家便利店和燃油零售门店。在门店背后，云原生基础设施为运行在 AWS 上的销售点系统、会员应用和电动汽车（EV）充电应用提供支持。随着公司扩大数字化业务，分诊工作量也随之增加。服务越多，警报就越多，而每条警报都需要先进行同样的人工调查，才能开始修复。为解决这一问题，Circle K 使用 Amazon Bedrock 构建了一套自动化分诊系统。Amazon Bedrock 是一项完全托管的服务，可通过单一 API 提供基础模型（FM）。有关各 AWS 区域的模型可用性，请参阅 Amazon Bedrock 中的“按 AWS 区域列出的受支持模型”。该系统采用代理式 AI 架构，自主调查每起事件，并在警报触发后的几分钟内向 Slack 发送结构化摘要。值班工程师现在收到的不再只是原始警报，而是可据以采取行动的背景信息，因此他们可以立即行动，无须花一个小时弄清楚发生了什么。自部署该系统以来，根据团队内部的事件响应指标，Circle K 已将平均分诊时间缩短至 15 分钟以内，降幅为 67–75%。本文介绍了最初采用 Amazon Bedrock Flows 的实现方案以及迁移至 Amazon Bedrock AgentCore 后的架构，并分享了在扩展该系统过程中获得的经验。分诊工作量带来的挑战 Circle K 的 DevOps 团队使用 Grafana 监控多个 AWS 账户中的基础设施。日常警报包括容器重启、错误率上升、延迟激增和部署失败。每条警报都是有用的信号，但随着系统扩展，团队希望帮助值班工程师借助适当的背景信息，快速判断哪些信号需要关注。警报到来时，分诊涉及一系列熟悉的人工步骤：查看 Amazon CloudWatch 中的近期日志、检查 Amazon OpenSearch Service 中的应用级追踪信息、核查 Amazon Elastic Container Service（Amazon ECS）的任务状态，以及对照 GitHub 中的内部运行手册核实症状。这些步骤为工程师提供了所需信息，但也表明，随着更多服务接入，需要重复收集大量背景信息。团队认识到，在两个方面进行前瞻性投入可能有所帮助。首先，每起事件都要重复执行相同的日志查询、运行状况检查和运行手册查找。其次，分诊的深度和速度可能因值班工程师对受影响服务的熟悉程度而异。随着警报量和所负责的服务增加，每次调查都要在多个工具之间切换，这可能拖慢响应速度，也使团队更难一致地应用最佳实践。因此，Circle K 的 DevOps 团队启动了一项研发（R&D）计划，探索 AI 如何支持监控和事件分诊。其目标是自动收集重复性的背景信息，并提供结构化、可据以采取行动的调查结果，同时为工程师在调查过程中的运维判断提供支持。Circle K 为何选择 Amazon Bedrock 在开始构建之前，团队评估了几种方法，包括在自行管理的基础设施上使用开源代理框架。采用这种方法意味着团队需要自行负责模型托管、提示词版本管理、工具编排和安全控制。借助 Amazon Bedrock，团队避免了这方面的负担。他们可以通过单一 API 访问基础模型，并且无需重写代码即可更换基础模型。 由于 Circle K 已经在 AWS 上运行，Amazon Bedrock 能够融入现有的 AWS Identity and Access Management (IAM) 策略、Amazon Virtual Private Cloud (Amazon VPC) 配置和日志处理管道。两项托管功能涵盖了编排和检索。Amazon Bedrock 提供智能体编排能力，使智能体无需自定义编排代码即可通过原生工具调用 AWS API、查询数据库和检索文档。Amazon Bedrock Knowledge Bases 是完全托管的检索增强生成 (RAG) 功能，负责内部产品卡片的导入和检索，因此团队无需运行单独的向量数据库。这让 DevOps 团队可以专注于提示词设计和工具定义。数据隐私也是整个方案的重要一环。Circle K 的事件数据包括运营指标、基础设施详情，以及可能包含敏感信息的日志。Amazon Bedrock 不会与模型提供商共享客户数据，也不会使用这些数据训练基础模型。对于需要将生产日志和内部服务详情输入系统的团队而言，这种数据处理方式满足了 Circle K 的安全要求。解决方案概览 本节介绍团队基于 Amazon Bedrock Flows 构建的初始架构。后文将介绍向 AgentCore 的迁移。该解决方案使用 Amazon Bedrock Flows 作为编排层，协调一组专门的智能体，每个智能体负责分析的不同部分。当 Grafana 告警向 Amazon Simple Notification Service (Amazon SNS) 发布通知时，流程便会启动；Amazon SNS 随后将通知转发到 Amazon Simple Queue Service (Amazon SQS) 队列。一个 AWS Lambda 函数轮询该队列，提取告警载荷并调用 Flow。在 Flow 内，两个智能体并行调用。AWSResourceExplorerAgent 查询由 AWS Organizations 管理的多个工作负载账户中的基础设施。它检查 Amazon ECS 任务状态、Application Load Balancer 目标运行状况，以及 CloudWatch 指标和日志。与此同时，OpenSearchExplorerAgent 查询 Amazon OpenSearch Service 中的应用程序级日志和分布式追踪数据。该智能体单独运行，因为 OpenSearch 会返回大量日志数据。将其隔离有助于使每个智能体的上下文窗口保持在可管理的范围内。它还独享知识库的访问权限，知识库包含描述各项服务及其依赖关系的产品卡片。两个智能体都返回发现结果后，GitHubExplorerAgent 开始运行。它接收前两个智能体的输出，找到受影响服务的 GitHub 代码仓库。然后，它搜索仓库中的应用程序代码、基础设施定义和近期提交，以确定问题来源并提出具体修复方案。将它安排在两个并行智能体之后运行，意味着它能准确知道要搜索什么，而不必进行宽泛查询。这三个智能体的输出全部传入 AnalysisPrompt 节点；该节点是一次不附带工具的模型调用。它接收 AWS 资源数据、OpenSearch 日志和 GitHub 上下文，然后生成结构化摘要：可能的根本原因、支持性证据、受影响的服务及其负责人，以及建议的修复步骤。提示词输出采用一致的格式，值班团队可以在 2 分钟内浏览完毕。Flow 将该摘要返回给调用它的 Lambda 函数，后者将摘要发布到 Slack 频道。从告警到 Slack 消息的整个过程耗时 5–15 分钟，具体取决于事件的复杂程度。下图展示了从最初的 Grafana 告警到最终 Slack 摘要的端到端架构。图 1：Circle K 使用 Amazon Bedrock Flows 构建的自动化事件分诊架构 分诊示例 一条 Grafana 告警：某项服务的 HTTP 5xx 错误率连续 3 分钟超过 5%。AWSResourceExplorerAgent 检查目标账户中的 ECS 任务运行状况，发现数据库连接池已耗尽，而 ECS 服务正在尝试重启。 OpenSearchExplorerAgent 返回应用程序日志，其中显示该服务连接其后端 PostgreSQL 数据库时出现“connection refused”错误。它还从知识库中检索受影响服务的产品卡片，其中记录了该服务对该数据库的依赖。GitHubExplorerAgent 搜索该服务的代码仓库和基础设施文件，找到 Amazon Relational Database Service（Amazon RDS）的定义。它发现该服务为每个请求新建一个数据库连接，而不是复用现有连接。AnalysisPrompt 接收全部 3 项结果。它将发生时间与警报前 10 分钟启动的预定营销活动联系起来。结合 GitHubExplorerAgent 的发现，它建议采取具体的代码级修复措施，而不是临时补丁。最终的 Slack 消息写道：摘要：XYZ Service 的 5xx 错误由连接池耗尽导致。根本原因：预定营销活动造成流量激增；连接池上限（50）不足以承载负载。证据：OpenSearch 日志显示 14:32 UTC 出现“connection refused”；ECS 显示自 14:30 起任务重启了 3 次。负责人：XYZ 团队（后端）。后续步骤：添加 Amazon RDS Proxy 以对连接进行池化，或更新服务以复用现有连接，而不是为每个请求新建连接；考虑为未来的营销活动设置 Auto Scaling 规则。扩展到 Amazon Bedrock AgentCore Amazon Bedrock Flows 架构连续数月运行良好，简单事件的分诊用时不到 10 分钟。随着时间推移，尽管服务集合保持不变，每次调查涉及的数据量和背景信息却不断增加。有些事件所需的分析时间超过单个 Flow 节点能够完成的时长。团队首先在现有设计中进行优化：更严格地筛选日志、缩短上下文窗口，并将某些服务拆分到单独的 Flows 中。这些措施有所帮助，但日志量和知识库仍在持续增长。Amazon Bedrock AgentCore 满足了这一需求。AgentCore 是一个可使用任何框架或模型大规模构建、连接和优化 AI 代理的平台。对于这一工作负载，关键能力是 AgentCore Runtime：整个调查在单个会话中运行，因此每一步都可以根据其数据需要花费相应的时间。AgentCore Runtime 支持最长 8 小时的会话，远超当前调查所需的时长。团队将代理逻辑容器化，并部署到 AgentCore Runtime。下图展示了迁移到 Amazon Bedrock AgentCore 后的生产架构。图 2：使用 Amazon Bedrock AgentCore Runtime 和 AgentCore Gateway 的生产架构。分析逻辑保持不变，但运行方式发生了变化。Flows 版本中的 3 个专用代理现在合并为一个在 AgentCore Runtime 会话中运行的代理。Lambda 函数启动会话，代理执行与之前相同的步骤。它跨账户查询 AWS 资源，从 Amazon OpenSearch Service 提取日志，搜索 GitHub，并从知识库检索产品卡片。代理在 15 分钟内将调查结果返回给 Lambda 函数，这处于 Lambda 的最长超时时限之内。随后，Lambda 函数将结构化摘要发布到 Slack。Amazon Bedrock AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力，负责代理访问其数据源，包括 Amazon OpenSearch Service、Amazon Bedrock Knowledge Bases 和 GitHub。Gateway 将每个数据源作为代理可调用的工具提供，从而集中管理访问控制，并使团队更容易添加或更改数据源。AgentCore Runtime 如何支持团队不断扩大的规模 除了支持更长时间运行的会话，Amazon Bedrock AgentCore Runtime 还提供了 3 项支持团队规模扩大的能力：会话持久性、基于 OpenTelemetry 的可观测性，以及框架灵活性。会话持久性：代理在整个调查过程中保留中间状态。 如果第一轮日志检查发现了线索，智能体就可以在保留已建立的上下文的同时，开展第二轮更有针对性的检查。这符合复杂的多服务事件采用的迭代式调查方式。可观测性：AgentCore 使用 OpenTelemetry 标准捕获每次会话的追踪数据，并通过 CloudWatch 呈现。团队可以查看每个步骤耗时多久、智能体执行了哪些知识库查询，以及瓶颈出现在哪里。这些洞察直接用于调整提示词。框架灵活性：借助 AgentCore Runtime，团队可以部署使用各种框架构建的容器化智能体。随着需求变化，他们可以在同一个 Runtime 上迭代智能体逻辑、增加初步排查步骤，或调整智能体的推理结构。AgentCore 架构现已投入生产，能够处理各种事件，从简单的单服务告警到大型多服务调查。结果：Circle K 于 2026 年 4 月部署了基于 AgentCore 的初步排查系统。根据团队内部的事件响应指标，平均初步排查时间从 45–60 分钟降至不到 15 分钟，缩短了 67–75%。简单事件可在 5–8 分钟内获得摘要。复杂的多服务事件过去需要一个多小时才能完成人工初步排查，如今可在 15 分钟内完成。工程师现在可以直接从摘要入手，无须自行收集背景信息。团队发现事件处理方式出现了三项变化：初步排查更一致。无论值班工程师对受影响服务有多熟悉，每个人收到的都是同样结构化的摘要，包含相同的日志摘录、知识库参考资料和建议的后续步骤。升级处理更快。当问题需要其他团队支持时，摘要为值班工程师提供相关背景信息，以便及时、有依据地升级处理。误报处理更迅速。当分析发现服务运行正常且没有相关联的错误时，工程师可以确认告警并继续处理其他工作。经验教训：构建这一系统经历了多轮迭代。对于使用 Amazon Bedrock 构建类似解决方案的团队，有四点经验尤为突出。将日志内容直接纳入提示词。早期版本只传入日志组名称和时间范围，然后由智能体尝试通过操作组查询 CloudWatch。这增加了延迟，而且返回的数据往往过多，难以处理。Circle K 改为让 Lambda 函数预先查询日志，再将相关日志行直接传给智能体，取得了更好的效果。智能体能够读取实际错误消息时，推理速度更快。针对用例调整检索和生成。检索配置显著影响知识库结果的质量。测试可用选项后，Circle K 团队发现，采用默认配置的 Amazon Bedrock Knowledge Base 最适合他们的数据。Amazon Bedrock 端到端处理嵌入、索引和向量存储，因此团队需要维护的组件更少。在生成方面，精心设计的系统提示词和经过调整的温度设置使 Slack 中的摘要保持一致。根据日志发现缩小代码搜索范围。如果没有线索就搜索服务的代码仓库，返回的结果会多到难以利用。团队在完成 AWS 资源和日志分析后才进行 GitHub 搜索，因此智能体已经知道要寻找哪种错误、哪个组件或哪项近期变更。在示例初步排查中，智能体就是这样发现该服务为每个请求都建立新的数据库连接的。让分析逻辑独立于编排层。分析时间会随数据量增加而增长，因此应预计调查耗时会逐渐变长。团队将提示词、工具定义和分析步骤与流程结构分开。这使他们能够将这些内容整合为 AgentCore Runtime 上的单个智能体，而无须重写初步排查逻辑。 下一步 目前，事件分诊系统会找出可能的根本原因并建议修复方法，再由工程师实施修复。接下来，团队计划与 AWS DevOps Agent 集成，使系统也能处理简单的修复操作，例如重启任务、扩容服务或回滚部署。每项操作运行前，都将由工程师在 Slack 中批准。团队还计划为智能体提供更多上下文：接入 Jira，将每起事件关联到相关工单并跟踪后续工作；接入 Confluence，在智能体已经读取的代码和日志之外补充内部文档；接入知识库中的运行手册，让智能体能够将症状与已知故障模式及过去有效的修复方法相匹配，而不只是依赖产品卡片。结论 Circle K 团队通过自动收集过去由工程师手动收集的上下文，将人工事件分诊所需的 45–60 分钟缩短至不到 15 分钟。系统从日志、AWS 资源和代码中收集数据，让智能体对这些数据进行分析，并将结构化摘要发送到 Slack。团队使用 Amazon Bedrock Flows 和 Amazon Bedrock Knowledge Bases 构建了第一个版本。随着调查规模扩大，团队转向在 Amazon Bedrock AgentCore Runtime 上运行单个智能体，并通过 AgentCore Gateway 访问数据源。如果您的团队在事件响应中花在收集上下文上的时间多于解决问题的时间，这种模式可以直接应用。要开始使用，请了解 Amazon Bedrock AgentCore 和 Amazon Bedrock Knowledge Bases。如需实践指导或希望与 AWS 专家讨论您的使用场景，请访问 Amazon Bedrock 入门页面或联系 AWS。我们希望了解您如何进行事件分诊。欢迎在评论区分享您的经验。关于作者 Marek Klatowicz Marek 是 Circle K 的云 DevOps 工程师，负责利用 AWS 为企业终端客户设计和改进云服务。最近，他将大量时间投入人工智能领域，构建能带来实际商业价值的解决方案。他相信简单实用的解决方案。Sefat Noor Orni Sefat 是 Amazon Web Services 的解决方案架构师，帮助企业客户在 AWS 上构建由人工智能驱动的运维工具。她专注于生成式人工智能应用、智能体架构和 DevOps 自动化。工作之余，她喜欢尝试烹饪、音乐和家庭自动化项目。