SRE 的 SLI、SLO、SLA 與錯誤預算：先分清楚「量什麼」「承諾什麼」「賠什麼」

三個縮寫，三個不同層次的問題

SRE（Site Reliability Engineering）用 SLI、SLO、SLA 三個概念，把「服務可靠嗎」這個模糊的問題拆成三個可以分別回答的層次：

• SLI（Service Level Indicator，服務水準指標）：量測什麼——用什麼具體、可觀測的數字代表服務品質
• SLO（Service Level Objective，服務水準目標）：內部目標訂多少——這個指標要維持在什麼範圍，才算「服務健康」
• SLA（Service Level Agreement，服務水準協議）：對外承諾、沒達成要賠什麼——寫進合約、對客戶的正式承諾，通常附帶罰則或補償

三者是包含關係：先有 SLI 這個量尺，才能訂 SLO 這個內部目標，SLA 則通常是 SLO 裡再留一點緩衝、正式對外公布的版本。

混用最常見的錯誤，是把內部拿來自我要求的 SLO 直接當 SLA 公佈出去——SLO 是團隊用來提早自我警惕的門檻，SLA 是對外的底線，兩者刻意留有落差才有意義。

用一個案例貫穿全文：電商訂單系統的 OrderService

為了不讓 SLI、SLO、SLA 停留在抽象定義，這篇文章統一用同一個場景舉例：電商微服務可觀測性專案 裡的 OrderService。

使用者呼叫「建立訂單」API 後，OrderService 發布 OrderCreatedEvent，交給 PaymentService 請款；付款完成後 PaymentService 發布 PaymentCompletedEvent，OrderService 收到後確認付款（OrderPaid），再觸發 ShippingService 出貨。整個流程畫成圖大致是這樣：

使用者
  │
  │ 建立訂單
  ▼                    ← SLI 量測點：建立訂單成功且夠快的比例
OrderService
  │
  │ 發布 OrderCreatedEvent
  ▼
PaymentService
  │
  │ 向金流請款
  ▼                    ← 錯誤預算消耗點：Consumer Lag 過高，訂單卡在這步
PaymentCompletedEvent
  │
  ▼
OrderService（確認付款 OrderPaid）
  │
  ▼
ShippingService（觸發出貨）

下面每一節都會回到這個場景，示範 SLI 怎麼選、SLO 怎麼訂、SLA 怎麼跟 SLO 拉開差距，以及錯誤預算怎麼算、怎麼用；最後一節再把這幾步收斂成一張總表。

SLI：先選對「量什麼」，量測才有意義

SLI 是一個比率，通常長這樣：

SLI = 好的事件數 / 總事件數

常見的 SLI 選擇，取決於服務的本質：

選 SLI 最容易犯的錯，是選了系統內部方便量測、但不代表使用者真實體驗的指標。例如只看伺服器的 CPU、記憶體使用率——這些是資源指標（Resource Metric），可以拿來做容量規劃，但不能直接代表使用者感受到的服務品質。

SLI 應該盡量貼近使用者視角、用業務語言描述，而不是直接拿 API 路徑、HTTP 狀態碼這種技術術語當指標名稱——使用者在意的是「建立訂單這件事有沒有順利完成」，不是「/orders 端點回不回 5xx」。拿 OrderService 舉例，比較貼近使用者體驗的 SLI 會是：過去一段時間內，「建立訂單」成功且在 300 毫秒內完成的比例，而不是「伺服器 CPU 有沒有超過 80%」這種內部資源指標。

底層量測時當然還是要落到具體的 API 與狀態碼，但那是實作細節，不是對外溝通這個 SLI 時該用的語言：

# 業務指標：建立訂單成功且在 300ms 內完成的比例
sum(rate(http_requests_total{service="OrderService", route="/orders", status!~"5..", le="300ms"}[28d]))
/
sum(rate(http_requests_total{service="OrderService", route="/orders"}[28d]))

SLO：內部目標，用來在「還沒出事」的時候就先警覺

SLO 是針對 SLI 訂出的目標範圍，通常寫成「在 N 天的滾動視窗內，SLI 要維持在 X% 以上」。針對前面的 OrderService 建立訂單 API，一個合理的內部 SLO 可能是：過去 30 天，可用性 ≥ 99.9%。

SLO 不是訂得越高越好。100% 的可靠性幾乎不可能達成，而且追求它的邊際成本極高——從 99.9% 提升到 99.99%，代表允許的故障時間從一年 8.76 小時降到 52.6 分鐘，這通常需要多活架構、更複雜的容錯機制，成本可能是等比級數上升，但使用者實際感受到的差異可能很小。

訂 SLO 時該問的問題是：使用者真的會在意這個差異嗎？多花的成本，值得換來這個差異嗎？對 OrderService 來說，建立訂單偶爾多等幾百毫秒，使用者多半無感；但如果整條「建立訂單 → 確認付款 → 觸發出貨」的事件鏈卡住超過幾分鐘，使用者就會直接看到訂單狀態卡住不動，這種等級的落差，才是決定 SLO 該訂多嚴格的依據。

常見的可用性 SLO 與對應的容忍停機時間（一年）：

SLA：對外承諾，通常比 SLO 更寬鬆

SLA 是寫進合約、對客戶的正式承諾，沒達成通常伴隨罰則（例如：退費、抵用額度）。因為違反 SLA 有實際代價，SLA 的門檻通常會設得比內部 SLO 更寬鬆。

如果 OrderService 未來要包裝成對外銷售的電商 SaaS，內部 SLO 可以訂 99.95%，但寫進客戶合約的 SLA 通常會退一步只承諾 99.9%——中間留的差距，就是給團隊在真正踩到「要賠錢」的紅線之前，有機會先自己發現、先自己修正的緩衝空間。

如果把 SLO 直接當 SLA 公佈，等於把「自我警惕的門檻」和「賠錢的底線」訂成同一條線，團隊會失去這段緩衝，每次 SLO 稍微沒達標就等於要面對合約糾紛，這通常會逼團隊在訂 SLO 時反而不敢訂高，長期反而傷害真正的可靠性文化。

錯誤預算：把「可靠性」換算成一個可以花的額度

錯誤預算（Error Budget）是 SRE 最核心的工具，公式很直接：

錯誤預算 = 1 - SLO

如果 OrderService 建立訂單 API 的 SLO 是 99.9%，錯誤預算就是 0.1%——代表在 30 天的視窗週期內，允許不可用（或不符合 SLI 定義的「好」）的時間大約是 43.2 分鐘，這是團隊在這個週期內可以「花」的額度。

錯誤預算真正厲害的地方，是它把「可靠性」跟「開發速度」放進同一個可以量化的天平上，變成團隊自己可以決定怎麼分配的資源，而不是模糊的「盡量別出事」：

• 預算還沒花完：代表系統目前比承諾的更可靠，團隊可以承擔更高風險——加快發版節奏、上更多實驗性功能、做更積極的架構重構
• 預算已經花完（或快花完）：代表可靠性已經逼近甚至跌破承諾的底線，這時候應該凍結非必要的變更，把資源轉去修復可靠性問題（減少故障、改善監控、補測試），直到預算恢復到安全水位

這個機制解決了 SRE 團隊與產品／開發團隊之間最常見的拉鋸：開發團隊想衝功能上線速度，SRE 想要穩定，雙方常常各說各話。錯誤預算把這個拉鋸變成一條雙方都同意、有數字依據的規則——預算沒花完就能衝，花完了就該停下來修穩定性，不需要每次都吵一輪「這樣改風險大不大」。

三者放在一起的實務流程：走一遍 OrderService 的完整情境

把前面幾節串起來，套進「建立訂單」這件事，四個概念實際會填成這樣的具體範例：

實際決策範例：某天 PaymentService 因為 Kafka Consumer Lag 飆高，大量訂單卡在「已建立、但付款一直沒被確認」，事後盤點這次事件吃掉了 30 分鐘的錯誤預算，只剩 13.2 分鐘餘裕。團隊據此決定這個月暫停訂閱制、優惠券等新功能開發，優先修 PaymentService 的消費延遲、補上 Consumer Lag 告警，等下個 30 天視窗重新開始、預算恢復安全水位，才恢復原本的功能開發步調。

這張表就是 SLI、SLO、SLA、錯誤預算實際搭配運作的樣子：SLI 決定量什麼，SLO 決定內部多嚴格，SLA 決定對外承諾多少，錯誤預算則把前三者換算成一個具體數字，讓「現在該衝新功能還是該停下來修穩定性」變成有數字依據的決策，而不是靠感覺吵架。

一句話總結

SLI 決定量什麼，SLO 決定內部目標訂多嚴格，SLA 決定對外承諾與賠什麼；錯誤預算則是把「可靠性」換算成一個團隊可以自己決定怎麼花的額度——預算還在，就有本錢衝新功能；預算花完，就該停下來把穩定性補回來。