概念定位

SLO 與 error budget 是把可靠性從口號變成政策的工具。SLO 定義的是服務要對哪個使用者旅程負責，error budget 定義的是這個責任在一段時間內可以承受多少退化。當這兩個條件被寫清楚，可靠性就能從「感覺上應該穩」變成「超過哪個門檻就要暫停、降風險或修復」。

這個節點先處理目標，再處理門檻。先問服務要守住什麼體驗，再問這個體驗要用哪些訊號衡量，最後才決定 burn rate 到多少時要 freeze。這樣寫的好處是，讀者會先理解政策責任，再理解數字本身。

大綱

• SLI 選型：user-journey-centric vs system-metric
• SLO 目標訂定：可達性、商業意義、頻率窗
• error budget：burn rate、policy、freeze 條件
• 跟 04 觀測 的訊號交接
• 跟 6.8 release gate 的凍結觸發
• 跟 8.1 事故分級 的門檻對齊
• 反模式：cargo-cult 99.99%、SLO 無人擁有、burn rate 無 alert

核心判讀

SLO 的責任是讓團隊知道自己到底在保護什麼。當讀者看到一個 SLO 時，第一個問題是這個數字是否對應使用者行為、商業風險與回復成本；數字高低要放在這個脈絡中判讀。

error budget 的責任是把風險傳導成決策。當 burn rate 開始上升時，團隊先確認 budget 還剩多少、目前的變更是否會放大風險、freeze 條件是否已經被觸發。這裡的重點是路由清楚，數字只是路由的輸入。

SLI 選型

SLI 選型的責任是把使用者旅程轉成可量測訊號。好的 SLI 先描述使用者能否完成重要任務，再選擇最能代表該任務的 log、metric、trace 或 client-side signal。

Availability 適合描述同步 API 與 user-facing request。它需要清楚定義分母與分子，例如只計算有效請求、排除客戶端取消，或把 timeout、5xx 與 business failure 分開。

Latency 適合描述體驗壓力。平均值容易掩蓋長尾，可靠性政策通常需要 percentile 或 histogram，並且要對應使用者旅程，再用單一 process 的 handler time 作為診斷輔助。

Freshness 適合描述資料管線、search index、cache projection 與 read model。這類服務即使 API 回應成功，資料過舊仍會破壞使用者體驗。

Correctness 適合描述金流、帳務、庫存、資料同步與 migration。這類可靠性目標需要資料校驗與 reconciliation，而不只看 request 成功率。

Durability 適合描述 queue、event log、object storage 與資料寫入。它關心寫入後能否找回、重播、備份與回復，常和 RPO / RTO 一起定義。

SLO 政策

SLO 政策的責任是把可靠性目標轉成團隊行為。數字本身只是門檻，政策要說明目標的 owner、時間窗、例外條件、檢視頻率與觸發後動作。

User journey 是 SLO 的錨點。checkout、login、message delivery、search freshness、invoice generation 都比 CPU 或 memory 更適合承載可靠性承諾，因為它們能直接對應使用者結果。

SLI formula 需要可重算。分母包含哪些 request、分子如何判定成功、資料來源來自 server-side 還是 client-side、sampling 有哪些限制，都需要寫進政策。

Objective 需要結合商業風險與回復成本。99.9% 與 99.99% 的差異不只是小數點，而是代表可接受 downtime、工程投資、成本與變更節奏的差異。

Freeze action 讓 error budget 進入工程決策。當 budget 消耗過快時，團隊需要知道哪些變更暫停、哪些修復可繼續、哪些例外需要 owner 核准。

Error Budget 與 Burn Rate

Error budget 的責任是把可靠性退化轉成可管理的風險餘額。它讓團隊在「追求穩定」與「持續變更」之間有共同語言。

Burn rate 要看短窗與長窗。短窗能捕捉快速事故，長窗能避免一次性尖峰造成過度反應；兩者一起使用，才適合觸發 page、ticket 或 release freeze。

Budget warning 適合做風險整理。團隊可以檢查近期 deploy、feature flag、migration、capacity、dependency 與 incident review action item，判斷是否需要降低變更速度。

Budget critical 適合觸發 release gate。此時可靠性風險已經從觀測層進入決策層，團隊需要把發布、rollback、capacity 與 incident readiness 放在同一張表中判讀。

Budget exhausted 適合觸發可靠性改善。改善內容可能是修 bug、補 capacity、降低 alert noise、補 runbook、重設 SLO 或清理 reliability debt。

判讀訊號

• SLO 數字無 owner、過半年沒檢視
• burn rate 無 alert、只有 monthly review
• error budget 耗盡但 deployment 節奏不變
• SLI 用 system metric（CPU / memory）、不對應 user journey
• 目標數字是抄來的（99.9 / 99.99）、無商業 anchor

案例對照

Google 提供的是制度原點，因為它把 SLO、post-incident review 與 toil budget 串成可管理的可靠性文化。Honeycomb 提供的是訊號層的延伸，因為 high-cardinality 與 burn rate alert 讓 SLO 可以在真實流量下被看見。Stripe 則把 SLO 風格的決策壓到交易語義上，讓 idempotency 與 migration 不會因為重試而失真。

當讀者把這三個案例放在一起，就會看見 SLO 不只是「填一個百分比」，而是把不同層級的風險接到同一條路由：制度、訊號與交易正確性。這也是本節章節要建立的核心能力。

Error Budget 三對齊跟 Release Gating

Error budget 三對齊是把「SLI 範圍」「SLO 目標」「Budget gate 觸發點」分別跟「使用者價值 / 可接受承諾 / 交付節奏」綁定的設計練習。任一條未對齊、policy 就會跟團隊行為脫鉤 — SLI 不對齊使用者價值、policy 就保護錯的東西；SLO 不對齊承諾、團隊就追錯目標；Gate 不對齊交付節奏、政策就無人遵循。

對應 G1 Google Error Budget Policy：揭露 SLO policy 設計的三個對齊 — 使用者行為對齊（哪些 journey 直接反映服務價值 → SLI 範圍）、可靠性承諾對齊（什麼水準算服務仍可接受 → SLO 目標）、交付節奏對齊（可靠性消耗到哪裡要改變發布策略 → Budget gate）。

三對齊完成後、release gate 可從「主觀風險判斷」轉成「政策驅動」：

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

把 budget gate 跟 6.8 release-gate 變更分層段 綁定、讓「budget 三階段」對應「release gate 三層放行決策」。

Error budget 是「可靠性 vs 交付節奏」的平衡工具、不是被追求的固定分數。當 budget 被 KPI 化、SLI 範圍會被縮小、告警會被延後、例外條件會被擴張 — 三者都降低 budget 的判讀可信度。

Burn Rate 雙窗監控

Burn rate 雙窗監控是把「budget 消耗速率」拆成短窗（急性事故）跟長窗（慢性退化）兩個 channel、各自觸發不同回應的設計。比固定閾值告警更接近使用者體感、且能區分「需立即頁」跟「需排修復節奏」。

對應 HC1 Honeycomb Burn Rate 驅動可靠性操作：揭露 fast burn / slow burn 雙窗監控的價值 — 固定閾值告警在高變化流量下容易失真、burn rate 提供比固定閾值更接近使用者體感的判讀方式。

雙窗監控的設計：

• Fast burn（短窗、高消耗率）：捕捉急性事故、觸發 page 立即響應
• Slow burn（長窗、低消耗率持續累積）：捕捉慢性退化、觸發 ticket 排入修復節奏

兩窗一起用、避免單一閾值在不同流量型態下失真。Honeycomb 自家平台展示 burn rate 訊號可以跟 trace outlier path 對接 — 看到 burn rate 上升、能直接跳到具體退化 trace（這是 Honeycomb 的產品特色、tracing-first 對 burn rate 的補強）。vendor-neutral 的同類概念見 4.3 tracing-context 跟 4.6 sli-slo-signal 的訊號設計。

控制面

SLO 與 error budget 的控制面是把可靠性訊號接到發布、事故與改善流程。SLO 只有在能改變團隊行為時，才會成為政策。

1. SLI 設計回到 4.6 SLI 量測與 SLO 訊號設計。
2. 資料品質限制回到 4.17 Telemetry Data Quality。
3. Budget warning 進入 release risk review。
4. Budget critical 進入 6.8 Release Gate。
5. 事故觸發與復盤回寫進入 8.1 事故分級 與 8.5 復盤。

SLO policy 需要定期校準。服務規模、使用者旅程、依賴型態與商業風險變化後，原本的 SLI、objective 與 freeze 條件也要重新檢視。

SLO policy 也需要例外流程。重大資安修補、合規變更、資料修復或客戶承諾可能需要在 budget 緊張時繼續推進；例外應記錄 owner、理由、風險與回退條件。

產業情境：金融科技

金融服務的 error budget 治理需要把合規週期納入凍結條件。交易關鍵路徑（payment / settlement / reconciliation）的 SLO 破壞可能直接觸發監管通報義務，budget 消耗到門檻時的升級路徑必須包含合規人員。

交易路徑的 SLI 選型需要涵蓋 correctness（reconciliation error rate），availability 和 latency 通過但對帳失敗仍然是 SLO 破壞。correctness SLI 的量測來源通常是日終或即時的 reconciliation pipeline，跟 availability SLI 的即時 request-level 量測有不同的時間粒度。

Budget 凍結的觸發條件除了 burn rate，還要對齊監管報告週期。若 budget 在季末報告前已消耗過多，凍結應提前啟動，因為報告期間內的可靠性退化會被放大審視。這個提前量取決於報告週期長度與修復節奏 — 月報制的提前量比季報制短。

Error budget 政策的升級路徑需要跟 compliance team 對齊。budget warning 階段通知工程 owner；budget critical 階段同時通知合規人員；budget exhausted 階段啟動合規審查流程。這個分層讓合規介入的時機跟工程介入同步，避免事後才發現可靠性退化已觸發通報義務。

金融場景的 budget 恢復比一般 SaaS 慢。恢復期間需要額外的 reconciliation 驗證（確認退化期間無交易錯漏）才能宣告 budget 回補。若 reconciliation 發現差異，budget 恢復會被延後直到差異被解決。這個約束讓金融服務的 freeze 持續時間通常比一般服務長。

常見反模式

SLO 反模式通常來自把目標數字當成可靠性制度本身。數字需要對應旅程、資料、owner 與決策，才有工程意義。

Cargo-cult 99.99% 的問題在於缺少服務脈絡。高可用目標會增加架構、成本、演練與值班負擔；低可用目標則會增加使用者與商業風險。合理目標要從服務承諾回推。

System metric SLO 會讓可靠性偏向基礎設施視角。CPU 健康不代表 checkout 成功，pod running 不代表資料新鮮；系統指標適合支援 diagnosis，user journey 指標適合承載 SLO。

交接路由

• 04 訊號治理：SLI / burn rate metric 設計
• 06.8 release gate：error budget 耗盡觸發 freeze
• 06.9 capacity / cost：容量不足傳導為 SLO 風險
• 06.14 dependency budget：依賴可靠性納入 SLO 算式
• 08 事故閉環：burn rate alert 啟動條件
• 08.13 repeated / toil：error budget 撥用 toil reduction
• 06.18 reliability metrics：SLO 跟 DORA / SPACE 的指標分層