一、背景

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

二、Google SRE中SLO的定義

服務水平目標（SLO）指定了服務可靠性的目標水平。由于SLO是做出以數據為依據的可靠性決策的關鍵，因此它們是SRE實踐的核心。

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

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

• SLO是做出工作優先級排序和可靠性相關工作的關鍵

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

• 沒有SLO，就沒有SRE

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

• 服務的利益相關方認可此SLO

• 服務正常狀態下可以達到SLO的要求

• 組織認可錯誤預算并在決策中發揮作用

• 有完善的SLO流程

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

三、Google SRE中SLO的實施

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

1）SLI選擇

• 對于請求驅動型服務，SLI一般選擇可用性（成功響應的請求比例）、延遲、質量。

2）SLI計算

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

3）SLO定義

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

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

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

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

• 獲得關鍵的利益相關者認可和批準。

4）錯誤預算

• 有了SLI和SLO，時間窗口內的允許失敗數就知道了。

• 如果給定時間內錯誤預算消耗殆盡，要制定錯誤預算執行策略，如：開發團隊專注于可靠性問題，直到系統處于SLO范圍內，功能迭代推遲；為了降低風險，凍結生產系統的變更，直到有了錯誤預算來支持變更。

5）記錄SLO和錯誤預算

• SLO的作者，審核人，批準日期，下次審核日期，相關背景。

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

• SLO的細節：SLI實現、如何計算、如何使用錯誤預算。

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

6）儀表盤和報表

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

7）持續改進SLO，提高SLO質量

四、我們的SLO實踐

從上文Google對SLO的介紹中，我們抽象出了關鍵信息來指導我們的建設。

1、服務分級

1）應用：技術視角

• 一個應用對應一個appid，包括前端和后端應用。

• 編碼構建后，可獨立部署運行。

• 一個業務，會包含多個應用，一般具有相同的命名前綴或關鍵詞。

2）業務：產品視角

• 一組網站/APP產品相關功能的聚合。
• 相對獨立的業務模塊。
• 包含一組相關聯的應用。

3）等級分級

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

• L0

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

• L1

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

• L2

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

• L3

其他后臺類業務或對用戶體驗無影響的業務。

4）分級對象

• 先對業務（產品）定級。
• 再對這個業務下的多個應用定級，根據應用所提供的產品功能和故障影響來定，應用等級不超過業務等級。
• 在對此業務中用戶所能觸達到的API定級，API等級不超過應用等級。

5）分級用途

• 基于服務等級，要求核心服務遵守對應技術標準。
• 對不同等級的服務，制定不同的變更流程。
• 報警基于服務等級來做分級。
• 要求服務滿足穩定性要求，如具備熔斷降級能力，具備同城雙活能力等。

6）分級運營

• 其他基礎平臺展示分級數據，基于服務等級定運行策略。

• 基于分級后的技術標準、流程等反推定級準確率提升。

2、SLO系統

1）SLI選擇

對于在線業務來說，基本都是請求驅動的業務，所以選擇可用性、延遲、吞吐。

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

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

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

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

2）SLI模型

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

3）SLI計算

• 統一標準，使用接入層負載均衡指標。所有面向用戶的公網服務都會經過接入層負載均衡，也即SLB（下文統稱為SLB)。

• 內網服務東西向調用時通過服務發現直接調用，不過SLB，所以無法用SLB的指標度量。我們認為內網服務的故障最終能在面向用戶側的公網服務中體現出來，所以我們只對面向用戶的公網服務做度量。

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

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

（a）相同等級的API權重應該是一樣的，不同等級的API應該加權；

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

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

（d）每分鐘業務可用性 = （L0 API總成功率 * 權重 + L1 API總成功率 * 權重）/ 總權重；

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

4）SLO定義

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

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

• 在業務分級時，我們會讓研發對業務設置一個可用性SLO目標，比如全年可用性>= 99.99%。

5）錯誤預算

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

6）記錄SLO和錯誤預算

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

7）儀表盤和報表

• API儀表盤與報表

• 業務儀表盤與報表

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

五、遇到的問題

1）業務定級

• 業務抽象認知不一，產品范圍可大可小。

• L0、核心L1業務在SRE的關注下定級基本準確，但其他業務定級就一言難盡了。

2）應用定級

• 應用數量遠多于業務，定級難度更高。

• 老應用等級更新延遲于業務重構或產品迭代。

• 除L0、核心L1應用外，其他應用等級準確率低。

3）接口定級 

• 接口數量又遠多于應用，定級耗時耗力，維護成本高，當時公司還沒有API GW平臺。

• 同上，接口等級更新延遲于業務重構或產品迭代。

4）SLI計算

• 當服務因上下游調用依賴導致請求失敗時，API的HTTP CODE可能是200，真實的錯誤被封到了業務錯誤碼中。SLB作為通用的負載均衡，不會去解析HTTP Body。

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

• 如果我們改用應用上報的Metrics（內部使用Prometheus），可以解決此問題。但當應用不可用，無法上報Metrics時，也會獲取不到數據，導致SLI數據不準確。

• 我們試過推研發把業務錯誤碼中的系統錯誤（調用依賴類的系統錯誤，而非業務邏輯錯誤）改為HTTP CODE，但成本極高，跟微服務的標準也不相符。

5）業務SLI

• 需要篩選出影響業務核心功能的API，這些API的SLI數據再聚合到業務，其他API的SLI數據不影響業務SLI 。

• 業務迭代導致API變更，原API SLI不再代表業務功能，導致業務SLI數據沒價值。

6）總結一下遇到的問題

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

• 業務SLI關聯關系、API SLI元信息更新不及時，數據準確率低；

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

• 部分部門的業務只提供內網服務，不直接對用戶，導致沒有SLI數據；

• SLI數據好像除了當報表外，也沒什么價值。

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

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

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

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

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

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

此方式雖然依舊無法跟基于故障時間的可用性數據對齊，但已經非常接近了，我們認為加上了數據補償機制之后，統一用這個計算標準的話，業務的可用性SLI是可以作為業務年度可用性報表使用的。想法又一次非常美好...

實際運作起來時，我們發現成本太高了。當發生了影響業務核心功能的事故，我們就要對故障數據去重，然后修訂故障當天的SLI數據。需要有人去盯著事故報告的損失，跟研發一起核對損失數據，再修訂SLI數據.....

最終，因為我們執著于提升SLI的準確率，導致整個SLO系統無法運轉......此時我們的SLO體系開始停滯和崩潰.....

六、反思

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

1）SLO是可靠性決策的關鍵因素，但不是非有不可

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

2）SLO的價值絕對不是報表，而是及時報警，發現影響SLI指標的異常

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

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

3）錯誤預算策略是詩與遠方

• 如果業務某個季度發生事故，把這個季度的錯誤預算耗盡，SLO已不符合預期，SRE也不能凍結這個業務的變更。

• 至于調整業務團隊的短期目標，從業務迭代轉到專注于可靠性問題還是可以的。但這個目標一般是事故驅動達成的共識。

• 如果讓國內互聯網公司產品迭代停止三個月，我想沒有哪個公司會同意。

4）SLI度量的核心是業務功能和應用，而不是聚合業務SLI

• API是業務功能的直接體現，通過度量API的SLI就能反映出業務某個功能的情況。

• 業務功能不可能全部枚舉出來，接口也不可能全部定級和計算SLI。但應用是有限且標準的，基于應用的Metrics即可算出所有應用的可用性SLI。

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

• 業務SLI的核心價值是NOC/技術支持團隊在Oncall時的關注指標，或構建業務場景監控時從業務指標到技術指標的下鉆串聯，更偏向運營層面。

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

七、業務分級優化

1）等級分級

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

① L0

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

• 滿足DAU > xx W；

• 滿足日均營收>  xx W；

• 雖未達到上述要求，但業務屬于公司戰略級方向。

② L1

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

③ L2

用戶可直接使用的其他業務，如播單、分享、專欄等。

④ L3

其他后臺類業務或對用戶體驗無影響的業務。

2）分級模型優化

• 對業務（產品）定級。

• 創建應用（也可叫服務，下文不再區分）時，用戶打標這個應用對此業務的重要程度即可：核心、重要、普通。此數據非定級使用。

• 用戶只需要在創建業務時做一次業務定級即可。

大大簡化我們的業務分級模型，不再對應用和API分級，減少大家的心智負擔和運維、運營成本。

八、SLI選擇與計算

在線業務常見的微服務調用鏈路如下：

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

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

• 應用Server側上報指標數據，計算出應用可用率、延遲等SLI：每個微服務都有這個指標上報，適用所有服務。

上篇中我們有提到，我們只度量了面向用戶的公網服務。這導致我們的SLI覆蓋率很低，大量的內網應用沒有SLI，那SLO報警也就無從做起了。現在補充了HTTP/gRPC Server Metrics后，就能覆蓋到所有應用，同時也能覆蓋到所有的服務不可用場景。

• 應用訪問超時，容器OOM、進程Panic等不可用，會在SLB側上報錯誤指標。

• 應用HTTP CODE 200，但因依賴下游服務、讀取DB、CACHE失敗等系統錯誤時，會在應用Metrics側上報錯誤指標。

• 當應用無法上報Metrics時，可以認為應用已徹底不可用。

除可用率、延遲指標外，應用數據層面的新鮮度指標也特別重要。當數據發生延遲時，應用Server側并不能直接感知到數據是延遲的，要通過其對中間件的Metrics指標來度量。應用對中間件的常見依賴如下圖：

可度量的數據新鮮度指標如下：

• 應用對消息隊列服務的寫入和消費延遲指標：數據消費延遲會導致用戶緩存數據不更新。
• 應用所使用DB的主從同步延遲指標：數據同步延遲會導致用戶緩存數據不更新。
• Canal作為數據同步組件的同步延遲指標：數據同步延遲會導致用戶緩存數據不更新。
• 多活場景下DTS組件的同步延遲指標：數據同步延遲會導致多機房DB數據不一致。

1、應用SLI選擇與計算

1）可用率

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

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

2）延遲

• SLB Metrics度量出的應用分位延遲。

• HTTP/gRPC Server Metrics度量出的應用分位延遲。

3）新鮮度

• 應用對MQ寫入、消費的Metrics來度量消息延遲。

• 應用所使用DB主從同步延遲Metrics。

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

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

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

假如我們已經度量了評論應用的SLI指標，當觸發SLO報警時，我們知道評論應用出問題了，但并不知道是發評論還是讀評論功能出問題。為了提高我們SLO的業務精度，我們需要再對業務的核心功能做度量。

2、業務核心功能SLI選擇與計算

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

1）定義業務功能

• 在SLO系統錄入業務對應的業務核心功能，如發送評論、拉取評論。

• 從API GW平臺獲取API信息，關聯到定義的業務功能。

2）API SLI選擇與計算

① 可用率

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

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

② 延遲

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

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

③ 吞吐

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

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

④ 新鮮度

• 因為應用Server側并不能直接感知到數據是延遲的，是通過應用對中間件的Metrics指標來度量，所以API維度并無新鮮度指標。

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

3、業務SLI選擇與計算

我們已經有了應用SLI、業務核心功能的SLI，難道還不夠嗎？為何還要建設業務SLI呢？

原因如下：

• 業務核心功能SLI是從技術指標計算出來的，如發評論功能的可用率和數據延遲。前面我們有提到錯誤的請求是指系統依賴導致的錯誤而非業務邏輯錯誤，所以此技術指標并不能代表業務邏輯上的成功率。

• 業務SLI的核心價值是NOC/技術支持團隊在Oncall時的關注指標，或構建業務場景監控時從業務指標到技術指標的下鉆串聯，更偏向運營層面。

業務指標是需要從業務系統獲取，如業務DB或數倉平臺。所以只能覆蓋公司級核心業務指標，如：

• 點播播放：播放量、在線人數
• 社區：發送評論量、評論彈幕量
• 登錄：平均登錄量、各渠道登錄量

• …

可以看出，業務SLI其實更側重于業務吞吐數據指標，有了這個指標后，我們可以做以下兩方面的工作建設：

• 重大事故發現：當業務SLI指標異常而觸發報警時，可以認為線上發生了重大事故。在很多公司，NOC團隊的核心就是關注業務指標的健康度情況。

• 業務觀測運營：從業務吞吐指標到業務功能技術指標再到應用技術指標，從上往下構建業務-技術全鏈路監控能力和可視化能力。

業務指標數據收集成本較高，需要按業務系統case by case來建設。我們的思路是讓業務部門自建業務數據，再由SLO系統同步、匯聚、清洗后做運營大盤與報警。

九、SLO與報警

1、應用SLO

應用維度我們度量了可用率、延遲、新鮮度，可設置對應的SLO如下：

• 可用率 >= 99.99%
• 響應99分位延遲 <= 1s
• 數據更新延遲 < = 5min

按照應用所屬業務的等級，給應用推薦一個默認的SLO，研發和跟SRE溝通后設定。注意：

• 此SLO用于觸發SLO報警策略
• 而非凍結研發變更

2、業務核心功能SLO

業務核心功能維度我們度量了可用率、延遲、吞吐，可設置對應的SLO如下：

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

按照所屬業務的等級，給代表業務核心功能API同樣推薦一個默認的SLO，研發和跟SRE溝通后設定。

3、業務SLO

業務指標本質上是吞吐指標，如播放量、在線人數、評論量等，不需要設置SLO，只用做吞吐下跌的業務報警即可。當觸發業務吞吐報警時，一般代表出現了嚴重事故。

4、SLO報警

雖然我們度量了應用、業務核心功能、業務三個對象的可用率、響應延遲、數據新鮮度、吞吐指標，但各個指標的報警價值并不一樣。

• 可用率：用戶功能不可用，價值高。
• 響應延遲：延遲不代表用戶功能一定不可用，價值一般。
• 數據新鮮度：更新延遲代表用戶數據延遲，價值高。
• 吞吐：業務側的吞吐能發現線上重大事故，價值高。

監控報警一般情況下是按如下分層建設的：

• 基礎設施：機房、網絡、設備等。
• 系統：服務器、存儲、硬盤、網卡、虛擬化等。
• 中間件：DB、Cache、MQ、LB等。
• 應用：進程內資源、系統資源、QPS、錯誤、依賴等。
• 業務：業務核心指標，訂單、播放、登錄等。
• 終端：性能、返回碼、運營商、地區、APP版本等。

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

1）目標錯誤率≥SLO閾值

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

優點：

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

缺點：

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

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

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

2）增加報警窗口

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

優點：

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

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

缺點：

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

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

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

3）增加報警持續時間

當SLO低于閾值持續一段時間后再觸發報警，如10分鐘或者1小時。

優點：報警精度更高。在觸發之前需要持續的低于SLO閾值，意味著報警更可能對應于重大事件。

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

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

4）消耗率報警

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

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

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

• 當錯誤預算消耗速率是36時，1小時發出報警。

• 當服務完全不可用，錯誤預算消耗速率是1000，2分10秒發出報警。

優點：

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

缺點：

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

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

不建議使用此報警策略，因為當錯誤率 < 3.6%時，永遠不會發出報警。

5）多次消耗率報警

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

Google建議設置如下三個報警條件：

• 1小時內消耗月度2％的預算消耗，發出緊急報警。

• 6小時內消耗月度5％的錯誤預算，發出緊急報警。

• 3天內消耗月度10％的預算，發出故障工單。

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

優點：

• 能夠根據關鍵值調整監控配置以適應多種情況：錯誤率高時快速報警；如果錯誤率很低但持續發生，最終會發出報警。

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

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

• 能夠根據錯誤率的嚴重程度來選擇適合的報警類型。

缺點：

• 更多數據、窗口大小和閾值需要管理。

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

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

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

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

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

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

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

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

優點：

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

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

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

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

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

最后總結一下我們開啟SLO報警的指標如下：

十、質量運營

有了各個維度的SLI指標和SLO報警后，我們可以很靈活的構建質量運營大盤，如：

• 基于業務SLI構建業務指標大盤。

• 基于業務核心功能SLI構建業務健康度大盤。

• 基于業務和應用的關聯關系構建業務應用健康度大盤。

• 業務可用率排名、應用可用率排名。

• 業務大盤到業務核心功能到應用指標的場景監控大盤。

總結

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