當 alert 不再叫醒你：New Relic 首席策略長談 observability 走進 intelligence 時代
TL;DR
- New Relic 三十年的 observability 歷史走過三個階段：instrumentation（插樁）、data platform（資料倉）、現在進到 intelligence era（智慧時代）
- 真正的 AI observability 不是把所有東西丟給 OpenAI，而是把「靜態統計、傳統 ML、neural net」三件套搭著用，LLM 當老闆，下面派 ML 跟統計工具去跑
- Dashboard 跟 alert 已經做到天花板了，再小的 widget 也看不完系統，再多的 alert 也只會讓你麻木，未來的 observability 工具該直接告訴你答案
- 終極願景是把現在會 page 工程師的事自動化到像 Kubernetes 重啟 pod 一樣不痛不癢，paging 人類變例外而不是日常
- 監控 AI 系統需要新的 golden signal：token 數、回答品質、用 judge model 去抽樣評估，但底層觀念跟過去 web 系統一模一樣
- 給剛入行工程師的建議：別用 AI 幫你寫文章，要把它當老師，請它讀你寫的東西然後挑你的問題
節目背景
Software Engineering Daily 是科技圈最老牌的開發者 podcast 之一，基本上是工程師的情報站，主持人陣容很多元。這集的主持人是 Lee Atchison，他是《Architecting for Scale》作者，前 AWS 七年資深工程師，後來也在 New Relic 做過架構工作，現在自己主持 Modern Digital Business podcast。受訪來賓是 Nic Benders，New Relic 的 Chief Technology Strategist，在 New Relic 已經待了十六年，等於是跟著這家公司從早期做 Ruby APM 的小新創一路走到今天 AI 驅動 observability 平台的活化石，連 observability 這個詞還叫 monitoring 的年代他就在做了。New Relic（NYSE 上市過、二〇二三年被 Francisco Partners 跟 TPG 用七十億美金私有化）是全球前三大的 observability 平台，做的事情說白了就是幫工程師看自己的系統哪裡在燒。
三十年走完三個時代：從插樁、資料倉到智慧
Nic 把整個產業的演進切成三段，每一段都是「上一段做到不能再做了，被迫往下一步走」的故事。
第一階段是 instrumentation。New Relic 早年坐在工位上每天想的就是「下一個要 instrument 哪個語言？」Ruby 之後是 Java，然後 .NET、Python、browser、mobile。插得越來越多，資料越收越多，最後反而被自己埋了。
第二階段是 data platform，大約二〇一三、一四年 New Relic 推出 NRDB。NRDB 的核心邏輯是「先把所有資料丟進來，事後想問什麼再問」。慢查詢是哪來的？拆掉測試系統的看？再按國家拆？這種互動式查詢撐起了 dashboard、alert、各種 explorer。十多年下來大家都這樣做。
第三階段就是現在進到的 intelligence era。問題很直白：資料多到你連該問什麼都不知道。Nic 講的這句話我覺得最重要：「dashboard 跟 alert 作為 observability 的做法已經到底了。你做不出比現在更花俏的 dashboard、更小的 widget、更多的 alert 設定工具，因為沒有人想設 alert，沒有人想做 dashboard，大家要的是答案。」
這句話放到整個 SaaS 產業看都成立。前陣子寫過Klarna CEO 砍掉一半員工說 SaaS 已死，邏輯一樣：產品的進化已經逼近用人類的方式做事的天花板了，下一步要嘛是讓 AI 來操作，要嘛是把整套工作流重寫。儀表板做得再漂亮，工程師面對的就是滿牆的圖看不完。
不是 AI 萬能，是 math + ML + AI 三件套
這集最有 takeaway 的一段是 Nic 把 intelligence 拆成三層：
| 層次 | 本質 | 例子 |
|---|---|---|
| 靜態統計 | 數學公式套參數 | baseline deviation、component analysis |
| 傳統 ML | 自動調 hyperparameter | baseline alert 自動 tune 噪音 |
| Neural net（現在大家叫 AI） | Transformer 之後的 LLM | OpenAI/Claude/Gemini 那一掛 |
他講得很實在：好的產品三層都要有。如果你以為「把所有東西丟給 OpenAI 然後它回答你」就叫 AI 產品，那你大概只用到了百分之三十的工具庫。
正確的架構是：LLM 當老闆（負責推理、總結、做決策），但工具箱裡面要塞滿傳統 ML 跟統計工具。要在 PB 等級的資料裡找異常，你不會把所有資料 tokenize 後丟給 Anthropic 燒錢，而是先用傳統統計方法找出可疑時間段，然後把這些段落丟給 LLM 問「哪個有趣？」這就是 MCP（Model Context Protocol）tool 的核心價值，讓 LLM 不用自己幹所有事，而是會調用最對的工具去幹。
我自己接 OpenRouter 跑 Agent 的時候也遇過類似的事：明明便宜的 statistical model 就能搞定的事，硬要丟給 Claude Sonnet 4.6 跑就是貴又慢。LLM 是大腦，不是所有問題的鎚子。
Alert fatigue 是十年老問題，沒人真的解決過
這段我聽完笑出來，因為太真實了。Nic 說每家公司、每個團隊跟他聊都會講同一件事：
「每次 incident retro 結束，結論永遠是『下次要早點發現，我們要設立一個 X、Y、Z 的 alert』。」
跑個三五年，整個系統有六七百個 alert，沒人記得每個是幹嘛的。前同事 Aaron Bento 還做過一個演講說「多加 alert 不會改善反應時間」，因為使用者被訓練成看到 alert 心想「先等一分鐘看會不會自己好」，反而拖長了 MTTR（mean time to repair，平均修復時間）。
這個現象在加密貨幣交易跟監控 DeFi 協議的人應該也很熟悉。我之前在鏈上收益的風控不只是看 audit 跟抵押物那篇講過：太多警報讓人麻木，最後真的出事的時候反而沒人看。
intelligence 在這裡的角色是什麼？兩層：
第一層是消費 alert：當你六個系統同時冒出警報，AI 知道要踢人類的腳；只有一個系統閃一下，AI 自己處理掉。
第二層更狠：把根本問題挖出來。Nic 問了一個很尖銳的問題：「我們為什麼要 alert？因為我們害怕系統壞了卻不知道。那能不能直接讓系統自己處理？」
把 toil 自動化掉，paging 人類變成例外
這是整集最讓我有畫面感的觀點。Nic 用 Kubernetes 當比喻：
「Kubernetes 偵測到 node 掛了會自動把 pod 重排，這件事我們現在覺得理所當然到根本不算技術。但這明明就是 self-healing，是九〇年代的人會驚嘆的事。我們今天 page 工程師的很多事情，未來都該變成這種『沒人 care 的背景事件』。」
他舉了一個非常具體的場景：未來工程師設定 observability 不該再花時間設定一堆 alert，而是直接跟系統說：「這些是我業務上最重要的訊號（例如下單成功率、付款轉化），你自己看著辦，有問題提前告訴我。」
中間的事情怎麼處理？fuzzy interface（模糊介面）是關鍵。傳統 runbook（操作手冊）是「if X then Y」，但實際運維碰到的事情九成都不是規格化的：憑證過期、IP 池滿了、上游 service mesh 出怪事。這些事情你寫不完，但是 LLM 可以根據「這看起來跟以前那個問題很像」做分類：
- 確定能處理的 → 自動執行（rollback、restart、scale up）
- 沒那麼緊急但要看 → 開 ticket 給人
- 真的緊急且未知 → page 工程師
這套東西如果做得好，就是把現在 SRE（網站可靠性工程師）一半的工作搬到自動化軌道上。聽起來像在搶人類的工作，但 Nic 跟 Lee 後面討論到一個很關鍵的反駁。
AI 不會搶你工作，會逼你做更多事
Lee 問了一個我很喜歡的問題：「我們把這麼多東西自動化了，工程師應該變輕鬆吧？」
Nic 的回答很冷靜：「New Relic 內部問過工程師同一個問題：『我們 platform 比以前好太多了，為什麼大家還是這麼忙？』答案是『因為我們做更多事了』。人力頻寬永遠是上限，平台變強只會讓你接更多工作，從來沒有人跟你說『太好了，那我們今天早點下班吧』。」
這個觀點在 AppLovin CEO 那篇也有出現過。我寫過AppLovin 一個員工一年產出一千萬美金 EBITDA，邏輯一樣：AI 讓單兵戰力翻十倍，但公司不會因此縮編一倍，公司會去做以前不敢做的事。
Nic 還補了一個歷史比喻很值得記：工業革命的時候，社會整體經濟規模大幅變大，但中間有一整代人原本的工作確實消失了，那些人並沒有「等到下一個產業興起」就能順利轉行，他們的人生過得很辛苦。AI 這次大概率也會是類似的轉移過程，工作會「移動」而不是「消失」，但搬家本身就是痛的。
Observability for AI：非確定性系統怎麼監控
這是一個有趣的反轉：AI 在改變 observability 產業的同時，AI 本身也變成一個需要被 observe 的東西。
新的 golden signal 跟以前不一樣：
- Token 數（直接連到燒錢速度）
- Sentiment（使用者是不是越來越不爽）
- Quality of answers（回答有沒有變差）
- Cost per request
- 各種 model 的切換是否帶來 regression
Nic 的觀點是「signal 不同，但模型相同」。意思是非確定性系統並沒有讓 observability 整套理論翻案，它只是多了一組新訊號。就像當年從靜態網站走到 Kubernetes 一樣，沒有人說 observability 死了，只是 golden signal 改變了。
最有意思的是「judge model」的做法：你的線上系統用便宜快速的模型（例如 GPT-5 mini）回應，然後抽千分之一的 query 丟給一個更強更貴的模型（Claude Opus、GPT-5）去評估「這個回答好不好」。這就像在 call center 派一個 supervisor 在走道上巡邏。
這套機制聽起來很合理，但實際做的時候會碰到一個問題：誰來監督 supervisor？我自己跑文章生成 pipeline 的時候就遇過，judge model 自己也有偏好，結果是「judge 喜歡的風格」不一定是「使用者喜歡的風格」。這個議題接下來幾年會被熱烈討論。
不是只看 AI 在不在亂講話，是看你業務有沒有達標
Nic 講了一個我覺得整集最有重量的故事，他二〇〇〇年初在某家新創，公司角落有一台電視，永遠只放一張圖：sales per minute（每分鐘銷售）。
「我們設了很多 alert，CPU、memory、database 全都有，但天花板那張圖才是真相。任何東西壞了，那條線會掉。它不告訴你壞在哪，但它告訴你『有沒有達到生意目標』。其他所有訊號，都只是 diagnostic（診斷工具）。」
這句話放到 AI 時代依然成立。你接了 Anthropic API、上了 RAG（檢索增強生成）、做了 fine-tune、加了 MCP tool，但最終要回答的問題還是：「使用者有沒有在我的產品上完成他想做的事？」其他都是過程。
太多公司現在追逐的 AI 觀測指標都是 vanity metric。Token 數很重要，但跟你的營收不一定線性相關。回答品質很重要，但如果使用者根本沒到 checkout 那一步，品質再高也沒用。
給剛入行工程師的建議：別讓 AI 幫你寫，讓 AI 教你寫
最後 Lee 問了一題完全跳脫主題的：「對剛畢業、擔心 AI 搶飯碗的新人，你最想說什麼？」
Nic 的答案分兩段。
第一段是現實的：現在進科技業真的很慘。總體經濟、AI 不確定性、地緣政治三層壓下來，所有公司都不敢 hiring，因為他們怕招了又得 lay off。新鮮人聽到的「科技業永遠缺人」這個故事，在二〇二六年是不成立的。要做好心理準備，要回到三十年前那種跑斷腿、用人脈、敲遍所有門的求職方式。
第二段是給操作建議的，這段我覺得很有 insight：「花時間用 Claude Code，去用這些工具寫東西。但不要把 AI 當『印程式碼的魔法機器』，要把它當你的私人老師（他引用了 Diamond Age 那本小說裡的 Young Lady's Illustrated Primer，一本會教小孩成長的互動書）。」
他講了一個我超有共鳴的點：「不要用 AI 幫你寫文章，我不想讀 AI 寫的文件。要用 AI 幫你『讀你已經寫好的東西』，請它告訴你『讀者會有什麼疑問』『哪裡寫得不清楚』，用它來打磨你自己的能力，不是替代你的能力。」
這跟我之前寫的我怎麼用 AI 打造寫作系統 的核心想法完全一致。AI 用對了是放大器，用錯了是麻醉劑，差別就在你有沒有把「思考」這件事留給自己。
寫在最後
整集聽完最大的感受是：observability 這個產業比大多數人想得更接近 AI 落地的最前線。它每天處理的就是「在 billion 級的資料中找 thousand 級的 signal」，這幾乎是 LLM 最擅長的事。但 Nic 也很清楚地警告：用 AI 解決所有問題只會把成本燒爆，正確姿勢是讓 LLM 當指揮，讓統計跟 ML 當士兵。
而真正的終局願景，是我們現在 page 工程師的所有 incident，都會像 Kubernetes 重啟 pod 一樣，變成沒人 care 的背景音。那一天還有點遠，但方向是清楚的。
如果這篇對你有幫助，wilsonhuang.xyz 上還有很多 podcast 拆解跟產業觀察，歡迎訂閱一下，新文章都會發在那邊。
Sources:
推薦閱讀
喜歡這篇文章嗎？
訂閱電子報，每週收到精選技術文章與產業洞察，直送你的信箱。
💌 隨時可以取消訂閱，不會收到垃圾郵件