當許多工程團隊在嘗試將 AI 引入維運時，最容易陷入的誤區就是追求完全自動化的 AI Agent（智能體），希望 AI 能直接修復問題。然而，在處理生產環境故障時，穩定性與可預測性遠比自動化重要。旅遊平台 Expedia 開發的 Service Telemetry Analyzer（簡稱 STAR）提供了一個非常務實的參考模型：將 AI 定位為輔助分析工具，而非決策者。
縮短故障排除的關鍵指標
在 SRE（網站可靠性工程）的實務中，有兩個核心指標決定了服務的可用性。第一個是 TTK（Time to Know），即從故障發生到確定問題原因所需的時間；第二個是 TTR（Time to Recover），即從發現問題到恢復服務的時間。STAR 平台的核心目標就是透過 AI 快速分析遙測數據，將 TTK 降低，讓工程師能更快進入修復階段。
從數據到診斷的確定性工作流
STAR 並非讓 AI 隨意猜測原因，而是採用一種確定性的工作流（Deterministic Workflow）。它將過程拆解為：收集遙測數據、使用特定領域的提示詞進行分析、整合中間結果、最後產出總結報告。
這種設計避免了 AI 常見的幻覺問題。系統會從 Datadog 等監控工具中提取標準化的基礎設施數據，例如 Kubernetes 的 Pod 重啟事件、健康檢查（Liveness/Readiness Probe）失敗紀錄，以及 JVM（Java 虛擬機）的堆積記憶體使用率與垃圾回收（GC）活動。由於這些基礎設施指標在不同語言開發的服務中具有一致性，AI 能夠在統一的標準下分析不同服務的健康狀況。
技術架構與非同步處理
在實作層面，STAR 最初使用 FastAPI 構建，但隨著分析任務增加，團隊發現大部分的操作屬於 I/O 密集型（I/O Bound），即系統大部分時間在等待 Datadog 的 API 回傳數據或等待 LLM（大型語言模型）生成文字。
為了提升效率並處理 API 的速率限制（Rate Limits），團隊將背景任務遷移至 Celery 異步架構，並使用 Redis 作為訊息代理（Message Broker）與結果後端。這使得系統能併發處理多個分析任務，而不會因為單一 LLM 請求的延遲而阻塞整個流程。
提示詞鏈接與工程實務
STAR 在 AI 的應用上採取了克制且精準的策略。它沒有使用複雜的 RAG（檢索增強生成）或 Function Calling（函數調用），而是採用提示詞鏈接（Prompt Chaining）。這意味著系統會將分析過程分解為多個專門的步驟，每個步驟由特定的提示詞引導，最後再將所有分析結果彙整。
這種做法確保了分析過程的可追溯性。為了持續優化這些提示詞，團隊引入了 Langfuse 進行追蹤與評估，並由領域專家（SME）對 AI 產出的結果進行人工審核，確保建議的準確性。
AI 輔助而非自動化替代
STAR 的定位是輔助工具。AI 負責處理繁瑣的數據彙整與初步分析，而最終的驗證與決策權依然留在工程師手中。這種人機協作模式在高風險的生產環境中至關重要，因為錯誤的自動化修復可能會導致更大規模的崩潰。
未來展望與擴展
Expedia 計劃將 STAR 擴展到更深層的維度，例如整合服務依賴關係圖、引入 MCP（模型上下文協定）以整合更多工具，甚至將其應用於混沌工程（Chaos Engineering）中，用來分析人為注入故障後的系統反應。
對於追求可觀測性升級的工程團隊來說，STAR 的經驗證明了：AI 在維運中的價值不在於替代工程師，而是在於將海量的遙測數據轉化為可理解的結構化診斷報告，從而將工程師從重複的數據挖掘工作中解放出來。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。