SLA、SLO、SLI 有甚麼分別？服務承諾、目標與衡量方式
SLA 是服務協議，SLO 是指定時間窗內的服務目標，SLI 則定義如何衡量服務表現。了解三者的關係、錯誤預算、常見陷阱，以及撰寫 SLA 的五項建議。
先用三句話分清楚它們各自回答甚麼問題：
- SLA（服務等級協議）：服務供應商與客戶之間的正式協議，列明對外承諾。例如「每月可用性不低於 99.99%，工作日收到的客服查詢於 24 小時內回覆」。
- SLO（服務等級目標）：服務指標要達到的目標，以及評估所用的時間窗。例如「每月可用性不低於 99.99%」。SLO 可以是內部目標，不一定要寫入 SLA。
- SLI（服務等級指標）：衡量服務表現的指標及測量方式，例如「成功請求數 ÷ 有效請求總數」。99.90% 是這個指標在某個時間窗內的測量值。判斷是否達到 SLO，要以約定的同一時間窗比較；判斷是否觸發 SLA 的違約條款，還要看合約的計算規則、適用範圍與例外。
SLA：寫明服務承諾與違約後果的協議
SLA 涵蓋供應商對產品效能與功能的承諾。可用性是最常見的條款之一，未達標的處理方式通常是服務費抵扣額（Service Credit）：依約抵扣後續服務費，具體比例及申請條件以合約為準。合約也可能另行約定賠償或延長服務期。
一份 SLA 通常包含以下內容：
- 服務範圍：提供哪些服務。
- 義務條款：協議有效期內必須達成哪些 SLO。
- 衡量方式：採用哪些 SLI、如何測量，以及報告頻率與詳細程度。
- 有效期限：協議何時生效、何時審核，以及重新議定的時間點。
- 違約處理：未達標時，雙方分別承擔甚麼後果。
SLA 的兩個常見陷阱
- SLO 定義含糊：怎樣才算「服務中斷」？頁面完全無法開啟算中斷，那麼慢到不能正常操作又算不算？定義不清楚，爭議出現時便容易各執一詞。
- 條款脫離使用者需要：SLA 往往由法務、銷售、採購與技術團隊共同議定，但參與者未必實際使用服務。訂立條款時，應讓最終使用者的需要成為主要依據。
SLO：指定時間窗內的服務目標
SLO 是服務團隊檢視表現的目標，也可以寫入 SLA，成為對外承諾。即使服務沒有 SLA，團隊仍可設定 SLO。
對成功率這類 SLI 而言，99.9% 的目標容許同一評估時間窗內有 0.1% 的有效請求失敗，這就是錯誤預算（error budget）。請求比例不能直接換算成停機分鐘數；只有以時間為基礎計算的可用性目標，才適合在相同定義下計算容許中斷的時長。
SLO 最難的部分是定義細節
「每月可用性 ≥ 99.95%」不難寫，難的是決定可用性究竟怎樣計算。假設某份協議規定，只有持續至少 10 分鐘，而且超過 10% 的請求返回 HTTP 500 的時段才算服務中斷，那麼 HTTP 502、8% 的錯誤率，或只有 9 分鐘的中斷，都不符合這項定義。這是用來說明定義影響的假設例子，並非建議採用的標準。每項 SLO 都應以清楚易懂的文字，寫明精確的計算方式。
SLI：先定義怎樣測，再比較結果
SLI 必須先交代甚麼算成功、分母包含哪些請求、資料從哪裏採集，以及缺失資料如何處理，之後才談測量結果。短時間窗內低於目標，不代表整個月的 SLO 已經失敗，更不能直接推論 SLA 違約。
用戶端、伺服器端與外部合成監測各有不同的覆蓋範圍。取樣、探測位置和資料缺失都可能影響結果。SLO 定義含糊，SLI 的測量也難以成為雙方一致認可的依據。
服務一定要有 SLA 嗎？
**不一定。**是否需要 SLA，應從供應商與採購方各自的需求考慮，不能只看產品是否供企業使用。
對供應商而言，客戶的採購要求是重要因素。大型客戶通常有採購部門與固定規範，沒有 SLA 可能無法完成採購；小額訂閱則未必有同樣要求。
對採購方而言，不要只着眼於違約處理條款。評估 SLA 需要法務、財務與 DevOps 團隊投入時間，採購流程也可能因此延長。SLA 的文字承諾與實際可靠性並不相同：有些供應商的承諾較保守，服務卻很穩定；也可能有供應商承諾甚高，故障卻頻繁。採購前應同時查看狀態頁的歷史可用性與故障紀錄。對大額採購、長期合約或新供應商，SLA 所帶來的責任與處理方式的確定性尤其值得評估。
給供應商的五項 SLA 撰寫建議
- 從客戶的需要出發。 開發團隊可能把可用性拆成伺服器、驗證碼服務等多個元件；客戶在意的往往是能否完成操作。把複雜的後端測量整理成客戶看得懂的結果指標，同時釐清技術團隊的責任範圍。
- 使用清楚簡單的語言。 避免讓難懂的措辭掩蓋條款含義。雙方越容易理解，日後爭議的空間就越小。
- 不要把所有能測的指標都寫進去。 客戶真正關心的指標應佔主要位置。可測量不代表必須承諾；加入無關緊要的指標，會分散重點並增加違約風險。
- 為對外目標預留餘量。 在已驗證的服務能力內設定承諾。例如採用相同測量方式與時間窗時，內部目標為 99.95%、對外承諾為 99.9%，可留出緩衝。這是示例，不是適用於所有服務的建議數值。
- 明確列出例外及計時規則。 例如客服處理需要先取得客戶提供的排查資料，雙方應寫明等候期間如何計時，以及是否適用排除條款，避免日後對回應或處理時長各有理解。
用數據支撐 SLA 的承諾與履行
可靠的服務承諾需要測量能力支持。觀測雲的**可用性監測（雲撥測）**從外部探測服務，依所選位置與頻率提供可用率及故障時長資料；監控器與事件時間軸則可協助追蹤故障和回應過程。
這些資料可以支援內部 SLO 評估，但不會自動成為合約認可的 SLA 履約憑證。測量方式與資料保留要求，仍需由雙方事先議定。參考可用性監測文件及監控文件。
常見問題
應該先有 SLO 還是 SLA？
通常可以先定義並驗證 SLI 與 SLO，再決定哪些目標寫入 SLA。這有助降低承諾風險，但不是必須遵循的固定順序。SLO 本身不依賴 SLA 才能成立。
內部 SLO 與對外 SLA 的目標數值必須相同嗎？
可以相同，也可以不同。一種做法是在相同測量方式與時間窗下，將對外目標定為 99.9%、內部目標定為 99.95%，為對外承諾留出餘量。若計算方式不同，兩個百分比便不能直接比較。
SLI 用甚麼工具測量才算有效？
關鍵是測量定義，而非工具名稱。可採用伺服器端計數、用戶端觀測或外部合成監測，取決於要衡量的使用體驗和覆蓋範圍。雙方應事先認可測量方法，並在 SLA 的「衡量方式」章節寫清楚。
客戶要求賠償 SLA 沒有提及的項目，應怎樣處理？
先核對主合約、其他適用條款與 SLA 的範圍，再由商務與法務團隊評估。SLA 沒有列出某項後果，並不能據此斷定整份合約都不涉及該項目。
