SLO是SRE中提出的一個(gè)工程理論，指出SLO指定了服務(wù)可靠性的目標(biāo)水平，是做出數(shù)據(jù)決策的一個(gè)關(guān)鍵指標(biāo)，也是SRE的核心。

結(jié)合SRE中的可靠性工程，B站也落地了自己的一整套實(shí)踐體系，如下圖所示，最上方是我們跟研發(fā)的協(xié)作體系，研發(fā)可以看到SRE的幾種角色，比如Oncall輪值、核心業(yè)務(wù)BP、PaaS平臺(tái)專家以及專門負(fù)責(zé)可靠性工程開發(fā)的SRE。可靠性工程中對(duì)服務(wù)的質(zhì)量運(yùn)營(yíng)就是通過(guò)SLO工程驅(qū)動(dòng)的可觀測(cè)、變更管理和報(bào)警治理。

一、可用性指標(biāo)困局

1.可用性對(duì)象多，指代不清

可用性的指向?qū)ο蠛芏啵虼宋覀兛赡懿磺宄捎眯缘木唧w內(nèi)容。實(shí)際上，可用性的度量可以是生產(chǎn)運(yùn)行的一個(gè)服務(wù)或應(yīng)用、應(yīng)用下的某一個(gè)接口、某一個(gè)業(yè)務(wù)模塊、某個(gè)團(tuán)隊(duì)或部門。

2.可用性度量難，數(shù)據(jù)標(biāo)準(zhǔn)、建模難

• 不可用難定義

度量可用性其實(shí)很難，首先我們要解決“什么是不可用”的問(wèn)題。怎樣的請(qǐng)求屬于失敗，需要提前制定標(biāo)準(zhǔn)，比如一個(gè)請(qǐng)求失敗是不可用，或一分鐘內(nèi)錯(cuò)誤率超過(guò)某個(gè)閾值是不可用，由此才能推動(dòng)后續(xù)實(shí)踐。

• 事故報(bào)告召回低、統(tǒng)計(jì)數(shù)據(jù)維度單一、監(jiān)控指標(biāo)難統(tǒng)計(jì)

傳統(tǒng)的可用性度量大多是基于故障的度量，如mttr指標(biāo)。但可用性的事故報(bào)告召回低，只有出現(xiàn)嚴(yán)重事故，才會(huì)生成故障報(bào)告。對(duì)于服務(wù)的某些短時(shí)間抖動(dòng)，我們一般不會(huì)通過(guò)數(shù)據(jù)報(bào)告的方式復(fù)盤。

3.運(yùn)營(yíng)需求場(chǎng)景多 ，報(bào)警、損失、報(bào)表等

可用性的數(shù)據(jù)還應(yīng)用于運(yùn)營(yíng)的場(chǎng)景。常見的運(yùn)營(yíng)需求包括報(bào)警能不能基于可用性完成；若出現(xiàn)生產(chǎn)故障，可用性損失的數(shù)據(jù)能否自動(dòng)產(chǎn)出，是否需要產(chǎn)出年度、月度或季度的可用性報(bào)表。

4.指標(biāo)、報(bào)警多，重點(diǎn)不清

隨著微服務(wù)體系發(fā)展，指標(biāo)和報(bào)警的數(shù)量攀升。當(dāng)SRE針對(duì)具體問(wèn)題進(jìn)行故障排查時(shí)，由于指標(biāo)過(guò)于豐富，我們?nèi)菀撞磺宄挪橹攸c(diǎn)或排查順序。除此之外，每次出現(xiàn)事故都會(huì)加報(bào)警，導(dǎo)致難以區(qū)分報(bào)警工單和巡檢，最終從報(bào)警的通道推送出來(lái)的基本都是噪音。

5.報(bào)警治理難，多維度報(bào)警無(wú)從下手

報(bào)警存在分層，IAAS、中間件、應(yīng)用、業(yè)務(wù)、終端等層面都有指標(biāo)，因此通知數(shù)量高達(dá)幾萬(wàn)條。為了保證通知到位，各項(xiàng)通知逐漸趨于高速度、高頻率，通知內(nèi)卷化嚴(yán)重。

二、SLI指標(biāo)的選擇和SLO的度量

1.SLO的方法論

先看一下整個(gè)SLO的方法論，這個(gè)方法論比較簡(jiǎn)單。

• SLI（服務(wù)等級(jí)指標(biāo)）：量化指標(biāo)，如服務(wù)的可用性延遲或容量。
• SLO（服務(wù)等級(jí)目標(biāo)）：量化指標(biāo)的目標(biāo)。
• SLA（服務(wù)等級(jí)協(xié)議）：SLO與后果，比如低于這個(gè)目標(biāo)之后，需承擔(dān)的后果和賠償。例如，公有云的云服務(wù)都制定了SLA協(xié)議，若可用性低于某個(gè)值，則需要以代金券等方式進(jìn)行賠償。在SLO工程中，基本上不會(huì)涉及SLA。

SLO指定了服務(wù)可靠性的目標(biāo)水平，是做出可靠性決策的關(guān)鍵數(shù)據(jù)，也是SRE實(shí)踐的核心。

2.常見SLO模型

對(duì)于一些常見的SLO模型，SRE也給了一個(gè)例子，是一個(gè)名為VALET的模型，對(duì)應(yīng)了5條指標(biāo)，即容量、可能性、延遲、錯(cuò)誤和工單。

3.實(shí)施SLO的理想流程

在SRE中，一個(gè)實(shí)施SLO的理想流程如下：

1）SLI選擇計(jì)算

首先，選擇指標(biāo)。以可用性為例，若指標(biāo)屬于請(qǐng)求驅(qū)動(dòng)型，那么成功響應(yīng)的請(qǐng)求比例除以總的請(qǐng)求，即可得到可用性量化指標(biāo)。此外，該指標(biāo)還能夠度量服務(wù)請(qǐng)求的延遲與請(qǐng)求的質(zhì)量。

其次，定義錯(cuò)誤。比如，HTTP 500、504、503是錯(cuò)誤，或404、429、403是錯(cuò)誤？

最后，度量數(shù)據(jù)。通過(guò)應(yīng)用的服務(wù)器日志、負(fù)載均衡或客戶端進(jìn)行度量時(shí)，SRE里推薦選擇負(fù)載均衡度量，因?yàn)檫@一層的度量成本與客戶端相較更低，并且可以度量從負(fù)載均衡到服務(wù)內(nèi)部所有鏈路的數(shù)據(jù)。

2）SLO定義

數(shù)據(jù)度量完成后，即可進(jìn)行SLO的定義，其具體做法與SLI類似。

3）錯(cuò)誤預(yù)算

即基于你的SLI指標(biāo)，得出時(shí)間窗口內(nèi)的允許錯(cuò)誤預(yù)算。例如，可用性全年是99.99%，那么基于一年的時(shí)間窗口就可得知一年內(nèi)99.99%的SLO允許的不可用時(shí)間是52分鐘。

當(dāng)錯(cuò)誤預(yù)算消耗殆盡時(shí)，可以制定一個(gè)策略，比如要求研發(fā)凍結(jié)生產(chǎn)系統(tǒng)的日常迭代，除非研發(fā)要做緊急的bug修復(fù)，或需要優(yōu)化生產(chǎn)的穩(wěn)定性。

4）儀表盤和報(bào)表

最后，需要一個(gè)儀表盤和報(bào)表來(lái)完成數(shù)據(jù)的展示和可視化，并持續(xù)改進(jìn)SLO。

4.SLO第一次嘗試

我們?cè)?019年做了第一次嘗試，按照這套體系去做整個(gè)SLO體系的度量和元信息的關(guān)聯(lián)。當(dāng)時(shí)的目標(biāo)是做一個(gè)非常準(zhǔn)確的度量數(shù)據(jù)，這個(gè)數(shù)據(jù)需要體現(xiàn)線上服務(wù)真實(shí)的可用性指標(biāo)，比如能體現(xiàn)它全年的可用性是多少，同時(shí)也能及時(shí)發(fā)現(xiàn)線上的問(wèn)題。但在實(shí)踐了大半年或一年左右之后，這套邏輯就難以為繼。

5.失敗反思

1）SLO生命周期運(yùn)營(yíng)

反思以上問(wèn)題后，我們重新構(gòu)建整個(gè)SLO生命周期的體系邏輯。

• 度量SLI，設(shè)置SLO

做指標(biāo)度量，設(shè)置SLO，增加指標(biāo)治理的步驟，提升指標(biāo)的準(zhǔn)確率。指標(biāo)治理完成后，度量可用率、數(shù)據(jù)延遲和業(yè)務(wù)指標(biāo)，使SRE和研發(fā)具備一致的觀測(cè)能力。

• SLO報(bào)警及智能診斷

基于這些指標(biāo)做SLO的告警，將其與傳統(tǒng)的告警區(qū)分，務(wù)必提供一個(gè)精確高效、透明分發(fā)的渠道。

• 錯(cuò)誤預(yù)算與SLO報(bào)警運(yùn)營(yíng)

保留錯(cuò)誤預(yù)算，但將其與SLO報(bào)警相結(jié)合，用于找出服務(wù)故障的共性因素，并與研發(fā)共同進(jìn)行穩(wěn)定性的治理。

• SLO報(bào)表與儀表盤

做報(bào)表和儀表盤，使業(yè)務(wù)能綜合觀察到日、周、月、季、年的歷史可用率報(bào)表，能看到錯(cuò)誤預(yù)算消耗，包括可用率的排名等內(nèi)容。

• SLO生態(tài)建設(shè)

建立整個(gè)SLO的生態(tài)數(shù)據(jù)，一定要把SLO的指標(biāo)擴(kuò)展到上層的使用平臺(tái)，比如CI、CD、壓測(cè)平臺(tái)或內(nèi)部的多活管控平臺(tái)。只要是服務(wù)變更的核心平臺(tái)，就可以把服務(wù)SLO的指標(biāo)擴(kuò)展到平臺(tái)上，使研發(fā)在平臺(tái)中就能看到服務(wù)實(shí)時(shí)的可用性指標(biāo)，也可以用這個(gè)指標(biāo)完成變更預(yù)檢、發(fā)布觀測(cè)、智能阻斷等。

整個(gè)模式建立在CMDB元信息、微服務(wù)框架、可觀測(cè)能力、報(bào)警中心、事件中心以及AIOps能力的基礎(chǔ)上。

2）可用性指標(biāo)選擇

進(jìn)行指標(biāo)可用性的度量最常見的兩種模式：一是度量請(qǐng)求成功率，二是度量服務(wù)的可用時(shí)間。

請(qǐng)求成功率：只要定義什么是錯(cuò)誤，就能知道錯(cuò)誤率，從而就能得出請(qǐng)求成功率。它的計(jì)算非常簡(jiǎn)單，你只要找出錯(cuò)誤的code，再做治理，最后統(tǒng)計(jì)出錯(cuò)誤code即可。

可用時(shí)間：這個(gè)計(jì)算會(huì)更為復(fù)雜，首先要度量什么是不可用時(shí)間。比如，一分鐘服務(wù)的錯(cuò)誤率大于20%時(shí)，就認(rèn)定這一分鐘不可用，那么統(tǒng)計(jì)出不可用的時(shí)間，算出總時(shí)間，即可得到服務(wù)的可用性。

根據(jù)我們之前的實(shí)踐經(jīng)驗(yàn)，對(duì)以上兩種方式的選擇主要考慮指標(biāo)的準(zhǔn)確度。哪個(gè)指標(biāo)有價(jià)值，哪個(gè)指標(biāo)能發(fā)現(xiàn)線上問(wèn)題，哪個(gè)指標(biāo)對(duì)業(yè)務(wù)價(jià)值大，就用哪個(gè)指標(biāo)。而對(duì)報(bào)警的精確度來(lái)說(shuō)，基于時(shí)間的統(tǒng)計(jì)方式的錯(cuò)誤率是固定的，錯(cuò)誤率不達(dá)標(biāo)也不代表用戶不受影響，所以通常會(huì)選擇基于請(qǐng)求成功率。線上問(wèn)題發(fā)現(xiàn)率的統(tǒng)計(jì)也是基于請(qǐng)求成功率，這對(duì)業(yè)務(wù)價(jià)值最大。

3）SLI指標(biāo)治理：錯(cuò)誤治理

運(yùn)用請(qǐng)求成功率最核心的一點(diǎn)就是要完成錯(cuò)誤的標(biāo)準(zhǔn)化和錯(cuò)誤的識(shí)別。

在一個(gè)網(wǎng)絡(luò)鏈路中，會(huì)出現(xiàn)很多錯(cuò)誤。比如，基于TCP/HTTP的一個(gè)簡(jiǎn)單模型來(lái)看，Client發(fā)SYN包的時(shí)候，Server有可能遇到網(wǎng)絡(luò)不可查或者網(wǎng)絡(luò)超時(shí)等情況，然后Client會(huì)發(fā)送SYN Retry。當(dāng)把數(shù)據(jù)包發(fā)過(guò)去之后，對(duì)端的端口可能掛了，數(shù)據(jù)包也會(huì)Reset。

例如，在讀緩存或者讀DB這些強(qiáng)依賴或者依賴一個(gè)下游服務(wù)不可用時(shí)，服務(wù)會(huì)出現(xiàn)請(qǐng)求正確性的錯(cuò)誤，雖然在一定的時(shí)間內(nèi)將請(qǐng)求處理完畢，但相應(yīng)的數(shù)據(jù)出現(xiàn)錯(cuò)誤。

因此在這條鏈路中，基于Client和Server的視角都可能出現(xiàn)不同類別的錯(cuò)誤。不管是基于SLB的Client的視角，還是基于服務(wù)上下游調(diào)用的Client的視角，對(duì)下游服務(wù)的熔斷、下游服務(wù)網(wǎng)絡(luò)不可達(dá)、下游服務(wù)應(yīng)用無(wú)響應(yīng)或者響應(yīng)超時(shí)，以及下游服務(wù)雖響應(yīng)但返回了一個(gè)錯(cuò)誤的內(nèi)容等這些情況，都是不可用的場(chǎng)景。

而基于Server的視角，只有這種場(chǎng)景能通過(guò)Server的視角度量出來(lái)：Server返回請(qǐng)求，但請(qǐng)求返回的是錯(cuò)誤內(nèi)容，如業(yè)務(wù)錯(cuò)誤code碼。

• 錯(cuò)誤碼標(biāo)準(zhǔn)化

SLB視角：HTTP 5xx

當(dāng)錯(cuò)誤的類型定義清楚后，就要定義我們的Code碼，而從負(fù)載均衡的視角來(lái)看，比如說(shuō)我們的基本是5xx。

Server視角：業(yè)務(wù)Code -5xx

我們參考HTTP 5xx對(duì)業(yè)務(wù)的Code碼做了一個(gè)-5xx的定義，比如服務(wù)內(nèi)部錯(cuò)誤，導(dǎo)致內(nèi)部業(yè)務(wù)邏輯無(wú)法處理，會(huì)把錯(cuò)誤return出來(lái)，一般會(huì)出現(xiàn)一個(gè)-500或-504。

如果因?yàn)檎{(diào)用下游服務(wù)超時(shí)而導(dǎo)致整個(gè)鏈路的耗時(shí)消耗完畢，服務(wù)無(wú)法處理，會(huì)拋一個(gè)-504；如果服務(wù)接了限流的框架，限流時(shí)會(huì)拋一個(gè)-509。

Client視角：業(yè)務(wù)Code -5xx

4）可用性SLI：多維計(jì)算

最終對(duì)服務(wù)的度量集中在兩個(gè)維度：

• SLB HTTP 5xx：

從SLB的層面看負(fù)載均衡中所上報(bào)的服務(wù)的5xx錯(cuò)誤量、服務(wù)的QPS以及服務(wù)的耗時(shí)。SLB層面若產(chǎn)生了5xx的Code碼，那就代表應(yīng)用訪問(wèn)超時(shí)、容器OOM或者進(jìn)程Panic等不可用，這都是一些非常嚴(yán)重的故障。

• HTTP/gRPC Server -5xx：

另一層面是在服務(wù)本身的Metrics層面上報(bào)。我們的服務(wù)可能分為HTTP的協(xié)議和gRPC的協(xié)議，不同的協(xié)議可能是不同的Metrics，所以最終會(huì)在SLB層面去度量SLO，然后在服務(wù)層面度量HTTP和gRPC的請(qǐng)求。

我們?cè)诙攘糠?wù)本身的Metrics時(shí)，發(fā)現(xiàn)它出現(xiàn)了一些-5xx的Code碼，這個(gè)對(duì)應(yīng)的場(chǎng)景就是應(yīng)用HTTP Code 200，但因依賴下游服務(wù)、讀取DB、CACHE失敗等系統(tǒng)錯(cuò)誤時(shí)，則會(huì)在應(yīng)用Metrics側(cè)上報(bào)業(yè)務(wù)Code的錯(cuò)誤指標(biāo)。

通過(guò)這兩種指標(biāo)的度量，就能度量出服務(wù)所有的故障場(chǎng)景。

5）數(shù)據(jù)延遲SLI

除了可用性的度量外，我們還對(duì)服務(wù)的延遲指標(biāo)做了度量，此延遲所指的不是接口的延遲，而是存儲(chǔ)和數(shù)據(jù)層面的延遲。因?yàn)槲覀冏隽送请p活，同城雙活中有很多數(shù)據(jù)同步的場(chǎng)景，比如數(shù)據(jù)庫(kù)的同步和緩存的同步等。數(shù)據(jù)若產(chǎn)生延遲，將嚴(yán)重影響用戶體驗(yàn)。

6）業(yè)務(wù)指標(biāo)SLI

技術(shù)指標(biāo)有時(shí)無(wú)法發(fā)現(xiàn)業(yè)務(wù)指標(biāo)層面的問(wèn)題和故障。

我們以前遇到過(guò)一些案例：如用戶頻繁掉登錄，最后發(fā)現(xiàn)是APP上誤踢登錄；還有用戶充值失敗，最后發(fā)現(xiàn)是業(yè)務(wù)邏輯的bug。

7）多對(duì)象、多SLI、多指標(biāo)計(jì)算

最終我們的度量方式是多對(duì)象，多SLI指標(biāo)，多SLI實(shí)現(xiàn)。

度量對(duì)象的第一層級(jí)就是業(yè)務(wù)，業(yè)務(wù)通過(guò)大數(shù)據(jù)的一些流式實(shí)時(shí)計(jì)算以及數(shù)據(jù)庫(kù)的Binlog來(lái)做度量，它用于度量在線人數(shù)、播放量、評(píng)論、彈幕、登錄和營(yíng)收等指標(biāo)。

我們還度量了業(yè)務(wù)的某些核心功能。例如，無(wú)論是發(fā)彈幕評(píng)論還是登錄，都有對(duì)應(yīng)的服務(wù)端的API，它面向用戶側(cè)的公網(wǎng)訪問(wèn)。我們會(huì)把這些API度量出來(lái)，然后通過(guò)服務(wù)端的技術(shù)指標(biāo)來(lái)觀察這些功能的可能性。因?yàn)闃I(yè)務(wù)指標(biāo)的度量更多是一個(gè)吞吐量的變化，通過(guò)服務(wù)端的技術(shù)指標(biāo)對(duì)這些接口做度量，觀察公網(wǎng)接口，最終將成功或失敗的結(jié)果反饋給用戶，由此能度量出核心功能的可用性。

生產(chǎn)系統(tǒng)中有成千上萬(wàn)的API，不可能度量出所有的API，所以我們有一個(gè)兜底策略，即對(duì)所有的應(yīng)用都使用這套可用性的度量指標(biāo)。針對(duì)接口，我們可能會(huì)在SLB、API GW這種偏外網(wǎng)的入口層面做接口的度量，應(yīng)用方面則會(huì)在Promethues埋點(diǎn)，同時(shí)也會(huì)度量它用到的存儲(chǔ)組件的延遲指標(biāo)。在實(shí)踐中，我們發(fā)現(xiàn)技術(shù)指標(biāo)召回的問(wèn)題遠(yuǎn)遠(yuǎn)大于業(yè)務(wù)指標(biāo)召回的問(wèn)題，因?yàn)闃I(yè)務(wù)指標(biāo)一旦產(chǎn)生問(wèn)題，就代表生產(chǎn)已經(jīng)發(fā)生了非常明顯的故障。

由于不是每一個(gè)服務(wù)都直接對(duì)用戶提供公網(wǎng)功能，很多服務(wù)可能時(shí)內(nèi)網(wǎng)服務(wù)，或是下游依賴的服務(wù)，產(chǎn)生不可用問(wèn)題的時(shí)候就會(huì)被SLO發(fā)現(xiàn)，同時(shí)發(fā)出告警。但最終用戶可能沒(méi)有感知，因?yàn)樯嫌捂溌泛荛L(zhǎng)，很有可能在某一個(gè)鏈路就被熔斷或者被降級(jí)，所以服務(wù)的故障不代表最終用戶的故障，服務(wù)維度的技術(shù)指標(biāo)所召回的問(wèn)題遠(yuǎn)遠(yuǎn)大于業(yè)務(wù)指標(biāo)召回的問(wèn)題。

三、SLO報(bào)警實(shí)踐

前文也提到了告警的問(wèn)題，例如，每次出事故都加告警、報(bào)警狼來(lái)了、全是噪音以及報(bào)警準(zhǔn)確率低等，令人無(wú)從下手……問(wèn)題在哪？我們?cè)谧鯯LO告警時(shí)慢慢發(fā)現(xiàn)了根因。

1.SLO的告警是果，其他告警是因

做故障復(fù)盤時(shí)之所以要加告警，是因?yàn)榘l(fā)現(xiàn)這個(gè)服務(wù)的CPU產(chǎn)生抖動(dòng)、服務(wù)磁盤的使用率過(guò)高、磁盤滿了都會(huì)導(dǎo)致服務(wù)出異常。每一個(gè)因最終都有可能影響服務(wù)的穩(wěn)定性，但是SLO是真正代表服務(wù)的可用性的指標(biāo)，它是一個(gè)果，只要你有了這個(gè)果，就能做到兜底，無(wú)需再加各種因。

我們以往的報(bào)警沒(méi)有區(qū)分系統(tǒng)錯(cuò)誤和業(yè)務(wù)錯(cuò)誤，也沒(méi)有清晰定義出研發(fā)需要關(guān)注的錯(cuò)誤，導(dǎo)致每天可能有幾萬(wàn)條報(bào)警，研發(fā)難以一一查看。如果Code碼不是200就報(bào)警，那么這種報(bào)警就沒(méi)有任何意義。

最終我們以SLO告警作為核心，規(guī)劃新的報(bào)警治理。

1）SLO告警降噪思路

• 研發(fā)只關(guān)注應(yīng)用告警

研發(fā)只需要關(guān)注應(yīng)用告警，包括SLO的告警和影響SLO的常見因素，最常見的三種是依賴錯(cuò)誤、中間件異常、容量。我們可以通過(guò)HPA的策略解決容量問(wèn)題，比如全部覆蓋HPA，在CPU超過(guò)50%或者60%的擴(kuò)容情況下，就不會(huì)每天收到大量報(bào)警。

• 通過(guò)應(yīng)用SLO指標(biāo)發(fā)現(xiàn)對(duì)下層（中間件、組件）依賴錯(cuò)誤

以數(shù)據(jù)庫(kù)不可用為例，以往研發(fā)可能會(huì)收到業(yè)務(wù)的數(shù)據(jù)庫(kù)不可用的告警，或者緩存。如果產(chǎn)生了主從切換，或緩存的某一個(gè)節(jié)點(diǎn)宕機(jī)，研發(fā)可能會(huì)收到業(yè)務(wù)用到某一個(gè)緩存不可用而宕機(jī)的告警，但是現(xiàn)在的思路則是，研發(fā)無(wú)需再關(guān)注中間件層面的告警，只需通過(guò)自己應(yīng)用側(cè)埋點(diǎn)的指標(biāo)就可以發(fā)現(xiàn)中間件的問(wèn)題。

• 下層告警對(duì)研發(fā)透明

服務(wù)可以上報(bào)對(duì)緩存的一個(gè)依賴指標(biāo)，它會(huì)上報(bào)出對(duì)緩存的每一次請(qǐng)求是否成功，耗時(shí)多少等情況。如果緩存出現(xiàn)問(wèn)題，按業(yè)務(wù)指標(biāo)直接上報(bào)出來(lái)即可。如果緩存發(fā)生了主從切換，但是最終對(duì)服務(wù)的SLO沒(méi)有任何影響，那么研發(fā)完全可以無(wú)視這個(gè)事件。同時(shí)，難免有些業(yè)務(wù)未能達(dá)成此類最佳實(shí)踐，研發(fā)也可以按需去訂閱下層的告警。

2）SLO告警運(yùn)營(yíng)體系：1-5-10 

• 設(shè)置SLO告警

在設(shè)置SLO告警時(shí)，需要精確的計(jì)算邏輯避免無(wú)效告警。這方面我們使用了SRE中提到的錯(cuò)誤預(yù)算窗口、消耗率、多消耗率報(bào)警及多窗口的計(jì)算策略。

• 分發(fā)和協(xié)同

傳統(tǒng)的分發(fā)和協(xié)同一般通過(guò)短信或者IM工具，比如釘釘、企業(yè)微信等渠道。并且傳統(tǒng)的報(bào)警都是面向于某一個(gè)應(yīng)用，發(fā)送給權(quán)限人，但由于元信息平臺(tái)人員的權(quán)限一般不會(huì)因?yàn)榻M織架構(gòu)調(diào)整或者是研發(fā)的職責(zé)調(diào)整而出現(xiàn)變更，所以難以精確識(shí)別出關(guān)注應(yīng)用告警的研發(fā)人員。比如，一個(gè)服務(wù)產(chǎn)生問(wèn)題，可能收到報(bào)警的有三四十人，其中真正關(guān)心服務(wù)的人員可能只有兩三個(gè)。

• 根因定位

我們做了一個(gè)智能診斷的平臺(tái)，結(jié)合可觀測(cè)，使研發(fā)能夠在5分鐘內(nèi)定位問(wèn)題。

• 運(yùn)營(yíng)分析

導(dǎo)出SLO告警的數(shù)據(jù)，分析每個(gè)團(tuán)隊(duì)的處理效率。結(jié)合研發(fā)反饋的告警有效性，將這些數(shù)據(jù)用于運(yùn)營(yíng)分析，以此了解告警的預(yù)算消耗、告警觸發(fā)的原因。告警準(zhǔn)確率高、低噪音、故障高召回、智能快速診斷、公開透明、高效協(xié)同是這一套機(jī)制運(yùn)轉(zhuǎn)下去的前提。

SRE提出了兩個(gè)概念，第一個(gè)概念是錯(cuò)誤預(yù)算，第二個(gè)是消耗率。

錯(cuò)誤預(yù)算對(duì)風(fēng)險(xiǎn)識(shí)別、故障定級(jí)和穩(wěn)定性決策十分重要。如果要做變更，比如生產(chǎn)要做網(wǎng)絡(luò)割接、或某個(gè)服務(wù)要變更維護(hù)，一定會(huì)對(duì)服務(wù)產(chǎn)生影響。過(guò)去對(duì)服務(wù)的嚴(yán)重程度是以時(shí)間來(lái)度量，現(xiàn)在轉(zhuǎn)而查看它會(huì)消耗多少的錯(cuò)誤預(yù)算。

3）SLO告警策略

• 目標(biāo)錯(cuò)誤率≥SLO

基于你制定的SLO（包括錯(cuò)誤預(yù)算和消耗率）制定報(bào)警策略，若目標(biāo)錯(cuò)誤率大于SLO，就可以告警。

缺點(diǎn)：假如這個(gè)服務(wù)每時(shí)每刻的錯(cuò)誤率剛好都是0.1%，若一分鐘報(bào)警一次，一天能報(bào)1440次，但這個(gè)服務(wù)的可用率剛好還是99.9%，滿足SLO的要求。

• 錯(cuò)誤預(yù)算窗口

增加時(shí)間窗口。例如，報(bào)警策略是消耗30天的窗口的5%，即36小時(shí)，把36小時(shí)的錯(cuò)誤預(yù)算消耗完畢后，再發(fā)出一條告警。這種告警也不太合適，原因有二，其一，假設(shè)以一個(gè)36小時(shí)的窗口來(lái)做計(jì)算，那么報(bào)警觸發(fā)后，在36小時(shí)的滑動(dòng)窗口的一段時(shí)間內(nèi)，會(huì)持續(xù)發(fā)出告警；其二，假如錯(cuò)誤率剛好是0.1%，剛好是SLO閾值的臨界點(diǎn)，那么就要達(dá)到36小時(shí)才能觸發(fā)告警。

• 增加報(bào)警持續(xù)時(shí)間

可以增加單個(gè)報(bào)警的持續(xù)時(shí)間，比如SLO低于閾值10分鐘之后發(fā)出告警，或者低于SLO閾值一小時(shí)后發(fā)出告警。

缺點(diǎn)：不論服務(wù)是100%不可用，還是0.1%不可用，都是在10分鐘后發(fā)出告警，報(bào)警的靈敏度與服務(wù)的錯(cuò)誤率無(wú)關(guān)。針對(duì)此問(wèn)題，SRE提出了消耗率的概念。

• 多次消耗率報(bào)警

嚴(yán)重故障：1小時(shí)消耗月度2％(14.4h)的預(yù)算消耗，發(fā)出緊急報(bào)警。

輕微故障：6小時(shí)消耗月度5％(36h)的錯(cuò)誤預(yù)算，發(fā)出緊急報(bào)警。

兜底策略：3天消耗月度10％(3d)的預(yù)算，發(fā)出故障工單。

• 多窗口，多消耗率報(bào)警

以一小時(shí)的窗口做報(bào)警計(jì)算為例，若5分鐘時(shí)錯(cuò)誤已經(jīng)告警，那么接下來(lái)的55分鐘也會(huì)繼續(xù)發(fā)出告警。因此這個(gè)策略增加另一個(gè)窗口，在報(bào)警和恢復(fù)時(shí)檢查是否仍然達(dá)到錯(cuò)誤預(yù)算消耗速率。

這需要兩個(gè)條件，一是必須把一個(gè)小時(shí)的錯(cuò)誤預(yù)算消耗完畢，二是在接下來(lái)檢測(cè)的時(shí)間窗口內(nèi)錯(cuò)誤率仍很高，應(yīng)對(duì)的場(chǎng)景是服務(wù)的可用率馬上歸零，又馬上恢復(fù)。這種場(chǎng)景下報(bào)警可立即觸發(fā)，并立即恢復(fù)。

由于錯(cuò)誤預(yù)算和消耗率理解起來(lái)太復(fù)雜，所以用時(shí)間窗口、可用率和錯(cuò)誤量的概念替代錯(cuò)誤預(yù)算和消耗率。我們將服務(wù)進(jìn)行線上分級(jí)，按照服務(wù)的等級(jí)分梯度設(shè)置報(bào)警條件，緊急窗口用于發(fā)現(xiàn)嚴(yán)重事故，非緊急的窗口用于處理一些低速流血的問(wèn)題。

比如，緊急窗口用于發(fā)現(xiàn)服務(wù)的平均可用率低于某個(gè)值，同時(shí)錯(cuò)誤量最近一分鐘大于某個(gè)值，這就是緊急的報(bào)警窗口。非緊急窗口是指服務(wù)一天的可用性剛好低于SLO，制定好報(bào)警策略后，此時(shí)報(bào)警能夠發(fā)現(xiàn)線上的緊急問(wèn)題和非緊急問(wèn)題。

4）SLO告警分發(fā)、協(xié)同

我們借助事件中心的分發(fā)能力，重新做了一套告警分發(fā)協(xié)同的機(jī)制。

這種方式可以實(shí)現(xiàn)對(duì)人員的精確識(shí)別，并擁有一個(gè)高質(zhì)量的協(xié)同群渠道。整個(gè)報(bào)警采取公開、透明、協(xié)同的處理方式，補(bǔ)充了傳統(tǒng)報(bào)警方式缺失的能力。但需要注意，不能用一些誤報(bào)率很高的報(bào)警運(yùn)行這套機(jī)制，這種低質(zhì)量的告警推送到群內(nèi)會(huì)產(chǎn)生刷屏現(xiàn)象。

5）SLO告警根因定位

步驟如下：

在我們的場(chǎng)景中，只垂直做服務(wù)的故障，就會(huì)發(fā)現(xiàn)根因定位邊界很清晰。基于業(yè)務(wù)指標(biāo)、應(yīng)用指標(biāo)、中間件指標(biāo)以及服務(wù)的容量指標(biāo)，就可以發(fā)現(xiàn)服務(wù)的故障點(diǎn)。因此，我們只需要做故障定界，無(wú)需立刻定位服務(wù)的根因。在當(dāng)前的微服務(wù)架構(gòu)下，只要知道服務(wù)故障點(diǎn)的位置，就可立刻止損。

6）案例分享

我們?cè)谌豪锿瞥隽艘粭lSLO的告警，并在告警卡片里會(huì)推送一個(gè)SLO的診斷鏈接，然后直接@服務(wù)所負(fù)責(zé)的或做過(guò)變更的研發(fā)。研發(fā)直接點(diǎn)開鏈接就可以快速地做故障的定界，確認(rèn)接口和服務(wù)的錯(cuò)誤類型。

在根因分析方面，我們會(huì)觀察它依賴的資源、依賴的下游服務(wù)或者依賴的中間件，使研發(fā)能快速得知具體的服務(wù)故障點(diǎn)。故障定界后，研發(fā)做止損，最后服務(wù)恢復(fù)，完成故障修復(fù)。針對(duì)SLO的故障場(chǎng)景，上文提到用于生產(chǎn)的實(shí)際模型，可以達(dá)成1分鐘報(bào)警、研發(fā)5分鐘完成故障定界兩個(gè)目標(biāo)。

四、SLO運(yùn)營(yíng)

1.SLO指標(biāo)運(yùn)營(yíng)

2.SLO報(bào)警運(yùn)營(yíng)

只要把告警發(fā)到群里，研發(fā)都會(huì)處理，因?yàn)楦婢浅?zhǔn)確，一旦發(fā)生就代表服務(wù)出問(wèn)題。與研發(fā)唯一的分歧是SLO告警出來(lái)后表示服務(wù)不可用，但是這個(gè)服務(wù)沒(méi)那么重要，研發(fā)會(huì)基于上游容忍自己服務(wù)錯(cuò)誤的原因，將其判斷為誤報(bào)。

這種場(chǎng)景下報(bào)警仍然準(zhǔn)確，但需要抑制服務(wù)的一些報(bào)警條件或者觸發(fā)條件，降低敏感度。

3.SLO與變更檢測(cè)

要建設(shè)整個(gè)SLO的生態(tài)，就要把SLO與變更檢測(cè)相結(jié)合。我們把實(shí)時(shí)的SLO指標(biāo)如可用率、錯(cuò)誤、QPS、延遲SLO擴(kuò)展到容器平臺(tái)之類的上層平臺(tái)，服務(wù)在發(fā)布和變更時(shí)集成了SLO的指標(biāo)大盤，研發(fā)可以實(shí)時(shí)看到自己服務(wù)的可用率和錯(cuò)誤量。在多活的管控平臺(tái)中，多活切量時(shí)也有服務(wù)SLO指標(biāo)的觀測(cè)，我們可以用這些指標(biāo)做變更的預(yù)檢，觀察服務(wù)整體的健康情況。

在發(fā)布中也可以做觀測(cè)和智能阻斷，一旦發(fā)現(xiàn)服務(wù)的指標(biāo)出現(xiàn)了可用性的下跌，可以智能阻斷該次變更。

Q&A

Q1: BiliBili是度量了每個(gè)服務(wù)的SLO嗎？

A1：對(duì)，我們度量的對(duì)象有三種，第一是業(yè)務(wù)，第二是通過(guò)API來(lái)度量業(yè)務(wù)的某一個(gè)功能，第三是使用這套指標(biāo)針對(duì)每個(gè)服務(wù)做一個(gè)度量。因?yàn)樯a(chǎn)的API非常多，不可能把所有API都度量出來(lái)。面對(duì)服務(wù)沒(méi)有任何指標(biāo)的情況，就無(wú)法進(jìn)行度量，但只要有指標(biāo)就可以度量出來(lái)。

Q2: 如果想度量一個(gè)系統(tǒng)的可用率，這個(gè)系統(tǒng)由50個(gè)微服務(wù)組成，是取平均值嗎？

A2：不是的，取平均值并無(wú)意義。首先要看是中間件還是一個(gè)業(yè)務(wù)系統(tǒng)。假設(shè)是一個(gè)業(yè)務(wù)系統(tǒng)，比如登錄系統(tǒng)，里面可能有10個(gè)微服務(wù)，可以把登錄相關(guān)的核心接口定義出來(lái)，用它們的可用率度量這個(gè)登錄系統(tǒng)的可用率，把所有的錯(cuò)誤量、請(qǐng)求量全部相加，累加之后再去算整體的可用率，而不應(yīng)該取平均值。因?yàn)槿绻?wù)某一個(gè)功能的可用率很低，平均之后這個(gè)數(shù)據(jù)就會(huì)失真。

比如有一個(gè)服務(wù)每天的請(qǐng)求量是1萬(wàn)，今天的可用率只有90%，另一個(gè)服務(wù)每天的請(qǐng)求量可能只有100，這兩個(gè)數(shù)據(jù)一旦平均，數(shù)據(jù)失真就會(huì)特別嚴(yán)重，所以不建議取平均值。

Q3: oncall人員會(huì)收到所有的告警嗎，若收不到，有問(wèn)題無(wú)法觸發(fā)oncall人員，如果收又會(huì)被告警轟炸，這種情況怎么辦？

A3：首先告警體系本身是分級(jí)的，處在不同層級(jí)的人關(guān)注的告警不一樣。例如存儲(chǔ)中間件的同學(xué)會(huì)關(guān)注中間件的指標(biāo)，SRE可能會(huì)關(guān)注應(yīng)用的指標(biāo)，也會(huì)關(guān)注部分中間件的指標(biāo)，而研發(fā)關(guān)注的也是應(yīng)用本身的指標(biāo)和部分中間件的指標(biāo)，相關(guān)人員需要接收自己有權(quán)限的服務(wù)報(bào)警。

至于告警轟炸問(wèn)題，傳統(tǒng)的告警加的是因。只要這個(gè)指標(biāo)的波動(dòng)有可能影響服務(wù)的可用性，我們就會(huì)添加一堆告警，這種情況下屬于告警轟炸。但如果能把服務(wù)的SLO指標(biāo)清晰定義并度量出來(lái)，用這個(gè)指標(biāo)做報(bào)警，由此很多基于因的報(bào)警都可以慢慢下線。

Q4:這套體系是否只針對(duì)業(yè)務(wù)開發(fā)，對(duì)SRE 有沒(méi)有告警降噪的案例？

A4：不是的，這套體系針對(duì)業(yè)務(wù)開發(fā)和SRE，雙方共同關(guān)注告警。至于告警降噪的案例，我們這套告警上線后，對(duì)應(yīng)用的其他告警做了策略的調(diào)整，包括告警的下線。比方說(shuō)有一個(gè)APP接了限流框架，觸發(fā)限流的告警，每天的告警數(shù)量可能有幾萬(wàn)條。SLO告警上線后，我直接取消了這個(gè)告警。因?yàn)榉?wù)觸發(fā)限流之后，只要達(dá)到一定的錯(cuò)誤率，就會(huì)被SLO報(bào)警所觸發(fā)，然后按照企微協(xié)同，再到SLO的根因定位的一套機(jī)制處理限流告警，所以無(wú)需一些基于因的度量告警。

Q5:線上壓測(cè)流量、測(cè)試用戶的誤告怎么處理？

A5：測(cè)試用戶可以通過(guò)生產(chǎn)一種灰度或者染色的方式來(lái)處理，即對(duì)用戶流量做一些打標(biāo)。我們可以在指標(biāo)上報(bào)的時(shí)候加上這種標(biāo)簽，這個(gè)操作在我們的系統(tǒng)種稱為染色，這個(gè)請(qǐng)求帶有一個(gè)顏色標(biāo)簽，那么在它的指標(biāo)中，染色的標(biāo)簽可以識(shí)別并被上報(bào)。

我們?cè)跍y(cè)試環(huán)境做SLO指標(biāo)度量和報(bào)警的時(shí)候，就不會(huì)再看染色的流量，而是只看基準(zhǔn)版本的流量。如果生產(chǎn)的問(wèn)題很嚴(yán)重，可以用類似的方式，即只看你基準(zhǔn)版本的流量，不看染色的流量，或者將兩個(gè)流量的報(bào)警場(chǎng)景區(qū)分開。

Q6:如何探測(cè)SLO是否已經(jīng)達(dá)到閾值？

A6：SLO的計(jì)算本質(zhì)上還是通過(guò)Promethues計(jì)算，只是報(bào)警觸發(fā)的窗口即錯(cuò)誤預(yù)算窗口和消耗率這兩個(gè)概念太難理解，所以我們換成了一個(gè)服務(wù)的可用率加一個(gè)計(jì)算的時(shí)間窗口，本質(zhì)還是Promethues來(lái)做計(jì)算。

Q7:剛開始進(jìn)行SLO建設(shè)，如何說(shuō)服研發(fā)團(tuán)隊(duì)配合?

A7：我們內(nèi)部也經(jīng)常遇到這種場(chǎng)景，這個(gè)部門出現(xiàn)了一個(gè)事故，但沒(méi)有報(bào)警，就會(huì)問(wèn)能不能用SLO告警覆蓋，感覺(jué)SLO是萬(wàn)能的，然后我們就找研發(fā)團(tuán)隊(duì)去聊如何做SLO告警。其實(shí)它的前提是首先要定義你的SLI指標(biāo)，要看這個(gè)業(yè)務(wù)系統(tǒng)要度量什么。對(duì)在線服務(wù)來(lái)說(shuō)，可用率是最核心的度量指標(biāo)。但可用率這個(gè)指標(biāo)怎么度量，有哪些上報(bào)的指標(biāo)可以度量出來(lái)？舉個(gè)例子，可以通過(guò)負(fù)載均衡的指標(biāo)來(lái)度量，服務(wù)如果沒(méi)有接Promethues的埋點(diǎn)SDK，就無(wú)法通過(guò)服務(wù)度量。但服務(wù)會(huì)打日志，可以通過(guò)日志來(lái)度量。本質(zhì)來(lái)說(shuō)還是要有指標(biāo)，這是第一步。第二步，指標(biāo)一定要能呈現(xiàn)并上報(bào)服務(wù)產(chǎn)生的錯(cuò)誤。

只要滿足這兩個(gè)條件，就能做這套系統(tǒng)。它需要服務(wù)標(biāo)準(zhǔn)和微服務(wù)框架的配合，微服務(wù)框架中要有這套指標(biāo)和錯(cuò)誤，然后才能度量出一個(gè)非常精確的SLO系統(tǒng)。其實(shí)研發(fā)的配合就是在第一步做指標(biāo)治理這一方面，后續(xù)整個(gè)運(yùn)營(yíng)機(jī)制主要由SRE來(lái)建設(shè)。這套系統(tǒng)對(duì)研發(fā)來(lái)說(shuō)，能幫助他發(fā)現(xiàn)現(xiàn)象問(wèn)題，且報(bào)警非常準(zhǔn)確，能讓他快速定位線下問(wèn)題，這樣他一定會(huì)主動(dòng)配合你使用這套系統(tǒng)。

Q8:怎么解決抖動(dòng)告警？比如每隔幾分鐘 5xx錯(cuò)誤？

A8：這也是一個(gè)很常見的生產(chǎn)的報(bào)警模式，分兩種情況看，一種情況是報(bào)警很嚴(yán)重，服務(wù)已經(jīng)不可用，必須處理。

另一種情況就是你可以容忍服務(wù)短時(shí)間內(nèi)一個(gè)5xx，因?yàn)檫@個(gè)服務(wù)最近可用性很不好，研發(fā)和我們都知道。那可以調(diào)整報(bào)警策略，抑制每幾分鐘產(chǎn)生5xx的條件，比如可以把報(bào)警窗口放大，把5分鐘的窗口放大到10分鐘的窗口，5分鐘的可用率存99.9%，你可以把它降為99%，通過(guò)新的報(bào)警策略去抑制它。

還有一個(gè)方法是先靜默一段時(shí)間，服務(wù)最近的可能性下跌是一個(gè)已知的事實(shí)，等把服務(wù)的可能性優(yōu)化之后，再打開報(bào)警窗口。

Q9:收到告警之后如何知道具體是哪個(gè)錯(cuò)誤造成的？

A9：可以通過(guò)故障定界實(shí)現(xiàn)。SLO告警本身只是告警，所以必須與SLO的診斷、可觀測(cè)相結(jié)合。因?yàn)榭捎^測(cè)觀測(cè)的是因，它就是用于發(fā)現(xiàn)服務(wù)的哪些指標(biāo)產(chǎn)生了波動(dòng)，這些指標(biāo)可能會(huì)影響服務(wù)的可用性。但可觀測(cè)并沒(méi)有告知結(jié)果，并沒(méi)有告訴你服務(wù)的可用性下跌，這就是可觀測(cè)和SLO的區(qū)別。

可觀測(cè)幫助找出原因，SLO讓我們知道結(jié)果，所以SRE里面第二本書的第四章，提及SLO報(bào)警的時(shí)候，介紹了一個(gè)實(shí)踐：你有一個(gè)SLO的大盤，這個(gè)大盤使你得知服務(wù)的SLO產(chǎn)生影響，接下來(lái)應(yīng)該告訴研發(fā)，服務(wù)的黃金指標(biāo)有哪些，并基于可觀測(cè)做成一個(gè)大盤，那么這個(gè)大盤就可以讓研發(fā)在收到告警之后，快速定位錯(cuò)誤的原因，做故障的定界。

武安闖

嗶哩嗶哩  SRE負(fù)責(zé)人

先后負(fù)責(zé)中間件運(yùn)維、在線業(yè)務(wù)保障和SRE穩(wěn)定性工程，《2021.07.13 我們是這樣崩的》文章作者。從0到1帶領(lǐng)運(yùn)維向SRE轉(zhuǎn)型，建設(shè)B站穩(wěn)定性體系，主導(dǎo)建設(shè)SRE轉(zhuǎn)型、SLO工程、容量管理體系、高可用架構(gòu)、多活容災(zāi)等專項(xiàng)，當(dāng)前專注于SRE穩(wěn)定性體系規(guī)劃建設(shè)和落地實(shí)踐。