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

【資料圖】

結(jié)合SRE中的可靠性工程，B站也落地了自己的一整套實踐體系，如下圖所示，最上方是我們跟研發(fā)的協(xié)作體系，研發(fā)可以看到SRE的幾種角色，比如Oncall輪值、核心業(yè)務(wù)BP、PaaS平臺專家以及專門負責可靠性工程開發(fā)的SRE?？煽啃怨こ讨袑Ψ?wù)的質(zhì)量運營就是通過SLO工程驅(qū)動的可觀測、變更管理和報警治理。

一、可用性指標困局1.可用性對象多，指代不清

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

2.可用性度量難，數(shù)據(jù)標準、建模難不可用難定義

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

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

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

3.運營需求場景多 ，報警、損失、報表等

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

4.指標、報警多，重點不清

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

5.報警治理難，多維度報警無從下手

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

二、SLI指標的選擇和SLO的度量1.SLO的方法論

先看一下整個SLO的方法論，這個方法論比較簡單。

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

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

2.常見SLO模型

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

3.實施SLO的理想流程

在SRE中，一個實施SLO的理想流程如下：

1）SLI選擇計算

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

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

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

2）SLO定義

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

3）錯誤預(yù)算

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

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

4）儀表盤和報表

最后，需要一個儀表盤和報表來完成數(shù)據(jù)的展示和可視化，并持續(xù)改進SLO。

4.SLO第一次嘗試

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

5.失敗反思

1）SLO生命周期運營

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

度量SLI，設(shè)置SLO

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

SLO報警及智能診斷

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

錯誤預(yù)算與SLO報警運營

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

SLO報表與儀表盤

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

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

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

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

2）可用性指標選擇

進行指標可用性的度量最常見的兩種模式：一是度量請求成功率，二是度量服務(wù)的可用時間。

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

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

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

3）SLI指標治理：錯誤治理

運用請求成功率最核心的一點就是要完成錯誤的標準化和錯誤的識別。

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

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

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

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

錯誤碼標準化

SLB視角：HTTP 5xx

當錯誤的類型定義清楚后，就要定義我們的Code碼，而從負載均衡的視角來看，比如說我們的基本是5xx。

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

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

如果因為調(diào)用下游服務(wù)超時而導(dǎo)致整個鏈路的耗時消耗完畢，服務(wù)無法處理，會拋一個-504；如果服務(wù)接了限流的框架，限流時會拋一個-509。

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

4）可用性SLI：多維計算

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

SLB HTTP 5xx：

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

HTTP/gRPC Server -5xx：

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

我們在度量服務(wù)本身的Metrics時，發(fā)現(xiàn)它出現(xiàn)了一些-5xx的Code碼，這個對應(yīng)的場景就是應(yīng)用HTTP Code 200，但因依賴下游服務(wù)、讀取DB、CACHE失敗等系統(tǒng)錯誤時，則會在應(yīng)用Metrics側(cè)上報業(yè)務(wù)Code的錯誤指標。

通過這兩種指標的度量，就能度量出服務(wù)所有的故障場景。

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

除了可用性的度量外，我們還對服務(wù)的延遲指標做了度量，此延遲所指的不是接口的延遲，而是存儲和數(shù)據(jù)層面的延遲。因為我們做了同城雙活，同城雙活中有很多數(shù)據(jù)同步的場景，比如數(shù)據(jù)庫的同步和緩存的同步等。數(shù)據(jù)若產(chǎn)生延遲，將嚴重影響用戶體驗。

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

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

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

7）多對象、多SLI、多指標計算

最終我們的度量方式是多對象，多SLI指標，多SLI實現(xiàn)。

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

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

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

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

三、SLO報警實踐

前文也提到了告警的問題，例如，每次出事故都加告警、報警狼來了、全是噪音以及報警準確率低等，令人無從下手……問題在哪？我們在做SLO告警時慢慢發(fā)現(xiàn)了根因。

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

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

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

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

1）SLO告警降噪思路研發(fā)只關(guān)注應(yīng)用告警

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

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

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

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

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

2）SLO告警運營體系：1-5-10設(shè)置SLO告警

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

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

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

根因定位

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

運營分析

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

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

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

3）SLO告警策略目標錯誤率≥SLO

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

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

錯誤預(yù)算窗口

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

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

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

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

多次消耗率報警

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

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

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

多窗口，多消耗率報警

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

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

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

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

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

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

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

5）SLO告警根因定位

步驟如下：

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

6）案例分享

我們在群里推出了一條SLO的告警，并在告警卡片里會推送一個SLO的診斷鏈接，然后直接@服務(wù)所負責的或做過變更的研發(fā)。研發(fā)直接點開鏈接就可以快速地做故障的定界，確認接口和服務(wù)的錯誤類型。

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

四、SLO運營1.SLO指標運營

2.SLO報警運營

只要把告警發(fā)到群里，研發(fā)都會處理，因為告警非常準確，一旦發(fā)生就代表服務(wù)出問題。與研發(fā)唯一的分歧是SLO告警出來后表示服務(wù)不可用，但是這個服務(wù)沒那么重要，研發(fā)會基于上游容忍自己服務(wù)錯誤的原因，將其判斷為誤報。

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

3.SLO與變更檢測

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

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

Q&A

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

A1：對，我們度量的對象有三種，第一是業(yè)務(wù)，第二是通過API來度量業(yè)務(wù)的某一個功能，第三是使用這套指標針對每個服務(wù)做一個度量。因為生產(chǎn)的API非常多，不可能把所有API都度量出來。面對服務(wù)沒有任何指標的情況，就無法進行度量，但只要有指標就可以度量出來。

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

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

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

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

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

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

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

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

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

A5：測試用戶可以通過生產(chǎn)一種灰度或者染色的方式來處理，即對用戶流量做一些打標。我們可以在指標上報的時候加上這種標簽，這個操作在我們的系統(tǒng)種稱為染色，這個請求帶有一個顏色標簽，那么在它的指標中，染色的標簽可以識別并被上報。

我們在測試環(huán)境做SLO指標度量和報警的時候，就不會再看染色的流量，而是只看基準版本的流量。如果生產(chǎn)的問題很嚴重，可以用類似的方式，即只看你基準版本的流量，不看染色的流量，或者將兩個流量的報警場景區(qū)分開。

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

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

Q7:剛開始進行SLO建設(shè)，如何說服研發(fā)團隊配合?

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

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

Q8:怎么解決抖動告警？比如每隔幾分鐘 5xx錯誤？

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

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

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

Q9:收到告警之后如何知道具體是哪個錯誤造成的？

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

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

武安闖

嗶哩嗶哩 SRE負責人

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

關(guān)鍵詞：