【AIOps】從救火員到建築師：SRE 如何演進為 AI 可靠性工程（AIRE）？

本文受到 kagent 團隊的文章 AI Reliability Engineering For More Dependable Humans 啟發而撰寫，延伸探討 AIRE 的演進脈絡、歷史典故與工程師角色轉型。若想深入了解 kagent 框架本身，可參考筆者的 kagent 完整解析。

Google 的 SRE 手冊（Site Reliability Engineering） 2016 年出版時，許多人認為這是一本「運維工程師的聖經」。它的核心主張只有一句話：把軟體工程的方法論帶進系統維運。用代碼取代手動操作，用 SLO 取代感覺，用 Error Budget 取代爭論。

近十年過去了，這套方法論確實改變了產業。但它也遭遇了一個它當年未曾預料到的敵人：複雜性的指數增長。

當你的系統從十幾個服務長成數千個微服務，當你的監控數據從 GB 級別膨脹到 TB 級別，當你的告警從每天幾十條變成每天上萬條 —— SRE 手冊裡的那些原則依然正確，但人類的認知頻寬，已經追不上系統的熵增速度了。

2025 年，維運的遊戲規則正在被徹底改寫：從以人為核心的網站可靠性工程（SRE），轉向以 AI 為核心執行、人類進行高層次監督的 AI 可靠性工程（AIRE, AI Reliability Engineering）。

這是一場關於「誰來決策、誰來行動」的深刻哲學革命。

傳統 SRE 的困境：我們被複雜性囚禁了

數位系統的熵增，已超越人類認識論的邊界

現代數位架構由數萬個相互依賴的微服務組成，分佈在多雲環境、邊緣節點與動態擴展的容器叢集中。每秒鐘，系統產生數百萬條指標（Metrics）、日誌（Logs）與分散式追蹤（Traces）。

統計數據顯示，現代企業的運維團隊通常需要同時使用 2 到 10 種不同的監測工具。這導致嚴重的資料孤島（Data Silos）與認知過載 —— 當故障發生時，工程師在多個儀表板之間切換，進行「手動相關性分析」，這往往佔據了平均修復時間（MTTR）的 70% 以上。

維運苦差事的經濟學：一個令人汗顏的數字

SRE 的核心目標之一，一直是消除「維運苦差事」（Toil）—— 那些手動、重複且缺乏長期價值的日常雜務。現實卻是殘酷的：

指標類別	2025 年現況
開發者用於編寫新代碼的時間	僅約 16% 的工作時間
重大停機平均成本	20% 的組織單次超過 100 萬美元
全球 2000 強企業年度微停機損失	高達 4000 億美元
資深工程師每日告警處理量	平均超過 1,000 條

這些數字背後，是告警疲勞（Alert Fatigue）、人才流失與創新停滯的惡性循環。向 AIRE 的轉換，不再是「可選升級」，而是組織生存的必要途徑（Rootly）。

雲原生維運的演進路徑：從「下命令」到「自己想」

有了 Agent 的加入，雲原生維運（Cloud-Native Operations）的演進，似乎也逐漸發生變化。

雲原生維運演進路徑：命令式 → 宣告式 → 自動化 → 自主化

這條演進路徑從左到右，人類參與程度逐漸降低，系統的自主判斷能力則不斷提升：

命令式（Imperative）— 人是唯一的大腦 最傳統的維運方式。工程師手動下指令、執行 Shell Scripts，每一個動作都需要人明確告訴系統「要做什麼、怎麼做」。這個階段的痛點是：人的知識無法規模化，出了事只能靠有經驗的人熬夜排查。

宣告式（Declarative）— 描述終態，讓系統自己達到 Kubernetes YAML 和 GitOps 是這個階段的代表。工程師不再說「先做 A，再做 B」，而是宣告「我要的最終狀態是什麼」，由系統負責收斂到目標。這大幅降低了人工錯誤，也讓基礎設施可以版本控制、可審計、可重現。

自動化（Automated）— 預定義好，機器自動跑 Kubernetes Operator 模式與預定義工作流程（如 CI/CD Pipeline、Auto-scaling）讓系統能在特定條件觸發時自動執行一連串動作。但有個天花板：它只能處理「預料之中」的情況，遇到沒事先定義的異常，還是得把人叫起來。

自主化（Autonomous）— LLM 推理 + Agents 接管未知 這是目前正在發生的革命。結合大語言模型的推理能力與 AI Agent 的工具調用能力，系統終於能夠面對預料之外的狀況——自主診斷、自主決策、自主修復。這不是「更快的自動化」，而是引入了真正的「判斷力」。

Instead of writing scripts and runbooks,
define INTENT.

自主化的階梯：從 L0 到 L5

理解 AIRE，最清晰的框架來自自動駕駛的自主化等級概念。維運的演進，同樣可以用六個等級來描述：

等級	描述	人機關係
L0：手動維運	所有觀察、決策、行動均由人執行	人類全權控制
L1：輔助維運	系統提供視覺化，能執行單步自動化腳本	人類下令，系統執行子任務
L2：部分自主	進階告警關聯，特定時段能「放手」	「手離」但「眼不離」
L3：條件自主	系統能自主識別異常並提出修復方案	「眼離」但請求時必須接管
L4：高度自主	特定場景內（如無狀態服務）完全自主修復	人類僅負責治理與事後審核
L5：完全自主	全場景全天候自我修復與優化	人類作為最終受益者

目前大多數 SRE 實踐介於 L1 到 L2 之間，而 AIRE 的使命是將組織推向 L3 乃至 L4。這種跨越的關鍵，在於 AI 是否具備環境檢測（Environmental Detection）與動態決策能力，而非只是靜態的規則比對。

從靜態腳本到代理推理：技術的本質躍遷

傳統自動化的脆弱性

傳統自動化（Automation）是 基於規則（Rule-based） 的：「如果 CPU > 80%，則重啟服務」。換句話說：工程師版的「你有沒有試過關掉再開？」 —— 有效，但只對認識的問題有效。在複雜的分散式系統中，面對「未知之未知」（Unknown Unknowns）時極度脆弱，環境條件一旦偏離，腳本不是失效就是引發副作用。

AIRE 代理的三維感知框架

AIRE 採用的 代理式工作流（Agentic Workflows） 具備 LLM 驅動的推理層，能根據當前遙測數據、歷史事故記錄與系統拓撲圖，動態建構行動計畫。以 kagent 等領先框架為例，其決策模型建立在三個維度的上下文之上：

時間上下文（Temporal Context） AI 能識別當前的異常模式是否與三個月前某次版本發佈後的故障吻合，迅速定位隱蔽的性能退化。這是基於時間的直覺。

系統上下文（System Context） AI Agent 掌握系統的依賴圖譜（Dependency Graph），它知道結帳服務的延遲可能源於底層資料庫的 row lock，或某個第三方 API 的間歇性超時。這是結構化意識。

知識上下文（Knowledge Context） 透過 RAG（Retrieval-Augmented Generation）技術，AI Agent 能即時檢索內部的 Runbooks、Slack 討論記錄以及 Postmortem 報告，將破碎資訊拼湊成完整的調查敘事。這是組織的集體記憶（kagent.dev）。

歷史的韻律：飛行工程師的消逝

人類技術史上每一次重大進步，都伴隨著從「親力親為」到「抽象監督」的轉變。

航空自動化的啟示

1950 年代，遠程噴射客機（如波音 707）的駕駛艙需要五名組員，其中飛行工程師（Flight Engineer）專門監控成百上千個儀表板，手動調節發動機推力、燃油平衡與電力分配。

隨著數位航電系統的出現，這些監控任務逐漸被電腦接管。1981 年，FAA 宣布兩員駕駛制是安全的，飛行工程師這一職位從此走入歷史（Simple Flying）。

今天的 SRE 團隊，就是那些正在監控儀表板的飛行工程師。AIRE 的出現，相當於為數位基礎設施安裝了全權數位發動機控制系統（FADEC） —— 人類工程師不再需要盯著每一條延遲曲線，而是將注意力集中在「航向預判」與「戰略決策」。

OODA 迴圈的機器化轉生

軍事戰略家約翰·博伊德（John Boyd）提出的 OODA 迴圈（Observe-Orient-Decide-Act）是事件響應的靈魂。在 AIRE 時代，這四個階段正經歷機器速度的重塑：

觀察（Observe）：從閾值到遙測神經網絡

傳統 SRE 依賴靜態閾值（如 CPU > 80% 告警）。AIRE 時代透過 eBPF 等核心技術，系統在人類意識到問題之前，就能在「爆炸前兆」的微弱信號中辨別出異常模式。

定向（Orient）：從猜測到圖譜推理

這是 AIRE 與傳統 AIOps 的本質差異。傳統 AIOps 只是對告警進行聚類；AIRE 進行的是根因推理 —— 透過理解服務調用鏈與資源依賴關係，AI 能將數小時的「排除法」診斷縮短為數秒鐘的「圖譜分析」。

決定與行動（Decide & Act）：從手動執行到自主閉環

在 AIRE 模式下，AI Agent 會生成變更提案（如：回滾特定 PR、調整負載平衡權重），並根據預設的信心閾值與風險評估，決定自主執行還是請求人類確認。

人在哪裡？HITL vs. HOTL 的抉擇

AIRE 並非「人類退場」，而是人類退守到正確的位置。根據任務的風險等級，有兩種截然不同的人機協作模式：

人在迴圈（Human-in-the-Loop, HITL） 適用於高風險場景（金融結算、資料庫遷移）。AI 負責生成多種方案與風險預測，但最終的「確認按鈕」必須由人類按下。犧牲速度，換取責任歸屬的清晰。

人在環上（Human-on-the-Loop, HOTL） 適用於低風險或高度可逆的場景（服務擴容、CDN 刷新）。AI 自主執行，人類作為監督者，隨時準備撥動「緊急制動器」。最大化機器處理規模。

選擇哪種模式，本身就是工程師需要主動設計的治理決策，而非默認。

轉換的陣痛：建立在非確定性上的信任

LLM 的隨機性與 SLO 的確定性之間的撞擊

傳統 SRE 建立在「確定性」的基礎上：測試必須通過，SLO 必須被量化。但 LLM 的輸出具有機率性。我們不能再用舊的「可用性百分比」衡量 AI 的可靠性，而必須開發新指標：認知準確度（Cognitive Reliability）與接地度（Groundedness）（DevOps.com）。

爆炸半徑的擴張問題

一個被錯誤配置的 AI Agent 如果擁有生產環境的寫權限，其造成的破壞可能比一個初級工程師快上千倍。因此，治理層（Governance Layer） 是 AIRE 架構中不可或缺的核心元件，而不是事後的補丁。

工程師角色的根本轉型

在 SRE 時代，工程師的價值體現在「能在壓力下快速排障」；在 AIRE 時代，工程師的價值體現在 「能設計出讓 AI 安全排障的系統」。

這包括三個新核心能力：

設計安全護欄 —— 定義 AI Agent 的行為準則與權限邊界
治理 AI 決策 —— 審查 AI 的推理邏輯，糾正模型偏見與漂移
韌性工程 —— 利用混沌工程（Chaos Engineering）主動「訓練」系統的自我修復能力

從「消防員」到「可靠性建築師」，這是一場關於 SRE 自身角色的自我升級。

結語：當 AI 接管苦差事，人類去哪裡？

從 SRE 到 AIRE，這場演進正在教會我們一件事：真正的英雄主義不再體現在火場中的衝鋒，而體現在對系統的深刻理解與優雅設計。

當 AI 接管那些乏味的、重複的、令人疲憊的維運苦差事，SRE 才真正獲得自由 —— 去思考「為什麼」，去創造「從未存在過的東西」。

AIRE 不是 SRE 的終點，而是更高層次的起點。想更深入了解 AI Agent 在雲原生環境中的具體實踐，可以參考我之前寫的 HolmesGPT 深度解析與 kagent 完整解析。