問題場景

高變更頻率服務最常見的失效是小幅回歸連續累積，單點故障反而少見。每次回歸都不夠大，不會立刻觸發全停；但連續幾週後，使用者體感持續惡化，團隊才發現可靠性債已經超標。

這種情境需要的是「連續消耗判讀」，不是單次事故判讀。error budget policy 就是把連續消耗變成可操作的放行規則。

決策機制

政策設計先做三個對齊，再做門檻定義。

有了這三個對齊後，release gate 可以從「主觀風險判斷」轉成「政策驅動」：

1. budget 健康：正常發版。
2. budget 快速消耗：啟用變更限速、提高驗證門檻。
3. budget 透支：凍結非必要變更，先修復與回補訊號。

可觀測訊號

政策有效與否要靠訊號判讀，不靠會議共識。

常見陷阱

把 error budget 當 KPI 會讓政策失真。這個機制的責任是「保護可靠性與交付節奏的平衡」，不是讓團隊追求某個固定分數。當 KPI 化開始主導行為，常見結果是 SLI 縮小、告警延後或例外條件過度擴張，最終反而降低判讀可信度。

下一步路由

要把這個案例落到制度層，先回到 6.6 定義政策欄位，再到 6.8 實作 gate。若你發現訊號不足，先補 4.16 與 4.20。

問題場景

很多團隊 postmortem 寫得完整，但事故仍反覆發生。根因通常是 action item 沒有被制度化追蹤，分析能力本身不是瓶頸。當改進工作和日常 feature 競爭同一批資源時，沒有 closure 機制的 action item 很容易被延後到失效。

治理機制

可靠的 closure 機制要先把 action item 分級，再對應不同完成標準。

分級之後要做三件事：

1. 為每個 action item 指派單一 owner。
2. 寫出可驗證完成條件（不是「優化」「強化」這類抽象字）。
3. 把 closure 狀態納入固定 review cadence。

可觀測訊號

常見陷阱

最常見陷阱是把 action item 當作「會後待辦」而不是 release policy 的一部分。這會讓高風險改進沒有實際約束力。正確做法是把 P0/P1 項目直接綁到 release gate，未完成時不得放行關聯變更。

下一步路由

先在 8.19 Incident Decision Log 保留 action item 的決策脈絡，再到 8.22 Incident Evidence Write-back 回寫觀測與驗證項目。若要把 closure 變成制度，回到 6.21 Reliability Debt Backlog 進行排序治理。

引用源

• Google SRE Book
• Google SRE Workbook

問題場景

許多團隊的可靠性工作會被 incident handling 與手動修復吃掉。短期看似把事情解決，長期會造成兩個後果：一是 on-call 壓力升高，二是系統問題持續累積。沒有 toil budget 時，團隊很難判斷何時該停止加功能、先補工程基礎。

決策機制

Toil budget 是把工時結果接到 release 與 backlog 決策的機制，單純統計工時只完成一半。

可觀測訊號

常見陷阱

最常見錯誤是把 toil 視為「正常運維工作」，結果讓超標狀態常態化。另一個錯誤是只記錄工時，不把結果接到 release gate 與優先序調整。這兩種做法都會讓可靠性債繼續滾大。

下一步路由

把 toil budget 落地時，先在 6.21 Reliability Debt Backlog 建立分類與排序，再把超標條件接到 6.8 Release Gate。事後改善要回寫 8.22 Incident Evidence Write-back。

引用源

• Google SRE Book
• Google SRE Workbook