很多工程縮寫第一次看都像在玩記憶力遊戲，SLI / SLO / SLA 特別像。

三個都在講穩定性，三個都跟服務品質有關，三個也常常一起出現。差別是，它們站在不同層級。

最短的版本是：

• SLI 是你量什麼
• SLO 是你希望它多好
• SLA 是你對客戶承諾什麼

這三個放在一起，才會把「我們服務很穩」這種模糊感覺，變成能監控、能討論、能管理風險，甚至能寫進合約的東西。

SLI 是你量什麼

SLI 是 Service Level Indicator，服務水準指標。

它回答的問題是：我們到底用哪個數字判斷服務好不好？

常見的 SLI 包含：

• request 成功率
• API 可用率
• P95 / P99 latency
• 錯誤率
• 付款成功率
• 搜尋結果回傳時間
• AI 回覆的 TTFT 或完成率

例如「最近 30 天 99.92% 的 API request 成功」就是一個 SLI。它不是目標，也不是承諾，它只是儀表板上的真實數字。

如果沒有 SLI，團隊很容易用感覺吵架。有人覺得系統很穩，有人覺得常常壞，但大家看的不是同一個數字，最後就會變成口水戰。

SLO 是你希望它多好

SLO 是 Service Level Objective，服務水準目標。

它回答的問題是：這個 SLI 要到什麼程度，才算我們接受的服務品質？

例如：

• API 30 天成功率要大於 99.9%
• P95 latency 要低於 300ms
• 付款流程成功率要大於 99.95%
• AI 聊天第一個 token 要在 1.5 秒內出現

SLO 通常是團隊內部目標。它不一定直接寫給客戶看，但它會影響工程決策。

如果 SLO 被穩定達成，團隊可以比較放心地加功能、做實驗、推新版本。如果 SLO 一直被打破，代表系統健康度已經在亮黃燈，這時候再一直加新功能，通常就是把未來事故提前叫出來。

Error budget 是 SLO 最好用的地方

SLO 真正有用，不是因為它看起來很專業，而是因為它可以推導出 error budget。

假設 SLO 是 99.9% 可用率，意思是 30 天內最多可以有 0.1% 的請求失敗或不可用。這 0.1% 就是可以被消耗的錯誤預算。

它的好處是讓工程團隊不需要追求不切實際的 100%。

如果 error budget 還很充足，代表系統還有空間承擔變更風險。如果 error budget 快燒完，代表最近事故、錯誤或延遲已經太多，團隊應該先修穩定性，而不是繼續衝功能。

所以 SLO 不是用來羞辱工程師的數字，它比較像是煞車系統。車還能開，但儀表告訴你不要再踩太兇。

SLA 是你對客戶承諾什麼

SLA 是 Service Level Agreement，服務水準協議。

它回答的問題是：如果服務沒有達到承諾，客戶可以得到什麼補償？

例如：

• 月可用率低於 99.9%，退還 10% 服務費
• 低於 99.0%，退還 25% 服務費
• 企業方案承諾特定回應時間，未達標可申請 service credit

SLA 是商業和法律層級的承諾，比 SLO 更硬。

也因為它更硬，SLA 通常會比內部 SLO 寬一點。團隊內部可能要求自己達到 99.95%，但對外只承諾 99.9%。這不是偷懶，而是留出緩衝，避免任何小波動都直接變成合約事件。

三個放在一起怎麼看

可以把它想成一層一層往外擴：

• SLI：儀表現在顯示 API 成功率是 99.92%
• SLO：我們內部目標是 99.9%，目前還在目標上方
• SLA：我們對客戶承諾是 99.5%，現在離合約底線還有距離

如果 SLI 掉到 99.82%，可能還沒有違反 SLA，但已經低於 SLO，代表 error budget 正在燃燒。這時候工程團隊應該開始處理，不要等到 SLA 真的被打破才說有事故。

這也是成熟工程管理和「壞了再修」最大的差別。

AI 產品更需要這套語言

AI 產品常常比傳統 API 更需要 SLI / SLO / SLA，因為 AI 的「壞」不一定只有 500 error。

AI 服務可能出現：

• 第一個 token 很慢
• 回答到一半中斷
• 工具呼叫成功率下降
• 長上下文任務超時
• 回覆品質漂移
• 外部模型供應商延遲暴增

這些都不一定能用單一 uptime 說清楚。

所以 AI 產品要定義更貼近使用者體驗的 SLI，例如 TTFT、完成率、工具成功率、重試率、任務總完成時間。接著再設定 SLO，最後才決定哪些東西真的要寫進 SLA。

一句話總結

SLI / SLO / SLA 不是三個要背起來的縮寫，而是一套把服務穩定性講清楚的方法。

SLI 是儀表，SLO 是目標，SLA 是契約。

沒有 SLI，大家不知道壞在哪裡。沒有 SLO，團隊不知道什麼叫夠好。沒有 SLA，客戶不知道你到底承諾到哪裡。

真正成熟的系統不是永遠不壞，而是知道自己怎麼量、什麼時候該停下來修、以及對客戶承諾的邊界在哪裡。