SLO 的品質上限由 SLI 決定。把 SLI 想成一個比率——好事件數 / 總事件數——它天然落在 0%～100%、直覺好懂，
1 − SLO就是 error budget。難的不是算，而是選：量到的東西必須真的反映使用者的感受。
🧠 Intuition
TIP
SLI = 好事件數 / 總事件數。例：成功 HTTP 請求 / 總請求（成功率）、100 ms 內完成的 gRPC / 總 gRPC（延遲達標率）。統一寫成比率，各服務的可靠度就能用同一把尺比較。
- 從使用者價值倒推，不要「監控抓得到什麼就設什麼」。指標太多會稀釋焦點，太少會漏掉重要面向。
- 先寫 SLI 規格（你認為對使用者重要的結果，與怎麼量無關），再定 SLI 實作（規格 + 測量方式）。兩者分開，才討論得清「量錯」還是「目標訂錯」。
- 不同組件類型有不同的建議 SLI：
- 請求驅動型：可用性、延遲、品質（未降級狀態下回應的比例）
- Pipeline 型：新鮮度（freshness）、正確性、覆蓋率（coverage）
- 儲存型：持久度（durability）——寫入的資料能被成功讀回的比例
- 對常見指標建標準化 SLI 模板（聚合區間、範圍、量測頻率、資料來源、延遲基準），避免每次從零定義、也免得日後對定義吵架。
⚖️ Tradeoffs
用平均值當 SLI — 看似穩，其實騙人
- 「平均延遲」會把長尾請求壓平，「平均 QPS」會掩蓋短時間爆量——多數指標該視為分佈而非單一平均。
- 延遲分布天生右偏（不會小於 0、有 timeout 上限），平均數與中位數常差很多；基於平均值的異常偵測容易誤判或漏判。
- 該看百分位：50th（典型體驗）、95th / 99th / 99.9th（最壞情境）。使用者實驗顯示——人們偏好「稍慢但穩定」而非「平均快但變異大」的系統。
量測點離使用者太遠 — 覆蓋率不足
- 伺服器端指標（如 HTTP 5XX 比例）好蒐集，但有些問題只在 client 端看得到（JS 慢、CDN 失效）。純伺服器端量會漏掉這段。
- 若做不到直接量使用者端，至少選一個合理的 proxy（如負載平衡器指標——已可用、又比純後端更接近使用者體驗）。
- 覆蓋率不足的訊號：故障沒被任何 SLI 捕捉，或 SLI 掉了卻對不上使用者影響。此時該把量測點移近使用者，或擴大 SLI 涵蓋的互動。
🔑 Takeaways
- SLI 統一寫成 好事件 / 總事件 的比率，直覺、可跨服務比較，且
1 − SLO直接給出 error budget。 - 選 SLI 要從使用者價值倒推、分清「規格 vs 實作」，並按組件類型（請求 / pipeline / 儲存）挑對面向。
- 看分佈與百分位而非平均值；量測點盡量靠近使用者，覆蓋率不足時調實作而非硬改目標。
No notes yet — jot your takeaways or Q&A here.