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

結合SRE中的可靠性工程，B站也落地了自己的一整套實踐體系，如下圖所示，最上方是我們跟研發的協作體系，研發可以看到SRE的幾種角色，比如Oncall輪值、核心業務BP、PaaS平臺專家以及專門負責可靠性工程開發的SRE。可靠性工程中對服務的質量運營就是通過SLO工程驅動的可觀測、變更管理和報警治理。

一、可用性指標困局

1.可用性對象多，指代不清

可用性的指向對象很多，因此我們可能不清楚可用性的具體內容。實際上，可用性的度量可以是生產運行的一個服務或應用、應用下的某一個接口、某一個業務模塊、某個團隊或部門。

2.可用性度量難，數據標準、建模難

• 不可用難定義

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

• 事故報告召回低、統計數據維度單一、監控指標難統計

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

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

可用性的數據還應用于運營的場景。常見的運營需求包括報警能不能基于可用性完成；若出現生產故障，可用性損失的數據能否自動產出，是否需要產出年度、月度或季度的可用性報表。

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

隨著微服務體系發展，指標和報警的數量攀升。當SRE針對具體問題進行故障排查時，由于指標過于豐富，我們容易不清楚排查重點或排查順序。除此之外，每次出現事故都會加報警，導致難以區分報警工單和巡檢，最終從報警的通道推送出來的基本都是噪音。

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

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

二、SLI指標的選擇和SLO的度量

1.SLO的方法論

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

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

SLO指定了服務可靠性的目標水平，是做出可靠性決策的關鍵數據，也是SRE實踐的核心。

2.常見SLO模型

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

3.實施SLO的理想流程

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

1）SLI選擇計算

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

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

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

2）SLO定義

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

3）錯誤預算

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

當錯誤預算消耗殆盡時，可以制定一個策略，比如要求研發凍結生產系統的日常迭代，除非研發要做緊急的bug修復，或需要優化生產的穩定性。

4）儀表盤和報表

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

4.SLO第一次嘗試

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

5.失敗反思

1）SLO生命周期運營

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

• 度量SLI，設置SLO

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

• SLO報警及智能診斷

基于這些指標做SLO的告警，將其與傳統的告警區分，務必提供一個精確高效、透明分發的渠道。

• 錯誤預算與SLO報警運營

保留錯誤預算，但將其與SLO報警相結合，用于找出服務故障的共性因素，并與研發共同進行穩定性的治理。

• SLO報表與儀表盤

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

• SLO生態建設

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

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

2）可用性指標選擇

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

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

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

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

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

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

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

例如，在讀緩存或者讀DB這些強依賴或者依賴一個下游服務不可用時，服務會出現請求正確性的錯誤，雖然在一定的時間內將請求處理完畢，但相應的數據出現錯誤。

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

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

• 錯誤碼標準化

SLB視角：HTTP 5xx

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

Server視角：業務Code -5xx

我們參考HTTP 5xx對業務的Code碼做了一個-5xx的定義，比如服務內部錯誤，導致內部業務邏輯無法處理，會把錯誤return出來，一般會出現一個-500或-504。

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

Client視角：業務Code -5xx

4）可用性SLI：多維計算

最終對服務的度量集中在兩個維度：

• SLB HTTP 5xx：

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

• HTTP/gRPC Server -5xx：

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

我們在度量服務本身的Metrics時，發現它出現了一些-5xx的Code碼，這個對應的場景就是應用HTTP Code 200，但因依賴下游服務、讀取DB、CACHE失敗等系統錯誤時，則會在應用Metrics側上報業務Code的錯誤指標。

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

5）數據延遲SLI

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

6）業務指標SLI

技術指標有時無法發現業務指標層面的問題和故障。

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

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

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

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

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

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

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

三、SLO報警實踐

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

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

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

我們以往的報警沒有區分系統錯誤和業務錯誤，也沒有清晰定義出研發需要關注的錯誤，導致每天可能有幾萬條報警，研發難以一一查看。如果Code碼不是200就報警，那么這種報警就沒有任何意義。

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

1）SLO告警降噪思路

• 研發只關注應用告警

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

• 通過應用SLO指標發現對下層（中間件、組件）依賴錯誤

以數據庫不可用為例，以往研發可能會收到業務的數據庫不可用的告警，或者緩存。如果產生了主從切換，或緩存的某一個節點宕機，研發可能會收到業務用到某一個緩存不可用而宕機的告警，但是現在的思路則是，研發無需再關注中間件層面的告警，只需通過自己應用側埋點的指標就可以發現中間件的問題。

• 下層告警對研發透明

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

2）SLO告警運營體系：1-5-10 

• 設置SLO告警

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

• 分發和協同

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

• 根因定位

我們做了一個智能診斷的平臺，結合可觀測，使研發能夠在5分鐘內定位問題。

• 運營分析

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

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

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

3）SLO告警策略

• 目標錯誤率≥SLO

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

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

• 錯誤預算窗口

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

• 增加報警持續時間

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

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

• 多次消耗率報警

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

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

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

• 多窗口，多消耗率報警

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

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

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

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

4）SLO告警分發、協同

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

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

5）SLO告警根因定位

步驟如下：

在我們的場景中，只垂直做服務的故障，就會發現根因定位邊界很清晰。基于業務指標、應用指標、中間件指標以及服務的容量指標，就可以發現服務的故障點。因此，我們只需要做故障定界，無需立刻定位服務的根因。在當前的微服務架構下，只要知道服務故障點的位置，就可立刻止損。

6）案例分享

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

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

四、SLO運營

1.SLO指標運營

2.SLO報警運營

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

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

3.SLO與變更檢測

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

在發布中也可以做觀測和智能阻斷，一旦發現服務的指標出現了可用性的下跌，可以智能阻斷該次變更。

Q&A

Q1: BiliBili是度量了每個服務的SLO嗎？

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

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

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

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

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

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

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

Q4:這套體系是否只針對業務開發，對SRE 有沒有告警降噪的案例？

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

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

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

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

Q6:如何探測SLO是否已經達到閾值？

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

Q7:剛開始進行SLO建設，如何說服研發團隊配合?

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

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

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

A8：這也是一個很常見的生產的報警模式，分兩種情況看，一種情況是報警很嚴重，服務已經不可用，必須處理。

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

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

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

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

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

武安闖

嗶哩嗶哩  SRE負責人

先后負責中間件運維、在線業務保障和SRE穩定性工程，《2021.07.13 我們是這樣崩的》文章作者。從0到1帶領運維向SRE轉型，建設B站穩定性體系，主導建設SRE轉型、SLO工程、容量管理體系、高可用架構、多活容災等專項，當前專注于SRE穩定性體系規劃建設和落地實踐。