100% 可靠不是目標，也不划算。SLO 定義「夠可靠」的門檻，1 − SLO 就是 error budget——一段時間內「允許不可靠」的額度。預算還有，就放手發布；預算燒光，就凍結變更、回頭補可靠度。
🧠 Intuition
TIP
把可靠度當成一個有額度的帳戶。SLO 99.9% / 月 → 你有 0.1% ≈ 43 分鐘的「可以壞」預算。每次當機、每個錯誤回應都在扣款；月初重置。
- SLI（指標）：實際量到的可靠度，如「成功請求 / 總請求」。
- SLO（目標）：SLI 要達到的門檻，如 99.9%。
- Error budget：
1 − SLO。把「穩定 vs. 迭代速度」從吵架變成算術——預算是共同貨幣，產品和 SRE 看同一個數字。
⚖️ Tradeoffs
SLO 訂太高（如 99.99%）— 看似安全，其實傷自己
- 預算極小（/月 ≈ 4 分鐘），一次部署事故就燒光 → 長期凍結發布。
- 為了守住數字，得投入與「使用者實際感受」不成比例的工程成本。
- 多數使用者根本分不出 99.9% 與 99.99% 的差別——超出感知的可靠度是浪費。
用 error budget 當發布閘門 — 標準做法
- 預算還有：自由發布、做風險高的實驗、加快迭代。
- 預算燒光：自動凍結功能變更，團隊轉去做可靠度（補測試、修脆弱點、加自動化）。
- 好處：把「要不要上線」變成政策而非每次爭論；獎勵把系統做穩的人。
- 代價：SLI/SLO 要選得準。指標若不反映使用者體驗，預算閘門會擋錯東西。
🔑 Takeaways
- Error budget = 1 − SLO，把「穩定 vs. 速度」化成一個雙方共用的數字。
- SLO 要綁使用者感受的 SLI，並刻意訂得「剛好夠用」，別追求 100%。
- 預算還有就放手發布，燒光就凍結變更回補可靠度——讓政策代替爭論。
2026-07-01
- Q：error budget 燒光時，真的要硬性凍結所有發布嗎？緊急安全修補怎麼辦？
- A：凍結的是「會增加風險的功能變更」，不是「降低風險的變更」。安全修補、可靠度改善、回滾本身屬於後者，照常放行——它們是用來回補預算的。實務上會在 SLO 政策裡白紙黑字列出豁免類別，避免每次事故都重新吵一遍。