CASE · CIRCLE-K
Circle K：用 Bedrock Agent 做故障初查，45–60 分钟降到 15 分钟内
Agent落地实操 · 2026-11-03
Write-up is in Chinese for now. English translation is pending.
初查耗时（前）
45–60 分钟
初查耗时（后）
15 分钟内
证据等级
C · 厂商自述
背景（公司、场景、痛点）
Circle K 是全球便利与燃油零售连锁。AWS 文称其运营超过 17,200 家门店，覆盖 27 个国家；门店背后的 POS、会员与电动车充电等应用跑在 AWS 上。数字化铺开后，云上服务与告警一起变多，DevOps 仍要在每次告警后先「拼上下文」，才能谈修复。
痛点不是「有没有监控」，而是初查税：同一套查日志、看健康度、翻 runbook 的动作，在每个告警上重复；当班工程师若不熟该服务，深度与速度还会抖。文章把这定性为会影响恢复速度的结构性成本。
他们也曾评估自建开源 Agent 框架，但意味着自己扛模型托管、prompt 版本、工具编排与安全控制。既然生产已在 AWS，最终用 Bedrock 吃现成 IAM / VPC / 日志管线，并把编排与检索交给托管能力。
原来怎么做
改造前的一天大致是：Grafana 冒出容器重启、错误率升高、延迟尖刺或发布失败；工程师依次打开 CloudWatch、OpenSearch、ECS，再去 GitHub 对 runbook——有用，但可重复劳动会随服务接入线性涨。
来源给出的基线是：典型人工初查约 45–60 分钟，之后才进入真正修复。传统监控聚合与 runbook 自动化能堆信号，却难像熟手一样跨工具做关联推理（来源表述）。
实际做法（步骤与架构）
流水线入口很克制：Grafana → SNS → SQS → Lambda，再调用编排层。这样告警先入队，由 Lambda 解析后再拉调查，而不是让同步 API 直接扛风暴。
- 并行取证。AWSResourceExplorerAgent 跨 Organizations 下多账号查 ECS 任务、ALB 目标组、CloudWatch 指标与日志；OpenSearchExplorerAgent 单独查应用日志与分布式追踪，并独占装有「产品卡」（服务依赖说明）的 Knowledge Base——拆开是为了避免大日志撑爆上下文。
- 定向搜代码。GitHubExplorerAgent 故意后置：带着前序线索再搜仓库、IaC 与近期提交，提出更具体的修复方向。文中示例曾据此指向「每请求新建数据库连接」一类代码层原因。
- 一次汇总。AnalysisPrompt 是无工具的单次模型调用，输出固定结构：可能根因、证据、受影响服务与 Owner、建议步骤；文称值班大约两分钟可扫完。
- 推到 Slack。Lambda 把摘要发到频道。告警到消息整体约 5–15 分钟，视复杂度而定。
Flows 版跑了数月，简单单服务可在 10 分钟内出结论；后来日志与知识库变大，单节点扛不住长调查。团队先做日志过滤、缩上下文、拆 Flow，仍不够后，于 2026 年 4 月迁到 AgentCore Runtime：同一套分析步骤收成单 Agent 长会话，经 AgentCore Gateway 访问 OpenSearch、知识库与 GitHub，并保留 OpenTelemetry 追踪便于调 prompt。目标不变——15 分钟内回到 Lambda 再发 Slack。
人在环上写得很清楚：今天系统只给到「可能原因 + 建议」，重启、扩容、回滚仍由工程师做；下一步才计划接 DevOps Agent，且每个动作要在 Slack 先批。另规划接入 Jira、Confluence 与更多 runbook。
Instead of raw alerts, on-call engineers now receive actionable context — AWS ML Blog（Circle K 客户故事）
效果（数字与声称方）
数字全部来自 Circle K 内部 incident-response 指标，经 AWS 文转述，不是第三方审计：
- 平均初查：45–60 分钟 → 15 分钟内（自称降幅 67–75%）——声称方：Circle K 团队 / AWS 转述
- 简单单服务摘要：5–8 分钟——同上
- 复杂多服务：此前人工常超过一小时，现称仍在 15 分钟内完成初查——同上
定性变化（来源归纳）：摘要格式统一，不熟该服务的值班也能按同一结构升级；假告警在「服务健康且无关联错误」时可更快确认。文中「营销活动打满连接池」是流程示意，未声明为某一公开工单编号。
reduced mean triage time to under 15 minutes, a 67–75 percent reduction — AWS ML Blog，基于 team's internal incident-response metrics
没说清楚的地方
- 统计窗口、样本量、分位数（P50/P90）未公开
- 根因误判率、摘要被驳回/无用的比例未知
- Bedrock 与日志查询成本、维护人月未披露
- 具体基础型号未写
- 是否覆盖非 AWS 工作负载未说明
Models at Work 等转述与 AWS 文数字一致，并标明未经独立核验；本页不以转述新增数字。
我们的判断
模式可抄，数字打折；小团队先做「只读摘要」，不要一上来自动改生产。
能不能抄：中等。价值（缩短 MTTR 前端的 triage）清楚，技术路径（告警总线 + 只读取证 + 固定摘要 + IM）也不神秘；但跨账号权限、知识库与误判复盘有持续成本。
前提条件：
- 告警 / 日志 / 部署记录可 API 读取且不太脏
- 值班沟通集中在可推送的 IM
- 有人维护工具定义、prompt 与驳回复盘
- 权限能做成最小只读
坑：脏遥测会让错误结论来得更快；把「初查加速」说成「自动修复」会高估；告警量很低时集成可能亏本；厂商故事缺样本量。
如果你要试的最小版本：选一个告警最吵的服务：告警 webhook → 脚本只读拉近 30 分钟日志与部署记录 → 用任意 LLM 生成固定四段摘要（现象/证据/可能原因/下一步）打到值班群。先不要自动改基础设施；连续两周对照「有摘要 vs 无摘要」的开工时间，再决定是否上知识库与跨账号权限。
我们的推测（非原文）：产品卡与 GitHub 后置搜索，可能是摘要质量的关键杠杆——没有服务依赖说明时，模型很难给出「该找谁、该改哪」级别的建议。