DevOpsDays Taipei 2026 心得
這次在 DevOpsDays Taipei 2026 分享了《Alert 分析進化史：從 Excel 到 AI Agent》。這個專案我從接手到現在大約做了一年，這次分享聚焦在怎麼把 Alert 的事後分析，從一份 Excel 一路長成 AI 分析驅動的流程。
這篇把當天講的、還有當天沒講清楚的，一起整理得更完整一點。
本文的內容與觀點皆由我自己撰寫，Claude Opus 4.8 協助潤飾文字。
正式開始前，補一下當天忘了先說清楚的前提：
- 簡報裡講的「AI」：我全部都是用 Claude Code。具體上是用 Skill 來控制 Workflow，所以這套經驗其實跟用什麼模型無關，換個模型、換個工具，道理一樣成立。
- 這裡的「Alert」全是應用程式層級的 Alert，不是 Infra 或系統層級。例如：不是 CPU、DB Loading 這一類錯誤，而是呼叫 API 出問題、或某個功能突然被大量使用這類型的。
這篇想回答的問題
故事的起點是一份 Excel：第一線同事每天用它記錄 Alert，出事再去翻 Kibana 找錯誤。流程是這樣的：
- Alert 發出
- 用 Excel 記錄
- 去 Kibana 找錯誤
這個做法是對的。只是真正的問題在別的地方：網路天生就不是 100% 穩定，量一大，本來就會有一定比例的 Alert 冒出來。這篇想回答的是，這些 Alert 該怎麼好好被管理、被記錄起來，而不要全部塞進 Excel 裡。講白一點，就是不要讓這些其實是假警報的 Alert，三更半夜把整個部隊叫起床。
第一個困難：這是一個跨團隊任務
一開場我就丟出第一個困難：這是跨團隊任務，而每個團隊都有自己的業務目標，平常本來就是以產品功能為重，所以調整 Alert 這件事的優先度，是很容易被往後排的。
既然優先度有困難，我就選了一條阻力最小的路：
開團隊 repo → 用 AI 分析 log → 把詳細資訊記錄成 issue → 建立 issue 看板來追蹤。
選這條路的關鍵，是 repo 上的 issue 完全獨立：團隊的主要任務不會被這個 repo 的 issue 干擾，對管理來說只要定期檢視就好。不去干擾其他團隊的優先順序，是這套設計推得動的前提。
第二個困難：Log 格式散亂
第二個困難更根本：
Log 格式散亂 → 程式分析不友善 → AI 沒辦法有效利用工具分析 → 最後建出來的 issue 很雜亂。
Log 格式，我花了非常多時間想辦法統一。現況是：在建立 Alert SOP 的同時定義 Alert 類型，再順水推舟定義出 Alert Model。
說是 Alert Model，其實就是 Log 規範，這部分有參考 OpenTelemetry 的定義。光是這件事，大概就討論了三個多月，才總算有第一個範例在線上跑起來。
調 Log 的心得
會後有朋友問我 Log 要怎樣才能寫好，我才想到我忘了放上這個說明。
我很久以前就在不斷調校 Log，更早的筆記可以參考 Log 層級的小筆記。
分享一個我自己的思考框架：
因為 Log 本質上就是 Event，所以可以直接參考 Event Listener 的機制來設計它。 一個 Class 搭配多個 Property，對應到 Log，就是 Message + Attribute：
Event ─ Class + Property
Log ─ Message + Attribute當然本質或應用上一定還有更多差異，但這個思路對於團隊該怎麼建立 Log 是很有幫助的起頭。每次設計 Log 時，都可以反覆問自己兩個問題：
- 這個 attribute 對於理解上下文到底有沒有用？
- 這個 message 真的算是一個「類型」嗎？
難的不是技術，是別人不這麼覺得
我的經驗知道這樣設計有助於分析 Alert，但不是每個團隊都能接受。所以 Alert 分析裡才會多一塊在做「錯誤合併」，而這塊非常困難。
我們都可以預期 AI 會亂做；真正麻煩的是，要怎麼叫 AI 把它亂做的結果持續更新、記錄下來。我目前的概念是：在 issue 裡存 regex，但 AI 要怎麼在一堆 issue 裡找到對應的那條 regex。這點我到現在還沒解決，雖然可以用各種 JSON 來記錄，只是管理肯定是困難的，可以想像有個人一直開出以前開過的 issue，這該怎麼管？
講到這裡會發現，第二個困難其實也是個「人」的問題：我覺得好分析的，別人不這麼覺得。而事實上 AI 也真的很難分析它，就像同事在 5/28 的 Meetup 分享過的那句話：這個難分析的模糊，會被不斷放大。
回到本質：人覺得好做，AI 才會覺得好做
繞了一圈，最後想回扣一個重點：通常要人覺得好做，AI 才會覺得好做。 那些最初的技術本質，其實一點都沒變：
- 要把程式寫好，AI 才有辦法接手、並寫出好的程式。
- Alert 管理要把 Log 寫好，AI 才有辦法接手、並分析出根因。
順便分享兩個我最近剛好遇到、長得很像的例子：
- 規格要先把情境想清楚，AI 才有思路寫出真正符合業務需求的程式。
- 簡報要先把大綱想好，AI 才有辦法照著流程把投影片產出來。
這幾個例子都有兩個共通點：
- 流程要進到下一個階段，前一個階段就必須把事情全部做完。 這剛好對照到我系統裡的設計：每個流程都是一個節點，之所以能在任何一個階段重來，正是因為前一個階段已經完備了。
- 把「AI」這兩個字換成「新人」、或是「隔壁同事」，結論還是對的。 所以還是那句話：人覺得好做，AI 才會覺得好做。
在沒有 AI 的時候，我們會怎麼做？
最近有同事來問我「AI 流程該怎麼設計」，我都會反問一句：
在沒有 AI 的時候，我們會怎麼做？
這個反問很多時候都派得上用場。其實很多年前，我也是用一樣的模式問自己：「在沒有 Docker 的時候，我們會怎麼做？」往往馬上就找到解答了。
雖然 AI 的出現造就了更多可能，但先人的智慧、技術的本質，依然是不變的。AI 在現階段能「直接」幫到我們的，其實都只是把流程裡的模糊放大出來，逼我們去面對、去把它解決掉。
所以這場分享真正想說的，大概就是這句：別急著把 AI 當解藥，先把程式寫好、把 log 寫好、把規格想清楚、把大綱配好，完成這些 AI 照不到的基本功，才是讓 AI 真的幫得上忙的前提。