SLO 與 SLI

Vibe Prompt

「幫我為一個 API 服務定義 SLI（可用性 99.9%、P95 延遲 <200ms）與 SLO。」

SLI 類型

| 指標 | SLI 範例 | |------|---------| | 可用性 | 成功請求 / 總請求 >= 99.9% | | 延遲 | P95 回應時間 < 200ms | | 吞吐量 | 每秒請求數 > 1000 | | 錯誤率 | 5xx 錯誤 < 0.1% |

計算方式

# 可用性 SLI
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

# P95 延遲
histogram_quantile(0.95,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

# 錯誤率
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

SLO 範例

| 服務 | SLO | 錯誤預算/月 | |------|-----|------------| | API Gateway | 99.9% | 43 分鐘 | | 資料庫 | 99.99% | 4.3 分鐘 | | 排程任務 | 99.5% | 3.6 小時 | | DNS 解析 | 99.99% | 4.3 分鐘 |

錯誤預算

每月錯誤預算 = (1 - SLO) × 30 × 24 × 60 分鐘
99.9% → 43.2 分鐘/月
99.99% → 4.32 分鐘/月

消耗速度太快 → 停止新功能，專注穩定性
消耗速度正常 → 可以繼續開發

關鍵要點

✅ SLI (Service Level Indicator) = 你實際測量的指標（如延遲的第 99 分位數）
✅ SLO (Service Level Objective) = 你對指標設定的目標（如 p99 < 200ms）
✅ SLA (Service Level Agreement) = 你對客戶承諾的條款（如 99.9% 可用性）
✅ 錯誤預算 = 100% - SLO，代表你可以「犯錯」的額度
✅ 錯誤預算耗盡時應停止新功能發布，全力改善穩定性

常見 SLI 定義

| 類別 | SLI 範例 | 良好目標 | |------|---------|:--------:| | 可用性 | 成功請求 / 總請求 | ≥ 99.9% | | 延遲 | p99 請求延遲 | < 200ms | | 吞吐量 | 每秒請求數 | ≥ 1000 req/s | | 持久性 | 資料未遺失率 | ≥ 99.9999999% | | 正確性 | 正確回傳結果的比例 | ≥ 99.99% |

錯誤預算計算

每月 SLO = 99.9% → 錯誤預算 = 0.1%
每月總時間 = 30 × 24 × 3600 = 2,592,000 秒
允許停機 = 2,592,000 × 0.1% = 2,592 秒 ≈ 43 分鐘

當本月已停機 > 30 分鐘 → 停止發布新功能

深入理解 SLO 的數學意義

為什麼 99.9% 和 99.99% 差這麼多？

很多人直覺覺得 99.99% 只比 99.9% 多了 0.09%，但實際上的 downtime 差異是 10 倍：

| SLO | 每年允許 downtime | 每月允許 downtime | 每週允許 downtime | |:---:|:----------------:|:----------------:|:----------------:| | 99% | 3.65 天 | 7.31 小時 | 1.68 小時 | | 99.5% | 1.83 天 | 3.65 小時 | 50.4 分鐘 | | 99.9% | 8.76 小時 | 43.8 分鐘 | 10.1 分鐘 | | 99.95% | 4.38 小時 | 21.9 分鐘 | 5.04 分鐘 | | 99.99% | 52.6 分鐘 | 4.38 分鐘 | 1.01 分鐘 | | 99.999% | 5.26 分鐘 | 26.3 秒 | 6.05 秒 |

關鍵洞察：從 99.9% 提升到 99.99%，系統的可靠度需要提升 10 倍，但成本往往不只 10 倍。這就是為什麼不是每個服務都需要 99.99%——你要根據服務的商業價值來決定 SLO。

SLI 的測量方式：三種方法各有優缺

| 測量方式 | 做法 | 優點 | 缺點 | |:--------|:----|:----|:----| | 伺服器端 | 從伺服器日誌計算成功/失敗比例 | 精確、完整 | 可能錯過客戶端體驗的問題 | | 用戶端合成監控 | 定期從外部模擬使用者請求 | 反映真實用戶體驗 | 樣本數有限 | | 用戶端真實資料 | 在 App 中埋點上傳效能資料 | 最真實 | 開發成本高、隱私考量 |

實務上 Google 建議三種都用：伺服器端 SLI 作為主要指標，合成監控作為 alert source，真實用戶資料驗證兩者的一致性。

錯誤預算的實際運作

錯誤預算不只是數學公式——它是 SRE 團隊和開發團隊之間的「合約」：

情境一：錯誤預算充足（本月只用了 30%）
  → 開發團隊可以安心發布新功能
  → SRE 團隊提供部署支援

情境二：錯誤預算接近耗盡（用了 85%）
  → 開發團隊限制發布頻率
  → SRE 團隊優先處理穩定性改善

情境三：錯誤預算已耗盡
  → 凍結所有新功能發布
  → 所有人投入穩定性修復
  → 直到累積足夠的錯誤預算

這個機制的好處是不用主管決定——數據說了算。當 SLO 是 99.9%、錯誤預算只剩 10 分鐘時，誰敢在這個時候部署新功能？

SLO 的設定原則

永遠比 SLA 嚴格：SLA 是對客戶的承諾（合約），SLO 是內部目標。如果 SLA 是 99.9%，內部 SLO 應該設 99.95%，這樣即使稍微超標也不會違反 SLA。
從用戶角度出發：不要只看「伺服器正常運作」，要問「用戶的請求成功了嗎？」
逐步收緊：剛開始 SLO 設寬鬆一點（99%），穩定後再逐步收緊到 99.9%。
不要追求完美：100% 的 SLO 不切實際——追求完美反而會讓系統變得脆弱（不敢更新、不敢重啟）。

為什麼要學 SLO/SLI？

如果沒有 SLO，你就無法回答「系統夠不夠穩定？」這個問題。 你可能覺得系統很穩，直到用戶抱怨才發現已經 downtime 了 3 小時。SLO 讓你事先知道系統的穩定狀態，而不是出事後才發現。

名詞解釋

| 名詞 | 全稱 | 解釋 | |:----|:----|:----| | SLO | Service Level Objective | 你對服務可靠度的內部目標 | | SLI | Service Level Indicator | 衡量服務可靠度的量化指標 | | SLA | Service Level Agreement | 你對客戶合約承諾的服務水準 | | Error Budget | 錯誤預算 | SLO 允許的錯誤總量 | | Burn Rate | 燃燒速率 | 錯誤預算消耗的速度 |

下一章預告：事件管理 Incident Response

SLO/SLI 讓你知道服務的健康狀態。當服務真的出問題時，你需要一套標準的應對流程——下一章的 Incident Response 告訴你：從告警觸發、事件分級、止血行動到事後覆盤的完整流程。這不是臨場反應，而是事先演練過的 SOP。