AI Agent 時代的 SRE：讓 Claude 成為你的 On-Call 夥伴

羅聖明 (Barry)／Sr. Engineer, Trend Micro

2026-04-23 13:45 - 14:25 @ 張榮發基金會國際會議中心 11F

議程

簡報

本場次將分享一位 SRE 工程師如何將 AI Agent 融入日常 On-Call 工作流程的真實經驗。演講從一個深夜告警的故事開場──同樣的 API 5xx 故障，傳統做法需要 2 小時以上才能完成從查詢、定位、修復到撰寫報告的完整流程，而透過 Claude 搭配 MCP/Skill 整合 OpenSearch、Jira、Confluence 等工具後，僅需 15 至 20 分鐘即可完成。

演講將涵蓋兩大核心主題：

第一，AI 在 SRE 工作中的三層價值──快速查詢與整合、智慧分析與建議、知識沉澱與重用；

第二，如何讓 AI 操作 MCP 串接各種 SRE 工具，包含 OpenSearch 日誌查詢、Jira Incident 搜尋、Confluence Runbook 檢索等實際整合範例；

此外，也會坦誠討論實務上常見的疑問，包含成本考量、資料安全策略、以及如何在沒有完整工具鏈的環境下從小處開始導入 AI。本場次適合所有對 AI 輔助維運有興趣的工程師，無論你是資深 SRE 還是剛入門的維運人員，都能帶走可立即實踐的方法。

聽眾收穫：

實戰經驗與思維轉換：了解一位 SRE 工程師如何從「被動救火」轉變為「AI 協作」的工作模式，以及這個轉變如何將故障調查時間從 2 小時大幅縮短至 15 分鐘。聽眾將理解 AI 在 SRE 場景中不是取代人，而是扮演「永遠不會累的 Junior SRE」與「記憶力完美的資深顧問」角色。

AI 時代的 SRE 職涯視角：重新思考 SRE 工作的核心價值──當重複性查詢與報告撰寫被 AI 大幅加速後，工程師能將更多時間投入「預防」與「改善」，回歸 SRE 的本質。

1. 自我介紹

講者 Barry 是 Trend Micro 的 SRE。

過去經歷包含：

• 銀行業
• 資安業
• 約 5 年 SRE / 維運相關經驗

日常工作型態

Barry 的日常是典型高壓 SRE 工作型態：

• On-call 24/7
• 一年 365 天都可能被叫醒
• 維護 10 個後端服務
• 橫跨 6 個雲端環境

他形容自己帶著筆電去過很多地方，包括：

• 環球影城
• 迪士尼
• 看極光

但即使在旅行或休息時，也可能被 on-call 告警打斷。

Opsgenie 打給我的次數，比我家人還多。

這句話點出了 SRE 日常最真實的痛點：告警不分時間、不分地點，只要系統出事就必須立刻處理。

2. 痛點：你有沒有被 Alert 淹沒過？

凌晨 02:15 的典型場景

凌晨 02:15，手機震動，Opsgenie 大響。

這通常代表：

• 系統炸了
• SLA 掉了
• SLO Burn Rate 衝破閾值
• SRE 必須立刻醒來處理

這不是一次性的偶發事件，而是 SRE 工作中反覆發生的日常。

每次 Incident 都要做的事

當告警發生時，Barry 過去通常需要依序完成以下工作。

全部加起來，通常需要：

2+ 小時

等到事件處理完、報告寫完，大腦也已經燒完，才能回去睡覺。

這不是偶爾，這是每次。

這裡的核心痛點不是單一工具難用，而是 incident response 的整體流程高度碎片化：

• 要查監控
• 要查 log
• 要查文件
• 要拉人
• 要判斷影響範圍
• 要找根因
• 要提出解法
• 要補報告

而這些步驟過去大多必須由人類逐一、序列式完成。

3. Demo：看看我現在怎麼做

真實 Incident 情境

這一段以一個真實 incident 走一遍新的處理方式。

某個下午，Opsgenie 大響，原因是：

SLO Burn Rate 衝破閾值

這代表服務錯誤率或延遲等 SLO 指標正在快速惡化，需要立即調查。

對 Claude 下的指令

Barry 開啟 Claude，輸入：

$ claude
xxx domain 5xx error，開啟調查

特別的是，他沒有明確告訴 AI：

• 要去哪裡查
• 要用什麼工具
• correlation ID 是什麼
• 要先查哪一層
• 要怎麼產出報告

這代表 AI Agent 的價值不只是「回答問題」，而是能根據既有 Skill 與環境知識，自行展開調查流程。

AI 做的第一件事：讀 Skill

AI 做的第一件事不是直接猜答案，而是讀取 Skill。

沒有 Skill，AI 可能會走得比人類還慢。

Skill 的作用，是把組織內既有的 SRE 經驗、工具使用方式、調查流程與系統知識封裝起來，讓 AI 知道該怎麼開始。

如果沒有 Skill，AI 即使模型能力很強，也可能因為不了解內部系統而亂查、慢查或誤判。

AI 做了人類做不到的事：並行調查

接著 AI 將任務分派給多個 sub-agent。

整體流程可理解為：

Prompt
  ↓
Main Agent
  ├─ Sub Agent A → OpenSearch Log
  ├─ Sub Agent B → Confluence
  ├─ Sub Agent C → Site24x7
  ├─ Sub Agent D → Icinga2
  └─ Sub Agent E → Prometheus

這些 agent 是並行執行，而不是序列執行。

對人類來說，通常是：

先看 Dashboard → 再查 Log → 再查文件 → 再看監控 → 再問 RD

但 AI Agent 可以同時查多個來源：

• OpenSearch log
• Confluence 文件
• Site24x7 監控
• Icinga2 告警
• Prometheus metrics

同一件事，兩種速度

這是 AI Agent 在 incident response 中最明顯的優勢之一：它可以平行化人類原本只能序列處理的調查工作。

Sub-agent 帶回來的發現

Sub-agent 帶回了一個重要線索：

這是第 4 次 OOM Kill 了。

也就是說，這不是第一次發生，而是同類型問題已經重複出現多次。

AI 不只是發現當下事件，也能把歷史資料與當前事件連在一起。

AI 直接把歷史發現寫進報告標題

AI 產出的報告標題是：

Pod OOMKill 第 4 次重複

這個標題很重要，因為它直接揭露了事件性質：

• 不是單次偶發
• 是重複性問題
• 可能代表根因尚未被修復
• 需要更深入處理，而不是只重啟服務或關閉告警

Before / After

同樣的故障，導入 AI Agent 前後差異明顯。

AI Agent 的價值不是讓 SRE 完全不用處理 incident，而是大幅縮短：

• 初步定位時間
• 跨工具查詢時間
• 歷史比對時間
• 報告撰寫時間
• ticket 建立時間

4. 優化與 Skill：當中的一些心得

Skill 的核心價值

Barry 對 Skill 的定義是：

Skill = 把多年 SRE 經驗封裝成一句指令。

Skill 不是單純的 prompt template，而是將組織內部的維運知識、工具操作邏輯與調查流程產品化。

換句話說，Skill 本質上是：

Skill = Human Knowledge / SRE Experience + AI Automation

它把人類過去累積的 SRE 經驗，轉換成 AI 可以執行、可以重複使用、可以並行調查的操作流程。因此 Skill 不是寫完就結束，而是需要隨著每一次 incident、每一次誤判、每一次新服務上線持續更新。

它讓 AI 知道：

• 發生某類 alert 時，要先查什麼。
• 某個服務對應哪些監控工具。
• log 在哪裡。
• 相關 dashboard 在哪裡。
• 哪些訊號可以用來判斷影響範圍。
• 哪些歷史 incident 可能相關。
• 最後報告應該怎麼整理。

Skill 的調查流程

簡報中整理的 Skill 流程如下：

這個流程的重點不是讓 AI 自動亂查，而是提供一條有結構的調查路徑。

關於模型：不是最貴的 model 就最好

每次跑「完整」調查其實有成本與時間壓力。

實際情境可能是：

• 凌晨出事
• AI thinking 五分鐘
• 大家都很急
• Leader 一直問
• RD 全被拉進群組
• 最後發現是 false alert
• 場面尷尬

這代表完整 deep investigation 不一定適合每一次 alert。

如果每次告警都直接用最強模型做完整分析，可能會造成：

• 回應太慢
• 成本偏高
• 團隊等待焦慮
• false alert 也消耗大量資源

因此，不是最貴、最強的模型就一定最好，而是要根據情境選擇合適的調查深度。

解法：兩層架構

Barry 的做法是將調查分成兩層：

這種架構的好處是：

• 快速判斷是否真有影響。
• 避免 false alert 直接進入昂貴調查。
• 真正有問題時，再投入完整分析。
• 降低成本與等待時間。
• 讓 incident response 更符合現場節奏。

AI 是日常通用加速器

AI Agent 不只在 incident 發生時有用，也可以處理日常維運問題。

例如：

「OpenSearch 怎麼沒 log？」
→ 丟 AI 查

「Kafka 是不是漏資料？」
→ 丟 AI 追

「定期巡檢要看這 10 個指標」
→ 丟 AI 跑

AI 在日常工作中的價值包括：

• 快速查詢 log
• 比對監控資料
• 執行巡檢
• 協助整理報告
• 輔助排查資料流
• 協助確認指標異常

因此，AI 不應只被視為 incident tool，而可以成為 SRE 的日常通用加速器。

5. 導入 AI：怎麼開始，以及踩過的坑

沒有驚天動地的導入計畫

Barry 的導入方式並不是一開始就有大型專案或完整規劃。

他的做法是：

• 每次遇到 Alert，同時試試 AI。
• 看 AI 能做到哪裡。
• 看 AI 哪裡做不到。
• 持續補知識與修流程。

他的導入軌跡大致是：

先從寫報告開始
  → 再到搜尋 Log
  → 最後才讓 AI 調查 Root Cause

這是一種漸進式導入，而不是一開始就把關鍵工作全部交給 AI。

坑 #1：AI 不認識你的系統

AI 再強，如果不知道你的系統長什麼樣子，也只能猜。

它可能不知道：

• Log 在哪個 index？
• 某個 service 是什麼服務？
• 5xx 要先查哪一層？
  • ALB？
  • Pod？
  • DB？
• Alert 來自哪個監控工具？
• 哪些 dashboard 對應哪個服務？
• 哪些 log 欄位可以拿來查詢？
• 哪些團隊負責哪個系統？

沒有這些環境知識，AI 的輸出就容易變成不可靠的猜測。

坑 #2：AI 再聰明，沒 Infra 也沒用

AI 能否幫得上忙，高度依賴可觀察性基礎建設是否完整。

如果：

• log 沒有結構化
• 沒有 correlation ID
• 跨服務沒有 trace
• 監控資料分散且無法串接
• dashboard 與服務對應關係不清楚
• alert 沒有足夠 context

那 AI 很難建立完整因果鏈。

例如：

• log 沒結構化，只能靠文字猜。
• 沒 correlation ID，就無法把同一次 request 跨服務串起來。
• 跨服務沒 trace，因果鏈會斷掉。

所以：

先把 infra 做好，AI 才幫得上忙。

這是前提，不是奇蹟。

核心公式

簡報給出一個核心公式：

AI 上限 = 環境知識 × Infra 可觀察性

這句話總結了 AI Agent 在 SRE 場景中的限制。

AI 的能力不是只由模型決定，而是同時受限於：

• 它對內部系統的認識程度。
• 它能取得的觀測資料品質。
• 可觀察性基礎設施是否完整。
• 工具是否能被 AI 正確呼叫。
• 組織知識是否被文件化與結構化。

6. Adoption：不是一開始就敢把關鍵工作交給 AI

Barry 強調，他不是一開始就敢這樣把 incident investigation 交給 AI。

信任是逐步建立的。

Stage 1：最早只敢讓 AI 寫報告

一開始的做法是：

• 調查自己做。
• 結論自己下。
• AI 只負責整理 notes。
• 效率約從 1 小時縮短到 20 分鐘。

這個階段，AI 扮演的是文書與整理助手，不碰關鍵判斷。

仍然不敢交給 AI 做關鍵工作。

Stage 2：人類調查與 AI 調查同時跑

第二階段開始讓 AI 一起調查，但人類也同步調查。

做法包括：

• 人類調查與 AI 調查同時進行。
• 兩邊結論拉 RD 一起 review。
• 發現 AI 亂講次數多。
• 主要原因是知識庫不夠。
• 每天補知識。
• 每個 issue 都修文件。

這個階段的重點是：

• 持續測試。
• 持續迭代。
• 不急著完全相信。
• 用實際 incident 累積修正資料。

Stage 3：產品上線或異動後，AI 先找到關鍵點

第三階段發生在某個晚上，產品或服務上線異動後出事。這類 onboarding / rollout 後的 troubleshooting，通常需要快速串起部署變更、監控異常、log 線索與服務呼叫關係。

當時：

• RD 還在找問題。
• AI Agent 先找到關鍵點。
• AI 直接畫出 Incident Flow Chart。
• 問題脈絡一眼可見。
• RD 確認 AI 的分析吻合。

這是信任建立的重要轉折點。

AI 不只是整理資訊，而是開始在真實 incident 中提供有效洞察。

Stage 4：團隊開始信任

最後，團隊逐漸開始信任 AI Agent。

但這種信任不是一夜建立的，而是：

• 一個一個 incident 測出來。
• 一次一次修文件修出來。
• 一次一次驗證結論累積起來。
• 由人類 review 逐步放大權限。

AI Agent 不是裝了就能用。

它是你一天一天餵出來的夥伴。

這句話是整場分享很重要的觀念：AI Agent 不是即插即用的魔法工具，而是需要用組織知識、真實案例、文件與回饋持續訓練出來的工作夥伴。

7. 實務與心得：常被問的問題

每次事件調查成本

每次事件調查的 AI 成本約為：

$5 - $10

這個成本要放在 incident response 的整體成本中看。

如果 AI 能把一次 incident 從 2 小時縮短到 15 分鐘，節省的不只是金錢，也包括：

• SRE 睡眠與體力
• RD 被拉進群組的時間
• Leader 等待狀態
• SLA / SLO 惡化時間
• 報告與 ticket 整理時間
• 團隊整體認知負擔

資料不離開信任邊界

對企業導入 AI Agent 來說，資料安全是基本前提。

Barry 的做法是：

資料不離開信任邊界。

具體包括：

• 使用公司內部端點。
• 不走外部 API。
• PII 不出門。
• 敏感資料不送出信任範圍。

這對資安業或任何處理敏感資料的組織都很重要。

能有 Skill 就用 Skill

對 AI Agent 來說，Skill 是讓它理解組織工作方式的重要資產。

實務建議是：

能有 Skill 就用 Skill，然後每天補一點知識。

Skill 不是一次寫完就結束，而是每天透過真實事件、錯誤案例與文件修正持續補強。

AI 讓效率增加，但不代表你比較輕鬆

AI 可以讓 SRE 更有效率，但不代表工作就變輕鬆。

因為：

• Alert 還是會叫。
• Incident 還是會發生。
• 人類還是要判斷與負責。
• AI 的輸出仍需要驗證。
• 知識庫與 Skill 需要維護。
• Infra 可觀察性還是要持續補強。

但至少，AI 可以讓你更快完成初步調查、報告與 ticket，降低凌晨被叫醒後的負擔。

Alert 還是會叫，但至少你可以馬上睡回籠覺。

總結

這場分享展示了 SRE 如何在 AI Agent 時代重新設計 on-call 工作流程。

核心不是讓 AI 取代 SRE，而是讓 AI 成為 on-call 夥伴，協助完成：

• 初步 triage
• 跨工具查詢
• log 分析
• metrics 比對
• 文件查詢
• 歷史 incident 對照
• 影響範圍判斷
• 根因路徑整理
• 報告撰寫
• ticket 建立

但 AI Agent 要真正有用，前提是：

• 系統知識要被文件化。
• Skill 要持續累積。
• log 要結構化。
• 要有 correlation ID。
• 跨服務 trace 要補齊。
• 監控、log、文件、metrics 要能被 AI 存取。
• 團隊要透過真實 incident 逐步建立信任。

最重要的公式是：

AI 上限 = 環境知識 × Infra 可觀察性

這代表 AI Agent 的能力上限，不只取決於模型本身，更取決於組織是否具備足夠清楚、可存取、可串接的可觀察性基礎設施與內部知識。

最後，AI Agent 不是裝了就能用的工具，而是需要長期餵養與迭代的夥伴。

當它被正確導入後，可以把 SRE 從每次 2 小時以上的深夜 incident 流程中解放一部分出來，讓人更快理解問題、更快完成回報，也更快回去睡覺。