Circle K 如何用 Amazon Bedrock 将 DevOps 事故排查时间压缩到 15 分钟以内

本文由 Circle K 的 Cloud DevOps 工程师 Marek Klatowicz 共同撰写。

许多 DevOps 团队都熟悉这种事故分诊模式：警报触发后，在任何人能够修复问题之前，工程师需要花费 45–60 分钟来弄清楚发生了什么。他们要拉取日志、检查服务健康状况，并在多个工具之间关联各种症状。所有这些都要在修复工作开始之前完成。

在 Circle K，这一挑战随业务增长而放大。该公司在 27 个国家/地区运营着超过 17,200 家便利店和燃料零售店。在店面背后，一套云原生基础设施支撑着运行在 AWS 上的销售点（POS）系统、忠诚度应用和电动汽车（EV）充电应用。随着公司数字运营的扩展，分诊开销也随之增长。更多的服务意味着更多的警报，而每一个警报都需要同样的手工调查，然后才能开始修复。

为了解决这一问题，Circle K 使用 Amazon Bedrock 构建了一个自动化分诊系统，这是一项完全托管的服务，可通过单一 API 提供基础模型（FM）。有关各 AWS 区域的模型可用性，请参阅 Supported models by AWS Region in Amazon Bedrock。该系统采用智能体 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) 发布通知时，管道开始运作，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：使用 Amazon Bedrock Flows 的 Circle K 自动化事件分诊架构

分诊示例

一条 Grafana 告警：某服务的 HTTP 5xx 错误率连续 3 分钟超过 5%。

AWSResourceExplorerAgent 在目标账户中检查 ECS 任务健康状况，发现数据库连接池耗尽，ECS 服务正在尝试重启。OpenSearchExplorerAgent 返回的应用日志显示，该服务向其背后的 PostgreSQL 数据库发出“connection refused”（连接被拒绝）错误。它还从知识库中检索到受影响服务的产品卡片，其中记录了该服务对该数据库的依赖。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 版本的分诊系统。根据团队的内部事故响应指标，平均分诊时间从 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。

我们想听听您如何进行事件分诊。欢迎在评论中分享您的经验。