上一篇把 AI SRE 的實作拆解，從 metrics query、服務相依關係、logs、traces，一路講到最後整理給 LLM 的調查資料。接下來就安排一場演練，實際看看 AI SRE 查得怎麼樣。

我先啟動 Runner，再用 Chaos Mesh 對 teller-service → transaction-service 注入網路延遲。等 Grafana 告警出現後，就讓 AI SRE 接手，看看它能不能只靠 metrics、logs 與 traces，把問題縮小到正確的方向。

整個調查過程中，我沒有提供 Chaos Mesh 設定或演練內容。AI SRE 看得到的，只有系統當下留下的觀測資料。

模擬故障，等待告警

測試開始時，我先啟動 AI SRE Runner。Runner 收到 Grafana webhook 後，會先把告警放進 queue，再交給 Agent 開始調查。確認整套流程與 Slack 連線正常後，接著用 Chaos Mesh 延遲 teller-service → transaction-service 這條路徑。

核心設定如下：

spec:
  action: delay
  selector:
    labelSelectors:
      app.kubernetes.io/name: teller-service
  direction: to
  target:
    selector:
      labelSelectors:
        app.kubernetes.io/name: transaction-service
  delay:
    latency: "5s"
    jitter: "1000ms"
    correlation: "50"

這個 NetworkChaos 會從 teller-service 對 transaction-service 的流量下手，加入 5 秒延遲與 1 秒 jitter。jitter 是延遲的波動範圍，用來避免每個請求都呈現完全一樣的延遲；correlation: "50" 代表前後兩次延遲有 50% 的關聯，讓延遲變化不會每次都完全隨機跳動。

這次等的是存款 SLO Burn Rate 告警。Burn Rate 可以理解成 error budget（錯誤預算）的消耗速度。

假設某個 API 的 SLO 是 99.9%，代表每一百萬次請求大約可以容忍一千次失敗。Burn Rate 越高，這些額度就消耗得越快。

這條 Critical 告警會同時檢查過去一小時與最近五分鐘的資料。過去一小時的資料用來確認整體影響，最近五分鐘的資料則用來確認問題還在持續。兩個時間區間的 Burn Rate 都超過 14.4 倍時，Grafana 才會觸發告警，避免短暫抖動一直噴告警。

Slack 收到告警，AI SRE 開始調查

故障注入後，存款 SLO Burn Rate 升到 16.1 倍，超過 14.4 倍的告警門檻，Grafana 隨即觸發 teller-service 的 Critical 告警。

圖：Slack 收到 Critical 告警，AI SRE 已經開始調查。

Slack 收到告警時，Runner 也開始處理。AI SRE 接著按照前一篇介紹的流程，查詢告警服務、上下游服務、業務 metrics、應用與平台資源、log patterns 與慢 trace 樣本。

調查結果回到 Slack

AI SRE 完成調查後，會回覆在原本的 Slack 告警下方。值班人員可以在同一串訊息看到結論、影響與建議動作，完整報告也會一起附上。

圖：AI SRE 將對外呼叫路徑列為問題方向，並建議檢查連線建立、timeout 設定與網路狀況。

Slack 摘要先給出三個重點：

• 存款成功率驟降，延遲大幅拉長。
• 問題方向落在 teller-service 的對外呼叫路徑。
• 下游帳戶服務與交易服務本身運作正常，整體信心程度為中。

Slack 裡先放摘要，接著打開完整報告，看看 AI SRE 是根據哪些調查結果得到這個方向。

完整報告

影響範圍與主要指標

圖：報告列出成功率、P99、流量、error budget 與上下游狀態。

存款成功率從 100% 降到 71.3%，P99 從 270.4ms 升到 1667.7ms，流量只從 2.22 req/s 變成 2.24 req/s。延遲和錯誤都變嚴重，流量卻幾乎沒變，因此報告先排除了流量暴增。

調查時間線

圖：報告保留告警觸發、調查 SOP 與報告產出的時間。

時間線記下告警觸發、調查與報告產出的順序。報告在 00:03 產出時，告警仍是 firing，代表問題當時還沒恢復。

問題方向與因果鏈

圖：報告將 metrics、traces、上下游健康與資源狀態串成因果鏈。

這張圖是整份報告的核心。P50 只有 28.3ms，代表至少一半的請求很快就完成；P99 卻升到 1667.7ms，抽樣到的慢 trace 也都在一秒左右。換句話說，平常的請求看起來很快，但其中一小批會突然卡住超過一秒。AI SRE 接著對照三種操作的慢 trace、下游服務狀態與 teller 資源使用情形，排除流量暴增、下游服務異常與系統資源用盡，最後將調查方向縮小到 teller-service 的對外呼叫路徑。

疑似觸發物與建議動作

圖：報告將網路延遲、連線建立與 timeout 異常列為待確認方向，並給出止血、短期與防復發建議。

AI SRE 不知道這是一場演練，所以先按照真實事故給出建議：確認網路與 timeout 狀態，影響擴大時再考慮降級或限流。狀況解除後，還要補強調查工具，記錄 teller 呼叫下游時實際等待多久，並找出為什麼沒有整理出 timeout 或連線錯誤的 logs。

總結

這次從 Chaos Mesh 對 teller-service → transaction-service 注入網路延遲開始。Grafana 偵測到存款 SLO Burn Rate 超過門檻後，Slack 收到告警，Runner 也接著啟動固定調查流程，最後由 AI SRE 整理調查結果並產生報告。

如果把這份報告當成第一輪調查結果，我覺得是有幫助的。AI SRE 在不知道演練設定的情況下，把問題縮小到正確的對外呼叫路徑，也排除了流量、下游服務與系統資源問題，值班人員不用再從所有 metrics 重新查起。這個方向與我注入延遲的位置一致，現有資料仍無法確認實際原因，所以這份報告還不能直接拿來結案。

Chaos Mesh 注入的延遲是 5 秒，抽樣到的慢 trace 卻只有約 1 秒。一種可能是 teller-service 等到約 1 秒就先 timeout，還沒收到延遲後的回應。Loki 沒有取得可用的 log pattern，traces 也缺少 client span，所以 timeout 只能列為待確認方向，報告的信心程度也保留在「中」。

看完報告後，我開始懷疑，讓程式直接判斷資料是否充足，可能不太適合。這次 business metrics 有結果，也有 signal 命中，程式就把 insufficient 設成 false，沒有開放 MCP 補查。但 log pattern 沒有結果，traces 也缺少 client span，報告最後仍然無法確認實際原因。因為程式根本不會知道目前查到的資料到底夠不夠判斷。

想了一下，我覺得程式負責收集資料就好，記錄哪些查詢成功、哪些回傳空結果，以及缺少哪些監控資料，不用急著判斷資料夠不夠。等 AI 看完調查結果後，再判斷現有資料能不能支撐結論。資料不夠時，AI 再決定是否需要透過 MCP 繼續補查。

查詢權限仍然由 Runner 控制。AI 提出補查需求後，Runner 再檢查可用工具、查詢時間範圍與呼叫次數，避免調查一路查下去停不下來。

AI SRE 的實測先走到這裡。下一篇換個主題，看看 AI 還能接手哪些重複工作。

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