一、背景

最近幾年，Google SRE在國內(nèi)非常流行。Google SRE方法論中提出了SLO是SRE實踐的核心，SLO為服務(wù)可靠性設(shè)定了一個目標(biāo)級別，它是可靠性決策的關(guān)鍵因素。那如何選擇和計算SLI，如何設(shè)置SLO，如何實踐落地呢？本文就來講講B站SRE在實踐SLO時所走的彎路和總結(jié)的經(jīng)驗。

二、Google SRE中SLO的定義

服務(wù)水平目標(biāo)（SLO）指定了服務(wù)可靠性的目標(biāo)水平。由于SLO是做出以數(shù)據(jù)為依據(jù)的可靠性決策的關(guān)鍵，因此它們是SRE實踐的核心。

上文是Google SRE《站點可靠性手冊》中的原文。那為什么需要SLO呢，我們摘取原文中的核心觀點：

工程師稀缺，需要把時間投入到重要服務(wù)的核心問題上

• SLO是做出工作優(yōu)先級排序和可靠性相關(guān)工作的關(guān)鍵

• SRE的核心職責(zé)不僅是自動化和處理故障，日常工作都要按照SLO來開展

• 沒有SLO，就沒有SRE

為了采用基于錯誤預(yù)算的可靠性工程方法，同樣摘取原文中的核心觀點：

• 服務(wù)的利益相關(guān)方認(rèn)可此SLO

• 服務(wù)正常狀態(tài)下可以達到SLO的要求

• 組織認(rèn)可錯誤預(yù)算并在決策中發(fā)揮作用

• 有完善的SLO流程

否則，SLO合規(guī)性成為一個KPI或報告指標(biāo)，而不是決策制定工具。請記住這句話，因為我們的彎路就走到這里了。

三、Google SRE中SLO的實施

在《站點可靠性手冊》第二章“實施SLO”中，Google詳細(xì)講述了如何實施SLO，大致流程如下：

1）SLI選擇

• 對于請求驅(qū)動型服務(wù)，SLI一般選擇可用性（成功響應(yīng)的請求比例）、延遲、質(zhì)量。

2）SLI計算

• SLI的計算可以使用應(yīng)用服務(wù)器日志、負(fù)載均衡監(jiān)控、黑盒監(jiān)控、客戶端插件等數(shù)據(jù)源。
• 一般選擇負(fù)載均衡監(jiān)控，因為其代表一個用戶請求在整套系統(tǒng)所有模塊處理耗時和所有網(wǎng)絡(luò)傳輸耗時的總和，且和客戶端插件相比，實施成本較低。

3）SLO定義

• 基于計算出來的可用性、延遲數(shù)據(jù)，來定義合適的服務(wù)SLO。

• 服務(wù)可用性：例如，全年可用性 > = 99.99%。

• 服務(wù)延遲：例如，99%的請求<= 200ms，90的請求< 100ms。

• 可以在不同的時間窗口上定義SLO，比如一個月或一個季度。

• 獲得關(guān)鍵的利益相關(guān)者認(rèn)可和批準(zhǔn)。

4）錯誤預(yù)算

• 有了SLI和SLO，時間窗口內(nèi)的允許失敗數(shù)就知道了。

• 如果給定時間內(nèi)錯誤預(yù)算消耗殆盡，要制定錯誤預(yù)算執(zhí)行策略，如：開發(fā)團隊專注于可靠性問題，直到系統(tǒng)處于SLO范圍內(nèi)，功能迭代推遲；為了降低風(fēng)險，凍結(jié)生產(chǎn)系統(tǒng)的變更，直到有了錯誤預(yù)算來支持變更。

5）記錄SLO和錯誤預(yù)算

• SLO的作者，審核人，批準(zhǔn)日期，下次審核日期，相關(guān)背景。

• 定義和變更有平臺、流程、制度、變更事件可回溯。

• SLO的細(xì)節(jié)：SLI實現(xiàn)、如何計算、如何使用錯誤預(yù)算。

• 錯誤預(yù)算的記錄跟上面信息類似。

6）儀表盤和報表

• 除了已發(fā)布的SLO和錯誤預(yù)算，還需要一個報表和儀表盤來做展示。

7）持續(xù)改進SLO，提高SLO質(zhì)量

四、我們的SLO實踐

從上文Google對SLO的介紹中，我們抽象出了關(guān)鍵信息來指導(dǎo)我們的建設(shè)。

1、服務(wù)分級

1）應(yīng)用：技術(shù)視角

• 一個應(yīng)用對應(yīng)一個appid，包括前端和后端應(yīng)用。

• 編碼構(gòu)建后，可獨立部署運行。

• 一個業(yè)務(wù)，會包含多個應(yīng)用，一般具有相同的命名前綴或關(guān)鍵詞。

2）業(yè)務(wù)：產(chǎn)品視角

• 一組網(wǎng)站/APP產(chǎn)品相關(guān)功能的聚合。
• 相對獨立的業(yè)務(wù)模塊。
• 包含一組相關(guān)聯(lián)的應(yīng)用。

3）等級分級

我們分為L0-L3四個級別：

• L0

公司級核心業(yè)務(wù)，一般是公司級基礎(chǔ)服務(wù)或公司核心業(yè)務(wù)場景，如APP推薦、視頻播放、支付平臺及強依賴業(yè)務(wù)等。

• L1

部門級核心業(yè)務(wù)，一般是L0業(yè)務(wù)體驗中依賴的主要業(yè)務(wù)、核心的二類業(yè)務(wù)，如視頻播放頁的一鍵三連功能、核心二類業(yè)務(wù)動態(tài)、搜索等。

• L2

用戶可直接使用的其他業(yè)務(wù)，如播單、分享、專欄、答題等。

• L3

其他后臺類業(yè)務(wù)或?qū)τ脩趔w驗無影響的業(yè)務(wù)。

4）分級對象

• 先對業(yè)務(wù)（產(chǎn)品）定級。
• 再對這個業(yè)務(wù)下的多個應(yīng)用定級，根據(jù)應(yīng)用所提供的產(chǎn)品功能和故障影響來定，應(yīng)用等級不超過業(yè)務(wù)等級。
• 在對此業(yè)務(wù)中用戶所能觸達到的API定級，API等級不超過應(yīng)用等級。

5）分級用途

• 基于服務(wù)等級，要求核心服務(wù)遵守對應(yīng)技術(shù)標(biāo)準(zhǔn)。
• 對不同等級的服務(wù)，制定不同的變更流程。
• 報警基于服務(wù)等級來做分級。
• 要求服務(wù)滿足穩(wěn)定性要求，如具備熔斷降級能力，具備同城雙活能力等。

6）分級運營

• 其他基礎(chǔ)平臺展示分級數(shù)據(jù)，基于服務(wù)等級定運行策略。

• 基于分級后的技術(shù)標(biāo)準(zhǔn)、流程等反推定級準(zhǔn)確率提升。

2、SLO系統(tǒng)

1）SLI選擇

對于在線業(yè)務(wù)來說，基本都是請求驅(qū)動的業(yè)務(wù)，所以選擇可用性、延遲、吞吐。

• 可用性：我們度量了兩個指標(biāo)：錯誤量、請求成功率。

• 延遲：我們度量了p90和p99兩個分位的延遲數(shù)據(jù)。

• 吞吐：每天的請求總量和單位時間的請求速率。

可用性為什么不選擇可用時間來度量呢？如果選擇時間，一般的做法是在某個時間段內(nèi)錯誤率大于多少，則認(rèn)為這段時間內(nèi)服務(wù)不可用。假如這段時間內(nèi)某個服務(wù)錯誤率低于閾值但同時有大量用戶反饋不可用的話，我們不能掩耳盜鈴的認(rèn)為這段時間服務(wù)是可用的。因為無法解決這個問題，所以我們選擇了請求成功率。

2）SLI模型

• 應(yīng)用的API是業(yè)務(wù)功能的直接體現(xiàn)，通過度量API的SLI就能反映出業(yè)務(wù)某個功能的情況。
• 選擇能代表業(yè)務(wù)核心功能的API，按上面的業(yè)務(wù)分級模型對這些API定級，一般只度量L0、L1等級的業(yè)務(wù)和其接口。
• 業(yè)務(wù)一般都會提供多個功能，比如彈幕的讀寫，評論的讀寫，所以業(yè)務(wù)的SLI是由代表業(yè)務(wù)功能的多個API SLI數(shù)據(jù)聚合而成的。
• 對于API，我們度量可用性、延遲、吞吐。
• 對于業(yè)務(wù)，我們通過聚合API 的SLI，主要度量可用性。

3）SLI計算

• 統(tǒng)一標(biāo)準(zhǔn)，使用接入層負(fù)載均衡指標(biāo)。所有面向用戶的公網(wǎng)服務(wù)都會經(jīng)過接入層負(fù)載均衡，也即SLB（下文統(tǒng)稱為SLB)。

• 內(nèi)網(wǎng)服務(wù)東西向調(diào)用時通過服務(wù)發(fā)現(xiàn)直接調(diào)用，不過SLB，所以無法用SLB的指標(biāo)度量。我們認(rèn)為內(nèi)網(wǎng)服務(wù)的故障最終能在面向用戶側(cè)的公網(wǎng)服務(wù)中體現(xiàn)出來，所以我們只對面向用戶的公網(wǎng)服務(wù)做度量。

• API可用性：每分鐘計算出API的錯誤量（HTTP 5XX請求）、總請求量、成功率、分位延遲請求量、吞吐。每天再聚合出一天的錯誤量、總請求量、成功率、分位延遲請求量、吞吐。有了每天的數(shù)據(jù)后，可靈活的聚合出API每個季度、半年、全年或某個時間區(qū)間的數(shù)據(jù)。

• 業(yè)務(wù)可用性：對于業(yè)務(wù)來說，我們只做錯誤量、成功率聚合。

（a）相同等級的API權(quán)重應(yīng)該是一樣的，不同等級的API應(yīng)該加權(quán)；

?（b）每分鐘計算出L0等級API的錯誤量之和、總請求量之和、總成功率（1 - (錯誤量之和 / 總請求量之和)）；

（c）每分鐘L1等級的API也聚合出相同的數(shù)據(jù)；

（d）每分鐘業(yè)務(wù)可用性 = （L0 API總成功率 * 權(quán)重 + L1 API總成功率 * 權(quán)重）/ 總權(quán)重；

（e）有了業(yè)務(wù)每分鐘的可用性后，再聚合出業(yè)務(wù)一天的可用性，以及靈活的聚合出每個季度、半年、全年或某個時間區(qū)間的數(shù)據(jù)。

4）SLO定義

• 只對可用性和延遲做SLO定義，吞吐做SLI儀表盤和報表即可；

• 在API分級時，我們會對API設(shè)置一個基于分級的默認(rèn)SLO，比如L0 API 可用性>= 99.99%，L1 API可用性>= 99.99%，L0 API 99分位延遲<=200ms；

• 在業(yè)務(wù)分級時，我們會讓研發(fā)對業(yè)務(wù)設(shè)置一個可用性SLO目標(biāo)，比如全年可用性>= 99.99%。

5）錯誤預(yù)算

• 我們在一開始嘗試SLO時，并沒有去重點建設(shè)錯誤預(yù)算。只是使用了基于服務(wù)分級的SLO錯誤量和可用性報警。

6）記錄SLO和錯誤預(yù)算

我們提供了平臺化能力去支持定義SLO時的審核和記錄。

7）儀表盤和報表

• API儀表盤與報表

• 業(yè)務(wù)儀表盤與報表

上面一套SLO體系建設(shè)完成以后，我們對L0、核心L1業(yè)務(wù)都做了SLO定義、SLI指標(biāo)和計算。核心API和業(yè)務(wù)都具備了SLI報表能力，我們的可用性有了可視化的圖表，一切似乎非常美好...但仍存在問題。

五、遇到的問題

1）業(yè)務(wù)定級

• 業(yè)務(wù)抽象認(rèn)知不一，產(chǎn)品范圍可大可小。

• L0、核心L1業(yè)務(wù)在SRE的關(guān)注下定級基本準(zhǔn)確，但其他業(yè)務(wù)定級就一言難盡了。

2）應(yīng)用定級

• 應(yīng)用數(shù)量遠(yuǎn)多于業(yè)務(wù)，定級難度更高。

• 老應(yīng)用等級更新延遲于業(yè)務(wù)重構(gòu)或產(chǎn)品迭代。

• 除L0、核心L1應(yīng)用外，其他應(yīng)用等級準(zhǔn)確率低。

3）接口定級 

• 接口數(shù)量又遠(yuǎn)多于應(yīng)用，定級耗時耗力，維護成本高，當(dāng)時公司還沒有API GW平臺。

• 同上，接口等級更新延遲于業(yè)務(wù)重構(gòu)或產(chǎn)品迭代。

4）SLI計算

• 當(dāng)服務(wù)因上下游調(diào)用依賴導(dǎo)致請求失敗時，API的HTTP CODE可能是200，真實的錯誤被封到了業(yè)務(wù)錯誤碼中。SLB作為通用的負(fù)載均衡，不會去解析HTTP Body。

• 這就導(dǎo)致一個問題：服務(wù)故障了半個小時，但今天的可用性卻是100%，可用性SLI指標(biāo)沒受到任何影響，SLO也完全符合要求。

• 如果我們改用應(yīng)用上報的Metrics（內(nèi)部使用Prometheus），可以解決此問題。但當(dāng)應(yīng)用不可用，無法上報Metrics時，也會獲取不到數(shù)據(jù)，導(dǎo)致SLI數(shù)據(jù)不準(zhǔn)確。

• 我們試過推研發(fā)把業(yè)務(wù)錯誤碼中的系統(tǒng)錯誤（調(diào)用依賴類的系統(tǒng)錯誤，而非業(yè)務(wù)邏輯錯誤）改為HTTP CODE，但成本極高，跟微服務(wù)的標(biāo)準(zhǔn)也不相符。

5）業(yè)務(wù)SLI

• 需要篩選出影響業(yè)務(wù)核心功能的API，這些API的SLI數(shù)據(jù)再聚合到業(yè)務(wù)，其他API的SLI數(shù)據(jù)不影響業(yè)務(wù)SLI 。

• 業(yè)務(wù)迭代導(dǎo)致API變更，原API SLI不再代表業(yè)務(wù)功能，導(dǎo)致業(yè)務(wù)SLI數(shù)據(jù)沒價值。

6）總結(jié)一下遇到的問題

• 分級模型過于理想，定級成本高；

• 業(yè)務(wù)SLI關(guān)聯(lián)關(guān)系、API SLI元信息更新不及時，數(shù)據(jù)準(zhǔn)確率低；

• 無法通過一條Metrics計算到的可用性SLI來覆蓋業(yè)務(wù)全部故障場景；

• 部分部門的業(yè)務(wù)只提供內(nèi)網(wǎng)服務(wù)，不直接對用戶，導(dǎo)致沒有SLI數(shù)據(jù)；

• SLI數(shù)據(jù)好像除了當(dāng)報表外，也沒什么價值。

最后壓死我們SLO體系的稻草是一個業(yè)務(wù)需求：把業(yè)務(wù)的可用性SLI作為業(yè)務(wù)年度可用性總結(jié)報表，替代基于故障時間計算出的業(yè)務(wù)年度可用性。此需求我們認(rèn)為是合理的，因為我們度量了業(yè)務(wù)可用性SLI，那算出的可用性當(dāng)然可以作為業(yè)務(wù)年度總結(jié)報表來使用了。但我們在實際使用數(shù)據(jù)時遇到了一個問題：

假設(shè)某業(yè)務(wù)正常情況下一天的總請求是24W，此業(yè)務(wù)某天故障了半個小時，這半個小時在未故障時的請求量是1W，故障時因為用戶或鏈路上的重試導(dǎo)致接入層負(fù)載均衡收到的故障請求為2W。

• 基于請求成功率算出的當(dāng)天業(yè)務(wù)可用性：( 1 - 2W / ( 24W + 1W) ) * 100% = 92%，假設(shè)此業(yè)務(wù)一年內(nèi)其他時間日請求不變，每天都是100%可用性，則此業(yè)務(wù)全年可用性為：1 - (2W / ( 25W + 24W * 364))  = 99.977%

• 基于故障時間算出的當(dāng)天業(yè)務(wù)可用性為：( 1 - 0.5 / 24 ) * 100% = 97.916%，假設(shè)此業(yè)務(wù)全年其他時間每天都是100%的可用性，則此業(yè)務(wù)全年可用性為：( 1 - 0.5 / 24 / 365 ) * 100% = 99.994%

可以看出，兩種計算方式得出的可用性差距極大。為了解決這個問題，我們想到了一種數(shù)據(jù)補償機制：基于故障時段的同環(huán)比數(shù)據(jù)對故障損失數(shù)據(jù)去重，盡量向故障時間數(shù)據(jù)靠齊。去重后基于請求成功率數(shù)據(jù)結(jié)果為：

• 忽略重試增加的1W請求量，則當(dāng)天業(yè)務(wù)可用性：( 1 - 1W /  24W ) * 100% = 95.833%，假設(shè)此業(yè)務(wù)一年內(nèi)其他時間日請求不變，每天都是100%可用性，則此業(yè)務(wù)全年可用性為：1 - (1W / ( 24 * 365))  = 99.988%

此方式雖然依舊無法跟基于故障時間的可用性數(shù)據(jù)對齊，但已經(jīng)非常接近了，我們認(rèn)為加上了數(shù)據(jù)補償機制之后，統(tǒng)一用這個計算標(biāo)準(zhǔn)的話，業(yè)務(wù)的可用性SLI是可以作為業(yè)務(wù)年度可用性報表使用的。想法又一次非常美好...

實際運作起來時，我們發(fā)現(xiàn)成本太高了。當(dāng)發(fā)生了影響業(yè)務(wù)核心功能的事故，我們就要對故障數(shù)據(jù)去重，然后修訂故障當(dāng)天的SLI數(shù)據(jù)。需要有人去盯著事故報告的損失，跟研發(fā)一起核對損失數(shù)據(jù)，再修訂SLI數(shù)據(jù).....

最終，因為我們執(zhí)著于提升SLI的準(zhǔn)確率，導(dǎo)致整個SLO系統(tǒng)無法運轉(zhuǎn)......此時我們的SLO體系開始停滯和崩潰.....

六、反思

我們開始反思問題出在了哪里，SLO的價值到底是什么？SLI度量的對象到底是什么？是業(yè)務(wù)嗎，還是應(yīng)用？Google 基于錯誤預(yù)算做了消耗率報警，我們的SLO除了做報表外好像沒啥價值？想清楚這些問題后我們才意識到之前為什么走偏了。

1）SLO是可靠性決策的關(guān)鍵因素，但不是非有不可

• 在沒有SLO、SLI之前，我想大家的穩(wěn)定性工作也能分的清楚優(yōu)先級，比如基于事故復(fù)盤來決策高可用工作方向，如服務(wù)降級、熔斷、中間件高可用、多活容災(zāi)等。

2）SLO的價值絕對不是報表，而是及時報警，發(fā)現(xiàn)影響SLI指標(biāo)的異常

• SRE中有一章專門講基于SLO的報警，但在我們的實踐中卻忽略了這個方向，執(zhí)著于提升SLI指標(biāo)的準(zhǔn)確率。

• 應(yīng)用每天都有無數(shù)的報警通知，如CPU、內(nèi)存、磁盤、調(diào)用超時、請求錯誤、請求重試等，產(chǎn)生了大量噪音。但哪些報警會影響到可用性SLI需要SRE和研發(fā)關(guān)注呢？我想這就是SLO的核心價值之一了。

3）錯誤預(yù)算策略是詩與遠(yuǎn)方

• 如果業(yè)務(wù)某個季度發(fā)生事故，把這個季度的錯誤預(yù)算耗盡，SLO已不符合預(yù)期，SRE也不能凍結(jié)這個業(yè)務(wù)的變更。

• 至于調(diào)整業(yè)務(wù)團隊的短期目標(biāo)，從業(yè)務(wù)迭代轉(zhuǎn)到專注于可靠性問題還是可以的。但這個目標(biāo)一般是事故驅(qū)動達成的共識。

• 如果讓國內(nèi)互聯(lián)網(wǎng)公司產(chǎn)品迭代停止三個月，我想沒有哪個公司會同意。

4）SLI度量的核心是業(yè)務(wù)功能和應(yīng)用，而不是聚合業(yè)務(wù)SLI

• API是業(yè)務(wù)功能的直接體現(xiàn)，通過度量API的SLI就能反映出業(yè)務(wù)某個功能的情況。

• 業(yè)務(wù)功能不可能全部枚舉出來，接口也不可能全部定級和計算SLI。但應(yīng)用是有限且標(biāo)準(zhǔn)的，基于應(yīng)用的Metrics即可算出所有應(yīng)用的可用性SLI。

• 業(yè)務(wù)核心功能的SLI通過API SLI已度量出來，是否要聚合成一條代表業(yè)務(wù)SLI的指標(biāo)其實并不重要。比如在業(yè)務(wù)報表頁面展示業(yè)務(wù)多個功能的API SLI數(shù)據(jù)可能會更直觀。

• 業(yè)務(wù)SLI的核心價值是NOC/技術(shù)支持團隊在Oncall時的關(guān)注指標(biāo)，或構(gòu)建業(yè)務(wù)場景監(jiān)控時從業(yè)務(wù)指標(biāo)到技術(shù)指標(biāo)的下鉆串聯(lián)，更偏向運營層面。

以上內(nèi)容詳細(xì)介紹了我們在實踐SLO體系時的思路，落地方式和遇到的問題。在沒徹底理解SLO及其價值的情況下，我們就嘗試建設(shè)SLO體系，走了很多彎路。反思階段我們也認(rèn)清了SLO的價值。下面我們就來講述我們新認(rèn)知下的SLO體系建設(shè)思路。

七、業(yè)務(wù)分級優(yōu)化

1）等級分級

還是分為L0-L3四個級別：

① L0

公司級核心業(yè)務(wù)，一般是公司級基礎(chǔ)服務(wù)或公司核心業(yè)務(wù)場景，如APP推薦、視頻播放、支付平臺及強依賴業(yè)務(wù)等，同時需滿足：

• 滿足DAU > xx W；

• 滿足日均營收>  xx W；

• 雖未達到上述要求，但業(yè)務(wù)屬于公司戰(zhàn)略級方向。

② L1

部門級核心業(yè)務(wù)，一般是L0業(yè)務(wù)體驗中依賴的主要業(yè)務(wù)、核心的二類業(yè)務(wù)，如視頻播放頁的一鍵三連功能、核心二類業(yè)務(wù)動態(tài)等。

③ L2

用戶可直接使用的其他業(yè)務(wù)，如播單、分享、專欄等。

④ L3

其他后臺類業(yè)務(wù)或?qū)τ脩趔w驗無影響的業(yè)務(wù)。

2）分級模型優(yōu)化

• 對業(yè)務(wù)（產(chǎn)品）定級。

• 創(chuàng)建應(yīng)用（也可叫服務(wù)，下文不再區(qū)分）時，用戶打標(biāo)這個應(yīng)用對此業(yè)務(wù)的重要程度即可：核心、重要、普通。此數(shù)據(jù)非定級使用。

• 用戶只需要在創(chuàng)建業(yè)務(wù)時做一次業(yè)務(wù)定級即可。

大大簡化我們的業(yè)務(wù)分級模型，不再對應(yīng)用和API分級，減少大家的心智負(fù)擔(dān)和運維、運營成本。

八、SLI選擇與計算

在線業(yè)務(wù)常見的微服務(wù)調(diào)用鏈路如下：

從上述鏈路圖中可以看出，可用率、延遲有如下兩種指標(biāo)：

• 應(yīng)用通過SLB代理時，使用SLB Metrics計算出應(yīng)用可用率、延遲等SLI：如服務(wù)A、服務(wù)B。

• 應(yīng)用Server側(cè)上報指標(biāo)數(shù)據(jù)，計算出應(yīng)用可用率、延遲等SLI：每個微服務(wù)都有這個指標(biāo)上報，適用所有服務(wù)。

上篇中我們有提到，我們只度量了面向用戶的公網(wǎng)服務(wù)。這導(dǎo)致我們的SLI覆蓋率很低，大量的內(nèi)網(wǎng)應(yīng)用沒有SLI，那SLO報警也就無從做起了?，F(xiàn)在補充了HTTP/gRPC Server Metrics后，就能覆蓋到所有應(yīng)用，同時也能覆蓋到所有的服務(wù)不可用場景。

• 應(yīng)用訪問超時，容器OOM、進程Panic等不可用，會在SLB側(cè)上報錯誤指標(biāo)。

• 應(yīng)用HTTP CODE 200，但因依賴下游服務(wù)、讀取DB、CACHE失敗等系統(tǒng)錯誤時，會在應(yīng)用Metrics側(cè)上報錯誤指標(biāo)。

• 當(dāng)應(yīng)用無法上報Metrics時，可以認(rèn)為應(yīng)用已徹底不可用。

除可用率、延遲指標(biāo)外，應(yīng)用數(shù)據(jù)層面的新鮮度指標(biāo)也特別重要。當(dāng)數(shù)據(jù)發(fā)生延遲時，應(yīng)用Server側(cè)并不能直接感知到數(shù)據(jù)是延遲的，要通過其對中間件的Metrics指標(biāo)來度量。應(yīng)用對中間件的常見依賴如下圖：

可度量的數(shù)據(jù)新鮮度指標(biāo)如下：

• 應(yīng)用對消息隊列服務(wù)的寫入和消費延遲指標(biāo)：數(shù)據(jù)消費延遲會導(dǎo)致用戶緩存數(shù)據(jù)不更新。
• 應(yīng)用所使用DB的主從同步延遲指標(biāo)：數(shù)據(jù)同步延遲會導(dǎo)致用戶緩存數(shù)據(jù)不更新。
• Canal作為數(shù)據(jù)同步組件的同步延遲指標(biāo)：數(shù)據(jù)同步延遲會導(dǎo)致用戶緩存數(shù)據(jù)不更新。
• 多活場景下DTS組件的同步延遲指標(biāo)：數(shù)據(jù)同步延遲會導(dǎo)致多機房DB數(shù)據(jù)不一致。

1、應(yīng)用SLI選擇與計算

1）可用率

• SLB Metrics度量出的應(yīng)用請求錯誤量（HTTP 5XX）、請求成功率。

• HTTP/gRPC Server Metrics度量出的應(yīng)用請求錯誤量（非業(yè)務(wù)邏輯錯誤，如因下游依賴、DB、Cache請求失敗導(dǎo)致的應(yīng)用系統(tǒng)級錯誤，在我們的微服務(wù)框架中，這類錯誤code一般是-5xx）、請求成功率。

2）延遲

• SLB Metrics度量出的應(yīng)用分位延遲。

• HTTP/gRPC Server Metrics度量出的應(yīng)用分位延遲。

3）新鮮度

• 應(yīng)用對MQ寫入、消費的Metrics來度量消息延遲。

• 應(yīng)用所使用DB主從同步延遲Metrics。

• 如果使用到Canal組件來更新緩存，那需要度量Canal對DB的消費延遲和對MQ的寫入延遲Metrics。

• 多活場景下DTS組件的同步延遲Metrics。

上述Metrics以應(yīng)用維度采集計算存儲，在應(yīng)用視角我們就能看到應(yīng)用的核心SLI，基于這些SLI指標(biāo)再來做可用率和新鮮度的SLO報警，報警準(zhǔn)確率可以大大提升。

假如我們已經(jīng)度量了評論應(yīng)用的SLI指標(biāo)，當(dāng)觸發(fā)SLO報警時，我們知道評論應(yīng)用出問題了，但并不知道是發(fā)評論還是讀評論功能出問題。為了提高我們SLO的業(yè)務(wù)精度，我們需要再對業(yè)務(wù)的核心功能做度量。

2、業(yè)務(wù)核心功能SLI選擇與計算

在上一篇中我們提到：應(yīng)用的API是業(yè)務(wù)功能的直接體現(xiàn)，通過度量API的SLI就能反映出業(yè)務(wù)某個功能的情況。所以我們需要對核心API做SLI度量。

1）定義業(yè)務(wù)功能

• 在SLO系統(tǒng)錄入業(yè)務(wù)對應(yīng)的業(yè)務(wù)核心功能，如發(fā)送評論、拉取評論。

• 從API GW平臺獲取API信息，關(guān)聯(lián)到定義的業(yè)務(wù)功能。

2）API SLI選擇與計算

① 可用率

• SLB Metrics度量出核心API的請求錯誤量（HTTP 5XX）、請求成功率。

• HTTP/gRPC Server Metrics度量出核心API的請求錯誤量、請求成功率。

② 延遲

• SLB Metrics度量出核心API的分位延遲。

• HTTP/gRPC Server Metrics度量出核心API的分位延遲。

③ 吞吐

• 核心API每天的請求總量和單位時間的請求速率。

注：吞吐只在核心API上度量，不在應(yīng)用上度量。因為應(yīng)用有多個API，包含很多不重要的API，對用戶感知很低，度量吞吐意義并不大。

④ 新鮮度

• 因為應(yīng)用Server側(cè)并不能直接感知到數(shù)據(jù)是延遲的，是通過應(yīng)用對中間件的Metrics指標(biāo)來度量，所以API維度并無新鮮度指標(biāo)。

上述Metrics以API維度采集計算存儲，這樣在業(yè)務(wù)核心功能視角我們就能看到各種SLI指標(biāo)情況，以此來了解業(yè)務(wù)功能目前的運行情況。

3、業(yè)務(wù)SLI選擇與計算

我們已經(jīng)有了應(yīng)用SLI、業(yè)務(wù)核心功能的SLI，難道還不夠嗎？為何還要建設(shè)業(yè)務(wù)SLI呢？

原因如下：

• 業(yè)務(wù)核心功能SLI是從技術(shù)指標(biāo)計算出來的，如發(fā)評論功能的可用率和數(shù)據(jù)延遲。前面我們有提到錯誤的請求是指系統(tǒng)依賴導(dǎo)致的錯誤而非業(yè)務(wù)邏輯錯誤，所以此技術(shù)指標(biāo)并不能代表業(yè)務(wù)邏輯上的成功率。

• 業(yè)務(wù)SLI的核心價值是NOC/技術(shù)支持團隊在Oncall時的關(guān)注指標(biāo)，或構(gòu)建業(yè)務(wù)場景監(jiān)控時從業(yè)務(wù)指標(biāo)到技術(shù)指標(biāo)的下鉆串聯(lián)，更偏向運營層面。

業(yè)務(wù)指標(biāo)是需要從業(yè)務(wù)系統(tǒng)獲取，如業(yè)務(wù)DB或數(shù)倉平臺。所以只能覆蓋公司級核心業(yè)務(wù)指標(biāo)，如：

• 點播播放：播放量、在線人數(shù)
• 社區(qū)：發(fā)送評論量、評論彈幕量
• 登錄：平均登錄量、各渠道登錄量

• …

可以看出，業(yè)務(wù)SLI其實更側(cè)重于業(yè)務(wù)吞吐數(shù)據(jù)指標(biāo)，有了這個指標(biāo)后，我們可以做以下兩方面的工作建設(shè)：

• 重大事故發(fā)現(xiàn)：當(dāng)業(yè)務(wù)SLI指標(biāo)異常而觸發(fā)報警時，可以認(rèn)為線上發(fā)生了重大事故。在很多公司，NOC團隊的核心就是關(guān)注業(yè)務(wù)指標(biāo)的健康度情況。

• 業(yè)務(wù)觀測運營：從業(yè)務(wù)吞吐指標(biāo)到業(yè)務(wù)功能技術(shù)指標(biāo)再到應(yīng)用技術(shù)指標(biāo)，從上往下構(gòu)建業(yè)務(wù)-技術(shù)全鏈路監(jiān)控能力和可視化能力。

業(yè)務(wù)指標(biāo)數(shù)據(jù)收集成本較高，需要按業(yè)務(wù)系統(tǒng)case by case來建設(shè)。我們的思路是讓業(yè)務(wù)部門自建業(yè)務(wù)數(shù)據(jù)，再由SLO系統(tǒng)同步、匯聚、清洗后做運營大盤與報警。

九、SLO與報警

1、應(yīng)用SLO

應(yīng)用維度我們度量了可用率、延遲、新鮮度，可設(shè)置對應(yīng)的SLO如下：

• 可用率 >= 99.99%
• 響應(yīng)99分位延遲 <= 1s
• 數(shù)據(jù)更新延遲 < = 5min

按照應(yīng)用所屬業(yè)務(wù)的等級，給應(yīng)用推薦一個默認(rèn)的SLO，研發(fā)和跟SRE溝通后設(shè)定。注意：

• 此SLO用于觸發(fā)SLO報警策略
• 而非凍結(jié)研發(fā)變更

2、業(yè)務(wù)核心功能SLO

業(yè)務(wù)核心功能維度我們度量了可用率、延遲、吞吐，可設(shè)置對應(yīng)的SLO如下：

• 可用率 >= 99.99%
• 響應(yīng)99分為延遲 <= 1s
• 吞吐不用設(shè)置SLO，做儀表盤和報表即可

按照所屬業(yè)務(wù)的等級，給代表業(yè)務(wù)核心功能API同樣推薦一個默認(rèn)的SLO，研發(fā)和跟SRE溝通后設(shè)定。

3、業(yè)務(wù)SLO

業(yè)務(wù)指標(biāo)本質(zhì)上是吞吐指標(biāo)，如播放量、在線人數(shù)、評論量等，不需要設(shè)置SLO，只用做吞吐下跌的業(yè)務(wù)報警即可。當(dāng)觸發(fā)業(yè)務(wù)吞吐報警時，一般代表出現(xiàn)了嚴(yán)重事故。

4、SLO報警

雖然我們度量了應(yīng)用、業(yè)務(wù)核心功能、業(yè)務(wù)三個對象的可用率、響應(yīng)延遲、數(shù)據(jù)新鮮度、吞吐指標(biāo)，但各個指標(biāo)的報警價值并不一樣。

• 可用率：用戶功能不可用，價值高。
• 響應(yīng)延遲：延遲不代表用戶功能一定不可用，價值一般。
• 數(shù)據(jù)新鮮度：更新延遲代表用戶數(shù)據(jù)延遲，價值高。
• 吞吐：業(yè)務(wù)側(cè)的吞吐能發(fā)現(xiàn)線上重大事故，價值高。

監(jiān)控報警一般情況下是按如下分層建設(shè)的：

• 基礎(chǔ)設(shè)施：機房、網(wǎng)絡(luò)、設(shè)備等。
• 系統(tǒng)：服務(wù)器、存儲、硬盤、網(wǎng)卡、虛擬化等。
• 中間件：DB、Cache、MQ、LB等。
• 應(yīng)用：進程內(nèi)資源、系統(tǒng)資源、QPS、錯誤、依賴等。
• 業(yè)務(wù)：業(yè)務(wù)核心指標(biāo)，訂單、播放、登錄等。
• 終端：性能、返回碼、運營商、地區(qū)、APP版本等。

對于研發(fā)、SRE來說，平時接觸最多的應(yīng)用和業(yè)務(wù)了，應(yīng)用和業(yè)務(wù)側(cè)的報警尤其重要。SLO報警一旦觸發(fā)就代表影響了用戶體驗，是準(zhǔn)確率最高的報警，可以作為無效報警治理的切入點。Google SRE在《站點可靠性手冊》中第五章節(jié)也詳細(xì)講解了基于可用率SLO的幾種報警策略

1）目標(biāo)錯誤率≥SLO閾值

選擇一個時間窗口（如10分鐘），該窗口內(nèi)錯誤率超過SLO閾值時發(fā)出報警。例如，如果SLO在30天內(nèi)為99.9％，則在前10分鐘的錯誤率≥0.1％時發(fā)出報警。

優(yōu)點：

• 檢測時間良好：總停機時間為0.6秒(10m * 0.1%)。此報警會觸發(fā)任何威脅SLO的事件，表現(xiàn)出良好的召回率。

缺點：

• 精度很低：報警會觸發(fā)許多不會威脅SLO的事件。10分鐘的0.1％錯誤率會發(fā)出報警，而每月錯誤預(yù)算僅消耗0.02％。

• 極端情況下，每天最多可以收到144個報警，即使不需要對此采取任何措施，此服務(wù)一個月仍然符合99.9%的SLO。

不建議使用此報警策略，精確度太低，每天可能會觸發(fā)很多報警，逐漸成為噪音，導(dǎo)致狼來了的效果。

2）增加報警窗口

可以設(shè)置當(dāng)事件消耗了30天錯誤預(yù)算的5％（30d * 5% = 36h）時才收到報警，以提高精度。

優(yōu)點：

• 檢測時間仍然很好：完全停機需要2分10秒(30d * 0.1% * 5%)。

• 比前方案1更精確：錯誤率持續(xù)了更長時間，報警可能對應(yīng)著嚴(yán)重影響錯誤預(yù)算的事件。

缺點：

• 非常差的恢復(fù)時間：在服務(wù)100％不可用的情況下，報警將在2分鐘后觸發(fā)，但在36小時后才恢復(fù)。

• 0.1%的錯誤下，需要36h時才觸發(fā)報警，此時存在?量數(shù)據(jù)點，計算成本會很高。

不建議使用此報警策略，當(dāng)錯誤率很低時，報警檢測時間太長，接到報警時問題可能已經(jīng)持續(xù)了1天。當(dāng)服務(wù)完全不可用時，2分鐘即可報警出來，但恢復(fù)要等待36小時，恢復(fù)時間太久。

3）增加報警持續(xù)時間

當(dāng)SLO低于閾值持續(xù)一段時間后再觸發(fā)報警，如10分鐘或者1小時。

優(yōu)點：報警精度更高。在觸發(fā)之前需要持續(xù)的低于SLO閾值，意味著報警更可能對應(yīng)于重大事件。

缺點：召回率和檢測時間不佳：由于持續(xù)時間不隨事件嚴(yán)重程度而變化，因此在服務(wù)100%中斷10分鐘或1小時后才會發(fā)出報警，0.2%服務(wù)中斷也會有相同的檢測時間。

不建議使用此報警策略，因為不管錯誤率如何，報警檢測時間都是一樣，報警無基于問題嚴(yán)重程度的分級，對SRE很不友好。

4）消耗率報警

消耗速率是指相對于SLO，服務(wù)消耗錯誤預(yù)算的速度。例如：當(dāng)錯誤率是0.1%時，此時消耗速率是1，當(dāng)錯誤率是10%時，此時消耗速率是100。下表展示消耗掉一個可用率SLO為99.9%的服務(wù)月度錯誤預(yù)算時的時間表。

可以將報警窗口定為1小時，并設(shè)定當(dāng)消耗掉當(dāng)月5％的錯誤預(yù)算時發(fā)出告警。1小時的窗口消耗掉30天錯誤預(yù)算的5%時，錯誤預(yù)算的消耗率為30d * 24h * 60m * 5% / 60m = 36，報警觸發(fā)所需的時間為：

• (（1 - SLO）/ 錯誤率）* 報警窗口 * 消耗率：(( 1 - 99.9% ）/ 錯誤率）* 1h * 36。

• 當(dāng)錯誤預(yù)算消耗速率是36時，1小時發(fā)出報警。

• 當(dāng)服務(wù)完全不可用，錯誤預(yù)算消耗速率是1000，2分10秒發(fā)出報警。

優(yōu)點：

• 良好的精確度：此策略選擇大部分錯誤預(yù)算消耗時發(fā)出報警。更短的時間窗口，計算起來代價較小，檢測時間好。

缺點：

• 低召回率：消耗速率低于36時永遠(yuǎn)不會發(fā)出報警，假如錯誤預(yù)算消耗率為35，在20.5小時（30d / 35 * 24h）后會消耗掉30天的全部錯誤預(yù)算。

• 服務(wù)完全不可用時觸發(fā)報警需要2分10秒，報警重置時間：58分鐘仍然太長。

不建議使用此報警策略，因為當(dāng)錯誤率 < 3.6%時，永遠(yuǎn)不會發(fā)出報警。

5）多次消耗率報警

可以使用多個消耗速率和時間窗口來解決上述的問題，來確保當(dāng)錯誤率較低時可以發(fā)出報警。

Google建議設(shè)置如下三個報警條件：

• 1小時內(nèi)消耗月度2％的預(yù)算消耗，發(fā)出緊急報警。

• 6小時內(nèi)消耗月度5％的錯誤預(yù)算，發(fā)出緊急報警。

• 3天內(nèi)消耗月度10％的預(yù)算，發(fā)出故障工單。

下表顯示了消耗的SLO預(yù)算百分比、相應(yīng)消耗效率和時間窗口：

優(yōu)點：

• 能夠根據(jù)關(guān)鍵值調(diào)整監(jiān)控配置以適應(yīng)多種情況：錯誤率高時快速報警；如果錯誤率很低但持續(xù)發(fā)生，最終會發(fā)出報警。

• 多個消耗速率和時間窗口，報警具有良好的精確度。

• 因為有3天10%錯誤預(yù)算的報警策略，所以有很好的召回率。

• 能夠根據(jù)錯誤率的嚴(yán)重程度來選擇適合的報警類型。

缺點：

• 更多數(shù)據(jù)、窗口大小和閾值需要管理。

• 由于有3天消耗10%錯誤預(yù)算的報警，當(dāng)服務(wù)完全不可用時，4.3分鐘就會觸發(fā)報警，但需要3天后才恢復(fù)。

• 如果所有條件都滿足，則會觸發(fā)多個報警，需要做報警屏蔽。當(dāng)服務(wù)完全不可用時，4.3分鐘內(nèi)10％的預(yù)算消耗報警也會觸發(fā)6小時5％的預(yù)算消耗報警、1小時內(nèi)2％的預(yù)算消耗報警。

這種報警策略已經(jīng)具備了很好的精確度和召回率，可以在報警系統(tǒng)里嘗試使用這種報警策略。

6）多窗口，多消耗率報警

可以加一個較短時間窗口，用于在報警和恢復(fù)時檢查是否仍然達到錯誤預(yù)算消耗速率，從而減少誤報。Google建議將短窗口設(shè)為長窗口持續(xù)時間的1/12。

如何理解短窗口的作用呢？以1小時消耗月度2%的錯誤預(yù)算為例：

• 假如服務(wù)錯誤率為10%，則錯誤預(yù)算消耗率是100，超過14.4的消耗速率，在43秒（14.4 * 5 / 100 * 60s = 43s）時已經(jīng)觸發(fā)了短窗口的條件：5分鐘錯誤預(yù)算消耗速率平均值大于14.4。
• 服務(wù)故障持續(xù)8.6分鐘（30d * 24h * 60m * 2% / 100 = 8.64m）時，會消耗掉月度2%的錯誤預(yù)算，觸發(fā)長窗口的報警閾值：1小時內(nèi)消耗掉2%的錯誤預(yù)算，此時發(fā)出報警。
• 服務(wù)故障停止5分鐘后，短窗口錯誤預(yù)算消耗速率平均值低于14.4，不會再觸發(fā)，報警恢復(fù)。
• 服務(wù)故障停止51.4分鐘后，長窗口錯誤預(yù)算消耗平均值速率低于14.4，不會再觸發(fā)。

你可以在前一小時和前五分鐘超過14.4倍錯誤預(yù)算消耗速率時發(fā)送工單，只有在消耗了2％的錯誤預(yù)算后，才發(fā)送報警。5分鐘后短窗口不再觸發(fā)，此時報警恢復(fù)時間最佳。

優(yōu)點：

• 靈活的報警框架，允許你根據(jù)事件的嚴(yán)重性和組織的要求控制報警類型。
• 良好的精度，與所有固定預(yù)算的部分報警方法一樣。不錯的召回率，因為有三天的窗口。

缺點：要指定的參數(shù)很多，這可能使報警規(guī)則難以管理。

這種報警策略大大降低了報警恢復(fù)時間，是最合理的報警方式，但增加了報警復(fù)雜度，理解起來也有一定的成本。其實方案5也是一種不錯的選擇，這兩種方案都可以實施，具體選哪種報警策略視自己公司的監(jiān)控系統(tǒng)和報警能力而定。

B站目前的SLO報警是基于策略5做了一定調(diào)整，不同的服務(wù)等級設(shè)定了不同的報警窗戶和消耗率，大致如下：

目前我的SLO報警策略也不夠精確，缺少低錯誤預(yù)算消耗速率的報警和長時間窗口報警，會漏掉哪些在偷偷消耗錯誤預(yù)算的事件。我們的SLO報警會先向方案5靠齊，再朝著方案6優(yōu)化。

最后總結(jié)一下我們開啟SLO報警的指標(biāo)如下：

十、質(zhì)量運營

有了各個維度的SLI指標(biāo)和SLO報警后，我們可以很靈活的構(gòu)建質(zhì)量運營大盤，如：

• 基于業(yè)務(wù)SLI構(gòu)建業(yè)務(wù)指標(biāo)大盤。

• 基于業(yè)務(wù)核心功能SLI構(gòu)建業(yè)務(wù)健康度大盤。

• 基于業(yè)務(wù)和應(yīng)用的關(guān)聯(lián)關(guān)系構(gòu)建業(yè)務(wù)應(yīng)用健康度大盤。

• 業(yè)務(wù)可用率排名、應(yīng)用可用率排名。

• 業(yè)務(wù)大盤到業(yè)務(wù)核心功能到應(yīng)用指標(biāo)的場景監(jiān)控大盤。

總結(jié)

沒有SLO就沒有SRE？想必到這里大家對SLO的方法論和實踐已經(jīng)有了深刻的理解。僅度量SLI做可用性報表來給業(yè)務(wù)帶上枷鎖是沒意義的，SLO的核心價值是定義服務(wù)能力，設(shè)置SLO報警，及時發(fā)現(xiàn)線上問題，優(yōu)化報警和推動穩(wěn)定性治理，主動幫業(yè)務(wù)團隊去提升業(yè)務(wù)質(zhì)量，合作共贏。?