第二章
邁向代理式工程的轉變

本章為最終書稿的第一章。請注意，GitHub 儲存庫將於稍後正式啟用。
若您願意實際參與本草稿的審閱與意見回饋，請與編輯聯繫：jleonard@oreilly.com。

過去十年間，網站可靠性工程（Site Reliability Engineering）大多被視為一個「規模問題」，而且答案早已明確：多做自動化、把警報調得更準、文件寫得更詳盡、找更聰明的工程師。這套思路確實有效——直到它不再有效為止。今天的問題不是系統不可靠，而是系統已經成長到超出人類能在即時狀態下可靠推理的範圍。

想像一位資深待命工程師在凌晨三點的處境。結帳流程觸發了延遲警報，操作手冊要求跑五個步驟的診斷：近期部署、依賴健康度、流量模式、區域容量、設定漂移。這位工程師之所以在值班名單上，正是因為他很擅長這件事。他在四個儀表板之間來回切換，尋找近期異動；把某次部署與一次設定推送做交叉比對；翻找 Slack 討論串，想確認另一個區域是否真有「吵鬧鄰居」的傳聞；再跑一次拓撲查詢，卻因為 metadata 服務恰好位於剛剛出問題的同一個區域，花了九十秒才跑完。等他終於拼湊出一個站得住腳的假設時，影響範圍已經擴大了三倍。這整個過程裡，沒有任何一個環節是工具故障。每個系統都盡了自己的本分：儀表板正常呈現、操作手冊寫得沒錯、Slack 討論串裡的訊息也都屬實。真正的瓶頸，是那位正在組裝情境的人類，而人類在結構上，已經跟不上系統需要這些情境被組裝出來的速度。

這不是在說那位工程師做錯了什麼——恰恰相反。他做到了這個角色所要求的一切，而這個角色要求的，是不可能的任務。把那個夜晚乘以一整季，你得到的是一支疲憊不堪的團隊，而且無論再增聘多少工程師都無法解決，因為瓶頸從來不是值班名單上有多少人，而是警報一響，每個人被要求做的事情本身。就算多請兩位資深工程師，你得到的也只是多兩個人在凌晨三點各自跑一次同樣不可能完成的診斷。

實際觀察成熟的工程組織會發現，問題不在於缺乏工具或流程，而是一種持續擴大的認知瓶頸。工程師被要求在應變事故、審核變更、解讀遙測資料、管理風險的同時，把整套系統放在腦中。即使擁有優秀的可觀測性與定義完善的操作手冊，訊號的數量與速度依然超出注意力所能吸收的範圍。結果我們都很熟悉：警報疲勞、事故應變拖長、變更趨於保守，團隊花在「維持」可靠性上的時間，多過花在「改善」可靠性上的時間。這些都不是個人的失職，而是當一個依「人類永遠站在迴圈中心」這個假設所設計的角色，遇上了一套早已超出這個假設的系統之後，必然會發生的事。

業界對這股壓力的回應是自動化——腳本、管線、自動修復，以及近來的 AI 輔助工具。自動化確實有幫助，但很快就遇到了天花板。自動化能更快地執行預先定義好的步驟，卻不理解情境、不權衡取捨、也不會在條件飄移時自我調整。系統愈動態，純粹的自動化就愈脆弱：每多一個例外，就多一條規則；每多一個依賴，就多一個條件判斷。久而久之，自動化堆疊本身變成了工程師在故障時還得額外理解的第二套系統，而在規模擴大之後，這套堆疊並不會降低認知負荷，只是把負荷轉移了位置。它擴展的是執行力，不是判斷力。

這正是本書其餘篇幅要處理的結構性錯位。我們建構出的系統，其狀態與動態早已超出人類步調所能理解的範圍，而我們的回應方式，是把更多過去由人類做的事情自動化，卻沒有改變迴圈中那個人類注定會成為瓶頸的部分。某種意義上，過去十年我們一直在最佳化迴圈裡錯誤的那一段。本書所主張的轉變，正是要補上這道落差：從「等待被告知該做什麼」的系統，走向「在人類設定的邊界內觀察、推理、行動」的系統；從「以待命工程師在凌晨三點能多快組裝出情境」來衡量的工程角色，走向「以系統在凌晨三點來臨之前推理得有多好」來衡量的工程角色。我們把這個轉變所催生出的學科，稱為「代理式可靠性工程」（agentic reliability engineering）。

1.1　SRE 難以為繼的規模化危機

網站可靠性工程當初被創造出來，是為了解決一個具體的問題：如何在不仰賴英雄式救火的情況下，可靠地營運大規模系統。長久以來，答案很清楚：標準化實務、把重複性工作自動化、量測一切、把可靠性當成工程問題而非事後補救的營運雜務。Error budget 給了團隊一套可量化的風險語言；減少 toil 則讓他們有紀律地運用工程時間。這套模型在系統呈線性成長、人類理解力還能跟上系統行為時，運作得很好。而我的看法是：我們已經越過了那個臨界點。

今天多數組織所經歷的可靠性危機，並非成熟度不足所致，而是規模與人類認知正面碰撞的結果。系統的變化速度快過人類能對其進行推理的速度；依賴關係的增生速度快過團隊能夠繪製地圖的速度；遙測資料的成長速度快過工程師能夠解讀的速度。可靠性已經變成了一個「注意力」問題，而不是「意圖」問題。有三個崩壞現象讓這道落差變得清晰可見：警報、事故應變、變更管理。這不是三個獨立的問題，而是同一個問題的三張臉。

第一個是警報。隨著系統成長，警報也跟著倍增。團隊的因應方式是不斷調校、分組、抑制、記錄警報，直到「管理警報」本身變成一份全職工作。到了那個地步，警報就不再是訊號，而變成了噪音管理的演練。工程師回應的已經不是現實世界，而是自己為了生存而建立的過濾規則。負責警報政策的團隊，如今其實是在經營一個小型的內部產品，客戶就是自己，而產品則是「一份還算能忍受的待命負擔」。要花資深工程師的薪水去打造這種東西，實在是件奇怪的事。

第二個是事故應變。時間軸之所以拉長，不是因為團隊反應慢，而是因為組裝情境的過程本身就慢。工程師把最關鍵的幾分鐘，花在重建「發生了什麼變化」「什麼東西彼此相關」「什麼才是重點」上。他們在各個可觀測性工具之間來回切換，因為沒有一個工具能掌握整個系統的全貌。他們得把最近一次部署、一次設定推送、一次基礎架構變更、一個上游的第三方事故拼湊在一起，而這些線索分別由不同系統擷取，彼此的「語言」也並不真的相通。等到真相終於浮現，系統往往已經進一步惡化。那些最關鍵的決策，本來需要在情境齊備之前就做出——也就是說，在現代條件下，這些決策根本不可能由人類做出，無論這些人類的工作能力有多強。

第三個是變更管理。隨著信心下降，組織開始增加關卡：審查變得更冗長，核准委員會愈設愈多。需要為一次部署背書的人數，與任何人對這次部署「真的安全」的信心程度成反比增長。速度變慢，不是因為團隊缺乏能力，而是因為不確定性升高，而人類面對不確定性的本能反應就是增加流程。這套做法一開始確實有用，但漸漸地，流程本身變成了瓶頸，會議節奏變成了限制變更上線速度的因素。到了這個地步，治理已經不再是在保護可靠性，而是在對可靠性課稅。誠實地說，這些關卡買到的只是「安全的外觀」，而不是安全本身。

在這三種崩壞現象裡，背後的假設都一樣：會有一位人類站在迴圈中央，掌握足夠的情境來做決策。這個假設在 SRE 大半的歷史裡都是成立的，但現在已經不再成立。訊號的數量、變化的速度、依賴關係的深度，都已經超出任何個人所能承載的極限，而圍繞著人類不斷增生的保守流程，變成了一種對「產能」的替代品，而不是補充。實質上，我們把人類變成了那些早已超出人類整合能力的系統的「整合層」。結果不只是一支疲憊的待命團隊，而是我們的系統可靠性從此有了一道結構性的天花板。

這正是「代理式可靠性工程」（Agentic Reliability Engineering，簡稱 ARE）被設計來填補的落差。ARE 是這樣一門學科：建構能夠觀察情境、權衡取捨、並在人類設定的意圖邊界內採取行動的可靠性系統，讓人類的角色移到迴圈之上，負責設計與監督，而不是深陷迴圈之中，成為即時決策引擎。我們不是在取代 SRE，而是在演進它。Error budget 沒有改變，SLO（服務等級目標）也沒有改變。改變的是：誰在讀警報、誰在為選項評分、誰在團隊同意的邊界內採取行動。本書接下來的篇幅，就是要巡覽這門學科在實務上究竟長什麼樣子。

1.2　定義代理式系統

在繼續往下之前，我們得先把語言講清楚。這個領域裡許多問題，都源自於術語被過度混用。「自動化」「智慧」「自主性」「代理性」常被交替使用，儘管它們描述的是截然不同的能力。這裡的釐清並非學術上的講究，而是根本性的，因為我們在後續章節裡所做的設計選擇，取決於我們實際上正在建構的是這幾者中的哪一個；一個把「以 LLM 為後盾的助理」和「代理式系統」混為一談的團隊，會設計出（並部署出）錯誤的東西。

所謂「代理式系統」（agentic system），是一種能夠感知環境、對所觀察到的內容進行推理、並在人類意圖所定義的邊界內採取行動的系統。三個元素，權重相等——拿掉任何一個，這個系統就不再是代理式的。只感知而不推理的系統，是監控。只推理而無法行動的系統，是分析。只行動而不感知也不推理的系統，是自動化。代理式系統，是同時做到這三件事、並且被限縮在一個有邊界的意圖範圍內的系統。而這個「有邊界」的部分，在這句話裡所做的工作，並不亞於那三項能力本身。

這正是代理式系統與我們共存了二十年的那種自動化之間的分野。自動化聚焦於執行：當特定條件成立時，遵循預先定義好的指令——若條件 A 發生，則執行動作 B。這個模型是確定性且可預測的，這正是它在營運上向來如此有價值的原因，也正是它在系統愈趨動態時愈顯脆弱的原因。自動化不理解自己為何要採取行動，不評估其他替代方案，也不會在條件飄移到預期之外時自我調整。當意外發生時，自動化要嘛悄無聲息地失敗，要嘛升級交給人類，要嘛自信滿滿地做出錯誤的事。而「自信滿滿地做錯事」，正是 SRE 社群長久以來關於自動化那些警世故事裡，最常見的失效模式。

代理式系統的行為方式不同。它們評估的是情境，而不是觸發條件；衡量的是信心，而不是確定性；根據意圖與限制條件來選擇行動，而不是套用靜態規則。重要的是，它們不需要永遠正確，只需要「有邊界、可觀察、負責任」。這是一個和「永遠正確」截然不同的工程目標，而這也正是可靠性工程師早已知道如何達成的目標，因為它和 error budget 所瞄準的目標一模一樣。我們建構的系統，大多數時候「夠好」就好，能夠揭露自己的不確定性，並且對「出錯時該怎麼辦」有一套明確的因應方式。我們要求的不是全知全能，而是對信心程度的誠實，以及對錯誤有設計過的回應方式。

有幾種常見的誤解，值得在此點名，因為誤稱的後果會反映在實務上。會總結儀表板、代寫事故更新的對話式助理，不是代理——它們只是觀察與描述，不推理也不行動，而且是站在可靠性迴圈之外，而非之內。經機器學習調校過的規則引擎，也不是代理——模型負責分類，但決策本身仍是寫死的，一旦條件飄移到預期之外，行為就會立刻變得脆弱。只依單一門檻觸發的反射式自動修復管線，同樣不是代理——它們只會反應，不會權衡，也無法在「不出手才是正確選擇」的時候選擇不出手。這些工具本身都不差，甚至大多很有用，但它們不是代理式的；把它們當成代理來對待，正是團隊日後在生產環境中被自己的系統嚇一跳的原因。

本書往後將反覆提及人類在這套定義下的角色，因此我們在此先為它命名一次，並始終如一地使用這個詞：我們會把人類稱為「迴圈之上的人類」（above-the-loop human）——負責定義意圖、設定限制、審核結果，並在系統遇到無法安全處理的狀況時介入的工程師、團隊或組織。「迴圈之上」不代表缺席迴圈，而是站在人類最能發揮價值的位置：判斷、當責，以及系統本身的設計。代理身處迴圈之中，因為這個迴圈如今以機器的速度運轉；人類則站在迴圈之上，因為就設計而言，這個迴圈多數時候本來就不需要人類參與。而當系統真的把例外浮現出來時，那正是人類這一天真正發揮作用的時刻。

因此，本書接下來會採用一個乾淨俐落的判準：如果一個系統透過結構化訊號感知環境、依據一套它應該優化的目標模型在多個選項之間做出選擇，並在人類設計的邊界內行動，它就是代理式的。若這三項特質缺了任何一項，它就是別的東西。把它稱為別的東西，不是一種失敗，而是一種衛生習慣。今天大部分的可靠性堆疊都不是代理式的，這沒關係；不好的是明明不是，卻硬把它稱為代理式，並照這樣去部署它。

1.3　為何成熟度決定代理式系統的投資報酬

代理式系統的承諾聽起來往往很普遍：更快的復原、更聰明的決策、更少的 toil、自主的執行。較少被說出口的是，這些成果的分布並不平均。同樣的代理能力，放進不同成熟度的系統裡，可能產生截然不同的結果。

這不是 AI 本身的局限，而是系統的一種特性。代理式系統不會創造秩序，它們只會放大既有的秩序；它們不會導入紀律，而是加速既有的紀律，不論那紀律是好是壞。當基礎薄弱時，自主性並不會掩蓋問題，反而會讓問題更早、更明顯地暴露出來；當基礎穩固時，自主性則會讓它的效果不斷複利累積。這正是為什麼有些團隊早期導入就看見顯著成效，有些團隊卻經歷混亂、不穩定與信任流失——也是為什麼兩支跑著類似試點專案的團隊，可能對「這個技術到底有沒有用」得出完全相反的結論。

在成熟度較低的環境裡，人類其實一直在默默地補貼系統。他們交叉核對儀表板，因為不信任任何單一資料來源；他們靠社交知識推斷擁有權，因為標籤本身是錯的；他們容忍模糊，因為別無選擇，並用文件從未捕捉到的經驗，填補缺漏的情境。一旦導入代理，這份補貼就消失了：彼此衝突的訊號，變成彼此衝突的決策；缺漏的中繼資料，變成看不見的關聯關係；不清楚的擁有權，變成無法被負責任地執行的行動。代理並沒有弄壞任何東西，它只是移除了那道原本掩蓋著「早已壞掉的東西」的緩衝層。若一支團隊把這個時刻誤診為「AI 的問題」，他們會花上一整年去調校錯誤的系統。

在成熟度較高的環境裡，同樣的機制卻會產生相反的效果。訊號經過整理，遙測資料是刻意設計的，服務被妥善標記、認領、串連，變更流程可觀察且可回溯。在這裡，代理不是在猜測，而是在推理；它們的決策不是投機取巧，而是有憑有據。每一次自主決策，都建立在先前的學習之上——報酬不是線性成長，而是複利成長。

這在實務上的意涵是：ARE 是一級一級「掙」來的，而不是一步到位的。這裡有一套成熟度模型，我們會在第 4.9 節正式展開；你在這套模型上所處的位置，決定了哪一種自主性能幫到你、哪一種會傷到你，以及在邁向下一級自主性之前，你需要先投資哪些基礎建設。現階段，讀者只需要記住這一點：沒有任何團隊會在第一天就直接部署 L5（第五級成熟度）的 ARE。本書的目的不是說服你跳過這些工作，而是依序向你展示這些工作究竟是什麼，好讓你所部署的自主性，是讓你變得更強，而不是讓你「錯得更快」。對多數團隊而言，導入代理式系統的第一個回報，往往不是更快的復原速度，而是誠實地看清——原本那套可靠性敘事，其實一直是靠文件從未提及的人，默默撐起來的。

1.4　意圖：被遺漏的抽象層

大多數可靠性系統會以同樣的方式失敗——不是因為缺乏資料、自動化或智慧，而是因為缺乏「意圖」的清晰度。

傳統 SRE 實務都是間接地編碼行為：門檻值暗示著可接受的風險，操作手冊暗示著優先順序，升級路徑暗示著誰擁有這件事。這些做法沒有一個明確陳述「系統究竟想達成什麼」，它們描述的是動作，而非目的。自動化能夠容忍這種間接性，因為當代理指標（proxy）與目標之間出現落差時，總有人類在場修正結果。但自主性無法容忍這一點：代理必須在多個行動之間做選擇、權衡取捨，並決定何時不該行動。這些決策無法單靠門檻值可靠地編碼出來，它們需要一種明確表達「系統應該優化什麼」的方式。我們把這種表達方式稱為「意圖」（intent）。

意圖是一份結構化的宣告，說明系統試圖產生的結果、必須遵守的限制，以及被允許做的取捨。它可以依服務、環境、時間或情境而變化。同一個服務，在尖峰時段可能優先考慮可用性勝過成本，在離峰時段則優先考慮效率勝過可用性；一個依照明確意圖運作的代理，可以在不需要任何人另外寫一份特例操作手冊的情況下，尊重這樣的區別。意圖不是一句模糊的使命宣言，而是與遙測資料、政策並列的一級輸入。一旦它取得這樣的地位，許多目前寫死成「若 X 則 Y」的邏輯，就能變成「在目前的意圖之下，Y 現在應該長什麼樣子」。

意圖與傳統門檻邏輯的對比十分鮮明，也值得仔細推演，因為本書其餘部分都建立在這個對比之上。以「在促銷期間維持結帳服務的效能」這個相同的營運目標為例，有兩種表達方式。

第一種是規則：「若結帳服務的 CPU 使用率連續超過三分鐘高於 80%，則擴充兩個副本；若記憶體使用率超過 85%，則呼叫待命人員。」今日我們大部分的自動化，看起來就是這個樣子——具體、可測試、容易寫。但它也很脆弱，完全沒有說明團隊真正在意的是什麼，那就是「客戶體驗」。即使延遲表現良好，它也會在 CPU 偏高時擴充服務；即使 CPU 表現正常，但延遲因為上游依賴而惡化，它也不會擴充服務；即使服務正順利地自動擴展、沒有任何客戶注意到異狀，它也會在記憶體達到 85% 時呼叫待命人員。這條規則編碼的，只是團隊真正想要之物的一個代理指標，而當這個代理指標偏離目標時，系統優化的就是這個代理指標本身。

第二種是意圖：「在尖峰時段，將結帳流程的 p99（第 99 百分位）延遲維持在 200 毫秒以下。在達到這個門檻之前，優先選擇具成本效益的容量配置。未經人類核准，不擴充超過兩個副本。在促銷活動視窗的最後一小時內，除非延遲超過 300 毫秒，否則完全不調整容量。」這段話寫起來更長，也更難寫得好。但這正是「為正確的理由，擴展正確的東西」的系統，與「只是遵循一條規則」的系統之間的差別。一個依照這份意圖運作的代理，可以依延遲而非 CPU 來擴展；在促銷活動即將結束時維持容量穩定，以避免打亂一個原本穩定的系統；並在限制條件彼此衝突時，誠實地把衝突攤在檯面上。團隊不再是告訴系統「該做什麼」，而是告訴系統「什麼應該為真」，並信任它會在能讓這件事成真的行動之中做出選擇。

意圖有三個對本書其餘內容至關重要的特質。它是「明確的」（explicit）：被寫下來、有版本控管、可供審查，而不是藏在某人腦中，或散落在三份不同操作手冊之間的縫隙裡。它是「有邊界的」（bounded）：搭配著代理在遵循它時被允許的限度，這樣一來，「優先選擇具成本效益的容量」就永遠不會演變成「在流量暴增時縮到零」，「將客戶影響降到最低」也永遠不會演變成「在下一次維護窗口之前封鎖所有變更」。它也是「可觀察的」（observable）：系統可以回報自己目前遵循的是哪一個意圖、為什麼，這樣一來，代理的行動與人類期望之間的分歧，就能變成一場建設性的對話，而不是一份事故事後檢討報告。

一旦意圖成為主要的抽象層，許多其他事情就會各就其位。可靠性不再只是對症狀做出反應，而是變成守住結果；代理不再只是優化「哪個訊號最大聲」，而是開始優化「組織真正想要什麼」；分歧變得可追溯，而不再神祕難解。可靠性的討論，從「系統為什麼那樣做」轉變為「它遵循的是哪一個意圖，而那個意圖是否仍然正確」。這是一場更有用的對話，也正是本書其餘部分想要支援的對話。

1.5　信任邊界與自主性的極限

沒有限制的自主性，不是智慧，而是風險。

關於代理式系統，最常見的一個迷思是：成功與否取決於我們願意放手多少控制權。事實正好相反。代理式系統在其權限被清楚劃定邊界時，表現最好。信任不是靠移除限制而產生，而是靠把限制設計好而產生。在可靠性工程裡，讓自主性真正可用的交付物，不是「自主性」本身，而是自主性運作所在的那道邊界。我們把這道邊界稱為「自主邊界」（autonomy boundary）。

自主邊界，是明確、可由機器強制執行的規格，定義代理被允許做什麼、在什麼條件下、以及如何被停止。我們會把「信任邊界」（trust boundary）這個詞保留給同一個概念的社會與合約面向——也就是人類、團隊、組織對「代理可以做什麼」所達成的協議——而把「自主邊界」用來指稱那個被工程化出來的實作物。這個區分很重要，因為社會層面的協議與技術層面的強制執行必須彼此吻合，而兩者之間出現落差，正是自主性最常讓團隊惹上麻煩的方式之一。

一個好的自主邊界有三項特質。它是「明確的」：代理被允許的行動、條件與停止機制，都以人類和代理都能讀懂的形式被寫下來。它是「機器可強制執行的」：這道邊界不是建議，而是運行在代理每一次決策路徑上的程式碼，超出邊界的決策不會被執行。它也是「可降級的」（demotable）：當信心下降、出現前所未見的條件、或人類發出覆寫指令時，代理的權限可以被縮減到一個更窄的範圍內，而不需要重啟系統或遺失狀態。一道無法即時收緊的邊界，不是邊界，只是一種期望。

航空業的比喻在這裡最經得起檢驗，我會用這一次，然後就此打住。自動駕駛系統不代表機師停止駕駛，而是意味著機師的角色轉變為監督、設定、介入，而整套系統的設計，讓機師能在任何一刻直接接管操控，同時機身仍持續飛行。自動駕駛也有明確的操作範圍：不會超過的高度、不會採取的姿態，以及在什麼條件下它會自行解除接管、把控制權交還給機師。這一整組特質——可監督、可設定、可被中斷、並在極限時自我解除——正是我們希望代理式可靠性系統呈現出來的樣子。自主性不是一個介於零到一之間的旋鈕位置，而是一個被設計出來的操作範圍，而這個範圍本身，就是交付物。

由此可以直接推導出第二個要點：人類的覆寫，不是自主性的失敗，而是自主性的一項特性。代理應該預期自己會被覆寫，並在被覆寫時把自己的推理過程攤開來；它們應該記錄自己當時遵循的是哪個意圖、遵守的是哪道邊界，好讓這次覆寫變成一個結構化的訊號，而不是事故紀錄裡潦草的一行字。當覆寫代表意圖本身是錯的，團隊就該調整意圖；當覆寫代表邊界設得太鬆，團隊就該收緊邊界；當覆寫代表代理是對的、而人類錯了（這種情況確實會發生，系統也應該對此誠實），團隊則學到另一件事。如果覆寫被當成「系統失敗」的證據，這一切都不可能發生。移除覆寫的能力，並不會讓系統更安全，只會讓它更脆弱，因為唯一的修正路徑已經被工程化地拿掉了。覆寫，正是人機協作發揮最大價值的時刻，系統的設計應該是邀請它發生，而不是懲罰它。

實際的後果是，工程投資的重心會發生轉移。在傳統自動化裡，工程心力投入在「動作」上：讓腳本可靠地做那件事。而在代理式系統裡，愈來愈多心力會投入在「邊界」上：明確指定代理可以做什麼、把它能做的條件編碼下來，並為那些在情況不對勁時收緊自主性的降級路徑安裝儀表。動作本身正變得愈來愈便宜；邊界，才是你真正被付錢去設計的東西。一旦把這個反轉內化，許多原本看似令人卻步的「在生產環境部署代理」，就會變成一套熟悉的工程紀律，而且能乾淨地對應到 SRE 團隊早已知道如何操作的政策、error budget 與審查流程。在這套模型裡，信任不是一種感覺，而是你所建構的那道邊界的一項屬性。就像生產系統的任何屬性一樣，它是可量測、可觀察、可改善的。

1.6　從反應式營運到會推理的系統

今天多數可靠性實務仍然是「反應驅動」的：某個東西壞了，訊號觸發，人類解讀情境，然後才有行動跟上。即使在營運良好的 SRE 團隊裡，這種模式依然主導著日常工作。成熟與不成熟的團隊之間，差別不在於是否需要反應，而在於他們能多快組裝出足夠的情境來做出良好的反應。代理式可靠性工程的目標，不是讓「反應」變得更快，而是把「推理」推到迴圈更前面的位置，讓需要反應的那一刻到來時，大部分工作其實早已完成。

在反應式模型裡，有三個脆弱的假設撐起整套系統：第一，故障發生得夠稀少，人類跟得上；第二，情境可以在事故發生時，從日誌、儀表板與近期記憶中快速重建；第三，經驗可以彌補缺漏的訊號。在現代的規模下，這三個假設沒有一個經得起生產環境的考驗——系統變化太過頻繁，任何個人都無法追蹤；依賴關係太過深遠，情境無法在事故發生的速度下被重建；而經驗，這三者之中最昂貴、最難累積的一項，卻無法乾淨地在不同系統、不同團隊、不同世代的架構之間轉移。

取代反應式營運的，不是更快的反應，而是持續不斷的推理。一個具備推理能力的系統，會在背景以機器的速度持續評估目前狀態、近期變化、歷史模式、服務關鍵性、已宣告的意圖，以及目前的自主邊界。從這些輸入之中，它形成對「接下來應該發生什麼」的預期。當現實與預期出現落差時，系統的回應是有憑有據的，而不是臨場即興的。系統並不是等到警報響起才開始思考——它早就在思考了，警報只是它的思考變得可見的那一刻。

這聽起來有點抽象，所以有必要具體說明本書所謂的「推理」究竟是什麼、不是什麼。我們所說的「推理」，指的是「受政策約束的決策」：代理依照一套明確的意圖與自主邊界模型，評估結構化訊號，為各個選項評分，然後決定行動或升級。我們指的不是自由形式的文字生成，也就是大型語言模型被要求寫一段文字時所做的那種事。這兩種活動彼此相關，底層技術也常常重疊，但工程紀律截然不同。一個可靠性決策必須是可重現、可稽核、有邊界的——這些特質，正是受政策約束的決策系統被設計來提供的，而純粹的生成式行為則不然。

同樣值得誠實說明的是，「推理」不是什麼。相關性不是推理——注意到兩個訊號同步變動，並不能解釋因果關係、意圖或取捨。儀表板不是推理——它們呈現資料，不做評估。事後分析不是推理——它是回溯性的，一個只在失敗之後才學習的系統，仍然把「失敗」當成自己的學習觸發條件。預測也不是推理——預測負載或故障機率固然有用，但沒有決策政策的預測，並不會產生可靠性；當多個預測彼此衝突、信心偏低，或意圖發生變化時，系統仍然得決定該怎麼做。推理，是透過對情境與限制條件的明確評估，把預測與行動連接起來。當推理被誤解為上述任何一種鄰近活動時，自主性就會讓人失望；當推理被刻意設計出來時，自主性就會變得可預測、可稽核、值得信賴。

一旦推理變成持續性的，警報的模型也會跟著轉變。警報不會消失，但它的角色會改變。在反應式模型裡，警報是系統第一次要求關注的時刻，是觸發後續一切的起點。在推理式模型裡，警報變成一個下游的產物——是系統把自己早已在形成中的決策浮現出來的那一刻。在代理式系統裡，最有用的警報，不再是「有東西壞了」，而是「我即將採取行動，這是我要做的事，以及原因」，或是「我無法行動，這是我目前撞上的邊界」。這種警報角色的轉變，是「推理已經移到迴圈更前面」最清楚、最日常可見的徵兆之一，也會在數週之內明顯改變待命的體驗。呼叫不再是「弄清楚正在發生什麼事」，而是「這是正在發生的事，這是系統已經做的事，這是系統自己無法做出的那個決定」。

在推理式模型裡，人類依然是核心，只不過如同我們前面所說的，是站在迴圈之上，而非身處其中。他們定義系統據以推理的意圖，劃出系統據以推理的自主邊界，審核系統產出的結果，並依此調整邊界與意圖。他們處理系統浮現出來的新奇狀況，因為這些狀況落在模型之外。當推理變得持續不斷時，這些工作沒有一項會消失，反而變得更加重要，因為它們如今是形塑系統所有自主行為的槓桿點。一支把意圖與邊界都設對的團隊，會在系統做出的每一個決策上得到複利式的回報；而任一項設錯的團隊，也會以同樣的速度得到複利式的錯誤。

整個轉變，一句話說完，就是「擴展的是判斷力，不是執行力」。我們並不是要求系統做更多過去由人類做的事，而是要求它接手迴圈中以機器速度運轉的那個部分——感知、評分、行動——好讓人類能專注於只有人類才能提供的那部分：對「系統本來就應該做什麼」的判斷。這句話，就是全書的標語；你會在本章結尾再看到它一次，之後，它會在沉默中持續發揮作用。

1.7　總結：為代理時代重新框架可靠性

本章一開始要挑戰的，是一個大家再熟悉不過的假設：可靠性主要關乎「出事時反應得好不好」。但浮現出來的，是另一套框架——在現代的規模下，可靠性已經不再是一個「反應」問題，而是一個「設計」問題，而這個設計必須承認：人類已經不再快得足以站在迴圈中心。一旦承認這一點，許多原本看似「精疲力竭」的現象，其實是一種範疇錯誤：待命名單本來就注定跟不上，要求更優秀的人類去吸收更多訊號，從來就不會是答案。

本書其餘部分要延續的三件事是這樣的。第一，這道落差是結構性的，不是營運性的。再好的工具、再多的訓練、再嚴謹的流程，都無法單靠自身補上這道落差，因為這道落差存在於「人類步調的意義建構」與「機器步調的系統動態」之間，而其中一方不會慢下來。第二，ARE 是我們為這門補上落差的學科所取的名字：它建構出能在人類撰寫的意圖與機器可強制執行的自主邊界之內，感知、推理、行動的可靠性系統，同時讓人類站在迴圈之上運作。你需要的詞彙已經都寫在紙上了：代理式系統、迴圈之上的人類、意圖、自主邊界、推理。我們不會重新定義這些詞，而是會直接使用它們。第三，本書其餘部分，會依照一支 SRE 團隊實際建構這門學科的順序，帶你巡覽這門學科在實務上的樣貌。

這個順序是刻意安排的，也是本書與你之間的一份契約。第二章談可觀測性，因為一個看不清楚的代理，也無法清楚地推理，而你今天所擁有的大部分可觀測性堆疊，都是為了另一種消費者而設計的。第三章談韌性：偵測、推理、行動、學習的迴圈，把可觀測性轉化為復原能力。第四章鋪設本書其餘部分所仰賴的架構骨幹（四個平面、一套成熟度模型，以及人機協同的控制迴路）。第五、六、七、八章，把 ARE 帶進 SRE 團隊早已在運作的工作流程之中：事故應變、交付、混沌工程、事前情報，展示當推理移到迴圈更前面之後，究竟改變了什麼。第九、十、十一、十二章，是本書技術上最核心的部分：決策智慧、推理模式、受治理的自主性，以及模擬。第十三、十四、十五章，則是營運模型、多代理架構，以及你最終會運行的代理生態系。尾聲則回到人類的角色，因為說到底，可靠性終究是一項由人類主導、借助機器來完成工作的事業。

這不是一本關於「取代工程師」的書，而是一本關於「把工程師一直以來最擅長的那部分工作還給他們」的書：判斷、設計、當責。我們透過把迴圈中以機器速度運轉的部分，交給那些被謹慎打造到足以被信任的系統，來達成這一點。我們擴展的是判斷力，不是執行力。本書其餘部分，要談的就是「如何做到」。