SRE 的四體問題：為什麼自主化維運取決於脈絡
發表於 2026 年 7 月 6 日 作者：Sanjeev Sharma，StackGen Field CTO（現場技術長）
一整間資深 SRE 所確認的信任落差，以及真正的工作從哪裡開始
上週我在班加羅爾的一場活動待了一整天，向滿場的資深 SRE、平台工程師與工程主管問了一個不太光鮮、但很直接的問題：AI SRE 現在到底走到哪裡了？
當你把這個問題丟給真正負責營運實際系統的人（不是分析師，也不是做 demo 的供應商），你聽到的不會是什麼復原時間下降的整齊故事。你會聽到 AI 代理人失敗的恐怖經驗。你會看到大家嚴肅面對過時的 runbook，以及只存在三位工程師腦袋裡的組織記憶。你也會看到各個團隊都站在某個階梯上，從「AI 協助我」到「AI 自己採取行動」不等，但沒有人完全確定要往上爬究竟需要什麼。
在討論、座談與走廊閒聊之間，同一個主題不斷浮現：AI 在維運中最大的挑戰不是模型能力，而是脈絡。
那天我一直回到的一個框架，是我開始稱為 SRE 的 4-Body Problem（四體問題）。以下是它的意思，以及為什麼我認為它能解釋今日自主化維運的希望與限制。
為什麼維運是一個四變數問題
幾年前，凌晨兩點，我坐在一場事故應變通話裡，線上有八家供應商、一份 200 列的 RACI 試算表，而每一方都展示著自己那一塊領域的綠燈儀表板。
兩家雲端供應商互相指責。某家編排供應商一聽到競爭對手的雲端也在範圍內，就立刻退出通話。真正的根本原因，則藏在一條由轉包商提供的網路遙測串流裡，而那條串流從未被整合進任何人的可觀測性系統。
那一晚教會我兩件事：沒有任何單一方掌握完整全貌；也沒有任何一個人，不管多資深，能在凌晨 2:07 把整個全貌都裝在腦中。
維運中的每一個重要決策，都需要同時跨越四個緊密耦合的真相體系來推理：
- 程式碼： 每一次 commit、PR、分支、建置產物、版本與設定變更。部署了什麼、什麼時候部署，以及跟昨天相比有什麼不同？
- 基礎設施狀態： 雲端帳號、網路、Kubernetes 叢集、佇列、資料庫與 IAM 政策實際且當前的樣貌。Terraform 說應該存在什麼，而此時此刻實際上又存在什麼？
- 執行期訊號： 指標、日誌、追蹤、事件、錯誤預算、SLO，以及影響客戶的警示。系統此時此刻正在做什麼？又是從什麼時候開始表現得不一樣？
- 營運知識： 那些部落智慧、事後檢討、架構決策紀錄、on-call playbook，「我們 2022 年試過那招，結果搞掉了一整個區域」的經驗、runbook，以及那些解釋某件事為什麼會變成現在這樣的 Slack 討論串。
每一個天體單獨來看，大致上都已經有解法（Git、Terraform、你的可觀測性工具組、Confluence）。問題在於，每一個真實決策都落在這四者的交會處，而交會處正是我們過去幾乎完全沒有系統的地方。
就像物理學裡的三體問題，加入第四個質量並不只是讓問題稍微變難；它會讓整個動態在本質上變得不同。唯一曾經能可靠駕馭這件事的，是少數資深工程師的大腦能同時追蹤這四個天體：昂貴、稀缺，而且每兩年就會離開。
我們用我最近開始稱為「人肉補土」（people putty）的東西把這個缺口黏住：少數人腦中的部落知識，以及下一個基礎設施變更一落地就開始過時的 runbook。那天幾乎每一場 session，底層其實都在講人肉補土如何在壓力下失效。
那天確認了什麼
一整天的對話，變成了一趟巡覽這四個天體，以及它們之間信任缺口的旅程。
討論不斷回到自主營運核心裡的根因問題。
他們處理的問題，正是決定這一切能不能真的進到 production 的關鍵：
- 你到底能信任一個 agent 到什麼程度，讓它執行自動化 RCA？
- 這種信任有多大程度取決於 agent 用來推理的資料品質？
戰情室反覆出現的樣貌，就是我前面描述的那種橋接會議：答案很少就在你眼前盯著看的那個資料體裡。更快的 RCA（根因分析）不是儀表板夠不夠聰明的問題，而是跨資料體關聯的問題。代理（agent）要讓戰情室消失，靠的不該是更快把人叫上線，而是在第一個人加入橋接會議前，就已經準備好以 SLO 為錨點的 RCA 假設。
關於代理失敗案例的討論，浮現了產品簡報永遠不會放進去的東西：
- 代理很有自信地修錯東西。
- 代理在 demo 時表現完美，一碰到真實、混亂的事故就崩潰。
- 代理的推理事後無法重建。
當代理用來推理的脈絡是碎片化的，它不只是會失敗。它會以看似合理的方式失敗，而這種錯誤最容易通過事後檢視。
關於營運知識與信任的討論，一再指向同一個方向。過期的 runbook 可以說比沒有還糟，因為它會誘發自信但錯誤的行動。而更大的趨勢也同樣清楚：大多數組織都處在 copilots 與 autopilots 之間的某個位置。
幾乎所有人都還在半山腰。問題是，什麼能讓你有資格爬上下一格。
基底先於代理
這是我不斷得到的結論，而現場大多數人也有同感：瓶頸不在模型品質。
你不能把代理放在四個彼此孤立、互不信任的系統之上，然後期待它可靠。代理的好壞，取決於它能拿來推理的脈絡有多好。碎片化的脈絡會產生幻覺，而且往往是那種看似合理的幻覺。
所以基礎工作不是購買代理，而是打造它們讀寫所依附的基底：一個統一、即時的知識圖譜，涵蓋所有四個資料體，以及它們之間的邊。價值就在這些邊上：
一次 commit 改動了一個服務。Terraform 佈建了新的基礎設施。Kubernetes 推出部署。OpenTelemetry traces 開始顯示延遲上升，同時 Prometheus 記錄到 SLO 燃燒。這張圖譜把這些事件，連到六個月前一次類似事故，以及當時解決問題的修復方式。
這張圖譜必須是活的，因為昨天的視圖不是今天的世界。它也必須有版本，因為每一次代理決策都是基於某個特定快照做出的，而你之後會需要重播它。
沒有這張圖譜，代理只是漂亮的展示。有了它，代理才變得可行：能跨越四個主體推理，在政策與影響範圍限制內行動，並把每個結果寫回去，讓下一輪循環變得更好。
信任是一條決策軌跡
如果基底是圖譜，那麼在其上真正贏得信任的，就是可稽核性。
失敗模式是真實存在的：許多看似厲害的「自主性」，其實只是中間塞了一個 LLM 的腳本；上週二提示詞還不一樣，週四模型版本又升級，卻沒有人記錄當時的輸入脈絡。那不是生產環境中的自主運作，而是行為無法可靠重現或稽核的不透明自動化。
不可妥協的架構承諾，就是決策軌跡。代理採取的每一個行動，你都需要一份可長期保存的紀錄，包含：
- 它看到的輸入（圖譜的哪一個快照）
- 當時生效的政策
- 使用的模型版本
- 它考慮過並排除的假設
- 它採取的行動，以及結果
這不是合規上的錦上添花。當代理第一次在生產環境做出真正有影響的事時，你的資安長（CISO）、風險主管和主管機關一定會問這些問題。你無法為其辯護的自主性，其實就不是你真正擁有的自主性。
這也是那些被大肆炒作的指標討論，終於能放到正確位置的地方。當代理能持續跨越四個主體推理，並且嵌入在流程路徑中，而不是事後才寫檢討報告，事故就會變少，凌晨兩點的告警呼叫也會成為例外。值得關注的數字，會從你恢復得多快，轉向你有多常根本不會度過一個糟糕的夜晚。但那是把基底與軌跡做對之後的結果，不是你的起點。
路徑
那麼，你要如何從拉著八家供應商一起開事故橋接會議，走向自主營運？兩個原則。
- 把維運視為資料。 別再讓程式碼、基礎架構狀態、執行階段訊號與維運知識，分別活在四套彼此隔絕、互不信任的堆疊裡。把它們整合成一個可查詢、可版本控管、也可推理的統一知識圖譜。代理程式（agent）是下一步，不是第一步。沒有這個基礎，就不會有任何代理程式值得信任到能放進關鍵路徑。
- 把代理程式嵌入通往正式環境的流程，而不是事後才補上。「人來做事，代理程式負責寫事後檢討」不是自主，而是聽寫。代理程式必須能在程式碼、基礎架構即程式碼（Infrastructure as Code）、Kubernetes 狀態、OpenTelemetry 遙測、Prometheus 指標與維運記憶之間，形成持續循環的推理（而且這個循環應該先讓事故更少發生）；它做出的每個決策，也都必須留下軌跡，讓下一次決策變得更好。
我們會在 2026 年達到完全自主維運嗎？不會。但方向已經很清楚，而且這條路不是靠更多人力來擴張，而是靠更好的脈絡，以及能可信地依據脈絡行動的代理程式。
不要從代理程式開始。從圖譜開始。從那四個本體開始。代理程式會跟上；而當它們跟上時，才會真正發揮作用。