背景
DevOps 團隊在處理系統事件時，常面臨「事件分級」（incident triage）的瓶頸。當警報觸發後，工程師通常需花費 45 至 60 分鐘手動拉取日誌、檢查服務健康狀態並關聯症狀，這段重複性的資料收集過程延遲了修復工作的開始。Circle K 作為一家在 27 個國家營運超過 17,200 家便利商店與燃料零售店的企業，其後端雲端基礎設施支撐著銷售點系統、忠誠度應用以及電動車（EV）充電應用。隨著數位營運擴張，警報數量增加，手動分級的工作負荷也隨之上升。 AWS ML Blog
發生什麼事
Circle K 與 AWS 合作，利用 Amazon Bedrock 建立了一套自動化分級系統。Amazon Bedrock 是一項全託管服務，透過單一 API（應用程式介面，讓軟體之間溝通的橋樑）提供基礎模型（FMs，Foundation Models，具備廣泛知識的大型 AI 模型）。該系統採用代理式 AI（agentic AI，能自主執行任務並使用工具的 AI 架構）來自主調查每個事件，並在警報觸發後的幾分鐘內，將結構化的摘要傳送至 Slack。部署此系統後，Circle K 的平均分級時間縮短至 15 分鐘以內，根據內部事件回應指標，這代表減少了 67% 至 75% 的時間。 AWS ML Blog
重點內容
該解決方案最初基於 Amazon Bedrock Flows 建構，後遷移至 Amazon Bedrock AgentCore。流程始於 Grafana 警報發布通知至 Amazon SNS（簡單通知服務，用於發送訊息的服務），再轉發至 Amazon SQS（簡單佇列服務，用於暫存訊息的佇列）。AWS Lambda 函數輪詢佇列並提取警報內容，接著呼叫 Flow。在 Flow 內部，兩個代理（Agent，執行特定任務的 AI 模組）平行運作：AWSResourceExplorerAgent 查詢跨多個工作負載帳戶的基礎設施，檢查 Amazon ECS（Elastic Container Service，容器託管服務）任務狀態、Application Load Balancer 目標健康狀態以及 CloudWatch 指標與日誌；OpenSearchExplorerAgent 則查詢 Amazon OpenSearch Service 的應用層日誌與分散式追蹤。由於 OpenSearch 會回傳大量日誌資料，將其隔離有助於管理每個代理的上下文視窗（context window，模型能同時處理的資訊範圍）。 AWS ML Blog
在上述兩個代理返回結果後，GitHubExplorerAgent 開始執行。它接收前兩個代理的輸出，尋找受影響服務的 GitHub 儲存庫，搜尋應用代碼、基礎設施定義與近期提交記錄，以定位問題根源並提出具體修復建議。所有三個代理的輸出會匯入一個 AnalysisPrompt 節點，這是一個不附帶工具的單一模型呼叫，負責生成結構化摘要，包含可能的根本原因、支持證據、受影響服務與負責人，以及建議的修復步驟。整個從警報到 Slack 訊息的過程視事件複雜度而定，耗時 5 至 15 分鐘。 原文
Circle K 選擇 Amazon Bedrock 的原因包括其託管特性與安全性。團隊評估過在自管基礎設施上使用開源代理框架，但這意味著需自行負責模型託管、提示詞版本控制、工具編排與安全控制。Amazon Bedrock 讓團隊能透過單一 API 存取基礎模型，且無需重寫代碼即可切換模型。此外，Amazon Bedrock Knowledge Bases（知識庫，提供檢索增強生成 RAG 能力的託管服務）處理內部產品卡片的摄取與檢索，團隊無需運行獨立的向量資料庫。在資料隱私方面，Amazon Bedrock 不會與模型供應商分享客戶資料，也不會使用這些資料訓練基礎模型，符合 Circle K 將生產日誌與內部服務細節輸入系統的安全要求。 原文
對使用者的意義
對於 DevOps 團隊而言，此系統將值班工程師從重複性的上下文收集工作中解放出來。工程師不再需要手動切換多個工具（如 CloudWatch、OpenSearch、GitHub）來調查警報，而是直接收到包含可執行上下文的結構化摘要。這使得工程師能立即採取行動，而非花費一小時弄清楚發生了什麼事。該系統透過整合 AWS IAM（Identity and Access Management，身份與存取管理）政策、VPC（Virtual Private Cloud，虛擬私人雲端）設定與日誌管線，無縫融入現有的 AWS 環境。 AWS ML Blog
