第七章
代理驅動的事故應變管線

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

同一起事故，交給五個不同的組織處理，會產出五種不同的結果——同樣的警報、同樣的根本原因、同樣的爆炸半徑。一個組織呼叫一位資深待命工程師，他花十二分鐘從六個工具裡組裝出情境，然後上線一次回滾；另一個組織，有一個代理在 23 秒內節流了非關鍵路徑，沒有呼叫任何人。分野兩者的不是技術，是架構。第 5.10 節會用刻意的細節，完整展開同一起事故橫跨全部五個成熟度等級的樣貌，本章其餘部分，都是讓這個比較變得有意義的裝置。

事故應變，是本書把四平面架構套用的第一個工作流程，這個選擇是刻意的。事故是高頻率、高成本、時間緊迫、而且被充分理解的——每一位讀者都值過班，每一位讀者都在時間壓力下組裝過情境，每一位讀者都在不確定修復是否有效的情況下上線過修復。這是少數幾乎每一位 SRE 都以幾乎相同方式親身經歷過的工作流程，這正是為什麼它是檢驗代理式可靠性工程是否值得的最乾淨的測試。如果 ARE 無法在事故期間安全地運作——在爆炸半徑正在擴大、決策最為要緊的時候——那本書其餘的一切都不值得實作。

本章也是那批反覆出現的代理陣容變得可見的地方。第一部順帶點名了好幾個代理，第二部則是它們透過參與同樣的場景贏得自己一席之地的地方。觀測代理持續維護決策級訊號，而不只是在有東西觸發時；拓撲代理擁有第二章命名為標準韌性產物的依賴與擁有權圖；發布代理提供變更情境；商業影響代理把「服務 X 正在惡化」翻譯成「使用者 Y 受到影響、代價為 Z」；學習代理在第 5.8 節首次完整登場，透過把每一起事故都轉化為系統對自身模型的結構化更新，來閉合這個迴圈。這些不是各自獨立的產品，而是四平面架構裡的角色，每一個都擁有訊號平面或推理平面的一部分，每一個都產出其他代理能夠消費的結構化產物。本章，正是讀者第一次看見它們實際運作的地方。

一開始就值得點名的結構性特質是：本章的每一節，都對應到第 3.1 節 DRAL 迴圈中的某一拍。第 5.1 節到第 5.4 節，以逐漸提升的解析度展開「偵測」這一拍；第 5.5 節展開「推理」這一拍；第 5.6 節展開「行動」這一拍；第 5.8 節展開「學習」這一拍；第 5.7 節談人在迴圈中如何具體套用到事故應變，並回頭引用第 4.7 節作為正規處理方式；第 5.9 節與第 5.10 節則做量測與比較。依序閱讀，本章是一個持續運作的迴圈套用在單一工作流程上；不按順序閱讀，每一節依然站得住腳，因為架構是同一套。

本章會貫穿一個標準情境：一個支付處理服務的結帳旅程上，發生了一次第一級延遲惡化。這正是第 3.1 節實作範例、以及第 4.8 節參考架構走查所錨定的同一個情境。讀者已經看過一次代理節流非關鍵路徑，本章要圍繞這個情境，展開這個迴圈其他每一拍，然後在第 5.10 節，讓同一起事故在五個成熟度等級上重演一次，展示這套架構如何改變結果。

開始之前，先說明範圍。本章是事故應變的標準處理方式，但並不窮盡一切。特定的失效類別（資料平面中斷、安全事故、跨區域連鎖失效），各自有這裡展開的模式的變體，第七章與第八章，會分別在混沌工程與事前工作的脈絡下接續其中一些。本章展開的，是代理驅動事故應變的一般形狀：架構、代理、它們產出的產物、量測它們的 SLO，以及決定一支團隊能安全運作什麼的成熟度進程。一旦這個形狀被內化，各種變體就是直接了當的延伸，不是全新的框架。

5.1　從警報到情境覺知

警報不是現實的模型，它們是現實的碎片。

傳統的警報堆疊，是為了人類的注意力而優化的。它們在門檻被突破時發出通知，並假設人類會推斷情境、關聯訊號、判斷什麼重要。當系統較小、變化較慢時，這個假設是合理的；對於狀態變化速度快過人類讀完一個儀表板的分散式系統而言，它不再成立。DRAL 的「偵測」這一拍，需要一個不同的產物，本節為它命名。在一套代理式事故應變管線裡，「情境覺知」不是一種心理狀態，而是一項交付物——由系統產出，由人類（或站在偵測這一拍之上的代理）消費。

想想「情境覺知」要有用，必須包含什麼：觸發的訊號，附帶完整契約；量測偏差所依據的歷史基準線；拓撲情境——哪個服務惡化了、它有哪些依賴、哪些下游消費者會受到影響；變更情境——過去一小時上線了什麼、修改了什麼設定、對哪些群組推出了什麼；擁有權中繼資料——誰擁有這項服務、誰擁有這個依賴、涉及哪個待命輪值；以及這每一項輸入各自的信心區間，因為有些會是新鮮的，有些會是過時的。這些都不是新東西——每一位資深待命工程師，都在每一起事故的前兩分鐘手動組裝出這幅圖像。在代理式架構裡改變的，是這份組裝工作不再是人類的工作。訊號平面早已持續維護著這一切產物，觀測代理與拓撲代理，會在訊號突破其契約的顯著性門檻的那一刻，把它們組合成情境覺知物件。

把這件事具體化，回到標準情境。在 t=0 時，/api/v2/cart/submit 端點上的 p99 延遲開始向上漂移。觀測代理一直在依照一份宣告穩定狀態帶、新鮮度保證，以及這個訊號被允許支援哪些決策的訊號契約，持續發送結構化的延遲訊號。在 t=15 秒時，這個偏差超過了顯著性門檻，觀測代理發送這個附帶完整情境的訊號。拓撲代理附上依賴圖：payment-gateway 是上游，回報了一個已經三分鐘的降級狀態；inventory-api 是上游，四分鐘前才部署過；結帳旅程觸及四個下游消費者，它們的流量模式現在都變得可見。發布代理（在此首次客串登場，完整處理在第六章）附上近期變更事件：inventory-api 的部署、一次昨天上線但今早才變熱的設定推送、另一個服務上的一次功能旗標切換。這一切，都在 t=18 秒時落入了情境覺知物件裡。一個審視這個物件的人類，會知道自己原本要花十分鐘組裝出來的一切；一個讀取這個物件的代理，可以立刻開始推理。

這裡所命名的架構轉變，描述起來很小，後果卻很大。過去定義每一起事故頭幾分鐘的那份工作——從多個工具組裝情境——不再存在於事故的關鍵路徑上，它移動到更早的地方，進入訊號平面的持續運作中，而情境覺知物件，正是完成這次交接的產物。人類不再在凌晨三點盯著六個儀表板，人類讀的是一個結構化物件，這個物件早已知道那些儀表板本來會說什麼、以及它們合起來意味著什麼。這正是我們說「代理式可靠性把人類移到迴圈之上」的意思——人類的問題，不再是「正在發生什麼」，而變成了「根據這幅圖像，應該做什麼」。

另一項值得點名的特質是：情境覺知是有版本控管的。在 t=18 時發送的物件，與在 t=60 時發送的物件不是同一個。隨著事故展開，訊號到來，假設變得更銳利，矛盾被解決。情境覺知物件被持續更新，每一個版本都攜帶一個時間戳，以及與前一版本的差異。這一點有兩個重要原因。第一，下游代理能對「情境的變化」進行推理，而不只是對「目前狀態」進行推理，這正是第 5.5 節的「推理」這一拍能夠評估「情況正在穩定還是在惡化」的關鍵。第二，第 5.6 節將要求的稽核軌跡，仰賴的正是能夠準確重建「系統在每個時刻相信什麼」的能力，而有版本控管的物件，免費提供了這份重建產物。

這裡也是拓撲代理第一次在一整起事故裡贏得自己價值的地方。它維護的依賴圖不是一份 wiki 頁面，而是一個持續與觀測到的遙測資料進行驗證的即時資料結構，每個節點都內嵌了擁有權中繼資料與關鍵性層級。當情境覺知物件問「誰在這個服務下游」或「誰是這個依賴的待命人員」時，答案是在毫秒之間、對照一張一分鐘前還正確的圖計算出來的。第 2.4 節確立了這件事為什麼重要，本章，正是這個「為什麼」變得可操作的地方。

本節引出的一個實務問題是，建構情境覺知所需要的架構投資，實際上要花多少成本。答案因團隊起點而異。一支已經擁有結構化訊號發送（第二章的決策級遙測）、一張有擁有者的拓撲圖，以及一個發布事件串流的團隊，已經完成了三分之二的路程——剩下的工作，是把這些組合成結構化物件的觀測代理與拓撲代理。一支從原始指標、隨興部署、wiki 頁面式拓撲開始的團隊，會在代理式事故應變甚至還不可行之前，就先花上一到兩季在基質上。這正是第 4.9 節的成熟度模型在營運上誠實的地方之一——一支處於 L1 的團隊，無法單靠野心建構出代理式情境覺知，基質必須先存在，而基質正是那個緩慢的部分。一旦它存在，組合它的那些代理，就只是數週的工作，而不是數季。

5.2　代理式事故偵測與信心評分

情境覺知確立了系統相信正在發生什麼。偵測是下一步：判斷正在發生的事情，是否上升到「事故」的層級，並開始展開補救工作。在傳統維運裡，偵測是一次門檻突破事件——指標超過了那條線，警報觸發，事故就存在了。在代理式事故應變裡，偵測是更細微的東西，它是一項帶有信心的斷言：情境覺知物件所描述的，是一次需要回應的真實惡化，並附帶一份結構化的估計，說明系統對這個斷言有多信任。

信心，是這套架構裡偵測這一拍的第一等輸出，值得放慢腳步的概念性轉變，是代理的偵測不是一份判決，而是一個校準過的估計。推理平面對它產生的每一個假設，都附上一個信心分數：這很可能是一起依賴飽和事故，信心 0.82；這很可能是一次近期變更引發的迴歸，信心 0.31；這很可能是一次流量轉移，信心 0.14。這些分數，是從情境覺知物件所攜帶的輸入計算出來的：訊號契約顯著性的強度、跨多個訊號的一致性、類似推理模式的歷史成功率、彼此競爭的假設之間的區分度。這個數字不是一種感覺，而是推理過程的一項輸出，由學習代理（第 5.8 節）對照過去的結果校準，可透過第 3.6 節的校準誤差 SLO 量測。

這在實務上重要的原因，是信心正是下游治理平面用來決定「在這個特定時刻，什麼程度的自主性是合適的」的評估依據。一次信心 0.82 的依賴飽和偵測，結合一條「在這個服務層級，信心超過 0.80 就允許自主緩解」的信心驅動政策，會讓這個行動在沒有人類核准的情況下執行；一次信心 0.74 的偵測，會把同一個提案路由給人類；一次信心 0.45 的偵測，則完全不會產出任何行動——代理會帶著這份評估升級，但什麼都不執行。同一套架構透過同一個機制處理這三種情況，唯一改變的，是那個數字，以及解讀這個數字的政策。

一個實作範例會有幫助。標準情境在 t=22 秒時：觀測代理的延遲訊號已經存活了七秒，拓撲代理回報 payment-gateway 處於已知的降級狀態，發布代理回報四分鐘前 inventory-api 有一次部署。推理平面依照情境覺知物件產生三個假設：

hypothesis_1:
  cause: "upstream_dependency_saturation"
  target: "payment-gateway"
  evidence:
    - "payment-gateway reports degraded state for 3m"
    - "checkout latency rose 8s after payment-gateway alert"
    - "historical pattern: payment-gateway saturation produces this signature"
  confidence: 0.82
hypothesis_2:
  cause: "recent_change_regression"
  target: "inventory-api"
  evidence:
    - "inventory-api deploy 4m ago"
    - "checkout traverses inventory-api on slow path"
    - "no other deploys in past hour"
  confidence: 0.31
hypothesis_3:
  cause: "traffic_pattern_shift"
  target: "checkout-api"
  evidence:
    - "traffic up 8% versus same-time-yesterday"
    - "no capacity alarm yet"
  confidence: 0.14

推理平面不會把這些收斂成一份判決，而是把三個假設連同各自的信心分數與證據鏈一起呈現出來。治理平面依照第一級服務在依賴降級條件下的政策，讀取這個領先假設（0.82）。這條政策，允許在這類情況下、信心超過 0.80 就自主緩解，於是這個行動繼續進行。稽核軌跡記錄了全部三個假設、信心分數，以及政策決定。之後，當學習代理審查這起事故時，這個領先假設可以對照「後來證實是錯的」做驗證，這類失效的信心校準，也會為下一次被精煉。

值得點名的紀律是：長期而言，「校準」比「信心」更重要。一個 0.82 信心的斷言，只有在 82% 類似的斷言最終被證實是正確的情況下，才有用。第 3.6 節的校準誤差 SLO，量測的正是這一點。一個宣稱 0.9 信心、卻有 30% 是錯的的系統，無論它的推理看起來多麼精密，都有 CE 問題；一個宣稱 0.9 信心、只有 10% 錯誤的系統，則已經掙得了在這個門檻之上自主運作的資格。這套架構會以完全相同的方式呈現這兩種情況，是校準誤差 SLO 把它們區分開來。第 9.4 節會詳細展開正式的校準模型。對事故應變而言，重要的是這個信心數字被誠實地計算出來、被呈現給治理層，並被學習層對照結果量測。沒有經過校準的信心，不是信心，而是被包裝成判決的猜測。

另一項相關且值得點名的特質，是「負向信心」。有時候，代理最有用的輸出，是一次明確調降雜訊訊號的低信心偵測。一次在已知維護窗口、或負載測試期間，或在目前流量模式異常的區域裡觸發的延遲異常，應該產出一次較低信心的偵測，而不是一次被抑制的偵測。治理平面需要看見這份評估，只是需要它附帶著代理信心被調降的原因。這正是「警報抑制」的架構替代方案——抑制隱藏資訊，調降信心則以適當的權重呈現它，這正是下游政策做出正確決策所需要的東西。

從偵測邁向行動時，值得點名的架構特質是：信心不是每起事故一個單一的數字，而是一個隨時間演變的結構。標準情境在 t=22 秒時，領先假設的初始信心是 0.82；到了 t=60 秒，隨著更多證據累積，同一個假設可能來到 0.91；到了 t=120 秒，如果 t=30 秒採取的行動沒有產出預期的復原，信心可能已經降到 0.55，而替代假設（inventory-api 的變更）可能已經從 0.31 上升到 0.68。這套架構追蹤這一切——推理平面持續更新自己的假設排序，治理平面依照「目前」的狀態、而不是「初始提案被提出時」的狀態，重新評估自主性決策。正是這一點，讓這套架構能從一次錯誤的初始評估中優雅地復原：信心更新，政策回應，下一個行動符合目前的證據，而不是原始的猜測。第九章展開信心如何被計算與更新的正式模型；第十一章展開治理平面如何透過動態政策回應信心變化。對事故應變而言，這裡重要的是：信心是動態的，這套架構把它當成動態的來對待，稽核軌跡則擷取了每一次信心修訂，以及它所影響的行動。

5.3　時間軸建構與變更覺知

偵測確立了正在發生什麼，每一位事故指揮官都會問的下一個問題——每一個代理式系統也必須回答的問題——是「什麼改變了」。在現代分散式系統裡，許多東西持續在改變：程式碼發布、設定推送、功能旗標切換、流量路由變更、依賴升級、基礎架構擴縮。沒有嚴謹的變更覺知，事故診斷會變成瞎猜。組裝出一份有用時間軸的代理，會從結構化的變更事件出發，把它們與事故的訊號軌跡做關聯，並明確地為因果可能性評分。本節，是「偵測」這一拍解析度最高的地方。

這一切的架構前提，是變更要被擷取成資料。每一次部署、每一次設定推送、每一次功能旗標切換，都會向訊號平面發送一個結構化事件：誰做了這個變更、變更了什麼、什麼時候上線、影響了哪些群組、是否可逆、由誰擁有。發布代理，是訊號平面裡擁有這個串流的角色（第六章會完整展開發布代理，它是本書的第二個試煉場）。對事故應變而言，發布代理的工作更為狹窄：提供一個可查詢、依時間排序的變更事件串流，讓推理平面能夠把它與事故的訊號軌跡做關聯。如果這個串流不存在，代理式事故應變會立刻退化——代理無法對它看不見的變更進行因果推理，團隊只能退回到由人類憑記憶與聊天紀錄重建變更歷史，而這正是這套架構原本要消除的組裝步驟。

時間軸建構本身，是一項因果推理任務，不是日誌搜尋。目標不是按時間順序列出事件，而是判斷哪些變更「可能」產出了觀測到的訊號軌跡，哪些不可能。代理為每一個變更事件，依照領先假設評分它的因果可能性。三項因素主導這個評分：時間鄰近性（變更發生在訊號惡化之前多接近）、拓撲鄰近性（這個變更是否觸及了失效服務與其降級上游之間依賴路徑上的服務），以及歷史一致性（這類變更過去是否產出過類似的特徵）。這些每一項，都能從訊號平面早已維護的產物中計算出來。輸出，是一份依可能性排序的、可信的變更側原因清單，附掛在情境覺知物件上，供推理平面在第 5.5 節產生候選行動時使用。

incident: INC-2026-05-13-CHECKOUT-LATENCY
detection_time: t=15s
leading_hypothesis: dependency_saturation:payment-gateway
recent_changes: # last 60min, ranked by causal likelihood
  - event_id: rel-payment-gateway-12847
    type: deploy
    target: payment-gateway
    timestamp: t-23m
    causal_likelihood: 0.74
    rationale: >
      in dependency path; touched code that handles the request class
      showing degradation; historical similarity to two prior
      payment-gateway latency incidents
  - event_id: rel-inventory-api-44219
    type: deploy
    target: inventory-api
    timestamp: t-4m
    causal_likelihood: 0.28
    rationale: >
      in dependency path but on slow path only; small change surface;
      no historical precedent for this signature
  - event_id: cfg-traffic-shaper-9921
    type: config_push
    target: traffic-shaper
    timestamp: t-12m
    causal_likelihood: 0.09
    rationale: >
      in topology but not in this request's path; change affected
      unrelated traffic class
  - event_id: ff-toggle-recommendations-2241
    type: feature_flag
    target: recommendations-api
    timestamp: t-38m
    causal_likelihood: 0.03
    rationale: "outside dependency path for this incident"

代理的頭號嫌疑犯，不是最近的變更（四分鐘前的 inventory-api 部署），而是 23 分鐘前的 payment-gateway 部署。代理之所以知道這一點，是因為時間鄰近性只是好幾項輸入之一，而不是主導因素——歷史一致性與拓撲位置，都偏向那個較舊的變更。一個瞄一眼部署日誌的人類，可能會錨定在最近的變更上，代理則不會。

這一點之所以重要，是因為錯誤的因果推斷，會產出錯誤的行動。一個因為 inventory-api 部署是最近的變更而錨定在它身上的人類，會伸手去回滾那次部署——如果真正的原因是 payment-gateway 的變更，這次回滾會浪費時間，可能引入自己的惡化，同時讓真正的原因繼續運行。代理依照結構化的因果可能性評分、而不是近因偏誤來運作，會採取符合領先假設的行動（緩解 payment-gateway 的飽和），同時讓 inventory-api 的部署維持原狀。這正是這套架構的紀律，產出與同一個工作流程的人類主導版本明顯不同結果的地方之一，而這個差異，並不是因為代理更聰明——代理做的，是資深事故指揮官會做的同一套因果推理，只是它在毫秒之間對照結構化資料完成，而稽核軌跡則明確地記錄下這套推理。

時間軸也需要是可修訂的。隨著事故展開，新的證據到來——一個原本被歸因於依賴飽和的訊號，可能後來被證明是另一件事的症狀。推理平面隨著證據累積更新時間軸，因果可能性分數也隨之改變。正是這一點，防止了系統在證據已經不再支持某個早期假設之後，依然錨定在那個假設上。第 3.8 節命名了這種失效模式（當結果強化了錯誤歸因時的靜默學習腐化）。時間軸的可修訂性，正是事故發生當下對抗這種失效的架構性保護。學習代理（第 5.8 節）處理的，是同一套紀律的事後版本——當後續證據證明一個早期歸因是錯的時，整起事故的因果重建可以被修訂。

另一項值得點名的特質，是時間軸呈現「變更的缺席」時，權重與「變更的存在」相同。當沒有任何變更發生在惡化之前，這件事本身就是高價值的資訊——它排除了整整一類由變更引起的原因，把推理平面重新聚焦到環境、流量，或依賴側的假設上。一個處於壓力下的人類，往往傾向於發明一個變更來解釋惡化，因為另一種可能性（某個東西就這樣自己壞了）讓人感覺不太滿意。代理沒有這種偏誤——如果變更串流在相關的時間窗口內是空的，代理的領先假設會反映這一點，它提議的行動也會不同。

5.4　影響分析與爆炸半徑估算

偵測告訴系統正在發生什麼，因果時間軸告訴它為什麼。在任何行動被提議之前，下一個問題是：這正在多廣泛地擴散，誰受到了影響？這是商業影響代理的工作，它在本章首次亮相，是技術性惡化與治理平面最終必須做出的商業層級決策之間的橋樑。

商業影響代理的工作，是把「服務 X 正在惡化」翻譯成「使用者 Y 受到影響、代價為 Z」。這個翻譯不是可有可無的——沒有它，推理平面推理的是請求的百分比，治理平面則是在不知道真正利害關係的情況下評估行動是否符合政策。有了它，同一個提案就會攜帶一份明確的估計：這次惡化目前影響 12% 的結帳流量，偏重於歐洲西部晚間尖峰時段的客戶，以目前的擴散速率估計每小時營收影響為 18,000 英鎊，受影響的群組包含三個企業帳戶，其 SLA 會在惡化持續 30 分鐘時觸發罰則條款。這個數字不是精確的，而是經過校準的——它足以讓政策評估：提議的緩解措施的成本，是否值得換取它所防止的影響。

值得謹慎區分的概念，是「爆炸半徑」與「嚴重度」。嚴重度問的是「這次惡化有多糟」，是系統技術狀態的一項特質；爆炸半徑問的是「這正在多廣泛地影響使用者與下游系統」，是「誰、什麼東西暴露在這次惡化之下」的一項特質。一個 99% 使用者被路由到健康區域、只有 1% 在降級區域的第一級服務，嚴重度高（那個降級區域狀態很糟），但爆炸半徑低（只有 1% 的使用者受到影響）；一個中度惡化、但位於某條關鍵營收旅程關鍵路徑上的第二級服務，可能嚴重度中等，爆炸半徑卻很高。這兩項量測，是應變政策的兩個獨立輸入，把它們混為一談，是團隊誤判事故緊迫性最常見的方式之一。

商業影響代理，從訊號平面早已維護的產物中計算爆炸半徑。拓撲圖告訴它哪些下游消費者經過這條惡化路徑；觀測代理的流量分布訊號告訴它多大比例的請求暴露在其中；擁有權中繼資料告訴它哪些使用者群組受到影響（地理位置、客戶層級、旅程類型）；契約中繼資料告訴它哪些 SLA 受到牽連。輸出，是一個附掛在情境覺知物件上的結構化爆炸半徑物件，每一項輸入都可被追溯：

blast_radius:
  affected_traffic_pct: 12.4
  affected_cohorts:
    - geography: "eu-west"
      traffic_share: 0.68
    - customer_tier: "enterprise"
      accounts_implicated: 3
      sla_at_risk_at: "30m_continuous_degradation"
    - journey: "checkout_submit"
      critical: true
  spread_velocity: "stable"
  estimated_business_impact_per_hour_gbp: 18000
  estimated_business_impact_confidence: 0.71
  computed_at: "t=28s"

留意商業影響估計上的信心值。商業影響代理並不假裝自己精確地知道財務影響，它是從流量模式、觀測到的轉換率，以及歷史上「每次完成旅程的營收」，計算出這個估計，並連同數字一起回報這份估計經過校準的信心。治理平面的政策，可以依照這個信心區間，選擇使用或忽略這份估計——第一級行動的政策，往往要求商業影響估計要以足夠的信心超過一個門檻，低於這個門檻，這個行動就被當成只有「爆炸半徑」這一項輸入來對待。正是這一點，讓商業影響代理能夠參與例行事故，而不會過度承諾一份沒有人真正能夠捍衛的財務精確度。

商業影響代理呈現的另一項特質，是擴散速度。一個穩定的 12% 爆炸半徑，與一個每兩分鐘就翻倍的 12% 爆炸半徑，是完全不同的營運情境。前者適合經過衡量的回應；後者無論嚴重度如何，都需要立即圍堵，因為五分鐘後預測的爆炸半徑，才是真正驅動緊迫性的因素。商業影響代理從受影響流量的時間序列計算速度，並明確地呈現出來。推理平面在第 5.5 節為候選行動排序時，會把速度當成一項輸入：速度高時，圍堵性行動的排序會上升；速度穩定、且「行動出錯的成本」超過「等待的成本」時，調查性行動的排序會上升。

再一次，把這件事對照標準情境具體化。在付款延遲事故的 t=28 秒時，商業影響代理的評估是：受影響流量 12% 且正在上升，歐洲西部晚間尖峰時段，受影響群組中有三個企業帳戶，估計營收影響每小時 1.8 萬英鎊，信心 0.71，擴散速度緩慢但為正。推理平面把這個評估，連同領先假設（依賴飽和，信心 0.82）與因果時間軸（23 分鐘前的 payment-gateway 部署，因果可能性 0.74）一起讀取。這幅圖像此刻已經足夠連貫，讓推理平面能夠產出具體的候選行動——這正是第 5.5 節要展開的內容。在那之前，這套架構所完成的，是在大約二十五秒內，把一張圖上的延遲飆升，翻譯成一份結構化的原因、爆炸半徑、商業影響、擴散速度評估，每一項都附帶經過校準的信心，可供下游推理使用。這份組裝工作的人類等價物，在 2026 年，運氣好的話也要花上十分鐘。

5.5　建議產生與行動規劃

偵測完成，時間軸組裝完成，爆炸半徑估算完成，推理平面已經擁有足夠的資訊，可以開始做它被設計來做的工作。它產出「候選行動集」：一份針對這個情況、依照同樣的維度評分、每一項都附掛具體行動契約、每一項都攜帶自己的信心與逆轉路徑的簡短可信回應清單。候選行動集，是 DRAL「推理」這一拍的核心產物，也正是治理平面在任何事情被執行之前要評估的對象。本節，是「推理」這一拍解析度最高的地方。

值得點名的心智轉變，是推理平面不會選擇單一一個行動，而是呈現一個「集合」。經驗豐富的事故指揮官，本能地就會這麼做：他們比較回滾、節流、擴容，大聲權衡取捨，選擇一個自己最理解其最壞情況的選項。代理做的是同樣的工作，只是它以明確的方式進行，並依照可量測的維度為取捨評分。輸出不是「系統已決定做 X」，而是「系統辨識出三個候選方案；每一個各自長這樣；這是我們推薦的方案，以及原因」。治理平面讀取這個集合，套用政策，核准通過政策標準的任何選項（若有的話）。候選行動集，正是讓這一切成為可能的結構化產物。

每一個候選方案，攜帶五個欄位。「行動契約」宣告這個行動做什麼、需要什麼、如何逆轉，以及什麼算是成功（第 4.5 節的格式）；「信心」分數宣告推理平面對「這個行動能解決領先假設」的相信程度；「預測影響」宣告預期的爆炸半徑與 SLO 效應；「逆轉路徑」宣告如果不奏效，這個行動如何被撤銷；「治理層級」宣告這個行動所歸屬的政策體制，這正是下游治理平面用來決定「這個行動在目前的自主邊界內是否被允許」的依據。這五個欄位，是一個候選方案要成為治理平面有用輸入所必須宣告的最低限度——少於這些，政策就無法評估這個提案；多於這些，這個格式會變得笨重，卻不會增加任何決策相關的資訊。

candidate_1:
  action_contract: throttle_non_critical_paths
  target: checkout-api
  scope: non-critical request classes, 40% throttle, 10min max
  confidence: 0.87
  predicted_impact:
    latency_p99_recovery: 4-6min
    affected_traffic_pct: 8 (subset of currently-affected 12%)
    revenue_impact_offset_gbp: -3000 (cost of throttling)
  reversal: automatic_on_signal_recovery
  governance_level: autonomous_above_0.80

candidate_2:
  action_contract: rollback_deploy
  target: payment-gateway
  scope: revert to release rel-payment-gateway-12846 (prior known-good)
  confidence: 0.71
  predicted_impact:
    latency_p99_recovery: 8-12min
    affected_traffic_pct: 12 (full current blast)
    side_effect_risk: 0.18 (rollback may introduce regression
                        if other dependent services have caught up)
  reversal: rollback_of_rollback (re-deploy current release)
  governance_level: requires_human_approval_for_tier1

candidate_3:
  action_contract: scale_payment_gateway
  target: payment-gateway
  scope: +3 replicas in eu-west, 15min duration
  confidence: 0.42
  predicted_impact:
    latency_p99_recovery: unknown (does not address root cause)
    cost_increase_gbp_per_hour: 240
    success_probability_if_cause_correct: 0.55
  reversal: automatic_scale_down_after_window
  governance_level: autonomous_above_0.80

這三個候選方案並不對等。第一個是高信心的圍堵，爆炸半徑低，見效快，在目前政策下完全自主；第二個是教科書式的根因修復，但操作風險較高、見效時間較長，且政策要求在回滾第一級服務之前需要人類核准；第三個對這個領先假設而言是錯誤的行動（擴容對依賴飽和沒有幫助，只對容量耗盡有幫助），信心分數如實反映了這一點。推理平面並不因為呈現一個低信心選項而感到尷尬——這個候選方案的目的，是讓治理平面與「迴圈之上監看」的人類看見完整的圖像，包括那個大概沒有幫助的選項。

建議的行動，是從排序中浮現出來的。推理平面依照經驗豐富的事故指揮官會隱含權衡的四個維度，為每個候選方案評分：「有效性」（這個行動解決這個情況的可能性有多高）、「風險」（這個行動可能引入什麼新的失效模式）、「可逆性」（如果錯了，這個行動有多容易被撤銷）、「見效時間」（這個行動多快能可量測地改變系統行為）。這四個維度，在每種情況下並非等權重——在快速擴散的事故中，見效時間主導一切；在緩慢燃燒的事故中，風險與可逆性主導一切。推理平面的排序考慮了這一點，依照目前的爆炸半徑速度與領先假設的信心，呈現出維度加權分數最高的行動。

在這個實作範例裡，排序會把 candidate_1（節流）放在最上面：它通過自主執行政策，能完全自動地逆轉，以高信心處理了領先假設，並在幾分鐘內產生效果。candidate_2（回滾）如果領先假設正確，會更有效，但它較高的風險、較慢的見效速度，加上政策關卡，讓它只有在節流失敗、或信心進一步上升時，才是正確的選擇。candidate_3（擴容）是錯誤的行動；推理平面為了透明度而呈現它，但不推薦它。治理平面讀取這份排序，自主核准 candidate_1，執行平面執行這個行動。稽核軌跡記錄了完整的候選方案集、排序、政策決定，以及被選中的行動。如果後續證據證明領先假設是錯的，學習代理擁有完整的推理軌跡，可以據此精煉未來的排序。

值得點名的紀律是：稽核的單位，是候選方案集，而不是被選中的行動。當一個人類日後問「代理為什麼在凌晨三點節流流量」時，答案不是「代理決定要節流」，而是「代理考慮了三個候選方案，依照這條政策為它們排序，呈現了這個取捨，而政策核准了排序最高的選項」。這個推理是可以重建的，被考慮過、被拒絕的替代方案是可見的，決定這個選擇的政策是可以被檢視的。這正是讓自主事故應變能對高層、對合規、對團隊自己都站得住腳的關鍵。第九章會詳細展開讓這個排序穩健的取捨建模；第十一章會展開限制這套架構隨時間允許多少自主性的決策預算。對事故應變而言，重要的是候選行動集存在、是結構化的、可稽核的，並且是治理平面在任何事情發生在系統上之前，用來對照政策評估的輸入。

5.6　在當責邊界內的自主執行

候選行動已經被排序，治理平面已經對照政策評估了它，執行的授權已經被授予。DRAL 的「行動」這一拍，此刻已經準備好觸發，接下來幾秒鐘會發生的事，正是每一位讀者一直在等著看的：一個自主系統對一項真實服務執行一個真實行動，而第四章的架構性安全措施，正在做它們真正的工作。本節，是「行動」這一拍解析度最高的地方，也是「授權層級」概念（正式處理在第 11.4 節）首次登場的地方。

自主執行不是不受限制的行動，正好相反：它是一個範圍、時長、可逆性與結果驗證，全都被事先宣告好、由一個不能逾越這些宣告的系統來執行的行動。第 4.5 節的行動契約，讓執行變得有邊界；治理平面的政策，在這些特定條件下核准這個特定行動；執行平面，在政策核准的邊界內運行這份契約。這套架構的行為之所以可預測，是因為每一步都是結構化的，而自主性本身，正是團隊在撰寫行動契約與政策時所設計出來的東西。代理不是在自己編造，是團隊做了這些設計決策，代理只是在執行它們。

授權層級，是讓治理變得分級、而不是二元的細緻概念。治理平面問的不是「這個行動是否被允許」，而是「這個行動現在被允許在哪個層級」。這些層級，在此以第 11.4 節正式處理的預告方式命名：

唯讀操作。代理觀察並回報，但不改變系統狀態。永遠被允許。

圍堵操作。代理在不做出不可逆狀態變更的情況下縮小爆炸半徑。範例：節流、隔離、引流。通常在超過服務層級的信心門檻時是自主的。

矯正操作。代理以自動可逆的方式改變系統狀態。範例：擴容、重啟、功能旗標切換、受控回滾。通常在超過一個更高的信心門檻時是自主的，逆轉是強制性的。

結構性操作。代理以不可逆、或影響大範圍爆炸面的方式改變系統狀態。範例：schema 遷移、跨區域容錯移轉、資料修復。在執行當下永遠需要人類核准。

這個層級不只是行動本身的一項特質，而是「這個行動在目前情境下」的一項特質。一次影響 8% 流量的節流是一次圍堵操作；同一個節流若影響 80% 的流量，就跨入了矯正操作的領域，觸發更緊的政策。一次新增三個副本的擴容是矯正操作；一次讓服務規模翻倍的擴容，則往結構性操作靠攏，需要更高的授權。治理平面讀取行動契約宣告的範圍，依照目前情境計算出有效層級，並將它與該層級的政策做比對。自主邊界隨情境動態移動，正是這一點，讓同一套架構能在低風險操作期間積極、在高風險操作期間保守，而不需要改變底層機制。

執行本身，遵循本書其餘部分會回頭引用的一套序列：

execution_sequence:
  1_revalidate:
    - signal contracts still current
    - confidence still above policy threshold
    - blast radius assessment still within bounds
    - no contradicting evidence has arrived since proposal
  2_acquire_scoped_identity:
    - workload identity for this specific action
    - least-privilege credentials
    - audit-trail attribution
  3_execute_per_contract:
    - precondition checks pass
    - action runs within declared scope
    - duration bounded by contract maximum
  4_observe_outcome:
    - watch the action's declared outcome signals
    - watchdog enforces success-criteria evaluation
    - emit outcome signals back to Signal Plane
  5_evaluate_completion:
    - did the action achieve declared success criteria
    - within declared time window
    - without triggering declared abort conditions
  6_reversal_or_completion:
    - if successful: action stays in effect for declared duration, then reverses automatically
    - if unsuccessful: reversal fires immediately, audit event emitted, escalation triggered

這不是可有可無的儀式，每一步，都是讓這份自主性變得站得住腳的關鍵。「重新驗證」，防止基於過時情境的執行（在 t=22 秒政策核准、與 t=23 秒執行器啟動之間，可能已經有一個矛盾的訊號到來）；「範圍化身分」，防止過度寬泛的權限——這個行動只使用足以完成它、僅止於此的憑證；「依契約執行」，防止範圍蔓延——這個行動只做契約宣告的事，不多做任何事；「結果觀察」，閉合了 DRAL 的「學習」這一拍——沒有它，系統會行動，卻不會學習；「評估與失敗時逆轉」，防止「行動了卻沒有效果」——代理不會因為行動運行了就宣告成功，而是因為行動達成了宣告的結果才宣告成功。

標準情境從 t=30 秒到 t=215 秒：治理平面依照 autonomous_throttling_policy_v2.0，核准了 throttle_non_critical_paths。執行平面取得範圍化身分（綁定到平台團隊、專屬於這項服務的工作負載身分），再次運行這份契約的前置條件（全部通過），並更新流量分類器設定，把 checkout-api 上的次要與背景路徑分類節流 40%。action_started 事件在 t=31 秒發送，訊號平面開始觀察這個行動的效果。監視器盯著宣告好的成功標準：p99 延遲須在 5 分鐘內回到基準線，錯誤率須維持在 1% 以下。在 t=120 秒時，監視器回報初步成功：p99 已經回到基準線 60% 的路程。在 t=215 秒時，完全成功：p99 已在基準線，錯誤率穩定，被節流的請求數為 1,247（絕對數字很小）。這個行動此刻進入了自動逆轉窗口，除非情況再次惡化，節流將在再過 7 分鐘後解除。稽核軌跡記錄了每一步。團隊「迴圈之上監看」的工程師，在 t=15 秒事故被偵測到時收到通知，在 t=30 秒自主行動被核准時再次收到通知，並會在事故關閉時收到事故後摘要。他們不需要採取任何行動，他們看著這套架構完成自己的工作，SLO 時間軸則證實這份工作是穩健的。

一個更糟的情況同樣值得追蹤。假設在 t=120 秒時，監視器回報節流並沒有產出預期的復原，p99 沒有移動。這套架構會自動做幾件事：節流被保留下來（它沒有讓情況變得更糟，移除它可能會）；推理平面被告知自己的領先假設可能是錯的，它用新的證據重新為候選方案集排序；依賴飽和假設的信心下降，因為原本應該有幫助的行動沒有奏效；inventory-api 變更假設的信心則溫和上升。治理平面此刻進入了一個不同的政策體制：由於領先假設的信心低於自主門檻，下一個行動需要人類核准。待命工程師被呼叫，附帶完整情境：試過了什麼、發生了什麼、代理現在相信什麼、有哪些替代候選方案。代理不會自己升級自己的權限，它把不確定性升級給人類，附帶完整的推理軌跡。這正是有邊界的自主性在實務上的樣子：代理知道何時該停下來。

5.7　事故應變中的人在迴圈中

第 4.7 節命名了人在迴圈中的三種模式：迴圈之上、迴圈之中、迴圈之上監看。本節把這個框架具體套用到事故應變上。三種模式的實質內容不會改變，改變的是營運節奏——因為事故把這三種模式的節奏，都壓縮到了幾分鐘之內。

事故應變裡的「迴圈之上」，是事故開始之前發生的工作：團隊的意圖宣告（這項服務的穩定狀態是什麼）、他們撰寫的政策（哪些行動在哪些條件下是自主的）、他們編目的行動契約（代理被允許做什麼）、他們設定的 SLO 門檻。這些都不是在事故期間發生的，卻全都在事故期間運作著。迴圈之上的人類對這起事故的貢獻，是他們幾週或幾個月前所做的工作，而這份貢獻的品質，決定了這套架構究竟能否自主處理這起事故。一支在迴圈之上工作投資不足的團隊，會在事故期間發現這一點——當政策原來缺少了這起事故所代表的情況、代理因為沒有任何政策允許它原本會採取的行動而升級時。

事故應變裡的「迴圈之中」，是治理平面把一個提案路由給人類時發生的事。標準情況：一個信心跌破政策自主門檻的候選行動，或一個依設計就需要人類核准的授權層級（第 5.5 節的回滾案例）。迴圈之中的人類，不是冷啟動接到呼叫，他們收到的是一個附帶完整情境的候選行動：領先假設、替代方案、證據、建議的行動、這個決策被路由給他們的政策理由。他們的決策很快（幾秒到一分鐘），因為組裝工作早已完成。他們核准、修改，或駁回。執行平面運行他們核准的內容，這套架構繼續運作。人類在這裡的價值，是把判斷力套用到一個已經準備妥當的問題上，而不是從原始證據中組裝這個問題——正是這一點，讓迴圈之中的參與變得高價值，而不是在凌晨三點耗損人心。

事故應變裡的「迴圈之上監看」，是工程師觀察這套架構自主處理事故、準備好在事情看起來不對勁時介入、但不被要求核准任何事。他們即時看見稽核軌跡的累積，看見 SLO 指標（第 3.6 節的五大旗艦）的趨勢。如果他們想，可以直接質詢情境覺知物件；他們也可以什麼都不做，這套架構會從偵測到學習，全程處理這起事故，不需要他們的輸入。這是 L3 及以上成熟度的主導模式——大多數事故不需要一個迴圈之中的人類，迴圈之上監看的人類就足夠了。

標準情境在三個不同成熟度等級下，展示了這種轉變。在 L2（輔助式），每一個被提議的行動都路由給人類——代理完成組裝工作（情境覺知、時間軸、爆炸半徑、候選方案集），但執行需要明確的人類核准，待命工程師持續處於迴圈之中。在 L3（有邊界），低風險行動依政策自主執行，高風險行動依然路由——待命工程師間歇性地處於迴圈之中，取決於這起事故的需要。在 L4（適應式），大多數行動自主執行，人類處於迴圈之上監看，觀察、很少介入。同一起事故，在每個等級都有不同的「人類簽章」，第 5.10 節會把這個比較具體化。

跨越這些等級不變的，是當責。擁有這項服務的團隊，擁有這個結果，無論是不是有一個迴圈之中的人類按下了核准鍵。這套架構移動的是執行權，不是責任。L4 的待命工程師，並不因為他們沒有打出一條指令，就對系統所做的事情負較少的責任——他們負責任，是因為他們（或他們的團隊）撰寫了允許代理行動的政策。第 3.7 節的當責邊界，正是讓這個區別保持穩固的架構產物。第 4.7 節命名了這三種模式，本節，只是展示它們在事故壓力下長什麼樣子。

5.8　事後學習與回饋迴圈

事故結束了，節流逆轉了，延遲穩定了。在傳統維運裡，這正是操作手冊結束的地方：寫一份事後檢討，指派行動項目，排定一場審查會議，然後往前走。學習代理在本節首次完整登場，因為這套架構對「事故之後發生什麼」的看法，根本上不同。學習不是一份被寫出來的文件，而是系統對自身模型的一次結構化更新，由處理這起事故的同一個迴圈驅動，自動被擷取，透過受治理的路徑被套用。DRAL 的「學習」這一拍，在此閉合。

學習代理，是推理平面裡擁有這個迴圈的角色，它的工作很狹窄卻很重要：把每一起事故，轉化為系統模型上可量測的更新，以一種這套架構其餘部分能夠安全吸收的方式。具體來說，學習代理更新四類產物。相似性資料庫（「看起來像這一起的事故」的案例庫），會收到一筆新條目，附帶領先假設、採取的行動，以及結果。信心校準模型，依照「宣稱的信心是否真的符合觀測到的成功率」進行更新。政策參數，在資料顯示目前的門檻太緊或太鬆時，收到建議調整（不是變更，是建議）。行動有效性評分，依照這個行動是否達成宣告的成功標準，為每一份行動契約更新。第 3.6 節的校準誤差 SLO，是告訴團隊「學習代理的更新是否真的在改善這套系統」的金絲雀指標——如果 CE 在一次學習更新之後上升，代表這次更新腐化了校準，應該被回滾。

「封閉學習迴圈」（Closed Learning Loop，CLL），是本節正式介紹的架構模式，本書後續章節會持續引用它。這套模式有五個階段：擷取系統在事故期間相信什麼（情境覺知、領先假設、候選方案集、被選中的行動、預測結果）；觀察實際發生了什麼（達成的結果、附帶效應、復原時間、觸發的次要事故）；比較預期與結果（預測在哪裡符合、在哪裡分歧、這個分歧對底層模型意味著什麼）；根據這個比較，提議對系統模型、參數與政策的更新；透過受治理的路徑套用這些更新，低風險更新自動套用，高風險更新需要人類審查。每個階段都自動運行，人類在這個迴圈裡的角色，是審查被提議的更新，而不是產出它們。

把這件事具體化，學習代理針對標準情境的更新負載，可能會包含這樣的內容：

incident_learning:
  incident_id: INC-2026-05-13-CHECKOUT-LATENCY
  leading_hypothesis: dependency_saturation:payment-gateway
  chosen_action: throttle_non_critical_paths
  predicted_outcome:
    latency_p99_recovery: 4-6min
    effectiveness: 0.87
  observed_outcome:
    latency_p99_recovery: 3min_20sec
    effectiveness: 0.92
    side_effects: none
  learning_signals:
    - signal: effectiveness_underestimated_for_dependency_saturation
      delta: +0.05
      applies_to: throttle_non_critical_paths action contract
      proposed_update: action_effectiveness_rating +5%
      risk: low
      path: auto_apply_with_review
    - signal: calibration_within_band
      delta: 0.02
      applies_to: dependency_saturation hypothesis class
      proposed_update: none required
      path: log_only
    - signal: payment_gateway_deploy_correlation_strengthened
      delta: +0.08
      applies_to: causal_likelihood scoring for this pattern
      proposed_update: weight_increase_for_payment_gateway_recent_deploys
      risk: medium
      path: human_review_required
  similarity_store_entry:
    hash: <content_addressed>
    retrieval_keys:
      - signal_pattern: latency_p99_drift_with_upstream_degradation
      - service_tier: tier_1
      - upstream_service: payment-gateway
      - resolution_strategy: throttle_non_critical_paths

第一個學習訊號（有效性被低估了）是低風險的，附帶審查自動套用：這份契約的行動有效性評分會溫和上升，代理下次會以稍高的信心採用這個行動。第二個是空操作（校準在正常範圍內，不需要更新，這個訊號被記錄下來供趨勢監控之用）。第三個是中風險的：提高 payment-gateway 近期部署的因果可能性權重，會改變代理在未來類似事故裡如何為候選原因排序，這是對推理的一次結構性改變，「迴圈之上監看」的人類會在套用之前審查它。學習代理不會繞過這道關卡，它連同證據一起呈現這份提案，人類核准或駁回。稽核軌跡同時記錄提案與決定。

另一項值得點名的特質，是學習在這批反覆出現的代理陣容之間是可加總的。觀測代理，依照這起事故期間缺失或有雜訊的東西，更新自己的訊號契約；拓撲代理，依照這起事故期間變得可見的關係，更新依賴圖；發布代理，為重要的那類變更，更新自己的因果可能性評分；商業影響代理，依照自己預測的影響與觀測到的商業效應吻合得多好，更新自己的翻譯模型。學習代理協調這些更新，確保沒有任何一個代理的更新，腐化了另一個代理的校準，並確保系統的模型在各個代理之間保持一致。正是這一點，讓這套架構能運作在 L5（系統性）——在那裡，跨代理的協調式學習，正是產出複利曲線的關鍵。在 L3 或 L4，學習代理以更簡單的模式運作：它擁有推理平面的學習產物，並為其他代理的擁有者呈現提案，供他們透過自己的審查路徑套用。這套架構的行為在每個等級都是正確的，複利的速度隨成熟度而上升。

本節「沒有」主張事後檢討會消失，它們不會。事後檢討依然有價值，作為「發生了什麼」的人類可讀敘事，依然是跨團隊組織學習的主要產物。改變的是，事後檢討不再是學習唯一存在的地方——系統層級的學習，由學習代理以系統能據以行動的形式自動擷取；事後檢討，則以團隊能據以行動的形式擷取人類層級的學習。兩者互補，合在一起，它們產出的正是那種讓 ARE 值得工程投資的韌性曲線。

5.9　在代理式世界裡量測事故應變

第 3.6 節的五大旗艦 SLO，是代理式架構裡量測事故應變的方式。本節不介紹新的指標，而是展示這五項指標在一個真實事故時間軸裡長什麼樣子，這正是讓它們變得可操作、而不只是抽象的關鍵。本節裡的數字是示意性的，一支團隊實際會使用的運作區間，會因服務層級與成熟度等級而異。

「自主解決率」（ARR），是這套架構在不升級給人類的情況下端到端解決的偵測到事故所佔的滾動百分比。對事故應變而言，ARR 會依嚴重度與服務層級分段。一支在第一級服務上處於 L3 成熟度的團隊，可能在第一級服務上跑 ARR 35%（那些正當地需要人在迴圈中參與的高風險案例），在第二級服務上跑 ARR 70%（大多數能自主處理），在第三級服務上跑 ARR 90% 以上（這套架構在任何人注意到之前，就攔截並處理了的例行惡化）。標準情境，在 t=215 秒時以節流保持、復原確認結束，算作一次自主解決。團隊過去 30 天的第一級 ARR，正是像這樣的決策的滾動彙總。

「決策品質 SLO」（DQ-SLO），量測代理選擇的行動是否正確。一個決策若在宣告的視窗內恢復穩定狀態、沒有違反復原限制、也沒有觸發後續事故，就算成功。在標準情境裡，被選中的行動（節流）在預測視窗內恢復了 p99，沒有附帶效應：一次成功的決策。推理平面的領先假設（依賴飽和）是正確的：一次成功的診斷。兩者都貢獻到 DQ-SLO 的分子上。如果節流沒有奏效、而團隊最終核准的回滾引入了次要惡化，這兩次決策都會算在 DQ-SLO 的反面。一支在第一級服務上處於 L3 成熟度的團隊，應該把 DQ-SLO 維持在 80% 以上，才能正當化這個層級的自主性；低於這個區間，政策應該收緊，直到 DQ-SLO 恢復。

「推理延遲 SLO」（RL-SLO），量測這套架構從初始訊號到提交一個符合政策的行動，需要花多長時間。標準情境：偵測在 t=15 秒，候選行動在 t=30 秒排序完成，行動在 t=31 秒提交。這起事故的 RL-SLO：16 秒。團隊在 L3 成熟度下對第一級事故的 p95 RL-SLO 目標，可能是 45 秒；p99 可能是 90 秒。具體數字因領域而異，重要的是團隊已經宣告了這個區間，並依此運作。過長的推理延遲，通常能追溯到三個原因之一：推理平面裡低效的調查路徑、情境組裝期間過多的工具呼叫，或是需要與治理平面來回溝通的不清楚政策。這些每一個都可以修正，而 RL-SLO 正是揭露哪一個是主導因素的指標。

「行動有效性 SLO」（AE-SLO），量測這些行動是否真正達成了預期結果、且沒有附帶損害。標準情境裡的節流，達成了宣告的成功標準，沒有突破成本或爆炸半徑限制，也沒有觸發次要事故：計入 AE-SLO 的分子。一次恢復了 p99 延遲、卻讓團隊的每月雲端帳單翻三倍（因為它在其他地方觸發了一連串意外的重試連鎖反應）的節流，即使眼前的結果看起來不錯，也會讓 AE-SLO 失敗。AE-SLO 正是讓代理式復原的成本，以和可用性同樣清晰的方式，呈現在業務面前的指標。

「校準誤差」（CE），量測代理宣稱的信心，與它實際成功率之間的落差。如果推理平面持續回報 0.85 的信心、卻只有 60% 的決策成功，CE 會上升，團隊應該收緊自主門檻；如果 0.85 信心的決策實際上有 87% 成功，這份校準就是穩健的。學習代理在四個代理之間協調信心校準（第 5.8 節），正是讓 CE 維持在低點的關鍵。一支持續盯著 CE 的團隊，能在漂移出現在使用者可見指標的好幾個月前，就抓到它。對事故應變而言，CE 特別是標記「代理不斷擴大的自主性，是被改善的推理品質正當化的，還是靠門檻膨脹掙來的」的 SLO。前者是健康的，後者，正是第 4.9 節的 L2 → L3 信任天花板失效模式。

scenario: payment-gateway dependency saturation, checkout latency
detection_time: t=15s
resolution_time: t=215s (3m 20s)
per-incident measurements:
  ARR contribution: +1 (this incident resolved autonomously)
  DQ-SLO contribution: +1 (action succeeded, no secondary incident)
  RL-SLO: 16 seconds (signal to commit)
  AE-SLO contribution: +1 (success criteria met, no side effects)
  CE contribution:
    stated_confidence_at_decision: 0.82 (dependency saturation hypothesis)
    observed_outcome: success
    contributes_to_0.80-0.85_confidence_bin
rolling_30_day_SLOs_for_tier_1_services_at_L3_maturity:
  ARR: 36%        (target: 20-40%)
  DQ-SLO: 84%      (target: >=80%)
  RL-SLO_p95: 38s  (target: <=45s)
  AE-SLO: 87%      (target: >=80%)
  CE: 14%          (target: <=25%)

讓五大旗艦變得有用的架構特質，是它們由這套架構其餘部分運行所在的同一個訊號平面發出，不是一套獨立的量測系統。每一起事故的稽核軌跡，早已包含計算它們所需要的一切：候選行動集、被選中的行動、政策決定、結果觀察、領先假設及其信心。沒有一個獨立的回報步驟，這些指標，是這套架構的一個後果，而不是額外加上去的東西。

這也正是為什麼五大旗艦適用於第二部的每一個工作流程，而不只是事故應變。第六章會用它們量測交付品質；第七章會用它們量測混沌工程的學習速度；第八章會用它們量測事前工作對生產事故率的效果。同一套五項 SLO，同一套架構，不同的工作流程——正是這一點，讓代理式運作模型在整個可靠性工作的範疇裡保持連貫，而這正是第四部要展開的內容。

5.10　同一起事故，五個成熟度等級

同一起事故，在全部五個成熟度等級上演一次。失效沒有改變，觸發條件沒有改變，爆炸半徑完全相同。唯一的變數，是這套架構能做什麼，以及團隊必須做什麼，來補償架構做不到的事。這是本章的重頭戲，也是本書裡展示代理式可靠性究竟買到了什麼、最乾淨的示範。

事故：在一個星期二格林威治標準時間 14:23，歐洲西部的 payment-gateway 服務，因為一次 23 分鐘前上線的部署，進入了降級狀態。依賴它的 checkout-api 上的延遲開始向上漂移。這個訊號軌跡在全部五個等級裡都相同，不同的是 t=0 與解決之間發生了什麼。

L1：反應式。團隊依靠儀表板、警報與操作手冊運作。在 t=2 分鐘時，checkout-api 上的錯誤率門檻終於被突破，呼叫系統觸發。待命工程師打開五個分頁：指標儀表板、追蹤瀏覽器、部署日誌、待命群組的 Slack 頻道，以及 wiki 上的拓撲圖（上次更新是四個月前）。他們開始手動組裝情境。在 t=12 分鐘時，他們辨識出 payment-gateway 在 35 分鐘前部署過，但還不知道這是相關性還是因果。在 t=18 分鐘時，他們在 Slack 上聯絡 payment-gateway 團隊，那個團隊正在睡覺（歐洲西部的晚上，但那個團隊在美國太平洋時區）。在 t=24 分鐘時，他們決定手動節流 checkout-api 上的非關鍵路徑，花了三分鐘找到正確的操作手冊指令。在 t=27 分鐘時，節流被套用。在 t=32 分鐘時，延遲開始復原。在 t=38 分鐘時，事故關閉。總時長：38 分鐘。人類花在組裝情境上的時間：22 分鐘。查閱的儀表板數量：8 個。人類在壓力下做出的決策數量：大約 14 個。事後學習：會寫一份事後檢討，指派一個行動項目，更新一份 wiki 頁面。

L2：輔助式。同一起事故。在 t=0:15 時，觀測代理發送一個附帶完整情境的結構化延遲訊號，拓撲代理附上依賴圖，發布代理附上近期變更事件，情境覺知物件在 t=0:18 落地。推理平面產生三個候選行動，排序，附上信心分數。在 t=0:30 時，代理的建議送達待命工程師的呼叫器：「建議在 checkout-api 上執行 throttle_non_critical_paths。領先假設：payment-gateway 上的依賴飽和。信心 0.82。預測復原時間 4-6 分鐘。附上兩個替代方案。」工程師審查這份建議，組裝工作已經完成，他們不需要盯著五個儀表板。他們在 t=1:10 核准。這個行動運行，延遲在 t=5 分鐘時復原，事故在 t=8 分鐘時關閉。總時長：8 分鐘。人類花在組裝情境上的時間：零。人類花在做決策上的時間：40 秒。這類建議的建議採納率：87%（代理的建議一貫穩健，這正是 L2 在 L3 變得安全之前必須展現的能力）。

L3：有邊界。同一起事故。情境覺知物件在 t=0:18 落地，與 L2 相同；推理平面產生候選方案集，與 L2 相同。在 t=0:30 時，治理平面依照政策評估領先候選方案。信心 0.82 超過了這個服務層級在依賴降級條件下 0.80 的自主執行門檻，這個行動在沒有人類核准的情況下運行。待命工程師在 t=0:31 收到通知（「自主行動已執行：throttle_non_critical_paths；附上推理」），並從稽核軌跡介面觀察復原過程。他們不採取任何行動，這套架構處理這起事故。延遲在 t=4 分鐘時復原，事故在 t=5 分鐘時關閉。總時長：5 分鐘。待命工程師處於「迴圈之上監看」，而不是「迴圈之中」。ARR 貢獻：+1。信任天花板已經被跨越：這套架構此刻是代理作為執行者，不是代理作為顧問，而團隊擁有治理平面、行動契約，以及校準過的信心，讓這一切變得安全。

L4：適應式。同一起事故。L3 的一切都具備，加上這套架構已經運作足夠久，讓學習代理對這類失效的校準變得更銳利。推理平面的假設信心是 0.89（比 L3 更高，因為過去這個特徵的事故已經精煉了這個模型）。治理平面的政策本身，被目前的 SLO 狀態參數化：因為 CE 跑在 11%（遠低於 25% 的門檻），自主執行區間已經放寬，第一級依賴飽和行動，現在在信心 0.75（而不是 0.80）時就能被採取。這個行動在 t=0:27 運行，延遲在 t=3 分鐘時復原，事故在 t=4 分鐘時關閉。總時長：4 分鐘。這套架構此刻正在自己觀測到的校準範圍內、在團隊政策宣告的邊界之內，調整自己的門檻。待命工程師在這起事故期間的參與：零。他們的迴圈之上工作是可觀的——上一季他們花了三個下午精煉政策與行動契約，這份投資，此刻在這裡得到回報。

L5：系統性。同一起事故，只是在 L5，這起事故往往不會以同樣的規模發生。拓撲代理在變更當天早上，觀察 payment-gateway 的部署前訊號時，標記出這次部署帶有比平常更高的風險輪廓（其中一個變更的元件，過去曾有對延遲敏感的互動歷史）。發布代理把這個標記附掛到這次部署事件上。治理平面對「風險輪廓升高的第一級依賴部署」的政策，要求更小的初始金絲雀群組。這次部署，在最初 30 分鐘裡被金絲雀部署到 payment-gateway 容量的 5%，才繼續推進。延遲惡化在金絲雀階段就浮現，只影響不到 1% 的結帳流量，而不是 12%。代理把金絲雀的流量節流到它的父服務，在第 1 分鐘就記入一次自主解決的 ARR 額度，發布代理把金絲雀回滾到先前已知良好的版本。總客戶可見影響：不到 60 秒，影響不到 1% 的使用者。這個代理生態系學到了：學習代理更新了發布代理對這類部署的金絲雀規模模型。這套架構，在自己未來的失效模式演變成實質問題之前，就先抓住了它。這正是 L5 真正買到的東西：不是更快的回應，而是在具實質規模之前就更少發生的事故，因為這套架構越來越能夠預見。

這裡的結構性模式是：從 L1 到 L2 的收益，大多來自「消除組裝工作」；從 L2 到 L3 的收益，是跨越信任天花板；從 L3 到 L4 的收益，是適應性校準；從 L4 到 L5 的收益，是預見與生態系協調。每一次轉換，都有自己典型的工作，每一次轉換，大約需要一季專注的工程投資才能達成。

這個比較的重點，不是「L5 是每支團隊的目標」。大多數團隊在接下來三年裡，應該運作在 L2 到 L3 之間的某個區間，而第一級服務停在 L3，是一個合理的穩定狀態。重點是，每個等級都是可以到達的，每次轉換都是清晰可辨的，每個等級的價值都是可量測的。一支不知道自己身在哪個等級、也不知道自己能安全地移動到哪個等級的團隊，要嘛會在沒有基質能吸收它的情況下過度投資代理式基礎架構，要嘛會投資不足，繼續支付這套架構原本能夠處理的事故應變人力成本。第 5.9 節的五大旗艦 SLO，是團隊定位自己的方式；第 4.9 節的成熟度模型，是告訴他們每個等級長什麼樣子的依據。本章從頭到尾，正是「L3 事故應變在生產環境裡實際感覺起來是什麼樣子」的實作圖像。

從這個比較中，還值得提出第二項觀察，關於這些收益「來自哪裡」。從 L1 到 L2 的收益（38 分鐘到 8 分鐘），幾乎完全是消除情境組裝——同一個人類做著同一個決策，只是他們是在一個代理已經準備好的工作基礎上做，而不是從原始證據做起。從 L2 到 L3 的收益（8 分鐘到 5 分鐘），是消除人類對政策早已核准的行動的核准步驟；這裡所吸收的結構性風險，正是信任天花板所代表的東西。從 L3 到 L4 的收益（5 分鐘到 4 分鐘），是適應性校準——這套架構自己的門檻，隨著它觀測到的表現收緊或放寬，政策反映的是系統掙得的東西，而不是原本被配置的東西。從 L4 到 L5 的收益（4 分鐘到不到一分鐘），是預見——這套架構在完整的爆炸半徑成形之前，就在金絲雀階段抓住了失效。每一次轉換，都有自己典型的工程工作，而且每一次轉換的工作都不一樣。試圖跳過某次轉換典型工作的團隊，會在下一次事故時，準確地發現自己沒有投資的那項工程基質是什麼。

第三項觀察，是這張表格隱藏了一項每個等級都仰賴的紀律：團隊在自己「迴圈之上」工作上的投資。在 L1，團隊的迴圈之上工作，大多是操作手冊與儀表板，由待命工程師在事故期間消費。在 L2，迴圈之上的工作開始包含代理將會讀取的訊號發送紀律，以及拓撲圖的維護。在 L3 及以上，迴圈之上的工作，就是政策本身、行動契約、自主門檻、SLO 區間。花在代理式可靠性上的「人類時間」總量，不會隨成熟度上升而下降，它只是在生命週期裡移動到更早的位置。團隊在 L4 並沒有比在 L1 參與得更少，他們只是以不同的方式參與。迴圈之上的工作，正是讓事故期間「放手不管」的行為變得安全的關鍵，而這份工作的紀律，正是讓一支團隊的可靠性工作能夠擴展的關鍵。

5.11　從應變到設計

事故應變，是代理式可靠性證明自己的地方，而這份證明並不含蓄。同一起事故，由一支 L1 團隊處理、與由一套 L3 架構處理，在解決時間上相差七倍，在客戶可見影響上相差一個數量級，而團隊在事故進行期間必須做的事，也有著本質上的不同。這套架構不是魔法，它是刻意的工程投資的結果——投資在四個平面、行動契約、政策，以及代理式 SLO 上。這份投資會複利累積，正是這一點，讓它與自動化不同。自動化降低的是一項固定成本；代理式可靠性建構的，是一條隨著季度過去而向下彎曲的曲線，因為學習代理的模型變得更銳利、校準誤差維持在低點，而團隊對擴大自主性的信心，是掙來的，不是宣稱的。

本章「沒有」主張事故會消失，它們不會。第 5.10 節的 L5 圖像，不是零事故，而是更早被攔截、被圍堵得更小、由這套架構解決、而不是由凌晨三點筋疲力竭的人類解決的事故。團隊為此付出的代價，也不是零——它是事故發生之前必須完成的迴圈之上工作：政策設計、行動契約撰寫、SLO 區間調校、校準審查。總工程投入，與團隊已經花在可靠性上的投入相當；改變的是，這份投入在時間上落在哪裡、是哪種性質的工作。事故應變裡反應式的英雄主義萎縮，主動式的結構性工作成長，總量大致維持不變，但它的性質改變了，以一種讓團隊的工作生活實質變得更好的方式。

第六章是下一個工作流程。如果事故應變是這套架構在壓力下證明自己的地方，交付就是同一套架構在完全沒有壓力的情況下回報這份投資的地方。大多數可靠性失敗，不是始於事故期間，而是始於變更期間，而處理生產環境惡化的同一套四個平面，如果被接上同一套機制來評估變更，也能處理一次部署的惡化。發布代理將正式完整登場，「變更風險分數」（Change Risk Score，CRS）將正式介紹。本書最乾淨的一個實作公式，就在第 6.3 節，而它編碼的紀律，正是本章一直在展開的同一套紀律：結構化產物、校準過的信心、受治理的行動、被學習的結果。不同的工作流程，同一套架構，本書，正是複利累積的地方。