建站
咨詢
售后
建站咨詢
新聞中心
一、背景
最近幾年，Google SRE在國內非常流行。Google SRE方法論中提出了SLO是SRE實踐的核心，SLO為服務可靠性設定了一個目標級別，它是可靠性決策的關鍵因素。那如何選擇和計算SLI，如何設置SLO，如何實踐落地呢？本文就來講講B站SRE在實踐SLO時所走的彎路和總結的經(jīng)驗。
二、Google SRE中SLO的定義
服務水平目標（SLO）指定了服務可靠性的目標水平。由于SLO是做出以數(shù)據(jù)為依據(jù)的可靠性決策的關鍵，因此它們是SRE實踐的核心。
上文是Google SRE《站點可靠性手冊》中的原文。那為什么需要SLO呢，我們摘取原文中的核心觀點：
工程師稀缺，需要把時間投入到重要服務的核心問題上
- SLO是做出工作優(yōu)先級排序和可靠性相關工作的關鍵
- SRE的核心職責不僅是自動化和處理故障，日常工作都要按照SLO來開展
- 沒有SLO，就沒有SRE
為了采用基于錯誤預算的可靠性工程方法，同樣摘取原文中的核心觀點：
- 服務的利益相關方認可此SLO
- 服務正常狀態(tài)下可以達到SLO的要求
- 組織認可錯誤預算并在決策中發(fā)揮作用
- 有完善的SLO流程
否則，SLO合規(guī)性成為一個KPI或報告指標，而不是決策制定工具。請記住這句話，因為我們的彎路就走到這里了。
三、Google SRE中SLO的實施
在《站點可靠性手冊》第二章“實施SLO”中，Google詳細講述了如何實施SLO，大致流程如下：
1）SLI選擇
- 對于請求驅動型服務，SLI一般選擇可用性（成功響應的請求比例）、延遲、質量。
2）SLI計算
- SLI的計算可以使用應用服務器日志、負載均衡監(jiān)控、黑盒監(jiān)控、客戶端插件等數(shù)據(jù)源。
- 一般選擇負載均衡監(jiān)控，因為其代表一個用戶請求在整套系統(tǒng)所有模塊處理耗時和所有網(wǎng)絡傳輸耗時的總和，且和客戶端插件相比，實施成本較低。
3）SLO定義
- 基于計算出來的可用性、延遲數(shù)據(jù)，來定義合適的服務SLO。
- 服務可用性：例如，全年可用性 > = 99.99%。
- 服務延遲：例如，99%的請求<= 200ms，90的請求< 100ms。
- 可以在不同的時間窗口上定義SLO，比如一個月或一個季度。
- 獲得關鍵的利益相關者認可和批準。
4）錯誤預算
- 有了SLI和SLO，時間窗口內的允許失敗數(shù)就知道了。
- 如果給定時間內錯誤預算消耗殆盡，要制定錯誤預算執(zhí)行策略，如：開發(fā)團隊專注于可靠性問題，直到系統(tǒng)處于SLO范圍內，功能迭代推遲；為了降低風險，凍結生產系統(tǒng)的變更，直到有了錯誤預算來支持變更。
5）記錄SLO和錯誤預算
- SLO的作者，審核人，批準日期，下次審核日期，相關背景。
- 定義和變更有平臺、流程、制度、變更事件可回溯。
- SLO的細節(jié)：SLI實現(xiàn)、如何計算、如何使用錯誤預算。
- 錯誤預算的記錄跟上面信息類似。
6）儀表盤和報表
- 除了已發(fā)布的SLO和錯誤預算，還需要一個報表和儀表盤來做展示。
7）持續(xù)改進SLO，提高SLO質量
四、我們的SLO實踐
從上文Google對SLO的介紹中，我們抽象出了關鍵信息來指導我們的建設。
1、服務分級
1）應用：技術視角
- 一個應用對應一個appid，包括前端和后端應用。
- 編碼構建后，可獨立部署運行。
- 一個業(yè)務，會包含多個應用，一般具有相同的命名前綴或關鍵詞。
2）業(yè)務：產品視角
- 一組網(wǎng)站/APP產品相關功能的聚合。
- 相對獨立的業(yè)務模塊。
- 包含一組相關聯(lián)的應用。
3）等級分級
我們分為L0-L3四個級別：
- L0
公司級核心業(yè)務，一般是公司級基礎服務或公司核心業(yè)務場景，如APP推薦、視頻播放、支付平臺及強依賴業(yè)務等。
- L1
部門級核心業(yè)務，一般是L0業(yè)務體驗中依賴的主要業(yè)務、核心的二類業(yè)務，如視頻播放頁的一鍵三連功能、核心二類業(yè)務動態(tài)、搜索等。
- L2
用戶可直接使用的其他業(yè)務，如播單、分享、專欄、答題等。
- L3
其他后臺類業(yè)務或對用戶體驗無影響的業(yè)務。
4）分級對象
- 先對業(yè)務（產品）定級。
- 再對這個業(yè)務下的多個應用定級，根據(jù)應用所提供的產品功能和故障影響來定，應用等級不超過業(yè)務等級。
- 在對此業(yè)務中用戶所能觸達到的API定級，API等級不超過應用等級。
5）分級用途
- 基于服務等級，要求核心服務遵守對應技術標準。
- 對不同等級的服務，制定不同的變更流程。
- 報警基于服務等級來做分級。
- 要求服務滿足穩(wěn)定性要求，如具備熔斷降級能力，具備同城雙活能力等。
6）分級運營
- 其他基礎平臺展示分級數(shù)據(jù)，基于服務等級定運行策略。
- 基于分級后的技術標準、流程等反推定級準確率提升。
2、SLO系統(tǒng)
1）SLI選擇
對于在線業(yè)務來說，基本都是請求驅動的業(yè)務，所以選擇可用性、延遲、吞吐。
- 可用性：我們度量了兩個指標：錯誤量、請求成功率。
- 延遲：我們度量了p90和p99兩個分位的延遲數(shù)據(jù)。
- 吞吐：每天的請求總量和單位時間的請求速率。
可用性為什么不選擇可用時間來度量呢？如果選擇時間，一般的做法是在某個時間段內錯誤率大于多少，則認為這段時間內服務不可用。假如這段時間內某個服務錯誤率低于閾值但同時有大量用戶反饋不可用的話，我們不能掩耳盜鈴的認為這段時間服務是可用的。因為無法解決這個問題，所以我們選擇了請求成功率。
2）SLI模型
- 應用的API是業(yè)務功能的直接體現(xiàn)，通過度量API的SLI就能反映出業(yè)務某個功能的情況。
- 選擇能代表業(yè)務核心功能的API，按上面的業(yè)務分級模型對這些API定級，一般只度量L0、L1等級的業(yè)務和其接口。
- 業(yè)務一般都會提供多個功能，比如彈幕的讀寫，評論的讀寫，所以業(yè)務的SLI是由代表業(yè)務功能的多個API SLI數(shù)據(jù)聚合而成的。
- 對于API，我們度量可用性、延遲、吞吐。
- 對于業(yè)務，我們通過聚合API 的SLI，主要度量可用性。
3）SLI計算
- 統(tǒng)一標準，使用接入層負載均衡指標。所有面向用戶的公網(wǎng)服務都會經(jīng)過接入層負載均衡，也即SLB（下文統(tǒng)稱為SLB)。
- 內網(wǎng)服務東西向調用時通過服務發(fā)現(xiàn)直接調用，不過SLB，所以無法用SLB的指標度量。我們認為內網(wǎng)服務的故障最終能在面向用戶側的公網(wǎng)服務中體現(xiàn)出來，所以我們只對面向用戶的公網(wǎng)服務做度量。
- API可用性：每分鐘計算出API的錯誤量（HTTP 5XX請求）、總請求量、成功率、分位延遲請求量、吞吐。每天再聚合出一天的錯誤量、總請求量、成功率、分位延遲請求量、吞吐。有了每天的數(shù)據(jù)后，可靈活的聚合出API每個季度、半年、全年或某個時間區(qū)間的數(shù)據(jù)。
- 業(yè)務可用性：對于業(yè)務來說，我們只做錯誤量、成功率聚合。
（a）相同等級的API權重應該是一樣的，不同等級的API應該加權；
?（b）每分鐘計算出L0等級API的錯誤量之和、總請求量之和、總成功率（1 - (錯誤量之和 / 總請求量之和)）；
（c）每分鐘L1等級的API也聚合出相同的數(shù)據(jù)；
（d）每分鐘業(yè)務可用性 = （L0 API總成功率 * 權重 + L1 API總成功率 * 權重）/ 總權重；
（e）有了業(yè)務每分鐘的可用性后，再聚合出業(yè)務一天的可用性，以及靈活的聚合出每個季度、半年、全年或某個時間區(qū)間的數(shù)據(jù)。
4）SLO定義
- 只對可用性和延遲做SLO定義，吞吐做SLI儀表盤和報表即可；
- 在API分級時，我們會對API設置一個基于分級的默認SLO，比如L0 API 可用性>= 99.99%，L1 API可用性>= 99.99%，L0 API 99分位延遲<=200ms；
- 在業(yè)務分級時，我們會讓研發(fā)對業(yè)務設置一個可用性SLO目標，比如全年可用性>= 99.99%。
5）錯誤預算
- 我們在一開始嘗試SLO時，并沒有去重點建設錯誤預算。只是使用了基于服務分級的SLO錯誤量和可用性報警。
6）記錄SLO和錯誤預算
我們提供了平臺化能力去支持定義SLO時的審核和記錄。
7）儀表盤和報表
- API儀表盤與報表
- 業(yè)務儀表盤與報表
上面一套SLO體系建設完成以后，我們對L0、核心L1業(yè)務都做了SLO定義、SLI指標和計算。核心API和業(yè)務都具備了SLI報表能力，我們的可用性有了可視化的圖表，一切似乎非常美好...但仍存在問題。
五、遇到的問題
1）業(yè)務定級
- 業(yè)務抽象認知不一，產品范圍可大可小。
- L0、核心L1業(yè)務在SRE的關注下定級基本準確，但其他業(yè)務定級就一言難盡了。
2）應用定級
- 應用數(shù)量遠多于業(yè)務，定級難度更高。
- 老應用等級更新延遲于業(yè)務重構或產品迭代。
- 除L0、核心L1應用外，其他應用等級準確率低。
3）接口定級
- 接口數(shù)量又遠多于應用，定級耗時耗力，維護成本高，當時公司還沒有API GW平臺。
- 同上，接口等級更新延遲于業(yè)務重構或產品迭代。
4）SLI計算
- 當服務因上下游調用依賴導致請求失敗時，API的HTTP CODE可能是200，真實的錯誤被封到了業(yè)務錯誤碼中。SLB作為通用的負載均衡，不會去解析HTTP Body。
- 這就導致一個問題：服務故障了半個小時，但今天的可用性卻是100%，可用性SLI指標沒受到任何影響，SLO也完全符合要求。
- 如果我們改用應用上報的Metrics（內部使用Prometheus），可以解決此問題。但當應用不可用，無法上報Metrics時，也會獲取不到數(shù)據(jù)，導致SLI數(shù)據(jù)不準確。
- 我們試過推研發(fā)把業(yè)務錯誤碼中的系統(tǒng)錯誤（調用依賴類的系統(tǒng)錯誤，而非業(yè)務邏輯錯誤）改為HTTP CODE，但成本極高，跟微服務的標準也不相符。
5）業(yè)務SLI
- 需要篩選出影響業(yè)務核心功能的API，這些API的SLI數(shù)據(jù)再聚合到業(yè)務，其他API的SLI數(shù)據(jù)不影響業(yè)務SLI 。
- 業(yè)務迭代導致API變更，原API SLI不再代表業(yè)務功能，導致業(yè)務SLI數(shù)據(jù)沒價值。
6）總結一下遇到的問題
- 分級模型過于理想，定級成本高；
- 業(yè)務SLI關聯(lián)關系、API SLI元信息更新不及時，數(shù)據(jù)準確率低；
- 無法通過一條Metrics計算到的可用性SLI來覆蓋業(yè)務全部故障場景；
- 部分部門的業(yè)務只提供內網(wǎng)服務，不直接對用戶，導致沒有SLI數(shù)據(jù)；
- SLI數(shù)據(jù)好像除了當報表外，也沒什么價值。
最后壓死我們SLO體系的稻草是一個業(yè)務需求：把業(yè)務的可用性SLI作為業(yè)務年度可用性總結報表，替代基于故障時間計算出的業(yè)務年度可用性。此需求我們認為是合理的，因為我們度量了業(yè)務可用性SLI，那算出的可用性當然可以作為業(yè)務年度總結報表來使用了。但我們在實際使用數(shù)據(jù)時遇到了一個問題：
假設某業(yè)務正常情況下一天的總請求是24W，此業(yè)務某天故障了半個小時，這半個小時在未故障時的請求量是1W，故障時因為用戶或鏈路上的重試導致接入層負載均衡收到的故障請求為2W。
- 基于請求成功率算出的當天業(yè)務可用性：( 1 - 2W / ( 24W + 1W) ) * 100% = 92%，假設此業(yè)務一年內其他時間日請求不變，每天都是100%可用性，則此業(yè)務全年可用性為：1 - (2W / ( 25W + 24W * 364)) = 99.977%
- 基于故障時間算出的當天業(yè)務可用性為：( 1 - 0.5 / 24 ) * 100% = 97.916%，假設此業(yè)務全年其他時間每天都是100%的可用性，則此業(yè)務全年可用性為：( 1 - 0.5 / 24 / 365 ) * 100% = 99.994%
可以看出，兩種計算方式得出的可用性差距極大。為了解決這個問題，我們想到了一種數(shù)據(jù)補償機制：基于故障時段的同環(huán)比數(shù)據(jù)對故障損失數(shù)據(jù)去重，盡量向故障時間數(shù)據(jù)靠齊。去重后基于請求成功率數(shù)據(jù)結果為：
- 忽略重試增加的1W請求量，則當天業(yè)務可用性：( 1 - 1W / 24W ) * 100% = 95.833%，假設此業(yè)務一年內其他時間日請求不變，每天都是100%可用性，則此業(yè)務全年可用性為：1 - (1W / ( 24 * 365)) = 99.988%
此方式雖然依舊無法跟基于故障時間的可用性數(shù)據(jù)對齊，但已經(jīng)非常接近了，我們認為加上了數(shù)據(jù)補償機制之后，統(tǒng)一用這個計算標準的話，業(yè)務的可用性SLI是可以作為業(yè)務年度可用性報表使用的。想法又一次非常美好...
實際運作起來時，我們發(fā)現(xiàn)成本太高了。當發(fā)生了影響業(yè)務核心功能的事故，我們就要對故障數(shù)據(jù)去重，然后修訂故障當天的SLI數(shù)據(jù)。需要有人去盯著事故報告的損失，跟研發(fā)一起核對損失數(shù)據(jù)，再修訂SLI數(shù)據(jù).....
最終，因為我們執(zhí)著于提升SLI的準確率，導致整個SLO系統(tǒng)無法運轉......此時我們的SLO體系開始停滯和崩潰.....
六、反思
我們開始反思問題出在了哪里，SLO的價值到底是什么？SLI度量的對象到底是什么？是業(yè)務嗎，還是應用？Google 基于錯誤預算做了消耗率報警，我們的SLO除了做報表外好像沒啥價值？想清楚這些問題后我們才意識到之前為什么走偏了。
1）SLO是可靠性決策的關鍵因素，但不是非有不可
- 在沒有SLO、SLI之前，我想大家的穩(wěn)定性工作也能分的清楚優(yōu)先級，比如基于事故復盤來決策高可用工作方向，如服務降級、熔斷、中間件高可用、多活容災等。
2）SLO的價值絕對不是報表，而是及時報警，發(fā)現(xiàn)影響SLI指標的異常
- SRE中有一章專門講基于SLO的報警，但在我們的實踐中卻忽略了這個方向，執(zhí)著于提升SLI指標的準確率。
- 應用每天都有無數(shù)的報警通知，如CPU、內存、磁盤、調用超時、請求錯誤、請求重試等，產生了大量噪音。但哪些報警會影響到可用性SLI需要SRE和研發(fā)關注呢？我想這就是SLO的核心價值之一了。
3）錯誤預算策略是詩與遠方
- 如果業(yè)務某個季度發(fā)生事故，把這個季度的錯誤預算耗盡，SLO已不符合預期，SRE也不能凍結這個業(yè)務的變更。
- 至于調整業(yè)務團隊的短期目標，從業(yè)務迭代轉到專注于可靠性問題還是可以的。但這個目標一般是事故驅動達成的共識。
- 如果讓國內互聯(lián)網(wǎng)公司產品迭代停止三個月，我想沒有哪個公司會同意。
4）SLI度量的核心是業(yè)務功能和應用，而不是聚合業(yè)務SLI
- API是業(yè)務功能的直接體現(xiàn)，通過度量API的SLI就能反映出業(yè)務某個功能的情況。
- 業(yè)務功能不可能全部枚舉出來，接口也不可能全部定級和計算SLI。但應用是有限且標準的，基于應用的Metrics即可算出所有應用的可用性SLI。
- 業(yè)務核心功能的SLI通過API SLI已度量出來，是否要聚合成一條代表業(yè)務SLI的指標其實并不重要。比如在業(yè)務報表頁面展示業(yè)務多個功能的API SLI數(shù)據(jù)可能會更直觀。
- 業(yè)務SLI的核心價值是NOC/技術支持團隊在Oncall時的關注指標，或構建業(yè)務場景監(jiān)控時從業(yè)務指標到技術指標的下鉆串聯(lián)，更偏向運營層面。
以上內容詳細介紹了我們在實踐SLO體系時的思路，落地方式和遇到的問題。在沒徹底理解SLO及其價值的情況下，我們就嘗試建設SLO體系，走了很多彎路。反思階段我們也認清了SLO的價值。下面我們就來講述我們新認知下的SLO體系建設思路。
七、業(yè)務分級優(yōu)化
1）等級分級
還是分為L0-L3四個級別：
① L0
公司級核心業(yè)務，一般是公司級基礎服務或公司核心業(yè)務場景，如APP推薦、視頻播放、支付平臺及強依賴業(yè)務等，同時需滿足：
- 滿足DAU > xx W；
- 滿足日均營收> xx W；
- 雖未達到上述要求，但業(yè)務屬于公司戰(zhàn)略級方向。
② L1
部門級核心業(yè)務，一般是L0業(yè)務體驗中依賴的主要業(yè)務、核心的二類業(yè)務，如視頻播放頁的一鍵三連功能、核心二類業(yè)務動態(tài)等。
③ L2
用戶可直接使用的其他業(yè)務，如播單、分享、專欄等。
④ L3
其他后臺類業(yè)務或對用戶體驗無影響的業(yè)務。
2）分級模型優(yōu)化
- 對業(yè)務（產品）定級。
- 創(chuàng)建應用（也可叫服務，下文不再區(qū)分）時，用戶打標這個應用對此業(yè)務的重要程度即可：核心、重要、普通。此數(shù)據(jù)非定級使用。
- 用戶只需要在創(chuàng)建業(yè)務時做一次業(yè)務定級即可。
大大簡化我們的業(yè)務分級模型，不再對應用和API分級，減少大家的心智負擔和運維、運營成本。
八、SLI選擇與計算
在線業(yè)務常見的微服務調用鏈路如下：
從上述鏈路圖中可以看出，可用率、延遲有如下兩種指標：
- 應用通過SLB代理時，使用SLB Metrics計算出應用可用率、延遲等SLI：如服務A、服務B。
- 應用Server側上報指標數(shù)據(jù)，計算出應用可用率、延遲等SLI：每個微服務都有這個指標上報，適用所有服務。
上篇中我們有提到，我們只度量了面向用戶的公網(wǎng)服務。這導致我們的SLI覆蓋率很低，大量的內網(wǎng)應用沒有SLI，那SLO報警也就無從做起了?，F(xiàn)在補充了HTTP/gRPC Server Metrics后，就能覆蓋到所有應用，同時也能覆蓋到所有的服務不可用場景。
- 應用訪問超時，容器OOM、進程Panic等不可用，會在SLB側上報錯誤指標。
- 應用HTTP CODE 200，但因依賴下游服務、讀取DB、CACHE失敗等系統(tǒng)錯誤時，會在應用Metrics側上報錯誤指標。
- 當應用無法上報Metrics時，可以認為應用已徹底不可用。
除可用率、延遲指標外，應用數(shù)據(jù)層面的新鮮度指標也特別重要。當數(shù)據(jù)發(fā)生延遲時，應用Server側并不能直接感知到數(shù)據(jù)是延遲的，要通過其對中間件的Metrics指標來度量。應用對中間件的常見依賴如下圖：
可度量的數(shù)據(jù)新鮮度指標如下：
- 應用對消息隊列服務的寫入和消費延遲指標：數(shù)據(jù)消費延遲會導致用戶緩存數(shù)據(jù)不更新。
- 應用所使用DB的主從同步延遲指標：數(shù)據(jù)同步延遲會導致用戶緩存數(shù)據(jù)不更新。
- Canal作為數(shù)據(jù)同步組件的同步延遲指標：數(shù)據(jù)同步延遲會導致用戶緩存數(shù)據(jù)不更新。
- 多活場景下DTS組件的同步延遲指標：數(shù)據(jù)同步延遲會導致多機房DB數(shù)據(jù)不一致。
1、應用SLI選擇與計算
1）可用率
- SLB Metrics度量出的應用請求錯誤量（HTTP 5XX）、請求成功率。
- HTTP/gRPC Server Metrics度量出的應用請求錯誤量（非業(yè)務邏輯錯誤，如因下游依賴、DB、Cache請求失敗導致的應用系統(tǒng)級錯誤，在我們的微服務框架中，這類錯誤code一般是-5xx）、請求成功率。
2）延遲
- SLB Metrics度量出的應用分位延遲。
- HTTP/gRPC Server Metrics度量出的應用分位延遲。
3）新鮮度
- 應用對MQ寫入、消費的Metrics來度量消息延遲。
- 應用所使用DB主從同步延遲Metrics。
- 如果使用到Canal組件來更新緩存，那需要度量Canal對DB的消費延遲和對MQ的寫入延遲Metrics。
- 多活場景下DTS組件的同步延遲Metrics。
上述Metrics以應用維度采集計算存儲，在應用視角我們就能看到應用的核心SLI，基于這些SLI指標再來做可用率和新鮮度的SLO報警，報警準確率可以大大提升。
假如我們已經(jīng)度量了評論應用的SLI指標，當觸發(fā)SLO報警時，我們知道評論應用出問題了，但并不知道是發(fā)評論還是讀評論功能出問題。為了提高我們SLO的業(yè)務精度，我們需要再對業(yè)務的核心功能做度量。
2、業(yè)務核心功能SLI選擇與計算
在上一篇中我們提到：應用的API是業(yè)務功能的直接體現(xiàn)，通過度量API的SLI就能反映出業(yè)務某個功能的情況。所以我們需要對核心API做SLI度量。
1）定義業(yè)務功能
- 在SLO系統(tǒng)錄入業(yè)務對應的業(yè)務核心功能，如發(fā)送評論、拉取評論。
- 從API GW平臺獲取API信息，關聯(lián)到定義的業(yè)務功能。
2）API SLI選擇與計算
① 可用率
- SLB Metrics度量出核心API的請求錯誤量（HTTP 5XX）、請求成功率。
- HTTP/gRPC Server Metrics度量出核心API的請求錯誤量、請求成功率。
② 延遲
- SLB Metrics度量出核心API的分位延遲。
- HTTP/gRPC Server Metrics度量出核心API的分位延遲。
③ 吞吐
- 核心API每天的請求總量和單位時間的請求速率。
注：吞吐只在核心API上度量，不在應用上度量。因為應用有多個API，包含很多不重要的API，對用戶感知很低，度量吞吐意義并不大。
④ 新鮮度
- 因為應用Server側并不能直接感知到數(shù)據(jù)是延遲的，是通過應用對中間件的Metrics指標來度量，所以API維度并無新鮮度指標。
上述Metrics以API維度采集計算存儲，這樣在業(yè)務核心功能視角我們就能看到各種SLI指標情況，以此來了解業(yè)務功能目前的運行情況。
3、業(yè)務SLI選擇與計算
我們已經(jīng)有了應用SLI、業(yè)務核心功能的SLI，難道還不夠嗎？為何還要建設業(yè)務SLI呢？
原因如下：
- 業(yè)務核心功能SLI是從技術指標計算出來的，如發(fā)評論功能的可用率和數(shù)據(jù)延遲。前面我們有提到錯誤的請求是指系統(tǒng)依賴導致的錯誤而非業(yè)務邏輯錯誤，所以此技術指標并不能代表業(yè)務邏輯上的成功率。
- 業(yè)務SLI的核心價值是NOC/技術支持團隊在Oncall時的關注指標，或構建業(yè)務場景監(jiān)控時從業(yè)務指標到技術指標的下鉆串聯(lián)，更偏向運營層面。
業(yè)務指標是需要從業(yè)務系統(tǒng)獲取，如業(yè)務DB或數(shù)倉平臺。所以只能覆蓋公司級核心業(yè)務指標，如：
- 點播播放：播放量、在線人數(shù)
- 社區(qū)：發(fā)送評論量、評論彈幕量
- 登錄：平均登錄量、各渠道登錄量
-
…
可以看出，業(yè)務SLI其實更側重于業(yè)務吞吐數(shù)據(jù)指標，有了這個指標后，我們可以做以下兩方面的工作建設：
- 重大事故發(fā)現(xiàn)：當業(yè)務SLI指標異常而觸發(fā)報警時，可以認為線上發(fā)生了重大事故。在很多公司，NOC團隊的核心就是關注業(yè)務指標的健康度情況。
- 業(yè)務觀測運營：從業(yè)務吞吐指標到業(yè)務功能技術指標再到應用技術指標，從上往下構建業(yè)務-技術全鏈路監(jiān)控能力和可視化能力。
業(yè)務指標數(shù)據(jù)收集成本較高，需要按業(yè)務系統(tǒng)case by case來建設。我們的思路是讓業(yè)務部門自建業(yè)務數(shù)據(jù)，再由SLO系統(tǒng)同步、匯聚、清洗后做運營大盤與報警。
九、SLO與報警
1、應用SLO
應用維度我們度量了可用率、延遲、新鮮度，可設置對應的SLO如下：
- 可用率 >= 99.99%
- 響應99分位延遲 <= 1s
- 數(shù)據(jù)更新延遲 < = 5min
按照應用所屬業(yè)務的等級，給應用推薦一個默認的SLO，研發(fā)和跟SRE溝通后設定。注意：
- 此SLO用于觸發(fā)SLO報警策略
- 而非凍結研發(fā)變更
2、業(yè)務核心功能SLO
業(yè)務核心功能維度我們度量了可用率、延遲、吞吐，可設置對應的SLO如下：
- 可用率 >= 99.99%
- 響應99分為延遲 <= 1s
- 吞吐不用設置SLO，做儀表盤和報表即可
按照所屬業(yè)務的等級，給代表業(yè)務核心功能API同樣推薦一個默認的SLO，研發(fā)和跟SRE溝通后設定。
3、業(yè)務SLO
業(yè)務指標本質上是吞吐指標，如播放量、在線人數(shù)、評論量等，不需要設置SLO，只用做吞吐下跌的業(yè)務報警即可。當觸發(fā)業(yè)務吞吐報警時，一般代表出現(xiàn)了嚴重事故。
4、SLO報警
雖然我們度量了應用、業(yè)務核心功能、業(yè)務三個對象的可用率、響應延遲、數(shù)據(jù)新鮮度、吞吐指標，但各個指標的報警價值并不一樣。
- 可用率：用戶功能不可用，價值高。
- 響應延遲：延遲不代表用戶功能一定不可用，價值一般。
- 數(shù)據(jù)新鮮度：更新延遲代表用戶數(shù)據(jù)延遲，價值高。
- 吞吐：業(yè)務側的吞吐能發(fā)現(xiàn)線上重大事故，價值高。
監(jiān)控報警一般情況下是按如下分層建設的：
- 基礎設施：機房、網(wǎng)絡、設備等。
- 系統(tǒng)：服務器、存儲、硬盤、網(wǎng)卡、虛擬化等。
- 中間件：DB、Cache、MQ、LB等。
- 應用：進程內資源、系統(tǒng)資源、QPS、錯誤、依賴等。
- 業(yè)務：業(yè)務核心指標，訂單、播放、登錄等。
- 終端：性能、返回碼、運營商、地區(qū)、APP版本等。
對于研發(fā)、SRE來說，平時接觸最多的應用和業(yè)務了，應用和業(yè)務側的報警尤其重要。SLO報警一旦觸發(fā)就代表影響了用戶體驗，是準確率最高的報警，可以作為無效報警治理的切入點。Google SRE在《站點可靠性手冊》中第五章節(jié)也詳細講解了基于可用率SLO的幾種報警策略
1）目標錯誤率≥SLO閾值
選擇一個時間窗口（如10分鐘），該窗口內錯誤率超過SLO閾值時發(fā)出報警。例如，如果SLO在30天內為99.9％，則在前10分鐘的錯誤率≥0.1％時發(fā)出報警。
優(yōu)點：
- 檢測時間良好：總停機時間為0.6秒(10m * 0.1%)。此報警會觸發(fā)任何威脅SLO的事件，表現(xiàn)出良好的召回率。
缺點：
- 精度很低：報警會觸發(fā)許多不會威脅SLO的事件。10分鐘的0.1％錯誤率會發(fā)出報警，而每月錯誤預算僅消耗0.02％。
- 極端情況下，每天最多可以收到144個報警，即使不需要對此采取任何措施，此服務一個月仍然符合99.9%的SLO。
不建議使用此報警策略，精確度太低，每天可能會觸發(fā)很多報警，逐漸成為噪音，導致狼來了的效果。
2）增加報警窗口
可以設置當事件消耗了30天錯誤預算的5％（30d * 5% = 36h）時才收到報警，以提高精度。
優(yōu)點：
- 檢測時間仍然很好：完全停機需要2分10秒(30d * 0.1% * 5%)。
- 比前方案1更精確：錯誤率持續(xù)了更長時間，報警可能對應著嚴重影響錯誤預算的事件。
缺點：
- 非常差的恢復時間：在服務100％不可用的情況下，報警將在2分鐘后觸發(fā)，但在36小時后才恢復。
- 0.1%的錯誤下，需要36h時才觸發(fā)報警，此時存在?量數(shù)據(jù)點，計算成本會很高。
不建議使用此報警策略，當錯誤率很低時，報警檢測時間太長，接到報警時問題可能已經(jīng)持續(xù)了1天。當服務完全不可用時，2分鐘即可報警出來，但恢復要等待36小時，恢復時間太久。
3）增加報警持續(xù)時間
當SLO低于閾值持續(xù)一段時間后再觸發(fā)報警，如10分鐘或者1小時。
優(yōu)點：報警精度更高。在觸發(fā)之前需要持續(xù)的低于SLO閾值，意味著報警更可能對應于重大事件。
缺點：召回率和檢測時間不佳：由于持續(xù)時間不隨事件嚴重程度而變化，因此在服務100%中斷10分鐘或1小時后才會發(fā)出報警，0.2%服務中斷也會有相同的檢測時間。
不建議使用此報警策略，因為不管錯誤率如何，報警檢測時間都是一樣，報警無基于問題嚴重程度的分級，對SRE很不友好。
4）消耗率報警
消耗速率是指相對于SLO，服務消耗錯誤預算的速度。例如：當錯誤率是0.1%時，此時消耗速率是1，當錯誤率是10%時，此時消耗速率是100。下表展示消耗掉一個可用率SLO為99.9%的服務月度錯誤預算時的時間表。
可以將報警窗口定為1小時，并設定當消耗掉當月5％的錯誤預算時發(fā)出告警。1小時的窗口消耗掉30天錯誤預算的5%時，錯誤預算的消耗率為30d * 24h * 60m * 5% / 60m = 36，報警觸發(fā)所需的時間為：
- (（1 - SLO）/ 錯誤率）* 報警窗口 * 消耗率：(( 1 - 99.9% ）/ 錯誤率）* 1h * 36。
- 當錯誤預算消耗速率是36時，1小時發(fā)出報警。
- 當服務完全不可用，錯誤預算消耗速率是1000，2分10秒發(fā)出報警。
優(yōu)點：
- 良好的精確度：此策略選擇大部分錯誤預算消耗時發(fā)出報警。更短的時間窗口，計算起來代價較小，檢測時間好。
缺點：
- 低召回率：消耗速率低于36時永遠不會發(fā)出報警，假如錯誤預算消耗率為35，在20.5小時（30d / 35 * 24h）后會消耗掉30天的全部錯誤預算。
- 服務完全不可用時觸發(fā)報警需要2分10秒，報警重置時間：58分鐘仍然太長。
不建議使用此報警策略，因為當錯誤率 < 3.6%時，永遠不會發(fā)出報警。
5）多次消耗率報警
可以使用多個消耗速率和時間窗口來解決上述的問題，來確保當錯誤率較低時可以發(fā)出報警。
Google建議設置如下三個報警條件：
- 1小時內消耗月度2％的預算消耗，發(fā)出緊急報警。
- 6小時內消耗月度5％的錯誤預算，發(fā)出緊急報警。
- 3天內消耗月度10％的預算，發(fā)出故障工單。
下表顯示了消耗的SLO預算百分比、相應消耗效率和時間窗口：
優(yōu)點：
- 能夠根據(jù)關鍵值調整監(jiān)控配置以適應多種情況：錯誤率高時快速報警；如果錯誤率很低但持續(xù)發(fā)生，最終會發(fā)出報警。
- 多個消耗速率和時間窗口，報警具有良好的精確度。
- 因為有3天10%錯誤預算的報警策略，所以有很好的召回率。
- 能夠根據(jù)錯誤率的嚴重程度來選擇適合的報警類型。
缺點：
- 更多數(shù)據(jù)、窗口大小和閾值需要管理。
- 由于有3天消耗10%錯誤預算的報警，當服務完全不可用時，4.3分鐘就會觸發(fā)報警，但需要3天后才恢復。
- 如果所有條件都滿足，則會觸發(fā)多個報警，需要做報警屏蔽。當服務完全不可用時，4.3分鐘內10％的預算消耗報警也會觸發(fā)6小時5％的預算消耗報警、1小時內2％的預算消耗報警。
這種報警策略已經(jīng)具備了很好的精確度和召回率，可以在報警系統(tǒng)里嘗試使用這種報警策略。
6）多窗口，多消耗率報警
可以加一個較短時間窗口，用于在報警和恢復時檢查是否仍然達到錯誤預算消耗速率，從而減少誤報。Google建議將短窗口設為長窗口持續(xù)時間的1/12。
如何理解短窗口的作用呢？以1小時消耗月度2%的錯誤預算為例：
- 假如服務錯誤率為10%，則錯誤預算消耗率是100，超過14.4的消耗速率，在43秒（14.4 * 5 / 100 * 60s = 43s）時已經(jīng)觸發(fā)了短窗口的條件：5分鐘錯誤預算消耗速率平均值大于14.4。
- 服務故障持續(xù)8.6分鐘（30d * 24h * 60m * 2% / 100 = 8.64m）時，會消耗掉月度2%的錯誤預算，觸發(fā)長窗口的報警閾值：1小時內消耗掉2%的錯誤預算，此時發(fā)出報警。
- 服務故障停止5分鐘后，短窗口錯誤預算消耗速率平均值低于14.4，不會再觸發(fā)，報警恢復。
- 服務故障停止51.4分鐘后，長窗口錯誤預算消耗平均值速率低于14.4，不會再觸發(fā)。
你可以在前一小時和前五分鐘超過14.4倍錯誤預算消耗速率時發(fā)送工單，只有在消耗了2％的錯誤預算后，才發(fā)送報警。5分鐘后短窗口不再觸發(fā)，此時報警恢復時間最佳。
優(yōu)點：
- 靈活的報警框架，允許你根據(jù)事件的嚴重性和組織的要求控制報警類型。
- 良好的精度，與所有固定預算的部分報警方法一樣。不錯的召回率，因為有三天的窗口。
缺點：要指定的參數(shù)很多，這可能使報警規(guī)則難以管理。
這種報警策略大大降低了報警恢復時間，是最合理的報警方式，但增加了報警復雜度，理解起來也有一定的成本。其實方案5也是一種不錯的選擇，這兩種方案都可以實施，具體選哪種報警策略視自己公司的監(jiān)控系統(tǒng)和報警能力而定。
B站目前的SLO報警是基于策略5做了一定調整，不同的服務等級設定了不同的報警窗戶和消耗率，大致如下：
目前我的SLO報警策略也不夠精確，缺少低錯誤預算消耗速率的報警和長時間窗口報警，會漏掉哪些在偷偷消耗錯誤預算的事件。我們的SLO報警會先向方案5靠齊，再朝著方案6優(yōu)化。
最后總結一下我們開啟SLO報警的指標如下：
十、質量運營
有了各個維度的SLI指標和SLO報警后，我們可以很靈活的構建質量運營大盤，如：
- 基于業(yè)務SLI構建業(yè)務指標大盤。
- 基于業(yè)務核心功能SLI構建業(yè)務健康度大盤。
- 基于業(yè)務和應用的關聯(lián)關系構建業(yè)務應用健康度大盤。
- 業(yè)務可用率排名、應用可用率排名。
- 業(yè)務大盤到業(yè)務核心功能到應用指標的場景監(jiān)控大盤。
總結
沒有SLO就沒有SRE？想必到這里大家對SLO的方法論和實踐已經(jīng)有了深刻的理解。僅度量SLI做可用性報表來給業(yè)務帶上枷鎖是沒意義的，SLO的核心價值是定義服務能力，設置SLO報警，及時發(fā)現(xiàn)線上問題，優(yōu)化報警和推動穩(wěn)定性治理，主動幫業(yè)務團隊去提升業(yè)務質量，合作共贏。?
本文標題：要是還沒搞明白SLO，你算哪門子SRE呢？
轉載注明：http://www.5511xx.com/article/dhihhsg.html
