SLI、SLO 與錯誤預算：把「還算穩定」變成可以拿來吵架的數字

SLI（Service Level Indicator）就是「衡量服務好壞的那個數字」。而它有一個特別好用的標準形式：

SLI = 好事件的數量 / 有效事件的數量 × 100%

看起來平淡，但這個形式解決了三個實務問題。

問題①：它避開了分位數的所有陷阱

sum(rate(http_request_duration_seconds_bucket{le="0.3"}[30d]))
  /
sum(rate(http_request_duration_seconds_count[30d]))

問題②：「有效事件」讓你能排除不該算的東西

分母不是「所有請求」，是「應該被算進來的請求」：

• 健康檢查、爬蟲、內部監控的流量——排除。
• 使用者輸入錯誤造成的 4xx——通常排除（那不是服務壞了，ch04 講過同樣的道理）。
• 但 429（被限流）與 401 大量出現時要納入——那是服務端的問題。

問題③：它能直接算出錯誤預算

因為 SLI 是一個比例，1 - SLO 就直接是「允許失敗的比例」——這是後面整章的基礎。

五類常見的 SLI

大部分服務用「可用性 + 延遲」兩個就夠了。而如果你的系統有快取或複本，新鮮度往往是使用者實際抱怨的那一個（ch07 會回到這件事）——「我剛改的資料不見了」就是新鮮度問題。

SLI 最常見的錯誤不是算錯，是選錯量測對象。

錯誤的方向：從「我有什麼指標」開始

❌ CPU 使用率 < 80% 的時間比例
❌ 5xx 錯誤率 < 0.1%
❌ 所有 pod 都健康的時間比例

這些全部是白箱指標，而 ch01 已經證明過它們的盲點：請求根本沒進來的時候，這些數字全都很漂亮（TLS 憑證那個案例）。

正確的方向：從使用者做的事情開始

不是所有端點都需要 SLO

不同旅程可以有不同的門檻

付款  → 99.95% 成功，99% 在 2 秒內      （壞了直接損失營收）
搜尋  → 99.9%  成功，95% 在 500ms 內   （慢一點使用者會忍）
報表  → 99%    成功，90% 在 10 秒內     （內部使用，可以重試）

把所有東西都訂成一樣高，等於沒有優先級。而 SLO 的價值有一半來自它強迫你講清楚「什麼比較重要」。

一個實用的檢驗

SLI 定好之後，回頭問一句：「上次那場事故，這個 SLI 有掉下來嗎？」

如果沒有，那它就選錯了——SLI 的唯一價值，是在使用者受影響時它要跟著動。拿過去半年的事故清單來對照，是驗證 SLI 最快的方法。

訂 SLO 時最直覺的想法是「越高越好」，而這個直覺會導致最糟的結果。

先看數字

為什麼 100% 是錯的

• 它在物理上不可能：你依賴的雲端、網路、DNS 都不是 100%。
• 它會扼殺所有變更：任何部署都有風險，目標是 100% 就意味著最安全的策略是永遠不要改任何東西。
• 更重要的是：使用者感覺不出來。使用者的網路本身就有 1~2% 的失敗率。把可用性從 99.9% 提升到 99.99%，使用者體驗上的差異可能是零，而成本是好幾倍。

那該訂多少？從「使用者何時開始不滿」推

依賴鏈：一個讓人清醒的算式

你的服務 依賴 資料庫(99.95%) + 快取(99.9%) + 支付閘道(99.9%)

理論上限 = 0.9995 × 0.999 × 0.999 ≈ 99.75%

所以在這個架構下訂 99.99% 是不可能達成的，除非你為每個依賴做降級或容錯（快取失效時能降級、支付失敗能重試——見 高可用防禦）。SLO 不只是一個目標，它同時是對架構的要求。

這是整章、也是整軌最重要的一節。錯誤預算把「可靠性」從一個模糊的價值觀，變成一個可以被分配、被花用、被爭論的資源。

錯誤預算 = 1 - SLO

SLO 99.9%，一個月 3,000 萬次請求
→ 預算 = 0.1% × 3,000 萬 = 30,000 次失敗

關鍵觀念：它是預算，所以它是拿來「花」的

而真正的重點是：用完了會發生什麼

一份沒有後果的 SLO 是裝飾品。所以必須事先寫下 error budget policy——而且要有人簽字：

預算剩餘 > 50%    → 正常發版，可以做風險較高的實驗
預算剩餘 20~50%   → 正常發版，但高風險變更需要額外審查
預算剩餘 < 20%    → 只發修 bug 與穩定性相關的變更
預算用完           → 凍結功能發版，全隊投入可靠性工作，直到預算回補

連續兩個週期用完  → 重新檢視 SLO 是否訂得不合理，或架構是否需要投資

怎麼算剩多少

-- 30 天滾動視窗的預算消耗率
1 - (
  sum(rate(http_requests_total{status!~"5.."}[30d]))
  /
  sum(rate(http_requests_total[30d]))
) / (1 - 0.999)
-- 結果 0.85 → 已經燒掉 85% 的預算

滾動視窗 vs 日曆月

• 日曆月：好理解、與商業週期一致，但月初會「重置」——月底出大事的團隊只要撐過幾天就沒事了，這是一個壞誘因。
• 30 天滾動：更能反映「最近的健康狀況」，事故的影響會持續 30 天才淡出。實務上建議用這個。

錯誤預算的儀表板有一個問題：等你看到「預算用完了」，事情已經發生完了。burn rate 告警要解決的就是這個。

什麼是 burn rate

burn rate = 目前的錯誤率 / 允許的錯誤率

SLO 99.9%（允許 0.1% 失敗）
目前錯誤率 1%  →  burn rate = 10
→ 代表以這個速度，30 天的預算 3 天就會燒完

為什麼需要「多視窗、多燃燒率」

單一門檻永遠是錯的：門檻設高只抓得到災難、設低會被小抖動吵醒。解法是同時看快與慢兩種燒法，而且每一種都配一個長視窗與一個短視窗。

短視窗是做什麼的

-- 快速燃燒告警：長短視窗都要超標
(
  slo:error_ratio:rate1h > 14.4 * 0.001
  and
  slo:error_ratio:rate5m > 14.4 * 0.001
)

這樣做的好處

• 告警的數量與嚴重性掛鉤：小問題開工單、大問題才叫醒人。
• 告警的意義是統一的：不管是延遲變慢還是錯誤變多，訊息都是「你正在以 X 倍速度消耗使用者的耐心」——而不是「某台機器的 CPU 到 85% 了」。
• 它天然是徵狀告警（ch07 的主題）：它量的是使用者受到的影響，不是機器的狀態。

徵狀

某團隊在一年前導入 SLO，做得很認真：儀表板漂亮、burn rate 告警都設好了。一年後回頭看：

• SLO 儀表板有超過一半的時間是紅的。
• 錯誤預算每個月第一週就用完。
• 但發版節奏完全沒有變過——每週照發，沒有任何一次因為預算而暫停。
• 大家已經不看那張圖了。有人半開玩笑說：「反正它永遠是紅的。」

診斷

拆開來看，三件事同時錯了。

資料庫 99.95% × 支付閘道 99.9% × 簡訊供應商 99.5%
≈ 99.35%   ← 理論上限就已經低於目標

修法

教訓

SLO 與 SLA 的差別（不要搞混）

SLO 必須比 SLA 嚴格，這樣你會在賠錢之前就先被自己的機制攔下來。兩者訂成一樣是常見的錯誤——那等於沒有任何預警空間。

什麼時候不需要 SLO

• 內部工具、實驗性專案：維護 SLO 本身有成本，而它們壞了沒有人在乎。
• 還沒有基本監控的時候：SLO 建立在可靠的 SLI 資料上。順序是先有量測，再有目標。
• 沒有人願意為它做決策的時候：這是最重要的一條——如果組織不打算因為預算用完而改變任何行為，那就不要做 SLO，做好監控與告警就好。假的 SLO 比沒有 SLO 更糟。

四筆帳

• 建置與維護成本：SLI 的定義要隨著產品演進調整。過時的 SLO 比沒有更危險——它會用舊的標準給你虛假的安全感。
• 資料品質的依賴：SLI 建立在 metrics 之上，而 ch02/ch03 的每一個陷阱（cardinality、查詢寫錯、bucket 沒對齊）都會直接汙染 SLO。ch03 那場事故就是 SLO 被錯誤查詢餵養的例子。
• 組織成本：error budget policy 需要跨部門的同意與持續執行。這通常比技術部分難得多。
• 過度工程的風險：80 個 SLO 等於沒有 SLO。挑 3~5 個。

三個盲點

• SLO 是統計的，個案會被稀釋。99.9% 達標的同時，可能有一個大客戶 100% 失敗——因為他只佔總流量的 0.05%。對重要客戶要另外分開量（依 tenant 拆 SLI），這在 B2B 系統尤其重要。
• 它不涵蓋「還沒發生的風險」：憑證下個月到期、磁碟三週後會滿、某個依賴的版本已經停止支援——SLO 全部是綠的，而災難正在逼近。這類問題要靠飽和度指標與定期檢視（ch01 的四個黃金訊號裡，飽和度是唯一有預測性的那一個）。
• 它不會告訴你為什麼：SLO 只說「使用者受影響了」，根因還是要回到前五章的工具。這正是它作為「徵狀」的本質——而那是優點不是缺點。

把這一章收成三句

下一章處理最後一塊：有了 SLO 與 burn rate，什麼時候該把人叫醒？而更重要的是——什麼時候不該。