上一篇整理了 AI SRE 的需求，告警的來源和目的地、監控資料怎麼查、報告怎麼產生，以及整個過程怎麼維持唯讀。

需求列完，接著要詳細討論每一個需求。

告警的來源和目的地

lite-bank 的 metrics、logs 與 traces 分別存放在 Prometheus、Loki 與 Tempo，最後統一由 Grafana 查詢與產生告警。因此這次 AI SRE 直接把 Grafana 當作告警來源。

告警觸發後，Grafana Alerting 會透過 webhook 將內容送到 AI SRE Runner，由 Runner 啟動 Agent 進行調查。

通知目的地先選 Slack，主要是方便 demo，也符合 SRE 常被通訊軟體叫起床的工作日常。Runner 收到告警後，會先在 Slack 告警頻道貼出通知。Agent 完成調查後，再把調查摘要與完整報告回覆在同一則 Slack 告警訊息下方。

實務上也可以改成收到告警後自動建立 Jira ticket，等 Agent 調查完成，再將報告附加到 ticket。這次先使用 Slack，維持簡單流程。

如何取得 metrics、logs 與 traces

AI 要分析告警，第一步是讓它能夠查詢 Grafana 裡面的觀測資料。這裡有兩種做法：使用 MCP (Model Context Protocol)，或是自行開發工具呼叫 API。

目前 Grafana 官方已經提供 Grafana MCP Server，可以自建，串接後，AI 就能直接呼叫，不需要再替每個資料來源設計一套呼叫方式。

這種方式的優點是接得快，適合讓 AI 自由探索資料。缺點是能查什麼、回傳多少內容，以及資料格式長什麼樣子，都會受到 MCP Server 的功能和設計影響。

另一種做法是自行開發查詢工具，透過 Grafana API 讀取 Prometheus、Loki 與 Tempo。這條路前期需要多花一些時間整理查詢方式，不過每個工具要查什麼、允許多長的時間範圍、最多回傳多少資料，都可以自己決定。

兩種方式的差異大約可以整理成這樣：

因為系統的調查流程已經有明確 SOP，我希望每一次相同的告警 AI 都要看到一樣的資料，所以選擇自行開發唯讀查詢工具，讓 metrics、logs 與 traces 都透過 Grafana API 取得，再將結果整理成固定格式交給 AI。

最後決定主要調查流程使用自行開發的 API 工具，確保查詢內容與回傳格式穩定。當固定工具取得的證據仍不足時，AI 可以透過 MCP 進一步探索，補查原本流程沒有涵蓋的資料。這條路只在必要時開啟，並限制查詢範圍與使用次數，避免調查失控。

把資料整理成特徵值

Metrics 原本是一段隨時間變化的數值，也就是 time series。服務與 API 一多，一次查詢就可能產生大量資料點。完整交給 AI 會占用大量 context，也容易讓它混淆不同的時間、標籤與單位。

因此查詢工具會先把資料整理成容易判讀的特徵，再交給 AI：

每個特徵值都要保留查詢時間區間。過去五分鐘錯誤率 40%，和過去三十分鐘錯誤率 8%，可能來自同一場事故。查詢時間越長，短時間異常越容易被稀釋。AI SRE 會將目前區間和相同長度的穩定狀態比較，讓 AI 知道數值涵蓋哪段時間，以及變化幅度有多大。

整理方式也要配合 metrics 的性質。延遲要看 P99，才能看出最慢的一小群請求；連線池與 thread 要保留最高使用率；Pod restart 要看發生次數；OOMKilled 則要確認有沒有發生。全部使用平均值，很容易把真正需要注意的尖峰蓋掉。

原始資料仍然保留在 Grafana，報告也會附上實際查詢與 trace ID。AI 先使用精簡資料判斷，證據不足時再回頭查看完整資料。

最後決定先依照資料性質與查詢時間區間整理特徵值，再將精簡結果交給 AI；完整資料留在 Grafana 供後續查證。

調查流程的控制方式

工具準備完成後，下一個問題是由誰控制調查順序。

最簡單的做法，是把完整 SOP 與每個工具的使用方式都寫進 SKILL.md。LLM 收到告警後，先閱讀 skill 內容，再照上面的步驟使用工具查詢 metrics、logs 與 traces，最後整理結果並產生報告。

這種方式很有彈性。想增加調查步驟時，只要更新文字說明，LLM 也能根據前一步結果調整方向。SOP 寫進 SKILL.md 後，LLM 通常會依照指定順序調查；不過這些步驟仍是文字指引，無法保證 AI 每一步都會執行，也難以固定工具失敗與資料不足時的處理方式。

另一種做法仍然會使用 SKILL.md，只是 skill 的角色會改變。它不再要求 LLM 自己控制每一個查詢步驟，改成指導 LLM 呼叫調查工具、閱讀調查結果、進行因果推論，以及依照固定格式撰寫報告。

調查工具會依照 SOP 查詢資料、整理特徵值與判斷基本條件，再把結果交給 LLM。LLM 接著將 metrics、logs 與 traces 串成因果關係，例如從流量持平、P99 上升、client span 變慢與 connect timeout，推論下游呼叫變慢。固定流程由程式控制，因此相同類型的告警會遵循相同的調查規則。

報告會將內容分成三類：

固定流程也可能遇到沒有涵蓋的狀況。當調查資料顯示資料不足時，LLM 才會透過 MCP 進一步探索，而且會限制查詢範圍與使用次數。找到足夠證據後就回到報告流程，避免一路查下去沒有收尾。

最後決定由程式依照 SOP 執行固定調查，SKILL.md 負責指導 LLM 如何使用工具、判讀資料與撰寫報告。診斷結果會先以摘要方式回覆在 Slack 告警訊息下方，再附上完整報告，讓值班的人可以先掌握結論、影響與下一步。

AI SRE 的權限範圍

AI SRE 只負責調查與提出建議，涉及修改設定與操作 Kubernetes 的行為都保留給人類決定。

主要流程由查詢工具使用 Viewer 權限的 service account token 讀取 Grafana 資料，再把整理後的結果交給 LLM 推論。

資料不足時，LLM 才會透過 MCP 補充調查，而 MCP 連接 Grafana 使用的 token 同樣只有唯讀權限。兩條查詢路徑都只能讀取 metrics、logs 與 traces，所有 production 操作仍由人類審查與執行。

最後架構

前面四個問題都定案後，完整架構大致如下：

圖：AI SRE 分成 LLM 與調查程式兩個主要模組。調查程式依照 SOP 蒐集並整理資料，LLM 根據 SKILL.md 進行推論與撰寫報告；資料不足時，再透過 MCP 補充調查。

核心分成兩個主要模組：調查程式依照 SOP 執行固定流程，LLM 則根據 SKILL.md 判讀資料與撰寫報告。Runner 負責接收告警，Grafana 提供觀測資料，Slack 接收最後的調查結果，人類保留 production 的操作權。

架構設計到這裡先定案。下一篇開始進入實作。

今天就先寫到這，我們明天見！