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

Circle K 的 DevOps 团队此前面对一个常见困境：告警触发后，值班工程师往往要先花 45–60 分钟拉日志、查服务健康、在多个工具间比对症状，才能开始修复。随着业务扩张，这一问题被放大——Circle K 在 27 个国家运营超过 17,200 家便利店和燃油零售门店，其支撑销售点系统、忠诚度应用和电动汽车充电应用的云原生基础设施运行在 AWS 上，服务越多，告警越多，重复的手动排查也越多。

原有分诊流程与痛点

团队通过 Grafana 监控多个 AWS 账户的基础设施，日常告警涵盖容器重启、错误率升高、延迟飙升和部署失败。每次告警的处理都遵循相似步骤：在 Amazon CloudWatch 查看近期日志、在 Amazon OpenSearch Service 检查应用级追踪、确认 Amazon Elastic Container Service（Amazon ECS）任务状态，再到 GitHub 中比对内部 runbook。团队识别出两个值得投入的方向：一是同样的日志查询、健康检查和 runbook 查找会在每起事件中重复；二是分诊的深度和速度会随值班工程师对受影响服务的熟悉程度而波动。

为什么选择 Amazon Bedrock

团队在动手前评估过多种方案，包括在自管理基础设施上运行开源智能体框架，但那意味着要自行承担模型托管、提示词版本管理、工具编排和安全控制。Amazon Bedrock 通过单一 API 提供基础模型，且可在不改代码的情况下更换模型；由于 Circle K 本身运行在 AWS 上，它能直接接入现有的 IAM 策略、Amazon VPC 配置和日志管道。编排与检索由两项托管能力承担：Amazon Bedrock 提供智能体编排和原生工具调用，Amazon Bedrock Knowledge Bases 作为全托管 RAG 能力负责内部产品卡片的摄取与检索，团队无需自建向量数据库。数据隐私方面，原文明确说明 Amazon Bedrock 不与模型提供方共享客户数据，也不将其用于训练基础模型。

系统架构

初始方案以 Amazon Bedrock Flows 作为编排层，协调多个各司其职的专用智能体。链路起点是 Grafana 告警向 Amazon Simple Notification Service（Amazon SNS）发布通知，再转入 Amazon Simple Queue Service（Amazon SQS）队列；AWS Lambda 函数轮询队列、提取告警载荷并调用 Flow。Flow 内两个智能体并行执行，其中 AWSResourceExplorerAgent 跨由 AWS Organizations 管理的多个工作负载账户查询基础设施，检查 Amazon ECS 任务状态、Application Load Balancer 目标健康和 CloudWatch 指标等。原文还介绍了后续向 Amazon Bedrock AgentCore 的迁移及规模化过程中的经验。

编辑部观察

这条案例的价值不在模型本身，而在把“重复的上下文收集”从人身上剥离出来。值得注意的是，67%–75% 的降幅来自团队内部的事件响应指标，属于厂商与客户自述口径，并非独立第三方验证；15 分钟是平均分诊时间，不等于平均修复时间。对考虑类似方案的企业，可先核查三点：告警到工单的现有链路是否已标准化、内部 runbook 是否足够结构化以供检索、以及日志中敏感信息的处理边界是否与所选服务的数据条款一致。