業界常把 SLA、SLO、SLI 三個詞混為一談。本章釐清三者定義、給出選指標與訂目標的實務做法，並說明 SLO 如何驅動日常的工程決策。

三個詞：SLI、SLO、SLA#

SLI（Service Level Indicator）服務水準指標#

對「服務品質的某個面向」做出定義明確的量化測量。常見類型：

• 延遲（latency）：請求到回應的時間
• 錯誤率：失敗請求 / 全部請求
• 吞吐量：每秒請求數（QPS）
• 可用度（availability）：成功處理的「合法」請求比例（亦稱 yield）
• 持久度（durability）：對儲存系統而言，資料在長時間後仍存在的機率

業界常用「9 的數量」表達高可用度——99% 是「兩個 9」，99.999% 是「五個 9」，Google Compute Engine 公開目標 99.95% 是「三個半 9」。

理想上 SLI 直接量測「使用者關心的事」；若做不到，至少用合理的 proxy。例：使用者端延遲才是重點，但若只能在伺服器端量，就用伺服器端延遲作為替代。

SLO（Service Level Objective）服務水準目標#

針對 SLI 的目標值或範圍，形式通常是：

• SLI ≤ 目標，例如「平均搜尋延遲 < 100 ms」
• 或 下限 ≤ SLI ≤ 上限

沒有公開的 SLO 時，使用者會自己假設一個目標——可能太高（系統其實沒這麼穩，卻被依賴；如 Chubby 的事件）或太低（看起來不可信，沒人敢用）。發佈 SLO 是「期望管理」的工具。

Chubby 的計畫性停機#

Chubby 全球實例的真實故障非常少，導致服務團隊把它當作「永遠在」來依賴。SRE 的解法很反直覺：若這一季實際可用度沒掉到目標以下，就刻意製造一次受控停機，逼出所有不合理的依賴，迫使服務團隊正視「分散式系統會壞」的事實。

SLA（Service Level Agreement）服務水準協議#

明示或暗示的契約，包含「未達 SLO 的後果」（最常見是金錢——退款、罰款）。

區分 SLO 與 SLA 的簡單問句：「沒達標時會發生什麼？」沒有明確後果 → 那是 SLO；有合約罰則 → 那是 SLA。多數人說「SLA 違反」時，其實指的是 SLO 違反。

SRE 通常不直接擬 SLA（涉及商業與法務），但會：

• 協助評估達標難度
• 提供可量測的 SLI 定義（避免日後爭議）

Google Search 對公眾沒有 SLA，但仍有信譽與廣告營收的後果。

實務：選 SLI#

從使用者價值出發#

不要把監控能抓到的指標通通變 SLI——指標太多會稀釋焦點，太少又會漏掉重要面向。

不同類型服務的關注點：

• 使用者前台服務（如 Shakespeare 搜尋）：可用度、延遲、吞吐量
• 儲存系統：延遲、可用度、持久度
• 大數據管線：吞吐量、端到端延遲（有時也含各階段延遲）
• 所有系統：正確性——是否回了對的答案、處理了對的資料

蒐集與聚合#

• 伺服器端指標（如 HTTP 500 比例）容易蒐集；但有些問題只在 client 端看得到（例：JavaScript 慢、CDN 失效），需 client 端打點補齊
• 聚合時要小心：
  • 「平均 QPS」可能掩蓋短時間爆量
  • 「平均延遲」會把長尾請求壓平

多數指標應視為「分佈（distribution）」而非「平均值」。請看百分位數——50th（中位數，典型體驗）、95th、99th、99.9th（最壞情境）。

使用者實驗顯示：人們偏好「稍慢但穩定」的系統，而非「平均快但變異大」的系統。

統計謬誤的小提醒#

不要預設資料是常態分布。延遲分布天生右偏（不可能小於 0、有 timeout 上限），平均數與中位數可能差很多。基於平均值「偵測異常」的程序可能誤判過多或漏判過多。

標準化 SLI 模板#

對常見指標建立可重用的 SLI 模板，避免每次從零定義：

• 聚合區間：「1 分鐘平均」
• 聚合範圍：「某 cluster 所有 task」
• 量測頻率：「每 10 秒一次」
• 包含的請求：「黑箱監控的 HTTP GET」
• 資料來源：「伺服器端監控量測」
• 延遲基準：「Time to last byte」

實務：訂 SLO#

不要「從可量測出發」，要「從使用者需求倒推」#

使用者真正在意的事常常難以直接量測，所以倒過來想：「如果他們在意 X，我能找出哪個指標當代理？」

寫法範例#

• 「99%（1 分鐘平均）的 Get RPC 在 100 ms 內完成」
• 想表達曲線形狀就疊多個 SLO：
  • 90% 的 Get RPC < 1 ms
  • 99% 的 Get RPC < 10 ms
  • 99.9% 的 Get RPC < 100 ms
• 工作型態異質時分別訂：吞吐型 client 與低延遲型 client 各有 SLO

訂目標的指引#

SLO 不可能 100% 達成。允許「錯誤預算」並逐日、逐週追蹤——錯誤預算等於「達成其他 SLO 的 SLO」。

選目標時的原則：

• 不要從目前的效能訂目標：你會被綁死在「英雄式運維」上
• 保持簡單：複雜聚合難推理、難解釋
• 避免絕對化：「永遠可用」「無限延展」既不切實際也不必要
• SLO 愈少愈好：若沒辦法用某 SLO 在優先序爭議中勝出，這 SLO 就不值得存在
• 完美可以等：寬鬆目標日後加嚴 > 嚴目標日後放寬

SLO 是控制迴路的核心#

SLO 驅動的工程循環：

1. 監控與量測 SLI
2. 比對 SLI 與 SLO，判斷是否需採取行動
3. 若需行動，找出該做什麼以回到目標內
4. 執行

例：發現延遲在數小時內會超出 SLO → 測試「是不是 CPU bound」→ 若是則擴容。沒有 SLO，就不知道何時該行動。

設定期望的兩個策略#

• 保留安全餘裕：對內 SLO 比對外宣告更嚴，給自己處理慢性問題的空間
• 不要過度達成：使用者會依「實際表現」而非「宣告值」建構依賴。可刻意停機、節流或設計成「輕載時也不會更快」，避免養成過度依賴

實務：擬 SLA#

• 後果與罰則由商業與法務團隊決定
• SRE 的角色是評估達標難度與機率
• 保守一點：對外宣告愈廣，未來修改愈難
• SLO 寫作上的所有建議大致也適用於 SLA