03 | SRE切入点:选择SLI,设定SLO
還是先來復習下上節課講的“系統可用性”的兩種計算方式,一種是從故障角度出發,以時長維度對系統進行穩定性評估;另一種是從成功請求占比角度出發,以請求維度對系統進行穩定性評估。同時,我們還講到,在 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的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 02 | 系统可用性:没有故障,系统就一
- 下一篇: heima-Oracle学习-day1