📗〔讀書心得〕- SRE Ch4：SLI、SLO 與 SLA 的實踐指南
- 📗〔讀書心得〕- SRE Ch4：SLI、SLO 與 SLA 的實踐指南
- 為什麼需要制定服務等級目標（SLO）？
- 如何找到真正重要的 SLI 指標？
- 如何定義正確的 SLO 指標？
- 我的 TAKEAWAY
- Extended Reference ＆ FYI
這篇文章將聚焦於《Site Reliability Engineering》中的：
講解 SRE 如何透過 SLI、SLO 與 SLA 將系統的可靠性從「一種感覺」轉變為「可被量化、可被討論、可被管理」的工程問題。
為什麼需要制定服務等級目標（SLO）？
在軟體工程的世界裡，我們時常面臨一個痛點：服務上線後，使用者抱怨系統慢、時常無法存取，但團隊卻拿不出具體數據來評估問題的嚴重性。如何量化「穩定」、「快速」、「服務很慢」這些抽象概念，並讓所有團隊成員（從工程師到產品經理）都能有共同的認知，這正是 SRE (Site Reliability Engineering) 的核心課題。
SRE 借鑑軟體工程原則來解決運維問題，其中最關鍵的工具之一就是 服務等級目標（Service Level Objective, SLO）。它不只是一個數字，更是協調團隊目標、設定使用者預期、並驅動數據決策的指標工具。
核心三要素：SLI、SLO、SLA
許多人會將這三個名詞混用，但它們各有明確的定義和用途。簡單來說：
- SLI 是「測量工具」。
- SLO 是「目標」。
- SLA 是「合約」。
它們的關係就像是：我們用溫度計 (SLI) 來測量室溫，設定一個目標 (SLO) 是 26°C，並與家人約定 (SLA) 如果溫度超過 30°C，就要開冷氣。
服務等級指標（SLI）：量化服務品質的探針
定義： SLI 是用來衡量服務品質的具體、可量化的指標。
理想情況下，好的 SLI 必須能直接反映使用者體驗。
理想情況下，好的 SLI 應能直接反映使用者體驗。單看伺服器 CPU 使用率再高，並不代表服務品質差；但若錯誤率急升，使用者會立刻感受到服務不可用。唯有選擇正確的 SLI，才能真正揭示使用者的痛點。
然而，理想指標並非總能直接量測，因此常需使用代理指標。例如，企業尚未導入端到端的監控，雖然客戶端延遲指標更能反映使用者感受，但有時只能透過伺服器端延遲來推估。
常見的 SLI 指標：
- 可用性（Availability）： 衡量服務在一段時間內可用的比例，例如成功回應數 ÷ 總請求數。
- 延遲（Latency）： 衡量回應時間，例如 P99 API 延遲 < 200ms。
- 吞吐量（Throughput）： 衡量單位時間處理的請求數，常以 QPS 表示。
特別要注意，僅用平均值評估 延遲（Latency） 非常危險，因為會掩蓋「長尾效應」。一個服務或許 99% 請求能在 100 毫秒內完成，但剩下 1% 卻要耗時 10 秒，這些使用者的體驗極差。因此，在實務中延遲（Latency）更常採用百分位數（Percentile），如 P99 延遲，意即 99% 的請求延遲低於該值。
服務等級目標（SLO）：團隊共同努力的燈塔
SLO（Service Level Objective） 是針對 SLI（Service Level Indicator） 所設定的明確目標值，可以視為團隊對服務品質的目標。
SLO 主要體現在兩個價值面向：
設定預期
公布 SLO 能讓使用者清楚知道服務的可靠性等級，避免產生不切實際的期待。
例如，一個服務若宣稱可用性 99.9%，代表一年約有 8 小時可能不可用。這告訴使用者：系統並不是「永不出錯」，因此他們在設計架構時必須考慮容錯機制。
驅動決策
SLO 提供了量化的依據，幫助團隊判斷：當前應該把資源投向 可靠性提升，還是持續開發新功能。這讓工程決策不再只是「靠感覺」，而是有數據支持。
書中的經典案例小故事： Google 的 Chubby 服務曾因過於可靠，導致其他服務過度依賴它，沒有考慮其故障的可能性。為了矯正這種不健康的依賴，Google SRE 團隊甚至會「刻意」製造計畫性的服務中斷，來消耗錯誤預算，讓下游其他服務不得不面對現實，並為 Chubby 的不可用性做好準備。
服務等級協議（SLA）：具有法律或商業約束力的契約
SLA（Service Level Agreement） 是一份 正式契約，通常包含法律或商業懲罰條款。
一旦服務未能達成事先約定的 SLO（Service Level Objective），服務提供方可能需要支付賠償、退費，甚至承擔法律責任。換句話說，SLA 不只是技術承諾，而是商業承諾。
但 SLA 通常由業務、法務團隊與客戶簽訂。
- SRE 團隊的主要職責是協助業務方制定可行的 SLI 與 SLO，並確保系統能達到這些目標，以避免觸發 SLA 的懲罰條款。
澄清常見誤解：
SLA 並非每個服務都有。
Google Search 這樣面向大眾的服務就沒有明確的 SLA，因為無法與全世界的用戶簽訂合約。但即使沒有 SLA，SLI 和 SLO 仍然是管理和優化服務的關鍵工具。
如何找到真正重要的 SLI 指標？
既然我們已經理解了選擇適當指標的重要性，那麼該如何從茫茫的監控數據中，挑選出對服務最有意義的 SLI 呢？答案是：從你的使用者和服務類型出發。
單純地追蹤所有能收集到的數據是沒有意義的。
- 指標過多會分散注意力，導致無法聚焦於真正重要的問題；指標過少又可能忽略系統的關鍵行為。
- 通常只需少數幾個代表性指標，就足以評估和理解一個系統的健康狀態。
不同類型的服務，其關注的核心指標也會有所不同：
- 使用者導向的服務：
這類服務直接面對終端使用者，因此其 SLI 應緊密關聯使用者體驗。我們主要關注三個方面：
- 可用性（Availability）： 系統是否能回應請求？通常以成功回應的比例來衡量。
- 延遲（Latency）： 回應一個請求需要多長時間？這是衡量服務「快慢」的關鍵。
- 吞吐量（Throughput）： 系統在單位時間內能處理多少請求？這決定了服務的處理能力上限。
- 存儲導向的系統： 這類系統的核心價值在於資料的保存與存取。除了可用性和延遲外，耐用性（Durability） 變得尤為重要，它代表了「我的資料是否還在那裡？」。
- 大數據系統：
這類系統通常是批次處理或管道作業。重點指標是：
- 吞吐量： 在單位時間內處理了多少資料？
- 端到端延遲（End-to-End Latency）： 資料從被接收到完成處理，整個過程花了多長時間？
此外，所有系統都應關注 正確性（Correctness），亦即服務是否提供了正確的答案或資料。雖然這不總是 SRE 的直接責任，但它是評估系統健康的基石。
如何正確的聚合(Aggregation)收集到的指標？
在收集到原始數據後，我們通常會進行聚合。但這個過程需要非常謹慎，因為簡單的平均值可能會隱藏關鍵的細節。
舉例來說，一個服務的平均延遲為 100 毫秒，這聽起來不錯。但可能存在一種情況：95% 的請求都在 50 毫秒內完成，而剩下的 5% 卻要耗費 1 秒以上。這種被稱為「長尾延遲」的現象，會嚴重影響少數使用者的體驗。如果只監控平均值，我們將永遠不會發現這個問題。
紫色區塊為50th, 綠色區塊為85th, 紅色區塊為95th, 藍色區塊為99th percentile latencies for a system.
因此，針對針對延遲建議使用百分位數（Percentile） 來衡量指標，避免單一平均值所帶來的統計陷阱。
- P50（中位數）： 代表一般或典型的使用者體驗。
- P99 或 P99.9： 代表「最糟糕」但仍能接受的使用者體驗。如果連這些高百分位數的表現都很好，那麼絕大多數使用者肯定會感到滿意。
如何定義正確的 SLO 指標？
制定 SLO 的核心原則是：先思考你的使用者在乎什麼，而不是你能夠測量什麼。
從使用者的角度出發，這會使我們尋找更有意義的近似指標。如果只從容易測量的指標開始，最終制定的 SLO 可能與使用者體驗脫節，變得毫無用處，最後反而變成監控時的噪音。
從目標回推指標，通常比從指標尋找目標更有效。
以下是書中提及的一些實務上值得遵循的建議：
- 從使用者需求出發：
- 定義要精準：SLO 應該 清楚定義測量方式與條件，例如：「99% 的
Get函式呼叫，需在 100 毫秒內完成」。 - 考慮不同使用情境：若下游有多樣的客戶端，建議為 不同類型制定專屬的 SLO。
- 例如：對「互動型使用者」設定嚴格的延遲 SLO。
- 對「批次處理任務」則以吞吐量為核心目標。
- 擁抱不完美：
- 拒絕 100% 的神話：沒有系統能做到永遠可用。盲目追求 100% 不僅成本高昂，還會拖慢創新與部署速度。
- 引入錯誤預算（Error Budget）
- 制定 SLO 的黃金法則：
- 不以現有表現為標準：直接依照目前的系統性能來設定 SLO，團隊可能會被迫投入大量額外資源，只是為了勉強維持現狀，卻無法真正改善系統架構。這樣的目標往往不可持續，也會卡住未來的優化。
- 保持簡單：過於複雜的 SLO 難以理解，也可能掩蓋系統真正的性能變化。
- 避免絕對化：沒有一個系統能做到「永遠可用」或「無限擴展」。設定不切實際的目標只會徒增營運成本，卻不會帶來對等的用戶滿意度提升。
- 精選少數 SLO：選擇 足夠涵蓋服務關鍵特性的 SLO 即可。如果一個 SLO 從未在團隊討論中被引用來做決策，那它可能就不是一個有用的 SLO。
- 允許迭代：一開始可以設定一個較為寬鬆的目標，隨著對系統行為的理解加深，再逐步收緊。這比一開始就設定一個遙不可及的目標，最終被迫放寬要好得多。
如何利用 SLO 為使用者設定明確的期望？
發布 SLO 的一個重要目的，就是 替使用者建立合理的預期。
對使用者來說，他們需要了解一個服務的特性，才能判斷是否符合需求：
- 如果一個團隊要打造 即時相片分享平台，他們會優先考慮「高可用、低延遲」的服務，而不是「耐用性極高、成本低，但可用性較差」的儲存方案。
- 反之，若需求是 長期文件歸檔，那種低成本、高耐用的儲存服務反而是最佳選擇。
這就是為什麼 清晰的 SLO 能幫助使用者做出正確選擇。
另外書中有提到兩個 google 在實務會使用的策略，以保持使用者對服務的正確期待～
1. 保持安全緩衝（Safety Margin）
SRE 團隊會設定一個 比對外公布更嚴格的內部 SLO。
這樣做有幾個好處：
- 預留修復空間：當系統出現長期性問題時，可以在影響使用者前就提前處理。
- 增加架構彈性：讓團隊能安心做重構或成本優化，而不用擔心馬上衝擊使用者體驗。
2. 避免過度達成（Don’t Overachieve）
以基礎設施服務 （內部服務）為例，使用者依賴的其實是你「實際提供的效能」，而不只是你承諾的數字。
如果長期超額達成，使用者就會漸漸把「超額表現」當成理所當然，進而設計出依賴這種效能的系統。
避免這種情況，可以透過：
- 計畫性停機：Google 的 Chubby 服務因為太可靠，導致下游系統過度依賴，最後只好刻意安排停機，迫使其他團隊正視「它可能會故障」，為 Chubby 的不可用性做好準備。
- 限流策略：在負載較低時，透過刻意限制吞吐量，避免讓外部認為「系統無限快」。
我的 TAKEAWAY
- SLO 的制定應該由從使用者的角度出發： 不要從「我能測量什麼」開始，如後續導入了，反而浪費維運成本在不重要的指標上。
- SLO 的制定，就算是同一個服務，面對不同的客戶端，不同的使用需求，應當設定不同的 SLO 標準，而非設置一個萬用型的，造成低效的無用指標，或是花費高額營運成本才能達成的高額指標。
- SLI 必須定義清晰，避免溝通上的誤差。
- 最後一段關於 “Don’t Overachieve” 的做法聽起來有點反直覺，還在意會是否有需要因爲避免使用者有過度期待而直接停機並花完 error budget。
- Google 將可靠性提升到與產品功能同等重要的地位，並有高層支持。這需要公司領導層對可靠性有深刻理解與承諾，否則「錯誤預算耗盡就停止新功能開發」的決策將難以推動。
Extended Reference ＆ FYI
This Content is Authored by the writer, with AI-assisted proofreading and SEO optimization.
