[Amazon Bedrock] Circle K 如何用 Amazon Bedrock 把 DevOps 事故分诊压到 15 分钟以内

人工智能

Circle K 如何用 Amazon Bedrock 把 DevOps 事故分诊压到 15 分钟以内

本文与 Circle K 的云 DevOps 工程师 Marek Klatowicz 联合撰写。

很多 DevOps 团队都熟悉事故分诊的这个套路：告警触发，可在任何人着手修复问题之前，工程师得先花 45–60 分钟搞清楚到底发生了什么。他们拉取日志、检查服务健康状态，还在好几个工具之间把症状相互关联起来。这一切都发生在能够开始修复之前。

在 Circle K，这个挑战是跟着业务一起扩张的。公司在 27 个国家运营着超过 17,200 家便利店与燃油零售门店。店面背后，一套云原生基础设施支撑着跑在 AWS 上的销售终端（POS）系统、会员忠诚度应用和电动汽车（EV）充电应用。随着公司数字业务的扩张，分诊开销也同步增长。服务更多意味着告警更多，而每一条告警在开始修复之前，都需要同样的人工调查。

为了应对它，Circle K 用 Amazon Bedrock 搭建了一套自动化分诊系统——这是一项完全托管的服务，通过单一 API 提供基础模型（FM）。有关各 AWS 区域的模型可用性，参见 Amazon Bedrock 中按 AWS 区域划分的受支持模型。这套系统采用 agentic AI 架构，自主调查每一起事故，并在告警触发后的几分钟内把一份结构化摘要交付到 Slack。值班工程师收到的不再是原始告警，而是可据以行动的上下文，所以他们能立刻动手，而不是花上一个小时去弄清发生了什么。

自部署这套系统以来，Circle K 已把平均分诊时间降到 15 分钟以内——按团队内部的事故响应指标计算，降幅为 67–75%。

在本文中，我们既描述最初的 Amazon Bedrock Flows 实现的架构，也描述向 Amazon Bedrock AgentCore 的迁移，并分享系统在扩展过程中总结的经验教训。

分诊开销这一挑战

Circle K 的 DevOps 团队用 Grafana 监控横跨多个 AWS 账户的基础设施。平常的一天里，会有容器重启、错误率升高、延迟尖峰和部署失败的告警。每条告警都是有用的信号，但随着系统不断扩张，团队希望帮助值班工程师带着恰当的上下文，快速看出哪些信号需要关注。

告警进来时，分诊就是一串大家都熟悉的重复步骤：在 Amazon CloudWatch 里查看近期日志，在 Amazon OpenSearch Service 里检查应用级 trace，查看 Amazon Elastic Container Service (Amazon ECS) 的任务状态，再把症状与 GitHub 上内部 runbook 相互对照。这些信息确实是工程师需要的，但它同时也说明：随着更多服务接入，需要重复收集的上下文会有多少。

团队识别出两个方面，提前投入能够带来帮助。第一，同样的日志查询、健康检查和 runbook 检索，每一起事故都要重复一遍。第二，分诊的深度和速度会随着值班工程师对受影响服务的熟悉程度而变化。当告警量和服务归属范围都增长起来，每次调查都在多个工具之间来回切换会拖慢响应，也让团队的最佳实践更难一致地落地。

因此，Circle K 的 DevOps 团队启动了一项研发（R&D）专项，探索 AI 能如何支撑监控与事故分诊。目标是把重复的上下文收集自动化，给出结构化、可据以行动的结论，同时在调查过程中支撑工程师的运维判断。

Circle K 为什么选择 Amazon Bedrock

在动手构建之前，团队评估了几种方案，包括在自管基础设施上使用开源 agent 框架。那条路意味着要自己承担模型托管、prompt 版本管理、工具编排和安全控制。

有了 Amazon Bedrock，团队避开了这些开销。他们可以通过单一 API 访问基础模型，还能不重写代码就更换基础模型。由于 Circle K 本来就运行在 AWS 上，Amazon Bedrock 能够顺理成章地嵌进现有的 AWS Identity and Access Management (IAM) 策略、Amazon Virtual Private Cloud (Amazon VPC) 配置和日志流水线。

两项托管能力覆盖了编排与检索。Amazon Bedrock 帮团队承担 agent 编排，让 agent 原生具备 tool use，可以调用 AWS API、查询数据库、检索文档，而不必写自定义的编排代码。Amazon Bedrock Knowledge Bases 是完全托管的检索增强生成（RAG）能力，负责内部产品卡（product card）的摄取与检索，团队因此不需要再单独运维一个向量数据库。这让 DevOps 团队得以专注于 prompt 设计和工具定义。

数据隐私补全了整幅图景。Circle K 的事故数据包含运维指标、基础设施细节，以及可能含有敏感信息的日志。Amazon Bedrock 不会把客户数据分享给模型提供商，也不会用它来训练基础模型。对一个把生产日志和内部服务细节喂进系统的团队来说，这种数据处理方式满足了 Circle K 的安全要求。

解决方案总览

本节描述团队最初构建在 Amazon Bedrock Flows 上的架构。后文另一节会讲向 AgentCore 的迁移。

该方案把 Amazon Bedrock Flows 用作编排层，协调一组专用 agent，各自负责分析的不同部分。流水线的起点是一条 Grafana 告警把通知发布到 Amazon Simple Notification Service (Amazon SNS)，SNS 再把它转发进一个 Amazon Simple Queue Service (Amazon SQS) 队列。一个 AWS Lambda 函数轮询该队列，提取告警负载，并调用这个 Flow。

在 Flow 内部，两个 agent 会被并行调用。AWSResourceExplorerAgent 查询由 AWS Organizations 管理的多个工作负载账户中的基础设施。它检查 Amazon ECS 任务状态、Application Load Balancer 目标健康状态，以及 CloudWatch 的指标和日志。与此同时，OpenSearchExplorerAgent 查询 Amazon OpenSearch Service，获取应用级日志和分布式 trace。这个 agent 单独运行，因为 OpenSearch 会返回海量的日志数据。把它隔离开来能让每个 agent 的上下文窗口保持在可控范围内。它也是唯一能访问知识库的 agent，知识库里存放着描述每个服务及其依赖关系的产品卡。

两个 agent 都返回结论之后，GitHubExplorerAgent 才开始运行。它接收前两个 agent 的输出，找到受影响服务的 GitHub 仓库，然后搜索其中的应用代码、基础设施定义和近期 commit，以定位问题根源并提出一个具体的修复方案。把它排在并行 agent 之后运行，意味着它确切知道该搜什么，而不是执行一次宽泛的查询。

三份输出全部汇入一个 AnalysisPrompt 节点，那是一次不带任何工具的单独模型调用。它接收 AWS 资源数据、OpenSearch 日志和 GitHub 上下文，然后产出一份结构化摘要：可能的根因、支撑证据、受影响服务及其负责人，以及建议的修复步骤。prompt 的输出使用统一的格式，值班团队不到 2 分钟就能扫完。

Flow 把这份摘要返回给调用它的 Lambda 函数，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 收到这三份结果。它把发生时间与一场在告警前 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 agent。对这类工作负载而言，关键能力是 AgentCore Runtime：整次调查在单个 session 内完成，因此每一步都可以花上它的数据所需要的时间。AgentCore Runtime 支持长达 8 小时的 session，远远超过当前调查所需。团队把他们的 agent 逻辑容器化，部署到 AgentCore Runtime 上。

下图展示了迁移到 Amazon Bedrock AgentCore 之后的生产架构。

图 2：使用 Amazon Bedrock AgentCore Runtime 和 AgentCore Gateway 的生产架构

分析逻辑保持不变，但运行方式变了。Flows 版本里的三个专用 agent 现在合并成一个 agent，在一个 AgentCore Runtime session 中运行。Lambda 函数启动这个 session，agent 执行和以前相同的步骤。它跨账户查询 AWS 资源，从 Amazon OpenSearch Service 拉取日志，搜索 GitHub，并从知识库检索产品卡。agent 在 15 分钟内把结论返回给 Lambda 函数，仍在 Lambda 的最大超时时间内。随后 Lambda 函数把结构化摘要发到 Slack。

Amazon Bedrock AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力，负责居中调度 agent 对其数据源的访问，这些数据源包括 Amazon OpenSearch Service、Amazon Bedrock Knowledge Bases 和 GitHub。Gateway 把每个数据源暴露成 agent 可调用的工具，由此把访问控制集中起来，也让团队添加或更换数据源更简单。

AgentCore Runtime 如何支撑团队不断增长的规模

除了运行时长更久的 session，Amazon Bedrock AgentCore Runtime 还带来三项支撑团队规模增长的能力：session 持久化、基于 OpenTelemetry 的可观测性，以及框架灵活性。

Session 持久化： agent 在整个调查过程中保留中间状态。如果第一轮扫日志发现了什么，agent 可以再跑一轮更有针对性的扫描，而不丢失它已经建立的上下文。这契合复杂多服务事故那种迭代式的调查方式。

可观测性： AgentCore 用 OpenTelemetry 标准采集每个 session 的 trace，并通过 CloudWatch 呈现出来。团队可以看到每一步耗时多久、agent 发起了哪些知识库查询、瓶颈出现在哪里。这些洞察可以直接用于 prompt 调优。

框架灵活性： 有了 AgentCore Runtime，团队可以部署用范围很广的框架构建的容器化 agent。他们可以在同一个 Runtime 上迭代 agent 逻辑、增加分诊步骤，或随着需求变化重构 agent 的推理方式。

AgentCore 架构如今已在生产环境运行，承接从简单的单服务告警到大规模多服务调查的全谱事故。

成效

Circle K 在 2026 年 4 月部署了 AgentCore 版本的分诊系统。按团队内部的事故响应指标计算，平均分诊时间从 45–60 分钟降到 15 分钟以内，降幅为 67–75%。比较直接的事故在 5–8 分钟内就会得到摘要。复杂的多服务事故，过去人工分诊要一个多小时，现在在 15 分钟内完成。

工程师现在从一份摘要开始工作，而不是自己去收集上下文。团队看到事故处理方式上有三个变化：

分诊一致。 每位值班工程师收到的都是同一份结构化摘要，里面有相同的日志摘录、知识库引用和建议的后续步骤，不论他对受影响服务有多熟悉。

升级更快。 当问题需要其他团队支持时，摘要能为值班工程师提供相关上下文，让升级既及时又有依据。

误报处理更快。 当分析发现服务健康、也没有相关联的错误时，工程师可以确认这条告警然后继续别的事。

经验教训

构建这套系统经历了好几轮迭代。有四条经验特别突出，适用于用 Amazon Bedrock 构建类似方案的团队。

把日志内容直接放进 prompt。早期版本只传入日志组名称和时间范围，然后由 agent 尝试通过 action group 查询 CloudWatch。这增加了延迟，而且常常返回多到无法处理的数据。Circle K 后来改为让 Lambda 函数预先查询日志、把相关行直接传给 agent，结果更好。当 agent 能读到实际的错误信息时，它的推理更快。

针对用例调优检索与生成。检索配置会显著影响知识库的结果质量。在测试过可用的选项之后，Circle K 团队发现采用默认配置的 Amazon Bedrock Knowledge Base 最适合他们的数据。Amazon Bedrock 端到端地负责 embedding、索引和向量存储，团队需要维护的组件因此更少。在生成侧，一个设计良好的 system prompt 加上一套调优过的 temperature 设置，就能在 Slack 产出格式一致的摘要。

用日志里的发现来收窄代码搜索范围。没有线索就去搜索服务的仓库，返回的结果多到没法用。团队把 GitHub 搜索放在 AWS 资源分析和日志分析之后，这样 agent 已经知道该找哪个错误、哪个组件或哪次近期改动。在前面那个分诊示例里，agent 正是这样发现该服务每个请求都新开一个数据库连接的。

让分析逻辑独立于编排层。分析耗时随数据量增长，所以要预先考虑到调查会越来越久。团队把它的 prompts、工具定义和分析步骤与 flow 结构分离开来。这让他们能在不重写分诊逻辑的情况下，把这些内容合并成 AgentCore Runtime 上的单个 agent。

后续计划

如今，分诊系统负责找出可能的根因并推荐一个修复方案，由工程师来执行修复。接下来，团队计划与 AWS DevOps Agent 集成，让系统也能处理简单的修复动作。例子包括重启一个任务、给服务扩容或回滚一次部署。每个动作在执行之前都会由工程师在 Slack 里批准。

团队还计划给 agent 更多的上下文可用：

Jira，把每起事故关联到相关工单，并跟踪后续工作。 Confluence，在 agent 已经读取的代码和日志之外补上内部文档。 知识库里的 runbook，让 agent 能把症状对应到已知的故障模式和过去行之有效的修复方案，而不是只依赖产品卡。

结语

Circle K 团队把 45–60 分钟的人工事故分诊压到了 15 分钟以内，做法是把工程师过去手工完成的上下文收集自动化。系统从日志、AWS 资源和代码中收集数据，让 agent 在其上推理，并把一份结构化摘要交付到 Slack。

团队的第一版构建在 Amazon Bedrock Flows 和 Amazon Bedrock Knowledge Bases 之上。随着调查规模越来越大，团队转向 Amazon Bedrock AgentCore Runtime 上的单个 agent，由 AgentCore Gateway 提供对其数据源的访问。

如果你的团队把大部分事故响应时间都花在收集上下文而不是解决问题上，这套模式可以直接套用。要开始上手，可以了解 Amazon Bedrock AgentCore 和 Amazon Bedrock Knowledge Bases。想要实操指导，或与 AWS 专家讨论你的用例，请访问 Amazon Bedrock 入门页面 或联系 AWS。

我们想听听你们是如何做事故分诊的。欢迎在评论区分享你的经验。

关于作者