Circle K 如何用 Amazon Bedrock 将 DevOps 故障分诊缩短至 15 分钟内

Circle K 运营着覆盖 27 个国家、超过 17,200 家便利店和燃油零售门店的网络，其云原生基础设施支撑销售点系统、忠诚度应用和电动汽车充电应用。随着服务数量增加，告警量同步上升，值班工程师每处理一次告警往往要先花 45–60 分钟拉日志、查服务健康状态、跨工具关联症状，之后才能开始修复。 为此，Circle K 的 DevOps 团队用 Amazon Bedrock 搭建了自动化分诊系统。初始架构以 Amazon Bedrock Flows 作为编排层：Grafana 告警经 Amazon SNS 转发到 Amazon SQS 队列，Lambda 函数轮询队列并触发 Flow。Flow 内两个智能体并行运行，AWSResourceExplorerAgent 跨多个工作负载账户检查 ECS 任务状态、负载均衡器目标健康和 CloudWatch 指标与日志，OpenSearchExplorerAgent 查询 OpenSearch 中的应用日志与分布式追踪，并独享存放服务产品卡的知识库。随后 GitHubExplorerAgent 依据前两者输出定位受影响服务的仓库，检索代码、基础设施定义和近期提交。三路结果汇入一次无工具的模型调用，生成包含可能根因、支撑证据、受影响服务与负责人、建议修复步骤的结构化摘要，再回传 Lambda 发布到 Slack，全流程耗时 5–15 分钟。 文中给出的示例中，某服务 HTTP 5xx 错误率连续 3 分钟超过 5%，系统定位到数据库连接池耗尽，并结合营销活动时间点建议引入 Amazon RDS Proxy 或改为复用连接。部署后，团队平均分诊时间降至 15 分钟以内，按内部事件响应指标计算降幅为 67%–75%。 随着日志量和知识库持续增长，部分事件所需分析时长超出单个 Flow 节点能力。团队将智能体逻辑容器化并迁移到 Amazon Bedrock AgentCore Runtime，把三个专用智能体合并为单一会话内运行的智能体，会话最长支持 8 小时，结果仍在 15 分钟内返回 Lambda。AgentCore Gateway 统一代理对 OpenSearch、Knowledge Bases 和 GitHub 等数据源的访问，集中管理权限并简化数据源增删。