背景

又到一年的11.11大促日，最近很多團隊郵件上下游確認SLA，你是不是還沒搞明白服務質量SLA、SLO等概念？本文通過理論知識以及基于SLO告警治理的實踐經驗分享。詳細介紹如何設置SLO、有效的告警泛濫治理、以及如何根據SLO的指標來優化服務性能和可靠性。

問題（1）

首次接觸到了SLA（服務等級協議）的概念，其中承諾的響應時間是200毫秒。而服務接口的TP99（即99%的請求完成時間）超過了100毫秒，上游的超時配置卻是2000毫秒。這之間存在何種聯系呢？我感到有些困惑。后來在工作中逐步搞清楚了SLA的概念。

問題（2）

年初還有一個疑問一直困擾著我。例如，我負責的系統中的一個API接口的可用率是99.99%，那么在部門中，包含了N個系統和M個接口，部門的季度可用率是99.98%，這個數字又是如何計算出來的呢？統計的規則又是什么？我請教了XXX同學，給我解惑答疑，非常感謝！

問題（3）

比如我在XXX云購買了100臺云主機，在10:00-10:05這5分鐘內，有10臺機器出現故障，導致API的對外可用率只有90%（在這5分鐘內，總請求數為1萬，失敗的請求數為1000）。如果一個月30天，每天發生一次這樣的5分鐘，那么這可用率到底是多少呢？

帶著以上的這些問題，研究了服務質量的指標：SLI（服務水平指標）、SLO（服務水平目標）和SLA（服務等級協議）。如果你也對上面的問題感興趣，并且想找到答案，歡迎閱讀本文，以下是我的研究成果，供大家參考，如果有不對的地方，還請大家指正。

一、服務質量術語

如果你不了解你負責的系統內部的各種行為的重要程度，并且無法度量這些行為是否正確的話，就無法正確的去運維系統，更不用說穩定可靠的運維了。不管是對外服務還是內部API，都需要制定一個針對用戶的服務質量目標，并且努力去達到這個目標。

在這個過程中，我們需要根據歷史經驗，主觀判斷以及對服務的理解來定義一些 服務質量指標（SLI）,服務質量目標（SLO)，服務質量協議（SLA）以及這些指標的預期值和應對計劃。

1）服務質量指標SLI（Service Level Indicator）

定義：該服務的某項服務質量的一個具體量化指標

常見的SLI包括：

• 可用率（成功響應的請求比例）
• 請求延遲的99%（TP99請求處理耗時）
• 吞吐量（每秒請求量）
• 持久性（數據能夠保存的完整時間，常用于數據存儲系統）

2）服務質量目標SLO（Service Level Objective）

定義：服務的某個SLI的目標值或者目標范圍。

SLO的定義是SLI《目標值，或者 范圍下限《SLI《范圍上限。

設置服務水平目標（SLO）的好處主要體現在以下幾個方面：

1.對于客戶端而言，SLO提供了一種可預期的服務質量，這使得客戶端的系統設計可以更加簡單和穩定。客戶可以根據SLO來規劃和調整自己的業務流程，減少不確定性帶來的影響。

2.對于服務提供者而言，SLO帶來的好處包括：

• 可預期的服務質量：SLO可以幫助服務提供者明確服務質量的標準和目標，從而更好地管理和優化服務。
• 更好的成本/收益取舍：通過設定合理的SLO，服務提供者可以在資源投入和服務質量之間找到一個平衡點，實現更有效的資源利用和成本控制。
• 更好的風險控制：當資源受限或出現故障時，SLO可以幫助服務提供者更好地控制風險，避免服務質量下降對業務造成的影響。
• 故障時更快的反應和采取正確措施：SLO可以作為一個參考標準，幫助服務提供者在故障發生時更快地發現問題并采取正確的措施，減少故障恢復時間。

選擇一個合適的SLO是非常復雜的過程，難點是可能無法確定一個具體的值。比如對外API，每秒查詢數量QPS指標由用戶決定的，我們并不能針對這個指標設置一個SLO。但是我們可以指定請求TP99時間小于20ms.確定這個目標可以鼓勵開發者優化代碼性能.

3）服務質量協議SLA（Service Level Agreement）

定義：指服務和用戶之間的一個明確的，或者不明確的協議。描述了在達到或者沒有達到SLO之后的后果。這些后果可以是財務的（賠償）或者其他的。

區別SLO和SLA的一個簡單方法是問：“如果SLO沒有達到時，有什么后果？”，如果沒有定義明確的后果。那么我們肯定是在討論一個SLO，而不是SLA。

Google搜索服務是沒有公開SLA的一個典型服務。

4）云服務級別協議CSLA（Cloud Service Level Agreement）

詳見第三章節

圖片

二、SLO實踐案例

我們可以SLO實踐案例來指導我們的穩定性建設。

1）服務分級&核心接口分級

分級規則

• 根據業務影響，應用分為0-3級
• 應用里面的接口再次細分0/1級，因為很多歷史原因，很多0/1級系統內部N個接口，但M個接口是非核心的。或者2級應用里面有N個0級接口。關注核心接口的健壯性（是否可用率治理完成，是否可降級，是否配置合理的限流值）

分級用途

?基于服務等級，要求核心服務遵守對應標準（比如代碼評審，上線發布，變更流程，大促管控）。

?報警基于服務等級來做分級

?不同等級穩定性要求SLO不一樣，如具備熔斷降級能力等。

注意事項

• 全鏈路應用定級不統一：比如整個鏈路既有0級應用，也有1級別應用，還會存在很多3級應用

解決方案：推動下游更新應用等級

如下圖，通過工具掃描0/1級依賴的下游等級應用是3級，

• 接口定級不統一：比如某個歷史接口，A部門從自身角度出發認為接口不重要，但上游，上游強依賴，有時候出現線上故障后才知道該接口的重要性

解決方案：需要鏈路追蹤，從用戶視角（用戶購物、物流一線操作業務）看影響，但這個有時候挺難的，尤其是歷史接口，鏈路太長

3、接口可用率不準確：比如內部異常被catch吃掉了，沒有反應到接口最外層，比如服務故障了半個小時，但ump可用率還是100%

解決方案：進行代碼可用率治理，讓API可用率是真實的。

2）SLI實踐應用

選擇能代表業務核心功能的API，按上面的業務分級模型對這些API定級，一般只度量L0、L1等級的業務和其接口。那么應該定義哪些指標？為什么定義這些指標？這些指標是服務最重要嗎？

比如UMP打點監控指標有：

1）方法性能：TP50,TP90,TP99,TP999,TP9999,MIN,MAX,AVG

2）方法可用率

3）方法調用次數

這些監控指標我們都需要作為SLI嗎？答案肯定不是。只有理解用戶對系統的真實需求才能真正決定哪些指標是否有用。指標太多會影響重要的指標，指標太少又會導致重要的行為被忽略。一般來說，3-5個具有代表性的指標對系統健康度的評估和關注足夠了。

根據常見的服務SLI分為如下幾類

圖片

3）SLO實踐應用

我們應該從用戶最關心的方面入手，而不是目前可以監控度量什么著手（當然目前UMP監控度量的維度已經很多，部分指標可作為SLI）。制定適當的SLO的第一步是討論SLO應該是什么以及應該涵蓋什么。SLO為服務的客戶設置了目標可靠性級別。

為了更清晰的定義，SLO應該具體支持他們是如何被度量的，以及其有效條件。例如：99%（在1分鐘時間范圍內的請求匯總）的JSF-API調用會在200ms內完成（包括全部后端服務器）

圖片

選擇目標SLO策略建議

1.不要追求完美：不要以當前的運行狀態為基礎選擇目標，而應該從全局觸發，剛開始可以制定一個寬松的目標（前提滿足用戶），逐步收緊。比如目前API的TP99是8ms，對外SLO的TP99是10ms,如果后期接口內部邏輯改造,需求變更等導致API的tp99是20ms，則不滿足SLO。

2.留出一定的安全區：對內使用更高的SLO，對外使用稍低的SLO。這樣可以留出一些空間來響應需求等。緩沖區buffer可以保護我們不會對用戶產生直接影響。

您第一次嘗試SLI和SLO不一定正確。最重要的目標是進行適當的測量并建立反饋環路，以便您進行改進。隨著SLA的變更，系統架構不斷的迭代演變（比如之前SLA的TP99是1000ms，你采用mysql架構存儲數據，后面變成面向20ms，這時候的mysql架構就不適合了，需要演變為比如redis緩存等形式）

4）SLA實踐應用

研發需要和業務產品同事綜合考慮，目前內部通過郵件達成協議。外部云廠商則通過合同達成協議（保護未達到SLO的補償條款）

三、云服務協議(可跳過)

對本章節內容不感興趣的，可跳過

1）國家標準：信息技術 云計算 云服務級別協議基本要求

圖片

2）京東云主機服務等級協議（SLA）

圖片

3）阿里云服務器 ECS服務等級協議

圖片

4）AWS&Google云產品服務協議

圖片

圖片

四、API 網關服務等級協議

下面分別介紹不同廠商的API網關服務的可用率定義

1）京東云API 網關服務等級協議（SLA）

圖片

2）阿里云API 網關服務等級協議（SLA）

圖片

3）亞馬遜云API網關服務SLA

圖片

五、基于SLO告警治理實踐

SLO是可靠性決策的關鍵因素。應用每天都有無數的報警通知，如CPU、內存、磁盤、可用率、MAX，tp99，tp999等，產生了大量噪音。但哪些報警會影響到可用性，需要SRE和研發關注呢？這就是SLO的核心價值之一了。

告警設定的目標：根據SLO對重要的事件做出可操作性的告警。

告警設定的依據：基于服務質量指標（SLI）和錯誤預算，對每一個消耗大量錯誤預算的事件發出重大事件的告警通知。

參考上面設定的SLO配置的報警信息如下：

1）API告警配置

我們可以通過設置合理的閾值和規則，過濾掉那些不必要的告警信息，從而避免告警噪音對開發運維團隊的干擾，讓他們更加專注于真正的問題。

?通過UMP實現3個黃金監控指標（可用率、調用量、TP99）

在配置報警機制時，我們可以綜合考慮可用率、TP99以及調用量等因素來進行評估。通過這些指標的綜合評估，可以幫助我們更全面地了解系統運行情況，從而及時發現潛在的問題并采取相應的措施。

建議在進行報警配置時，可先采取較為嚴格的策略，即先緊后松，逐步調整到最佳狀態。這樣可以確保在最開始階段就能夠及時發現問題，避免出現重大故障。但隨著系統的逐漸穩定，我們也可以根據實際情況適當放寬報警閾值，以提高系統的可用性和效率。

需要注意的是，在進行報警配置時，我們需要結合具體的業務場景和系統特點來進行調整和優化。不同的系統可能存在不同的風險點和瓶頸，因此我們需要根據實際情況來制定相應的報警策略，以保證系統的穩定性和可靠性。

比如SLO：分鐘級TP99是200ms，但你日常TP99在80ms，根據日常接口的行為，電話critical報警一定得配置<=200ms，warning可配100ms或者150ms等不斷調整到最佳狀態

critical告警方式：咚咚、郵件、即時消息(京ME)、語音 可用率：（分鐘級）可用率 < 99.95% 連續 3 次超過閾值則報警，且在 3 分鐘內報一次警。性能：（分鐘級）TP99 >= 200.0ms 連續 3 次超過閾值則報警，且在 3 分鐘內只報一次警。

warning告警方式：咚咚、郵件、即時消息 可用率：（分鐘級）可用率 < 99.99% 連續 3 次超過閾值則報警，且在 30 分鐘內報一次警。性能：（分鐘級）TP99 >= 100.ms 連續 3 次超過閾值則報警，且在 30 分鐘內只報一次警。調用次數：當方法調用次數在 1 分鐘的總和，連續 3 次大于 2000000 則報警，且在 3 分鐘內只報一次警

備注：語音critical告警配置調用次數一般意義不大，因為如果你接口的可用率沒問題，并且你的TP99也在預期內，按調用次數高又有什么關系呢。但warning配置調用次數有一個好處，比如你配置了JSF限流，目前JSF限流是觸發了會報警，你可以在UMP或者Pfinder增加調用次數的閾值報警，比如設置為限流值的80%開始報警，這樣可提前發現限流導致的風險點。同時通過調用次數也可知曉流量增長趨勢

2）MQ告警配置

需要根據MQ延遲（數據從生產到消費需要多少時間）配置對應告警和應急預案

圖片

?生產者T(1)監控：生產者到MQ的時間監控

?消費者T(2.1)監控：通過MQ的積壓報警配置進行監控。

?消費者T(2.2)處理邏輯監控：配置處理邏輯的UMP報警。

正常場景：T(3) > T(1) + T(2.1) + T(2.2)   其中T(3)包含讀最終數據的耗時

積壓報警的配置需要結合上述耗時公式，并且經過壓力測試來確定。

假設在積壓20,000消息的情況下，現有服務能力能夠在N毫秒內處理完成，并且滿足[ T(3) > T(1) + T(2.1) + T(2.2) ]的條件。那么，報警閾值可以設置為積壓20,000消息以下，例如10,000 warning，15000 critical報警以預留處理時間。

例如，若[ T(3) = 2000ms ]，日常[ T(1) ]的最大值為20ms，在積壓20,000消息的情況下[ T(2.1) = 980ms ]，[ T(2.2) = 1000ms ]。

3）定時任務告警配置

由于定時任務跟常規的JSF-API接口或者MQ不一樣，定時任務是在規則約定的時間內執行，如果UMP是定時任務，最重要的一點就是確定好監控時段。只有正確地配置了監控時段，才能確保UMP在預計時間段內正常執行，這樣一旦UMP未能在預計時間段內執行，就會自動觸發報警機制，及時發現并解決問題。

比如xxx是每天的1點執行

我需要監控1點是否執行了

圖片

六、問題解答

通過閱讀本文，相信你已經知道如何解答文章開始的3個問題了

1）SLA、TP99、超時時間的關系？

1.TP99沒什么好說的，看接口的UMP打點即可，比如這圖接口的TP99是10-15ms。

圖片

• 由于上游是下單前黃金鏈路，對性能要求較高。SLA（其實是SLO)我們對外承諾的TP99(分鐘）是20ms，預留6ms的buffer
• 超時時間設置：超時時間可以設置在TP99（業務要求高的參考TP999、TP9999、MAX）（包含網絡延遲）的基礎上加上一定的緩沖時間。其中緩沖時間需要根據經驗或監控數據等日常行為統計學，增加一個安全緩沖時間。例如，如果下游接口的TP99是200ms，您可能將超時時間設置為300ms到400ms。
• 重試次數設置：

?下游接口必須支持冪等，方可重試

?重試策略：根據業務場景和下游接口的穩定性來決定重試次數。一般來說，重試次數不宜過多（1-3次），以避免加重系統負擔，同時要考慮重試后是否會不滿足你對外的SLA指標，尤其下游出現超時嚴重的時候。

?指數退避：使用指數退避策略，每次重試的間隔時間逐漸增加（例如，第一次等待1ms，第二次等待2ms，第三次等待4ms）。

4.實施和監控：監控實際的重試情況和超時情況，定期評估重試和超時策略對系統性能的影響。調整策略以適應實際情況。

請注意，設置超時時間和重試次數是一個需要平衡多個因素的決策過程。它需要考慮系統的穩定性、響應時間、資源使用和用戶體驗等多個方面。此外，任何重試策略都應該避免可能導致級聯故障或資源耗盡的情況。

2）團隊系統可用率是怎么計算的？

問題2：系統中的一個API接口的可用率是99.99%，那么在部門中，包含了N個系統和M個接口，部門的季度可用率是99.98%，這個數字又是如何計算出來的呢？

如A系統為黃金流程生產系統，因系統出現服務故障，導致生產業務無法操作，故障時長為A，影響業務占比率為B，則最終可用率故障時長為 C=A*B；

可參考問題3的計算公式

比如黃金鏈路故障時長150分鐘，影響業務占比10%，折合系統不可用時長=15分鐘。

則月度系統可用率=1-（故障總時長/統計周期總時長）*100%=1-（15/30*24*60)=99.96%

3）云主機&網關API可用率

問題3：比如在XXX云購買了100臺云主機（按照云主機SLA），其中在10:00-10:05這5分鐘，有10臺機器有故障，導致API對外可用率是90%（5分鐘之內總請求數1W，失敗請求數1000）。一個月30天每天發生類似的5分鐘1次。請問對用戶來說可用率是多少？

從2個維度來解答

• 從提供基礎服務的云服務等級協議來解答（這個不同云廠商基本是一致的）。
• 從面向用戶的API角度來解答 （不同廠商定義公式不一樣）

任何產品都不是，也不應該做到100%可靠，因為對用戶來說99.999%和100%的可用性大部分沒有本質的區別。那多少合適呢？可靠性目標需要考慮的因素：

• 服務可靠性要達到什么程度，用戶才會滿意？
• 如果可靠性不夠，是否有其他替代選擇？
• 服務的可靠程度是否會影響用戶對服務的使用模式？
• 是否直接關系到收入？
• 服務是針對消費者還是企業？

七、技術指標&業務指標

正如上面說的SLA定義了服務可用性、性能等技術指標。那么業務指標到底要解決什么問題？解決技術指標（可用率，tp99）看不到的問題。關注的是數據的正確性和完整性。

SLA的技術指標和業務監控的數據正確性通常是相互關聯的。技術指標不可用，則肯定業務指標會不可用。相反如果業務指標不可用有異常，不一定技術指標不可用。例如，如果一個系統的可用性低于SLA中定義的閾值，那么這可能會影響到業務流程的正常運行，從而導致數據錯誤或丟失。因此，為了確保業務連續性和數據準確性，SLA和業務監控通常需要共同考慮和管理。

八、「以終為始」SLA指導11.11大促備戰

SLA可以作為一個強有力的工具，指導11.11大促的備戰工作,明細如下：

1.明確服務目標：上下游明確SLA（服務性能TP99、可用性、峰值QPS）等方面的承諾。這些目標應該與11大促的業務需求相匹配，例如峰值流量下的系統穩定性和快速響應能力。

2.制定備戰計劃：根據SLA的要求，制定詳細的備戰計劃，包括資源配置、系統優化、災難如何快速恢復等。例如，如果SLA要求系統在高峰期的可用性達到99.99%，那么備戰計劃就需要考慮如何實現這一目標，你的容錯方案、降級方案、應急預案等。

3.軍演全鏈路壓測和容量規劃：為了確保在大促期間滿足SLA的要求，需要進行性能壓測&軍演全鏈路壓力測試和容量規劃。通過壓測高流量場景，驗證系統的性能和穩定性，并根據測試結果調整資源配置和系統優化策略。

4.監控和警報系統：建立一個全面的監控和警報系統，實時跟蹤服務的性能和健康狀況。如果某個指標超出了SLA的閾值，系統應該自動觸發警報，通知相關團隊采取行動。

5.優先級管理：在大促期間，根據SLA的重要性和影響范圍，設定問題的優先級，確保最關鍵的服務得到優先處理。

6.團隊協作和溝通：SLA要求各個團隊之間的緊密協作和高效溝通。建立跨部門的協作機制，明確每個團隊的職責和SLA目標，確保所有團隊都朝著同一個目標努力。

7.持續改進：11.11大促結束后，回顧整個過程，分析SLA的達成情況，找出改進的空間。將這些經驗和教訓應用到下一年的備戰中，持續提升服務質量。

附:1）SLO文檔示例

服務概述

常見的有API，MQ消息

圖片

說明和警告

?請求指標是在負載均衡器上測量的。此度量可能無法準確度量用戶請求未到達負載均衡器的情況。

?我們僅將HTTP 5XX狀態或者約定的API Response里的Code錯誤編碼消息視為錯誤代碼；其他一切都算成功。

2）云服務級別指標

圖片