Meta 為什麼不把故障交給 AI？ · 第 185 期

前言

各位讀者，2026 年的故障應對工具市場充滿了這樣的承諾：「MTTR¹ 最多縮短 70%。」「警報一響，幾十秒內就能鎖定根本原因。」「相當於僱用了一位永不入睡、從不遺漏上下文的資深工程師。」

然而，有一家企業已經實際驗證了這些承諾整整五年。那就是 Meta。超過 300 個團隊在使用，每天自動執行五萬件故障調查。去年 12 月，他們公開了該系統的論文。

論文報告的平均成效是 20%。而更令人意外的是，該系統的核心並非 AI 代理。

先說結論。瓶頸不在模型。瓶頸在於組織的知識尚未變成程式碼。

🌙 每天運行五萬次的腳本，全部由人撰寫

Meta 公開的系統名為 DrP。功能很簡單：警報響起時，自動執行預先編排的調查流程，並將結果貼到警報頁面上。凌晨三點被叫醒的待命²工程師，不必同時打開五個儀表板、翻找日誌，而是直接閱讀頁面上已經呈現的分析結果，開始調查。

Meta 將這些「預先編排的調查流程」稱為分析器（analyzer）。而這裡正是本文的起點。分析器是人用 Python 或 PHP 手寫的程式碼，一行行條件分支與數據查詢，說白了就是故障調查的腳本。

看看規模：超過 2,000 個分析器，超過 300 個團隊在使用，運行五年，每天自動分析五萬件。換算成 30 天就是 150 萬件，換算成秒就是每 1.7 秒就有某處在運行一個腳本。

這些腳本取代了三樣東西：無人更新的 Wiki 文件、散落在各人筆記型電腦上的個人腳本、以及只存在於資深工程師腦中的隱性知識³。用論文的原話來說，他們的方法是將組織中流傳的手動操作手冊和隱性知識轉化為程式碼。

成效在調查越複雜時越顯著。論文以三種情境（簡單服務錯誤、容器故障、AI 模型的功能問題）與手動方式進行比較，待命工程師需要執行的步驟數從 4 倍到 20 倍不等地減少。在最複雜的情境中，工程師要做的事被壓縮為唯一一件事：在警報頁面閱讀結果。

⚠️ 論文第九章裡的一個小標題

到這裡為止，還是一個熟悉的自動化成功故事。但翻到論文第九章「經驗教訓」，會看到這樣一個小標題：

「不要過度依賴 AI 系統進行診斷。」（Do not over-index on AI based systems for diagnosis）

一家運營著全球頂尖規模 AI 基礎設施的企業，在自己的故障調查論文中把這句話寫成了教訓。

先排除一個誤解。這不代表 Meta 不用 AI。DrP 的 SDK 裡包含了異常偵測、時間序列相關性分析、維度分析等統計與機器學習函式庫。還有掃描數千個程式碼與設定變更事件、給出「這很可能是肇因」排序的排名模型也在運行。

Meta 不交給 AI 的是判斷的骨架。先看什麼、後看什麼，遇到這個條件該往哪個方向走。這棵決策樹是人寫的。AI 只是在其中填充某一格的工具。

原因也寫在論文裡。純機器學習系統的侷限在於：訓練數據的品質、調查時點實際可存取數據的結構、以及各團隊難以修改工作流程。因此他們得出的結論是，在基於社群專業知識的規則式建議之上，再疊加 AI 的組合方案。

但更讓我駐足的是旁邊的另一條教訓，標題是「輔助還是完全自動化？」。

Meta 原本的目標是完全自動化。但他們轉了方向。原因有三：第一，系統不斷變化，腳本很快就會過時。第二，統計和機器學習會產生誤報和漏報。第三，從文化層面來說，工程師和待命人員始終不會完全信任全自動化的系統。

前兩點是技術問題。第三點不是。五年、300 個團隊、每天五萬件運行之後，Meta 撞上的牆不是準確率，而是信任。

論文中附帶的內部調查也印證了這一點。對於「DrP 有多頻繁地縮短 MTTR？」這個問題，回答「總是」的人只有 5.9%。最多的回答是「偶爾」（47.1%）。論文將此總結為「80% 以上的人報告了改善」，這不算錯，但回答的重心明顯偏向「偶爾」。順帶一提，反推百分比後，受訪者約 17 人。對於 300 個團隊在用的系統來說，這個樣本量非常小，這些數字僅供參考。

📉 20% 和 80% 之間藏著什麼

現在該看數字了，但在此之前有一件事需要先釐清。

Meta 的工程部落格這樣寫了成效：「MTTR 縮短了 20% 到 80%。」讀起來像是一個範圍。很容易覺得大概 40% 到 50% 吧，然後就翻篇了。

但論文摘要的寫法不同。**平均 20%。部分團隊達到 80% 以上。**同樣的數字，意思完全不同。

打開論文第七章就能看到原因。

分析器少於 5 個 → 10%~15%
10 個以上 → 50%~80%
全公司平均 → 20%

也就是說，80% 不是系統的性能，而是投入量的函數。自己團隊的調查流程有多少被轉成了程式碼，決定了成效的高低。

論文 7.2.4 節的團隊對比表看得更清楚。

1 號團隊：136 個分析器，改善率 82%
2 號團隊：92 個，75%
3 號團隊：66 個，84%
4 號團隊：48 個，69%
5 號團隊：39 個，58%
6 號團隊：29 個，73%
7 號團隊：23 個，56%
8 號團隊：12 個，7%

看最後一行。8 號團隊做了 12 個分析器。超過了論文自己設定的「10 個以上」門檻，但改善率只有 7%。論文的論點被論文自己的表格反證了。真正的斷崖在 12 個和 23 個之間的某個位置。

這裡我算了一筆。2,000 個分析器分給 300 個團隊，平均每團隊 6~7 個。而論文自己說少於 5 個只有 10%~15%。這意味著什麼？**Meta 內部，中位數所在的團隊還停留在低收益區間。**全公司平均停在 20% 的原因就在這裡。

時間成本也不小。論文指出，簡單的分析器一天就能做出來，但要完整涵蓋一個團隊的調查工作流程，需要幾個月。這不是購買工具的時間，而是轉移知識的時間。

最後也要提一下 MTTR 的絕對值。1 號團隊從 771 小時縮短到 139 小時。32 天變成了 5.8 天。這不是服務停機的時間，而是從偵測到解決、包含事後回顧在內的完整事故週期。如果覺得「MTTR 縮短 20%」聽起來很小，得同時看看基準線有多大。

補充一點，這張表中 7 號團隊那一行，用前後數值重新計算應該是 36%，但論文寫的是 56.1%。其餘七行的小數點都對得上，所以很可能是筆誤。但在照搬別人的表格之前，多按一次計算器總是有道理的。

🔁 那為什麼現在是「AI 原生」？

Meta 部落格的最後一段這樣收尾：未來將把 DrP 進化為 AI 原生平台。

不覺得奇怪嗎？前一句才寫「不要過度依賴 AI」，下一段就說要走向 AI 原生。

這不是矛盾。是順序。

重新看看 Meta 過去五年實際做了什麼。把散落在 Wiki 文件、個人腳本、資深工程師記憶中的調查知識，變成了這樣：

有型別定義的程式碼（調查流程以分支和條件明確化）
結構化輸出（結果以機器可讀的格式呈現）
留有執行紀錄的數據（保存過去 30 天的調查輸入輸出）

特別是第三點至關重要。Meta 建立了一套回測⁴機制：每次修改分析器時，都重新跑一遍歷史調查記錄來驗證。原本的目的是抓 bug。但結果是，故障調查過程本身變成了一個帶有標註答案的數據集。

這裡換個角度問：AI 代理要調查故障，需要什麼？

第一，手。需要存取數據的工具。第二，流程。需要知道先看什麼、後看什麼的地圖。第三，答案集。需要過去哪些判斷是對的記錄。DrP 五年來打造的，恰好就是這三樣。

論文中還有一條教訓，標題是「數據就是一切」。觀測數據的品質，以及服務依賴關係、數據血緣等結構化中繼資料。沒有這些，相關性分析根本做不了。模型再好，也沒有地方可以掛上去。

所以今天標題的答案是這樣：Meta 不是因為不信任 AI 才不交給它。**是順序還沒到。**而現在，他們判斷順序到了。

AI 要代替人工作，那項工作得先變成程式碼。模型再好，如果組織的知識還留在 Wiki 文件和某個人的腦子裡，AI 就無處著力。

🇰🇷 那我們又在什麼位置？

去年 6 月 24 日在首爾舉辦的一場會議上，三星電子 MX 事業部雲端團隊公開了自家路線圖。這是一個負責三星 Pay、Bixby、Galaxy Store 等超過 50 個對客服務穩定性的中央 SRE⁵ 組織。

他們提出的成熟度階段有四個：事後應對、自動應對、預測性運維、自主運維。而他們自我診斷的目前位置是第一個階段。自主運維的目標時間是 2028 年。國內頂尖 SRE 組織的自我評價都這樣，其他組織的座標也就不難推測了。

值得注意的是，柳賢成組長在演講結尾說的那句話：即使擴大自動化範圍，最終的責任和判斷仍然在人。這與 Meta 論文中「輔助還是完全自動化？」的結論完全一致。

同一場活動上，KT 巴蘭提亞事業本部長邊宇哲說得更直接：因為管理層的急躁，沒有觸及根本問題就先把 AI 貼上去，所以成效出不來。他指出的解法是將數據整理成 AI 能讀取的結構。這與 Meta 論文中「數據就是一切」如出一轍。

國內也有實際運行的案例。Yanolja 在 4 月公開了 6 個團隊 14 人在 6 週內打造了六個運維代理。其中故障應對代理將從故障發生到事後報告所需的 2 週縮短到了 24 小時。但拆解結構後會發現，這裡的代理同樣是在企業內部知識庫和文件檢索的基礎上運作的。順序是一樣的。

奧斯瓦爾德的視角

我重新數了論文第九章的六條教訓。其中關於模型性能的，**一句都沒有。**全部是關於採用的。

讓社群自己來做。到用戶所在的地方去。嵌入已經在用的工作流程中。特別是這句話讓我印象深刻：分析器開發對大多數軟體工程師來說不是本業。所以 Meta 把 SDK 打磨到一天就能做出一個，讓開發者能在程式碼編輯器裡直接看到結果。

二十多年做 GTM 策略，反覆看到一個模式：組織審查新工具時，第一個問題永遠是「準確率多少？」。但真正決定採用率的，幾乎總是「有多麻煩？」**如果要用一個準確率 95% 的工具，還得另外打開三個視窗，那這個工具就不會被用。如果準確率 70%，但結果直接浮現在你已經在看的畫面上，那它就會被用。**Meta 把結果推進警報頁面裡，不是技術選擇，而是 GTM 選擇。

所以我認為現在很多組織問錯了問題。不是「要導入哪個 AI 代理？」。應該先問的是：**我們團隊每次重複執行的判斷流程中，有幾個已經以程式碼的形式存在？**如果這個數字接近 0，買什麼模型都沒有地方可以掛。

結語

Meta 五年來每天運行五萬件的故障調查系統，核心不是 AI 代理，而是人手寫的 2,000 個腳本。**決定成效的也不是模型，而是寫了多少個腳本。**Meta 現在能說「AI 原生」，是因為五年來把隱性知識轉成了機器能讀取的格式。

想深入了解的話，翻開論文第九章「Lessons Learned」就好。三頁裡裝了五年的試錯。

想想你團隊裡每次都以相同順序重複執行的判斷流程。如果它還只存在於 Wiki 或某個人的腦子裡，為什麼還沒變成程式碼？是因為時間不夠，還是流程因人而異？歡迎在留言區分享最大的障礙，我會考慮納入下一期的主題。

💬 歡迎在留言區分享你對上述問題的經驗。我會考慮納入下一期。 📨 如果有同事正在考慮運維自動化或 AI 導入，請把這篇文章轉發給他們。

我每週二、四、日交叉閱讀科技、經濟與人文，寫下在交叉點發現的東西。也有像今天這樣，把一篇論文從頭到尾挖到底的日子。

參考資料 & 延伸閱讀

核心來源

Shubham Somani 等 13 人，“DrP: Meta’s Efficient Investigations Platform at Scale”，arXiv:2512.04250 [cs.SE]，2025 年 12 月。：7.2 節（MTTR 評估）和第 9 節（經驗教訓）是本文的核心依據。時間不夠的話，只讀第 9 節三頁就夠了。
Meta Engineering，“DrP: Meta’s Root Cause Analysis Platform at Scale”，2025 年 12 月 19 日。：論文的官方摘要版。但 MTTR 被壓縮為「20%~80%」的表述，與原文語氣不同。如果要引用數字，建議看論文原文。

背景知識

Rootly，“What Is an AI SRE Agent? How AI Is Changing Incident Response in 2026”，2026 年 4 月。：可以看到前言中提到的市場承諾是以什麼語氣在銷售的。這是廠商資料，需要保留判斷，但將自主性分為四級的框架，可以與三星的四級成熟度並列比較。
Google，“Being On-Call”，Site Reliability Engineering。：關於待命制度為什麼存在、為什麼消耗人的原始文獻。Meta 的論文也引用了這份文件。
ZDNet Korea，“數據讀不了的 AI 就是廢物，KT・三星的解法是”，2026 年 6 月 24 日。：三星電子 SRE 組織的四級路線圖和 KT 的數據結構診斷在同一篇報導中。對把握國內座標最有用。
伊德日報，“三星，用 AI 抓雲端故障，2028 年自主運維目標”，2026 年 6 月。：三星電子發表的數值目標（恢復時間縮短 90%、10 分鐘內偵測率 99% 等）有更詳細的整理。
AWS 技術部落格，“利用 Strands SDK 和 Bedrock AgentCore 建構 Yanolja AIOps Agent 的案例”，2026 年 4 月。：可以以 6 週 sprint 為單位，深入了解國內實際運行的運維代理的結構。

作者 安光涉（Oswarld） 現任世宗大學兼任教授，INLEVEL9 策略顧問。職涯經歷、研究、著作與近期活動會持續更新在作者介紹。最新動態 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

📝 術語說明

각주

MTTR（Mean Time To Resolution）：從發現故障到解決故障的平均時間。Meta 論文只計算了經過事後回顧的事故，所以不是服務停機時間，而是包含原因調查和處置在內的完整週期。 ↩
待命（On-call）：故障發生時能立即應變的輪值制度。凌晨三點警報響起時必須起床的那個人，就是當天的待命人員。 ↩
隱性知識（Tribal Knowledge）：沒有以文件形式留存、在組織內通過人際傳遞的知識。比如「那台伺服器出這種問題時，要先看那個地方」之類的。 ↩
回測（Backtesting）：用歷史數據重新跑一遍，驗證修改後的程式碼是否仍能產生相同結果的方法。Meta 保存了最近 30 天的調查記錄，每次修改分析器時都自動運行。 ↩
SRE（Site Reliability Engineering）：以軟體工程方式管理服務穩定性的職能和組織。2003 年從 Google 開始，待命和故障應對是核心工作之一。 ↩