業界常把 SLI、SLO、SLA 三個詞混著用，但它們是三層：SLI 是量到的數字，SLO 是這個數字要達到的目標，SLA 是沒達標時要賠錢的合約。分清楚，可靠度討論才不會各說各話。
🧠 Intuition
TIP
一句話分辨 SLO 與 SLA：「沒達標會發生什麼？」沒有明確後果 → 那是 SLO；有合約罰則（退款、罰款）→ 那是 SLA。多數人口中的「違反 SLA」，其實是違反 SLO。
- SLI（指標）：對服務品質某個面向的量化測量，如成功率、延遲、吞吐量、可用度、持久度。它是「實際量到的數字」。
- SLO（目標）：SLI 要達到的目標值或範圍，如「99%（1 分鐘平均）的請求 < 100 ms」。它是「我們承諾自己要守住的線」。
- SLA（協議）：對外的契約，寫明「未達 SLO 的後果」。通常涉及商業與法務，SRE 不直接擬，但負責評估達標難度、提供可量測的 SLI 定義以免日後爭議。
- 「9 的數量」是行話：99% 是「兩個 9」、99.999% 是「五個 9」；Google Compute Engine 公開的 99.95% 就是「三個半 9」。
⚖️ Tradeoffs
不公開 SLO — 讓使用者自己猜
- 沒有公開目標時，使用者會自行假設一個。可能猜太高（系統其實沒那麼穩卻被當成「永遠在」來依賴），也可能猜太低（看起來不可信，沒人敢用）。
- Chubby 就是經典教訓：它真實故障極少，服務團隊便把它當「永不掛」來依賴。SRE 的反直覺解法是——若這季實際可用度沒掉到目標以下，就刻意製造一次受控停機，逼出所有不合理的依賴，迫使大家正視「分散式系統會壞」。
- 結論：發佈 SLO 是一種期望管理工具，不是自曝其短。
對外 SLA 訂太寬 — 未來綁死自己
- 對外宣告愈廣、愈嚴，未來要修改愈難——使用者已經照著它建立依賴與合約。
- 實務上會保留安全餘裕：對內 SLO 比對外 SLA 更嚴，留出處理慢性問題的空間。
- 對外承諾則保守一點：寬鬆目標日後加嚴，遠比嚴目標日後放寬容易交代。
🔑 Takeaways
- 三層分工：SLI（量到的數字）→ SLO（要達到的目標）→ SLA（沒達標的合約後果），別混為一談。
- 分辨 SLO / SLA 的問句是「沒達標會怎樣？」——只有政策後果是 SLO，有金錢罰則才是 SLA。
- 公開 SLO 是期望管理；對內守得比對外嚴、對外承諾保守，才不會把自己逼進長期凍結。
No notes yet — jot your takeaways or Q&A here.