人工智能
Circle K 如何借助 Amazon Bedrock 将 DevOps 事件分诊缩短至 15 分钟内本文由 Circle K 云 DevOps 工程师 Marek Klatowicz 共同撰写。
许多 DevOps 团队都熟悉事件分诊的模式：告警一响，还没等人着手解决问题，工程师就要先花 45–60 分钟弄清楚到底发生了什么。他们拉取日志、检查服务健康状况，并在几个工具之间关联各种症状。这一切都发生在补救工作能够开始之前。
在 Circle K，这一挑战随着业务规模扩大而加剧。该公司在 27 个国家运营着超过 17,200 家便利店和燃油零售门店。在门店背后，一套云原生基础设施支撑着运行在 AWS 上的销售点系统、忠诚度应用和电动汽车（EV）充电应用。随着公司数字业务的扩展，分诊开销也随之增长。 更多服务意味着更多告警，而每一个告警在补救工作能够开始之前都需要同样的人工排查。
为了解决这一问题，Circle K 使用 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 中的内部运行手册进行交叉比对。 Amazon CloudWatch，检查 Amazon OpenSearch Service 中的应用级追踪， 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 Simple Queue Service（Amazon SQS） 队列。一个 AWS Lambda 函数轮询该队列，提取告警负载，并调用 Flow。
在 Flow 内部，两个智能体被并行调用。 AWSResourceExplorerAgent 使用 AWS Organizations 管理的多个工作负载账户中的基础设施查询。 AWS Organizations它会检查 Amazon ECS 任务状态、Application Load Balancer 目标健康状况，以及 CloudWatch 指标和日志。与此同时， OpenSearchExplorerAgent 查询 Amazon OpenSearch Service 以获取应用级日志和分布式追踪。该智能体单独运行，因为 OpenSearch 会返回大量日志数据。将其隔离可使每个智能体的上下文窗口保持可控。它还拥有对知识库的独占访问权限，该知识库包含描述每项服务及其依赖关系的产品卡片。
智能体运行。它接收前两个智能体的输出，找到受影响服务的 GitHub 仓库。然后搜索其应用代码、基础设施定义和最近的提交，以精确定位问题根源并提出具体修复方案。在并行智能体之后运行它，意味着它确切知道要搜索什么，而不是执行宽泛的查询。所有三个输出都输入到一个节点，该节点是单次模型调用，不附加任何工具。它接收 AWS 资源 d GitHubExplorerAgent 运行。它接收前两个智能体的输出，并找到受影响服务的 GitHub 仓库。然后搜索其应用代码、基础设施定义和最近的提交，以精确定位问题根源并提出具体修复方案。在并行智能体之后运行它，意味着它确切知道要搜索什么，而不是执行宽泛的查询。
所有三个输出都输入到一个 AnalysisPrompt 节点，这是一次未附加任何工具的单次模型调用。它接收 AWS 资源数据、OpenSearch 日志和 GitHub 上下文，然后生成结构化摘要：可能的根本原因、支持证据、受影响的服务及负责人，以及建议的修复步骤。提示输出采用一致的格式，值班团队可在 2 分钟内快速浏览。
Flow 将此摘要返回给调用它的 Lambda 函数，该函数再将摘要发布到 Slack 频道。从触发告警到发送 Slack 消息的整个过程需要 5–15 分钟，具体取决于事件的复杂程度。
下图展示了该架构的端到端流程，从最初的 Grafana 告警一直到最终的 Slack 摘要。
图 1：使用 Amazon Bedrock Flows 的 Circle K 自动化事件分诊架构
示例分诊
一条 Grafana 告警：某服务的 HTTP 5xx 错误率连续 3 分钟超过 5%。
AWSResourceExplorerAgent 检查目标账户中的 ECS 任务健康状况，发现数据库连接池已耗尽，ECS 服务正尝试重启。OpenSearchExplorerAgent 返回的应用日志显示，该服务向其后端 PostgreSQL 数据库报出“连接被拒绝”错误。它还会从知识库中检索受影响服务的产品卡片，该卡片记录了该服务对该数据库的依赖关系。 GitHubExplorerAgent 会搜索该服务的仓库和基础设施文件，并找到 Amazon Relational Database Service（Amazon RDS）的定义。它发现该服务在每次请求时都会打开一个新的数据库连接，而不是复用现有连接。
AnalysisPrompt 接收全部三项结果。它将时间点与一场在告警前 10 分钟启动的既定营销活动相关联。它再结合 GitHubExplorerAgent 的发现，推荐具体的代码级修复方案，而不是临时补丁。
最终的 Slack 消息内容如下：
Summary: XYZ Service 5xx errors caused by connection pool exhaustion
Root cause: Scheduled marketing campaign drove traffic spike; connection pool max (50) insufficient for load
Evidence: OpenSearch logs show "connection refused" at 14:32 UTC; ECS shows 3 task restarts since 14:30
Owner: XYZ team (backend)
Next steps: Add Amazon RDS Proxy to pool connections, or update the service to reuse existing connections instead of opening a new one per request; consider an Auto Scaling rule for future campaigns扩展至 Amazon Bedrock AgentCore
Amazon Bedrock Flows 架构在数月内运行良好，简单事件可在 10 分钟内完成分诊。随着时间推移，尽管涉及的服务集合保持不变，但数据量和每次调查背后的上下文都在增长。有些事件需要比单个 Flow 节点所能完成的更长时间的分析。
团队首先在现有设计范围内进行优化：更积极地过滤日志、缩短上下文窗口，并将某些服务拆分为独立的 Flow。这些措施有所帮助，但日志量和知识库仍在持续增长。
Amazon Bedrock AgentCore 满足了这一需求。AgentCore 是一个平台，可借助任意框架或模型大规模构建、连接和优化 AI 智能体。对于此工作负载，关键能力是 AgentCore Runtime：整个调查在单个会话中运行，因此每个步骤都可以根据其数据所需的时间来执行。AgentCore Runtime 支持最长 8 小时的会话，远超当前调查所需的时间。 团队将其智能体逻辑容器化，并部署在 AgentCore Runtime 上。
下图展示了迁移到 Amazon Bedrock AgentCore 之后的生产架构。
图 2：使用 Amazon Bedrock AgentCore Runtime 和 AgentCore Gateway 的生产架构
分析逻辑保持不变，但运行方式已经改变。Flows 版本中的三个专用智能体现在整合为一个在 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 还新增了三项能力，以支持团队不断扩大的规模：会话持久性、基于 OpenTelemetry 的可观测性以及框架灵活性。
会话持久性： 在整个调查过程中，智能体会保留一个中间状态。如果对日志的第一次遍历发现了某些线索，智能体可以运行第二次更有针对性的遍历，而不会丢失已经构建的上下文。这契合了调查复杂的多服务事件时所采用的迭代方式。
可观测性： AgentCore 使用 OpenTelemetry 标准捕获每个会话的追踪数据，并通过 CloudWatch 呈现。团队可以查看每个步骤的耗时、智能体发起了哪些知识库查询，以及瓶颈出现在哪里。这些洞察会直接用于提示词调优。
框架灵活性： 借助 AgentCore Runtime，团队可以部署使用多种框架构建的容器化智能体。他们可以迭代智能体逻辑、添加分诊步骤，或根据需求变化重构智能体的推理方式，而这一切都在同一个 Runtime 上完成。
AgentCore 架构现已投入生产运行，可处理各类事件，从简单的单服务告警到大型多服务调查均能应对。
结果
Circle K 于 2026 年 4 月部署了分诊系统的 AgentCore 版本。根据团队内部的 incident-response 指标，平均分诊时间从 45–60 分钟降至 15 分钟以内，降幅达 67–75%。简单事件可在 5–8 分钟内收到摘要。复杂的多服务事件此前人工分诊需要一小时以上，现在可在 15 分钟内完成。
工程师们现在从摘要入手，而不再自行收集上下文。团队看到事件处理方式发生了三项变化：
一致的分诊。 无论值班工程师对受影响服务的熟悉程度如何，每位值班工程师都会收到相同的结构化摘要，其中包含相同的日志摘录、知识库参考和推荐的后续步骤。
更快的升级处理。 当某个问题需要其他团队提供支持时，摘要会为值班工程师提供相关背景信息，以便及时、知情地进行升级处理。
更快地处理误报。 当分析发现服务运行正常且没有相关错误时，工程师可以确认该告警并继续处理其他工作。
经验教训
构建这个系统经历了多次迭代。其中有四条经验尤为突出，适用于使用 Amazon Bedrock 构建类似解决方案的团队。
将日志内容直接包含在提示词中。早期版本只传递日志组名称和时间范围，然后由智能体尝试通过操作组查询 CloudWatch。这增加了延迟，而且往往返回过多数据而无法处理。Circle K 通过让 Lambda 函数预先查询日志并将相关行直接传递给智能体，获得了更好的结果。当智能体能够读取实际的错误消息时，它的推理速度会更快。
针对不同用例调整检索与生成配置。检索配置显著影响了知识库的结果质量。在测试了可用选项后，Circle K 团队发现采用默认配置的 Amazon Bedrock 知识库最适合他们的数据。Amazon Bedrock 端到端处理嵌入、索引和向量存储，因此团队需要维护的组件更少。 在生成侧，精心设计的系统提示词和调优后的温度设置使 Slack 中的摘要保持一致。
借助日志中的发现来缩小代码搜索范围。在没有线索的情况下搜索该服务的代码仓库会返回过多结果，毫无用处。团队在完成 AWS 资源与日志分析之后才运行 GitHub 搜索，因此智能体已经知道要查找哪个错误、组件或近期变更。在示例分诊中，智能体正是通过这种方式发现该服务为每个请求都打开了一个新的数据库连接。
让分析逻辑与编排层保持独立。分析时间会随数据量增长，因此要预见到调查耗时会逐渐变长。团队将提示词、工具定义和分析步骤与流程结构分开维护。这样一来，就可以在不重写分诊逻辑的情况下，将它们整合到 AgentCore Runtime 上的单个智能体中。
后续步骤
如今，分诊系统会找出可能的根本原因并推荐修复方案，然后由工程师执行修复。接下来，团队计划与 AWS DevOps 智能体因此系统也能处理简单的修复操作。示例包括重启任务、扩展服务或回滚部署。每项操作在运行前都会由工程师在 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 知识库。如需实践指导或与 AWS 专家讨论您的使用场景，请访问 Amazon Bedrock 入门页面 或 联系 AWS.
我们想了解你是如何进行事件分诊的。欢迎在评论区分享你的经验。