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