還是先來復習下上節課講的“系統可用性”的兩種計算方式，一種是從故障角度出發，以時長維度對系統進行穩定性評估；另一種是從成功請求占比角度出發，以請求維度對系統進行穩定性評估。同時，我們還講到，在 SRE 實踐中，通常會選擇第二種，也就是根據成功請求的比例來衡量穩定性：

• Availability = Successful request / Total request

SRE? 強調的穩定性，一般不是看單次請求的成功與否，而是看整體情況，所以我們會把成功請求的占比設定為一個可以接受的目標，也就是我們常說的“3 個 9”或“4 個 9”這樣的可量化的數字。

那么，這個“確定成功請求條件，設定達成占比目標”的過程，在 SRE 中就是設定穩定性衡量標準的 SLI 和 SLO 的過程。

具體來看下這兩個概念。SLI，Service Level Indicator，服務等級指標，其實就是我們選擇哪些指標來衡量我們的穩定性。而 SLO，Service Level Objective，服務等級目標，指的就是我們設定的穩定性目標，比如“幾個 9”這樣的目標。

SLI 和 SLO 這兩個概念你一定要牢牢記住，接下來我們會反復講到它們，因為落地 SRE 的第一步其實就是“選擇合適的 SLI，設定對應的 SLO”。

好，那我們就正式開始今天的內容。我會帶你徹底理解 SLI 和 SLO 這兩個概念，并掌握識別 SLI、設定 SLO 的具體方法。

SLI 和 SLO 到底是啥？

SLI 和 SLO 這兩個概念比較有意思，看字面意思好像就已經很明白了，但是呢，仔細一想，你會發現它們很抽象。SLI 和 SLO 指的到底是啥呢？

接下來我給你講一個具體的例子，講完后，你肯定就能理解了。

我們以電商交易系統中的一個核心應用“購物車”為例，給它取名叫做 trade_cart。trade_cart 是以請求維度來衡量穩定性的，也就是說單次請求如果返回的是非 5xx 的狀態碼，我們認為該次請求是成功的；如果返回的是 5xx 狀態碼，如我們常見的 502 或 503， 我們就判斷這次請求是失敗的。

但是，這個狀態碼只能標識單次請求的場景。我們之前講過，單次的異常與否并不能代表這個應用是否穩定，所以，我們就要看在一個周期內，所有調用次數的成功率是多少，以此來確定它是否穩定。比如我們給這個“狀態碼返回為非? 5xx? 的比例”設定一個目標，如果大于等于 99.95%，我們就認為這個應用是穩定的。

在 SRE 實踐中，我們用 SLI 和 SLO 來描述。“狀態碼為非 5xx 的比例”就是 SLI，“大于等于 99.95%”就是 SLO。說得更直接一點，SLO 是 SLI 要達成的目標。

通過這個例子，你現在是不是已經理解了這兩個概念呢。SLI 就是我們要監控的指標，SLO 就是這個指標對應的目標。

好，那接下來我們要解決的問題就很具體了。我們應該選擇哪些指標來監控系統的穩定性？ 指標選好后，對應地怎么定它的目標呢？下面咱們就一一來探索。

系統運行狀態指標那么多，哪些適合 SLI？

我們先來討論怎么選擇 SLI。要回答怎么選擇這個問題，我們得先來看看都有哪些可供選擇的指標。

在下面這張圖中，我列舉了系統中常見的監控指標。

第一個問題：我要衡量誰的穩定性？ 也就是先找到穩定性的主體。主體確定后，我們繼續問第二問題：這個指標能夠標識這個實例是否穩定嗎？ 一般來說，這兩個問題解決了，SLI 指標也就確認了。這些指標是不是都很熟悉？那該怎么選呢？好像每一個指標都很重要啊！ 確實，這些指標都很重要。我們可以通過問自己兩個問題來選擇。

從我的經驗來看，給指標分層非常關鍵。就像上圖那樣分層后，再看穩定性主體是屬于哪一層的，就可以在這一層里選擇適合的指標。但是，你要注意，即便都是應用層的，針對具體的主體，這一層的指標也不是每一個都適合。

根據這幾年的實踐經驗，我總結了選擇 SLI 指標的兩大原則。

• 原則一：選擇能夠標識一個主體是否穩定的指標，如果不是這個主體本身的指標，或者不能標識主體穩定性的，就要排除在外。
• 原則二：針對電商這類有用戶界面的業務系統，優先選擇與用戶體驗強相關或用戶可以明顯感知的指標。

還拿我們上面 trade_cart 的例子來說，主體確定了，就是 trade_cart，應用層面的，請求返回狀態碼和時延就是很好的指標，再來檢查下它們能否標識的 trade_cart 穩定性，毫無疑問，這兩個指標都可以，那么請求返回狀態碼和時延就可以作為 trade_cart 穩定性的SLI 指標。

我們換一個指標，CPU 的使用率這個指標適合嗎？根據我們剛才說的原則，既然我們關注的是 trade_cart 的運行狀況，而 CPU 是系統層的指標，所以，在選擇應用層 SLI 的指標時，自然會把 CPU 排除掉。

你可能會說，這樣是不是太武斷了呀？

我們簡單來分析下。假設 CPU 使用率達到了 95%，但是只要 CPU 處理能力足夠，狀態碼成功率可能還是保持在 4 個 9，時延還是在 80ms 以內，用戶體驗沒有受到影響。另外一種情況，假設 CPU 使用率只有 10%，但是可能因為網絡超時或中斷，導致大量的請求失敗，甚至是時延飆升，購物車這個應用的運行狀態也不一定是正常的。所以結論就是，? CPU 使用率不管是 10% 還是 95%，都不能直接反映 trade_cart 運行是正常還是異常，不適合作為 trade_cart 這樣的應用運行穩定性的 SLI 指標。

講到這里，你可能會問，哎呀，你說的這兩個原則我理解了，分層也大概能做到，但是我還是需要做很多詳細的分析才能選擇出 SLI 指標，有沒有什么更便捷、更快速的方法來幫助我選擇啊？

嗯，不要著急，還真有這樣一套方法。怎么選 SLI，我們可以直接借鑒 Google 的方法： VALET。

快速識別 SLI 指標的方法：VALET

VALET? 是? 5? 個單詞的首字母，分別是? Volume、Availability、Latency、Error? 和Ticket。這 5 個單詞就是我們選擇 SLI 指標的 5 個維度。我們還是結合 trade_cart 這個例子，一起看一下每個維度具體是什么。

Volume- 容量

Volume(容量)是指服務承諾的最大容量是多少。比如，一個應用集群的 QPS、TPS、會話數以及連接數等等，如果我們對日常設定一個目標，就是日常的容量 SLO，對雙 11 這樣的大促設定一個目標，就是大促?? SLO。對于數據平臺，我們要看它的吞吐能力，比如每小時能處理的記錄數或任務數。

Availablity- 可用性

Availablity(可用性)代表服務是否正常。比如，我們前面介紹到的請求調用的非? 5xx? 狀態碼成功率，就可以歸于可用性。對于數據平臺，我們就看任務的執行成功情況，這個也可以根據不同的任務執行狀態碼來歸類。

Latency- 時延

Latency(時延)是說響應是否足夠快。這是一個會直接影響用戶訪問體驗的指標。對于任務類的作業，我們會看每個任務是否在規定時間內完成了。

講到這里，我要延伸下，因為通常對于時延這個指標，我們不會直接做所有請求時延的平 均，因為整個時延的分布也符合正態分布，所以通常會以類似“90% 請求的時延 <= 80ms，或者 95% 請求的時延 <=120ms ”這樣的方式來設定時延 SLO，熟悉數理統計的同學應該知道，這個 90% 或 95% 我們稱之為置信區間。

因為不排除很多請求從業務邏輯層面是不成功的，這時業務邏輯的處理時長就會非常短(可能 10ms)，或者出現 404 這樣的狀態碼(可能就 1ms)。從可用性來講，這些請求也算成功，但是這樣的請求會拉低整個均值。

同時，也會出現另一種極端情況，就是某幾次請求因為各種原因，導致時延高了，到了500ms，但是因為次數所占比例較低，數據被平均掉了，單純從平均值來看是沒有異常的。但是從實際情況看，有少部分用戶的體驗其實已經非常糟糕了。所以，為了識別出這種情況，我們就要設定不同的置信區間來找出這樣的用戶占比，有針對性地解決。

Errors- 錯誤率

錯誤率有多少？這里除了 5xx 之外，我們還可以把 4xx 列進來，因為前面我們的服務可用性不錯，但是從業務和體驗角度，4xx 太多，用戶也是不能接受的。或者可以增加一些自定義的狀態碼，看哪些狀態是對業務有損的，比如某些熱門商品總是缺貨，用戶登錄驗證碼總是輸入錯誤，這些雖不是系統錯誤，但從業務角度來看，對用戶的體驗影響還是比較大的。

Tickets- 人工介入

是否需要人工介入？如果一項工作或任務需要人工介入，那說明一定是低效或有問題的。舉一個我們常見的場景，數據任務跑失敗了，但是無法自動恢復，這時就要人工介入恢復；或者超時了，也需要人工介入，來中斷任務、重啟拉起來跑等等。

Tickets 的 SLO 可以想象成它的中文含義：門票。一個周期內，門票數量是固定的，比如每月 20 張，每次人工介入，就消耗一張，如果消耗完了，還需要人工介入，那就是不達標了。

這里我給出一個 Google 提供的，針對類似于我們 trade_cart 的一個應用服務，基于VALET 設計出來的 SLO 的 Dashboard 樣例，結合上面我們介紹的部分，就一目了然了。

VALET示例圖

好，VALET 我們就講完了，怎么選 SLI 指標，你是不是一下子就清楚了。可以說，這是一個我們可以直接復用的工具。上面 Google 的這張 SLO 樣例圖，建議你多看幾遍，看到時候，對比思考下自己系統的情況。

如何通過 SLO 計算可用性？

到這里，我們已經能夠根據自己想要保障穩定性的主體，來選擇合適的 SLI 指標了，也知道SLO 就是對應 SLI 要實現的目標，比如“幾個 9”。

但是，我們前面講到了系統可用性：

• Availability = Successful request / Total request

然后又深入到了提煉具體的 SLI，以及設定對應的 SLO，那這兩者之間是什么關系呢？也就是通過 SLO 應該怎么去計算我們的系統可用性的呢？這就涉及到系統整體可用性的兩種計算方式。

第一種，直接根據成功的定義來計算。

也就是我們前面定義一個請求的返回狀態碼必須是非 5xx 才算成功，同時時延還要低于80ms，同時滿足這兩個條件，我們才算是成功的，也就是納入上述公式中 Successful request 的統計中，用公式來表示：

• Successful = (狀態碼非 5xx) & (時延 <= 80ms)

如果還有其它條件，直接在后面增加做綜合判定。

但是，這種計算方式存在的問題就是，對單次請求的成功與否的判定太過死板，容易錯殺誤判。比如我們前面講對于時延，我們一般會設定置信區間，比如? 90%? 時延小于等于200ms? 這樣的場景，用這種方式就很難體現出來。而且，對于狀態碼成功率和時延成功率的容忍度，通常也是也不一樣的，通過這種方式就不夠準確。所以，我們就會采取第二種方式。

第二種方式，SLO 方式計算

我們前面講時延時講過以下幾個 SLO，這時我們設定穩定性的時候，就需要把公式計算方式靈活調整定義一下了。

• SLO1：99.95%?? 狀態碼成功率
• SLO2：90% Latency <= 80ms?????????
• SLO3：99% Latency <= 200ms

直接用公式表示：

• Availability = SLO1 & SLO2 & SLO3

只有當這個三個? SLO? 同時達標時，整個系統的穩定性才算達標，有一個不達標就不算達標，這樣就可以很好地將 SLO 設定的合理性與最終可用性結合了起來。所以，通常在 SRE 實踐中，我們通常會采用這種設定方式。

如果是這樣，第一種方式是不是就沒有用途了呢？當然不是。第一種計算方式也會有它特有的應用場景，它通常會被利用在第三方提供的服務承諾中，也就是 SLA( Service Level greement)。因為對于第三方提供商來說，比如云廠商，它們要面對的客戶群體是非常大的，所以很難跟每一家客戶都去制定像 SLO 這么細粒度穩定性目標，而且每家客戶對穩定性的要求和感知也不同，就沒法統一。

這種情況下，反而是第一種計算方式是相對簡單直接的，但是這樣也決定了 SLA 的承諾相比 SLO 肯定也相對比較寬松，因為 SLA 是商業服務承諾，如果達不成是要進行賠償的。關于?? SLA，最直接的參考資料，就是各個公有云廠商在官網公開的信息資料，你可以找到這些資料，作為自己的一個補充學習。

總結

講到這里，怎么選擇 SLI 指標、如何制定 SLO 目標，我們就介紹完了。你需要掌握下面三個重點。

1. 對系統相關指標要分層，識別出我們要保障穩定性的主體(系統、業務或應用)是什么，然后基于這個主體來選擇合適的 SLI 指標。

2. 不是所有的指標都是適合做 SLI 指標，它一定要能夠直接體現和反映主體的穩定性狀態。可以優先選擇用戶或使用者能感受到的體驗類指標，比如時延、可用性、錯誤率等。

3. 掌握 VALET 方法，快速選擇 SLI 指標。

思考題

最后，給你留一個思考題。

下面我給出一個 Google 的 SLI 和 SLO 設定標準示例，內容很直觀，需要你認真研究一下這個文檔，結合今天我們所講的內容，請你嘗試按照 Google 提供的規范格式，制定一個自己所負責系統的 SLO。

Google 的 SLI 和 SLO 設定模板鏈接：

https://landing.google.com/sre/workbook/chapters/slo-document

總結

以上是生活随笔為你收集整理的03 | SRE切入点：选择SLI，设定SLO的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。