半夜兩點告警響了,本來今天是美好的颱風假
你一臉厭世打開電腦,Grafana 一個視窗、Loki 一個視窗、K8s 事件一個視窗
最近誰動了部署又是另一個地方,你開始把這些線索一片一片拼起來試圖釐清到底哪裡出了問題?
每個維運過的人都經歷過這一幕
事故發生時,消耗時間的往往不是修復而是調查
可觀測性提供了你需要的資料,卻沒有提供答案
我將分享打造 AI 輔助事故調查系統的過程,以及如何把 AI 導入問題查找流程
目標很單純 當告警觸發的那一刻由 AI 接手「拼線索」這件苦差事
我們希望建立的不是一位會聊天的 AI,而是一位能協助 SRE 更快找出 Root Cause 的助手
這裡不討論 AI 是否取代 SRE
我想說的是另一件事「當 AI 把調查的苦工接走 工程師才能真正專注在需要判斷力的決策上」
聽眾收穫:
1.重新認識「可觀測性」的邊界:
有 metrics、logs、traces 不等於有診斷能力,理解這個落差是什麼以及 AI 如何填補它
2.了解一套適合 SRE 的 AIOps 工作流程:
從 Alert、證據收集、規則判斷、AI 分析到結構化報告,建立可落地的事故調查流程
3.知道 AI 為什麼不能直接接收告警:
理解規則引擎在建立上下文、降低幻覺與提高分析品質中的角色
4.學會如何讓 AI 的分析結果變得可驗證:
了解結構化輸出如何支撐後續自動化、系統整合與決策流程,而不只是生成一段文字
5.讓歷史事故成為可搜尋的組織知識:
向量搜尋讓「這次跟三個月前那次很像」從工程師直覺變成系統自動提示的能力

資深軟體架構師與技術組長
超過 15 年跨產業及平台的系統開發經驗
從早期 QB、VB、Perl、Assembly、C/C++
開發到 Java、C#、Python、JavaScript、Dart、Go、Rust
熱愛軟體工程、逆向工程及敏捷開發
也專注於新技術的推廣與研究