上一篇把 AI 主導混沌工程的實驗先收尾。從這篇開始，我想換一個工作現場更常遇到的問題：系統告警響了之後，先讓 AI 幫 SRE 做第一輪排查。

這個想法來自先前工作環境時看到的值班流程。

Ops SRE 收到告警後，先在群組通報，再找到 AP 負責人，也就是實際維護這套應用程式的人。AP 負責人接手後，還要開 Grafana 看 metrics、翻 logs、追 traces，最後拼出可能的原因，再交給 Ops SRE 整理回報。

這一輪查下來很花時間，最後也可能找不到問題點。我就在想，告警一發生，能不能馬上交給 AI 先調查？等團隊收到通知時，手上已經有第一輪結果，至少心裡有個底（其實是讓長官心裡有個底），知道要先往哪個方向確認。

把排查經驗整理成 SOP

每個團隊維運系統一段時間後，多少都會累積一些查問題的經驗。哪些告警先看哪個 dashboard、哪類錯誤先翻哪些 logs，久了就會形成一套大致的調查順序。

例如某個 API 成功率突然下降，大概會照這個方向查：

1. 先確認告警影響哪個服務、哪個 API，以及從什麼時間開始。
2. 查看 metrics，確認成功率、延遲、流量與資源使用量怎麼變化。
3. 搜尋同一段時間的 logs，看有沒有 timeout、連線失敗或 Circuit Breaker 打開。
4. 再用 traces 追一筆請求經過哪些服務，找出時間到底卡在哪一段。
5. 把觀察到的證據串起來，整理可能的原因與下一步。

這裡順便說明三種常見的 telemetry，也就是系統執行時留下的觀測資料：

• metrics 是數字趨勢，例如成功率、P99 延遲、CPU 與 thread 使用量。
• logs 是服務當下寫出的事件紀錄，可以看到錯誤訊息與程式執行狀況。
• traces 是單一請求跨服務的完整路徑，可以看出請求在哪個服務停最久。

服務不同，查詢內容當然會變。不過大致上都離不開「收到告警、根據經驗蒐集資料、比對時間、整理證據」這幾個步驟。

這些排查經驗整理成 SOP 後，就有機會交給 AI，讓它在告警發生時先調查一輪。

想像中的 AI SRE

我希望 AI SRE 收到 Grafana 告警後，可以依照調查 SOP 查詢 metrics、logs 與 traces，接著產生一份診斷報告。

等維運團隊收到通知時，手上已經有調查結果：

人類先檢查報告內容與證據，再決定後續怎麼處理。這樣維運團隊不用先在十幾個 Grafana panel 和不同監控系統之間來回切換，就能直接從最有可能的方向開始確認。

分析 AI SRE 有哪些需求

AI 會講得很有自信，這點大家應該都領教過（相信大家對於 完美 這兩個字應該不陌生）。應該要符合以下需求。

1. 收到告警就知道調查範圍

告警要帶入服務名稱、嚴重程度、發生時間與告警類型。輸入資訊不清楚，AI 很容易一開始就查錯方向，後面寫得再漂亮也沒用。

2. 調查順序要有明確 SOP

SOP 要寫清楚先查哪些 metrics、再看哪些 logs，以及什麼情況需要追 traces。

讓 AI 調查時有明確的起點與順序，避免相同告警今天看 CPU，明天突然跑去懷疑 DNS。

3. 每個結論都要附證據

如果證據不足，就直接寫「目前無法確認」。硬猜一個根因只會讓團隊瞎忙。

例如：報告不能只寫「可能是資料庫變慢」。它要附上對應時間的連線池使用量、錯誤 log 或 trace 延遲，讓人類能回頭確認。

4. 分清楚觀察、推論與待確認事項

這三種內容要分開寫。AI 調查結果不一定正確，最怕的是報告把通靈的結果包裝成已經確認的事實。

例如：「P99 延遲從 200ms 上升到 2s」是實際觀察；「下游服務變慢造成延遲」是根據證據做的推論；「剛才的部署可能是觸發原因」還需要人工對照變更紀錄。

5. 只讀取觀測資料

AI 透過 Grafana 查詢 Prometheus、Loki 與 Tempo。這三個系統分別提供 metrics、logs 與 traces。

AI 只能讀取這些觀測資料，不能修改服務、重新部署或操作 Kubernetes。它的工作是蒐集證據、整理推論與提出建議。人類保留處理 production 的決定權。

6. 報告要能提供下一步方向

報告要有告警摘要、影響範圍、時間線、原因與信心程度、佐證，以及接下來可以做的事情。

團隊看完後，至少要對兩件事有個方向：系統現在最可能壞在哪裡？下一步要先確認什麼？

接著來設計架構

需求整理完，接下來就要把它變成一套真的能運作的架構。

這套架構需要解決幾個問題：

• Grafana 告警要怎麼送進 AI SRE？
• metrics、logs 與 traces 要怎麼查詢，讓報告中的證據可以回頭查證？
• 診斷結果要用什麼格式，最後回報到哪裡？
• 整個調查流程要怎麼維持唯讀，避免 AI 直接改動 production？

接下來一樣請出受害者主角 lite-bank 當測試系統，讓 AI SRE 接收 Grafana 送出的告警，再依照 SOP 查詢 telemetry，最後產生診斷報告。

下一篇會從這些需求開始拆解 AI SRE 的架構。架構確認後，再進入實作與測試。

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