在現代軟體工程中，當系統發生故障時，網站可靠性工程師（SRE, Site Reliability Engineering）必須在極高壓力下迅速定位問題並恢復服務。隨著大型語言模型（LLM）的演進，業界開始出現 AI SRE 的概念，試圖將事故應變（Incident Response）完全自動化。然而，Anthropic 的可靠性工程師 Alex Palcuie 在 QCon London 的分享中指出，儘管 AI 在某些環節表現驚人，但目前仍無法完全取代人類 SRE。
背景與核心挑戰
事故應變的核心在於快速循環 OODA 迴圈：觀察（Observe）、定位（Orient）、決定（Decide）與行動（Act）。這是一個從接收警報、分析日誌、建立心理模型，到執行緩解措施並驗證結果的過程。對於 SRE 而言，最痛苦的並非單次故障，而是長期處於隨時可能被喚醒的壓力狀態。
理想情況下，如果 LLM 能處理標準化的緩解操作（如回滾版本或增加伺服器），人類工程師就能將精力轉向預防性工程，從結構上消除故障類別。但目前的現實是，LLM 在 OODA 迴圈的不同階段表現極其不均勻，呈現一種「鋸齒狀」的能力分佈：在觀察階段近乎超人，但在定位階段則潛藏危險。
觀察階段的超人表現
LLM 在收集信號與分析海量數據方面具有壓倒性優勢。人類工程師在分析數千行日誌或跨多個儀表板查詢指標時，受限於注意力和處理速度；而 LLM 可以平行處理大量端點，快速編寫 PromQL（Prometheus 查詢語言）且幾乎不犯語法錯誤。
Palcuie 分享了一個具體案例：在一次 500 內部伺服器錯誤的事故中，Claude 不僅快速定位到影像處理路徑的未處理異常，還進一步分析請求內容，發現大量新建立的帳號在同一時間發送特定數量的影像。LLM 透過連續的 SQL 查詢，揭露了這並非單純的程式 Bug，而是一場有組織的欺詐攻擊。這種從「錯誤信號」快速跳轉到「業務異常」的分析能力，遠超一般工程師在壓力下能達到的速度。
定位階段的邏輯陷阱
儘管觀察能力強大，但 LLM 在「定位（Orient）」階段經常陷入相關性與因果關係的混淆。例如，在某些快取失效導致的事故中，請求量會因為重試而激增，同時錯誤率上升。LLM 傾向於將這兩者視為因果關係，得出「流量增加導致容量不足」的錯誤結論，建議增加伺服器，而忽略了真正的根因是快取崩潰。
這種傾向對於資深工程師來說很容易被識破，但對於缺乏經驗的新進人員，LLM 的自信回答可能會產生誤導，將排錯方向引向錯誤的道路。這證明了 LLM 目前缺乏對系統深層運作邏輯的真正理解，僅能依賴模式識別。
實務應用的五大模式
為了最大化 AI 的價值並降低風險，Anthropic 團隊總結了五種有效的協作模式：
第一，將警報表達式直接交給 AI。不要從空白對話開始，而是提供 PromQL 查詢語句並要求 AI 保持好奇心，探索人類可能忽略的維度（如特定區域或狀態碼）。
第二，利用 AI 追蹤 Trace ID。在複雜的微服務架構中，AI 可以跨多個日誌源將單一請求的生命週期串聯起來，建立清晰的時間線，幫助工程師快速確認故障發生在 API 層還是後端。
第三，關聯變更視窗。將部署紀錄、配置推送與事故時間窗提供給 AI，讓它快速篩選出可能影響受損路徑的提交紀錄，縮小排查範圍。
第四，輔助撰寫事後分析報告（Postmortem）。AI 能處理整理 Slack 對話與會議記錄等瑣碎工作，但必須由人類審核根因分析。建議要求 AI 在不確定的地方標記 TODO，避免錯誤資訊進入知識庫形成惡性循環。
第五，簡化交接摘要。利用 AI 將冗長的對話記錄總結為精簡的交接段落，讓接手的人員能快速掌握進度。
影響、限制與長遠憂慮
將 AI 引入 SRE 工作流帶來了一個深層的學習問題：如果 AI 總是能快速給出正確的緩解方案，工程師是否會喪失排錯能力？資深工程師的直覺來自於多次被「燒傷」後的經驗累積（Scar Tissue）。如果初級工程師跳過困難的排錯過程，在面對 AI 無法處理的極端事故時，可能會因缺乏訓練而無法應對。
此外，Jevons Paradox（傑文斯悖論）在軟體工程中同樣適用：當開發工具變得更高效，導致軟體複雜度大幅增加，最終反而產生更多且更複雜的故障，抵消了工具帶來的效率提升。
總結來說，LLM 目前是極其強大的 SRE 助手，而非替代者。它能將人類從繁瑣的數據挖掘中解放，但最終的因果判斷與系統預防，依然需要具備經驗的人類工程師來把關。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。