B站 SRE 發(fā)展的 5 年

B站2017年之前沒有SRE，當時主要負責的事情就是效率優(yōu)先，需求響應（比如變更、標準化、報警治理和瑣事優(yōu)化）。2018年引入SRE文化，開始理解業(yè)務架構(gòu)、推進讀的多活建設(shè)、探索 SRE 里的 Oncall 制度/復盤文化在B站的落地。

2019年正式進入落地，首先做了瑣事優(yōu)化（釋放人力），將工單變更通過平臺來自助審批。之后做了 SLO 體系探索，包括平臺、基于 SLO 的服務分級體系、應急響應制度、復盤平臺、問題管理制度建設(shè)等。

2020年 SRE 穩(wěn)定性體系初步完善，20年B站做了很多活動（S10、跨晚、最美的夜等）。有了故障前的應急響應及故障后的復盤，開始探索故障前混沌工程和故障演練；質(zhì)量之后是容量，B站是容器化部署（探索 PaaS 容量管理體系），在一系列落地之后，2020年穩(wěn)定性體系初步完善。2021年至今SRE繼續(xù)轉(zhuǎn)型，從 Oncall 制度逐漸轉(zhuǎn)向 BP 制度，更加關(guān)注穩(wěn)定性和降本增效。之前做了多活、服務分級、SLO都會在今年重新做優(yōu)化建設(shè)。全員現(xiàn)在在做 SRE 轉(zhuǎn)型。

穩(wěn)定性保障

下面介紹一下轉(zhuǎn)型過程中具體的解析。首先是穩(wěn)定性保障（高可用、多活、容量管理、活動保障）。

高可用

先看下整體架構(gòu)。用戶首先從 CDN 層到接入層，接入層有4層 LB/7層 SLB，還有逐漸推廣的 API GW。

之后進到服務層，服務側(cè)會有一個 BFF（服務網(wǎng)關(guān)），下面是 Service、Job、Admin等。

• 中間件主要是 MQ，數(shù)據(jù)同步 Canal、DTS，消息通知 Notify、緩存；
• 存儲層面是關(guān)系型數(shù)據(jù)庫、 KV、對象存儲、ES等等；
• 再往下是可觀測與效率體系；
• 底層是穩(wěn)定性體系，包括服務分級&SLO、混沌工程/故障演練、多活容災/預案管理、問題管理/事件分析、容量/降本及活動保障。

接入層

這是接入層架構(gòu)，用戶通過 DNS 或降級 HTTP DNS 訪問 CDN，CDN 通過機房邊緣 POP 點匯聚流量到機房，機房有不同可用區(qū)(邏輯概念)，每個可用區(qū)主要是 SLB 和 API GW。

常見的故障有幾種：

網(wǎng)絡(luò)故障：邊緣節(jié)點回機房（運營商公網(wǎng)故障）；

機房故障：一般比較少遇到（主要看概率）；

組件故障：比如 SLB 節(jié)點發(fā)生故障等；

服務故障：SLB/API GW 所代理的服務等；

接入層的高可用方案，比如 DNS 降級 HTTP DNS、多 CDN 節(jié)點動態(tài)選路、APP邊緣節(jié)點網(wǎng)絡(luò)層故障降級第三方CDN重試；多 POP 點做流量匯聚，多線路做源站互備。

如果單可用區(qū) SLB 故障，支持 CDN 從其他可用區(qū)跨專線回源。

對于后端服務故障，SLB可發(fā)現(xiàn)服務區(qū)的所有節(jié)點；單可用區(qū)服務故障節(jié)點可以自動降級。SLB 也支持常見的降級、容災與限流。

最后是 7.13 故障，SLB重建花了一個小時，故障后對 SLB 初始化重建做了很多優(yōu)化，現(xiàn)在可以5分鐘重建一套SLB。API Gateway 的高可用與 SLB 類似，這里不再重復。

服務層

上面說了南北向（接入層），現(xiàn)在來看看東西向。對 SRE 來說，這一層一定要了解（微服務架構(gòu)），如果不了解一旦服務出現(xiàn)故障給不出業(yè)務故障止損預案。

服務調(diào)用是通過內(nèi)部 Discovery 服務發(fā)現(xiàn)組件進行調(diào)用，服務部署了多活（可用區(qū)A和B），每個機房服務都是多節(jié)點部署，不同節(jié)點所運行的物理機（比如是CPU型號不一導致單核算力不一，要看 K8s 有沒有做算力規(guī)劃）。

這個過程可能出現(xiàn)問題，比如容器節(jié)點算力不一，服務B流量過載、可用區(qū)故障等，也有幾種高可用能力：

• 服務調(diào)用有 P2C 算法，服務A調(diào)用服務B，服務B會返回自己節(jié)點的 CPU 使用率情況，服務A基于這次響應的 RT（包括服務B每個節(jié)點 CPU 使用率/成功率來選擇一個最優(yōu)的節(jié)點），雖然服務B不同節(jié)點 CPU 算力不一，但最終 CPU 使用率是一樣的；
• 熔斷，服務B故障時，服務A做一個熔斷；
• 降級的場景有兩種：

一是可用區(qū)的降級，當服務B在某可用區(qū)故障，服務A調(diào)用B可以通過服務發(fā)現(xiàn)組件降級到其他可用區(qū)；另外是做多活的時候，服務在本可用區(qū)沒有做部署的情況下降級到其他可用區(qū)；

內(nèi)容質(zhì)量降級，服務B故障服務A可以訪問本地緩存/降級服務。在我們場景里，如果播放地址失敗會降級到災備播放地址。B站首頁APP推薦可能是動態(tài)的，推薦系統(tǒng)故障也會降級給用戶熱門視頻。

• 限流有兩種，一種是微服務框架側(cè)全局限流，它在框架層面的攔截器，B站內(nèi)部主要是 Golang，使用 Kratos框架，基于框架做了分布式限流。第二部分是動態(tài)限流，不需要預先配置，基于 Google 的 TCP BBR 算法來實現(xiàn)的，會自動分析每個容器節(jié)點 CPU 使用率/成功 QPS 等來自適應做一個保護。

中間件

服務還有一種故障場景是中間件的依賴。

看看核心服務對中間件依賴，比如服務寫數(shù)據(jù)，對評論、彈幕數(shù)據(jù)可以接受最終一致，把寫的數(shù)據(jù)扔到 MQ，用 Job 消費消息隊列，寫入DB。DB 層面會掛一個 Canal 組件，來消費數(shù)據(jù)庫binlog，將消息寫回消息隊列，再刷到緩存里。

我們用到最常見的組件就是緩存/MQ/DB。

緩存在生產(chǎn)系統(tǒng)里有三種模式，Redis Cluster、Redis單節(jié)點/分布式、Memcache（內(nèi)部是按這個順序做推薦建議），每種語言在生產(chǎn)環(huán)境 SDK 都出現(xiàn)過各種各樣的 Bug。

比如短連接風暴，之前搞拜年紀活動，活動一開始充電服務就故障了。后來發(fā)現(xiàn)，Jedis 的并發(fā)數(shù)量超過配置的 Total 之后，后續(xù)連接會變成短鏈接。redis單線程機制，長連接和和短連接性能相差10倍的數(shù)量級，一旦遇到短連接性能就會急劇下降。

我們用過各種語言，連 Redis 之后，往一個節(jié)點發(fā)一些cluster nodes 或者 slot 風暴這種請求，甚至可能會固定往一個節(jié)點發(fā)請求，很快把一個節(jié)點打死了。

當發(fā)生 cluster 風暴，再遇到短連接就會出現(xiàn)雪崩，根本沒辦法恢復。想恢復只能重建緩存或做一個冷重啟。后來我們對緩存做了統(tǒng)一的 proxy 代理（sidecar 模式，或者通過 proxyless sdk），也是為了降本增效，把單容器改成 sdk 模式進行部署訪問。

消息隊列主要做臨時持久化，異步寫DB。集中式代理，不用 sidecar 模式部署，我們內(nèi)部支持 redis 和 gRPC 兩種協(xié)議。2020年B站做了很多擴圈活動，kafka topic數(shù)量急劇增加，當時代理是 kafka 的 Sarama SDK，這個 SDK 也是各種炸，不停出現(xiàn)故障。

數(shù)據(jù)庫層面，內(nèi)部提供數(shù)據(jù)庫 proxy，用 sidecar 模式部署。對業(yè)務做讀寫分離，對業(yè)務透明。對異常SQL做攔截，比如慢SQL。為了降本增效，現(xiàn)在也提供了SDK模式。

前面說了很多架構(gòu)層面的內(nèi)容，SRE 一定要了解業(yè)務架構(gòu)，如果不懂架構(gòu)只能做日常需求（那和配管沒區(qū)別），不懂業(yè)務架構(gòu)的 SRE 是沒有靈魂的。

那有了高可用能力，B站就不炸了嗎？2021.7.13故障，B站/微博/知乎全網(wǎng)熱搜，我們做一下復盤。

2021.7.13 故障

2021.7.13 晚 10:52，用戶反饋B站無法使用，內(nèi)部大量服務、域名接入層報警不可用。
10:57分，Oncall 同學發(fā)現(xiàn) SLB 故障。
11:17，內(nèi)網(wǎng)登陸也受影響，17分核心成員才陸續(xù)進入內(nèi)網(wǎng)系統(tǒng)。
11:23分，讀多活業(yè)務基本恢復。多活機房 SLB 容量過載，多活機房服務層正常/接入層掛了（容量漲了4倍左右）。
11點之后流量逐漸下降，重啟恢復。當時直播業(yè)務也做了多活，首頁接口沒做多機房流量分發(fā)（所以沒有恢復）。
11:17分登陸分析問題，開始懷疑是 SLB 組件問題，聯(lián)系最近在SLB層面做了三次引擎 Lua 層的變更，也沒有恢復。

此時面臨2個選擇，一是繼續(xù)排查問題（底層Debug，SLB具體是什么故障？)；二是給業(yè)務一個可以預期的止損手段。

當時選擇新建一套 SLB，嘗試隔離流量恢復業(yè)務。之后驗證流量隔離是有效的。

1:00左右，新建 SLB 全部完成，開始做業(yè)務流量切換。
1:40左右，業(yè)務已經(jīng)全部切到新集群，核心業(yè)務全部恢復。

這里能看到很多問題：

• 用戶的鏈路和辦公網(wǎng)鏈路未徹底隔離，11:17分才陸續(xù)進入內(nèi)網(wǎng)系統(tǒng)，有些辦公網(wǎng)后臺直接放在公網(wǎng)對用戶訪問，辦公網(wǎng)放到公網(wǎng)也會用到公網(wǎng) SLB（沒有徹底隔離）。
• 多活未按預期立即生效。多活機房SLB流量過來，只支持讀，不支持寫。
• 人力不足。故障止損和排查無法并行。1點左右新建，后面才嘗試做故障排查。組件故障預案不完善、處理耗時久（集群的創(chuàng)建、配置的下發(fā)、公網(wǎng) IP 配置花了接近1個小時）。
• 復雜事故影響面積大，故障定位成本高。
• 同時也看到，多活是機房級故障時容災止損最快方案！

通過 7.13 故障能看到：

• 多活基架能力不足。機房與業(yè)務多活定位關(guān)系混亂，流量調(diào)度層面不支持精細基于用戶特征做流量分片。
• 切量強依賴 CDN 平臺，多活的接入層/用戶流量調(diào)度分發(fā)層是在 CDN 層面實現(xiàn)，并沒有做一個多活統(tǒng)一管控平臺。
• 多活元信息也缺乏平臺管理，比如哪個業(yè)務做了多活（多活是同城雙活/異地容災），業(yè)務有哪些規(guī)則支持多活。?

高可用 - 多活

對于多活元信息定義做了標準化，業(yè)務多活 CRG 的定義（CRG 定義參考了螞蟻的多活模式）。

• Gzone 服務（全局共享服務），可以在用戶間共享數(shù)據(jù)，一個可用區(qū)寫/其他可用區(qū)讀（數(shù)據(jù)強一致性）。B站場景里，視頻播放/番劇/影視/稿件信息/直播間信息數(shù)據(jù)都是平臺型數(shù)據(jù)，這種數(shù)據(jù)在用戶間共享不需要做單元化。
• Rzone 單元化業(yè)務（用戶流水型數(shù)據(jù)），多可用區(qū)分片寫/讀，用戶維數(shù)據(jù)在B站里就是社區(qū)類場景（評論/彈幕/動態(tài)等適合單元化的場景）。
• Czone 和 Gzone 有點類似，Czone 所有可用區(qū)都可以寫/讀（非單元化），介于 Gzone 和 Rzone 之間的，這種場景需要業(yè)務接受一定數(shù)據(jù)延遲和不一致。

對機房進行梳理，當時上海有很多機房（都在一個地域內(nèi)，機房定位比較混亂）。梳理后將上海的4個機房劃成兩個邏輯可用區(qū)，同城雙活（Gzone 類型服務）部署在上海；把江蘇可用區(qū)作為 Rzone 單元化服務部署模擬異地；我們又規(guī)劃華北/華南的可用區(qū)，來做單元化、Czone 服務部署（30ms-40ms網(wǎng)絡(luò)延遲）。

高可用 - 同城雙活

組件層面也做了優(yōu)化。流量的 Router 是在 DCDN 層面，分發(fā)到各個機房，各個機房的服務在讀寫存儲，主要是 KV、DB，Proxy 來做接入，同城雙活的可用區(qū)只支持讀，寫都是通過 Proxy 轉(zhuǎn)到主機房。通過 GZS 來做多活狀態(tài)管理。

對這些組件優(yōu)化主要是這幾個：

• DCDN 支持用戶 Mid、設(shè)備ID來做一致性 Hash，同時支持多機房動態(tài)權(quán)重。DCDN 是基于 Nginx 來構(gòu)建的，后來重新開發(fā)支持多機房的動態(tài)權(quán)重。
• 服務原來的多活是不支持寫的，沒在多活機房做本地化部署和寫鏈路感覺。核心鏈路一定要在本地寫，微服務框架支持寫感知，弱依賴服務回到主機房。
• 存儲層面最早多活沒有 Proxy 組件，需要業(yè)務自己決定哪個機房讀/寫（管理成本特別高）。我們后來統(tǒng)一做 Proxy 做業(yè)務接入管理。
• KV 存儲原本不支持機房部署或者容災切換，之后也做了改造優(yōu)化。包括 TIDB 也支持多機房容災切換。
• GZS 通過 GZS 來管理業(yè)務多活元信息、多活定義、切量編排/可視化。?

GZS：Invoker

GZS 內(nèi)部叫 invoker，基于 API 的元信息管理，結(jié)合內(nèi)部 CMDB 系統(tǒng)（CMDB 存儲業(yè)務元信息/審批平臺)，同時聯(lián)動內(nèi)部幾個多活組件，比如 DCDN/KV存儲/DB存儲/API GW 組件來做流量切換。核心就是優(yōu)化上面四部分：

• 多活規(guī)則元信息獲取方式優(yōu)化
• 平臺多活和同城雙活切量演練
• 多活編排、接入流程優(yōu)化
• 審批、巡檢、可觀測能力加強

實際多活編排和切量流程是，編排先選擇業(yè)務（評論/彈幕/播放）、選擇業(yè)務類型（同城雙活/單元化）、編排接入層規(guī)則。

數(shù)據(jù)庫層編排是 KV、DB，要把多活各個維度資源編排出來，業(yè)務就可以發(fā)起切量。

業(yè)務和業(yè)務域。業(yè)務域（直播/電商/社區(qū)），業(yè)務域下會有業(yè)務(社區(qū)有評論/彈幕/點贊等），切量編排是對流量編排或存儲編排。

切量完成之后觸發(fā)審批。審批之后是巡檢，巡檢主要為三部分：

• 容量巡檢，CPU/MEM；連接池，流量切到另一個機房，流量可能會翻倍；還有數(shù)據(jù)庫/緩存連接池能否扛得??；限流，微服務框架也有很多限流配置，限流能否扛住。
• 延時巡檢，主要做存儲層面的巡檢，現(xiàn)在是同城雙活，延遲基本上沒啥問題。
• 隔離巡檢，存儲有沒有跨業(yè)務混用？比如評論的業(yè)務是否用一個動態(tài)/彈幕 DB、KV。
• 可觀測，巡檢指標可觀測，連接池、限流是怎么變化的？業(yè)務多活流量規(guī)則，流量切換是否符合預期？是否把流量從1:1切到1:0；業(yè)務涉及核心應用SLO 指標。?

除了質(zhì)量之外，前面提到降本增效一定是今年很多互聯(lián)網(wǎng)公司的目標，下面說如何通過容量管理做降本增效。

容量管理

容量管理之前，SRE 要想一個問題，要管什么容量？

• ?在整個系統(tǒng)架構(gòu)中有接入層（核心是帶寬）；
• 應用層面核心就是計算資源；
• DB 和存儲，那是存儲資源。?

對 SRE 來講，容量管理的核心應該是應用。

容量管理做出之后誰關(guān)注？

不同角色關(guān)注是不一樣的，比如研發(fā)/SRE/平臺/預算團隊等等。

目標收益是做之前要想清楚的。這里是每個角色對容量管理的預期：

• 研發(fā)核心是有資源擴容、自動擴容、發(fā)布/回滾不被資源限制。
• SRE既要關(guān)注服務資源使用率，還要關(guān)注彈性擴縮，部門資源水位、降本增效。
• 部門維度，關(guān)注部門資源水位、使用率、部門成本、部門 TopN 服務報表。
• 平臺維度，容器平臺關(guān)注 Buffer、平臺超賣、資源混部、資源利潤率、降本增效。
• 成本團隊就是資源用量、賬單這些事情。

思考這些問題之后，內(nèi)部圍繞 K8s 形成了容量管理，右邊是架構(gòu)圖。

底層是 K8s 平臺，上層是基于 K8s 應用基礎(chǔ)數(shù)據(jù)搜集（集群容量/資源池容量/Node容量/應用容量/應用基本畫像）；

再往上是VPA/HPA/合池/配額管理。VPA 是面向 SRE平臺（對研發(fā)不可見），VPA 的好處是動態(tài)調(diào)整服務 Request 指標，提升 K8s 可調(diào)度資源數(shù)量；

HPA，橫向彈性伸縮，面向研發(fā)，解決服務擴容的問題；

合池，Buffer 復用，增加彈性資源能力。要解決機器維度的差異或者 Node 節(jié)點的差異；

配額管理，沒有合池每個部門只能看到獨立資源的物理資源，合池之后看不到物理資源（只能看邏輯資源，LIKE云平臺），Limit 作指標。

最上面就是容量可視化和報表運營，底層的元數(shù)據(jù)和容量保障之上給業(yè)務提供統(tǒng)一可視化平臺/運營平臺，查詢部門資源容量/排序，某個組織/業(yè)務的容量和數(shù)據(jù)。

容量管理 - VPA

VPA 是降本增效的利器。首先看幾個概念，在應用維度K8s有三個指標，一個是CPU Used（實際用了多少CPU，比如Limit 配了8個C，Request能配4個C，超賣的2倍，業(yè)務實際應用了2個c，Used 2c/Request 4c/Limit 8c；應用 CPU Limit/CPU Request=業(yè)務超賣率）。B站一開始超賣是應用維度超賣，就是給到研發(fā)自己配置。

遇到一些痛點，當 Request 分配完，Used 特別低時，資源池沒有資源可調(diào)度，SRE找研發(fā)按應用維度調(diào)整超賣率，對研發(fā)來講想搶占資源，這個服務是穩(wěn)定的，不想把資源釋放出來，就導致共識很差，效率很低，收益特別小。后來把VPA改成平臺維度。

改造平臺維度之后，研發(fā)不關(guān)注超賣率，只關(guān)注 Limit，不再感知 Request，VPA 的指標放到平臺維度，業(yè)務實際用了多少 CPU/CPU total=物理資源 CPU 使用率。CPU Limit/CPU Total=資源池超賣率。CPU Request/CPU  Used=資源冗余度。內(nèi)部情況物理資源 CPU 使用率低于40%，會調(diào)整 VPA 策略，動態(tài)回收 Request，比如有一個業(yè)務部門資源使用率特別低，直接調(diào)整為 VPA 策略。

右邊是K8s與VPA聯(lián)動的架構(gòu)圖，上面是 VPA 管理平臺：策略管理/數(shù)據(jù)運營/黑名單/預警。

比如某些業(yè)務不適合VPA，比如Job類型/推送服務（一天只運行5-10分鐘），給這個服務做VPA沒有任何意義。

做活動時整個資源池應用CPU使用率會增加，這個時候開啟VPA，會導致第二天資源池分配的 CPU request 會增加，導致資源池沒資源可用。

同時做 VPA 之后也對 VPA 做了很多預警策略，發(fā)現(xiàn)VPA是否符合預期。

中間是 VPA 與 K8s 聯(lián)動 VPA 策略引擎。

底層是 K8s 提供的 VPA API。VPA主要解決兩個場景。一是新增一個Pod，比如一臺機器掛了，pod做一個漂移很常見，這種場景通過 K8s 的 APIServer 層面 Webhook 對所有新增的 Pod 做VPA；二是下發(fā) VPA 策略對存量所有 Pod 做 updater，存量和新增的 Pod 都可以VPA。

規(guī)則按照這四個來：服務等級/服務畫像/資源類型/度量指標。舉個例子，內(nèi)部L0服務，以CPU Used 7天P99指標，來 VPA 所有容器 CPU 資源，L2服務既要做CPU的VPA，也要做內(nèi)存的 VPA。基于1天的指標來做就會更有利。

這是線上合池K8s資源使用率，有兩個指標，一個是只看容器CPU使用率，另外是一看物理機維度CPU使用率怎么樣，在8月初，物理機使用率達到50%以上，整個容器層面也可以超過40%。在VPA之前，我們一個資源池CPU使用率高峰期可以達到20%-30%就不錯了。今年上半年都沒有加資源，就靠VPA滿足業(yè)務新增所有需求。

前面講了高可用、多活，B站每年會有很多活動，比如S11、跨網(wǎng)拜年紀。2021年S11當天直播在線人數(shù)突破千萬。

活動保障流程主要是活動了解->容量預估->壓測演練->復盤清單->技保能力&預案。

前面講了高可用、多活，B站每年會有很多活動，比如S11、跨網(wǎng)拜年紀。2021年S11當天直播在線人數(shù)突破千萬。

活動保障流程主要是活動了解->容量預估->壓測演練->復盤清單->技保能力&預案。

活動重保

活動開始前做活動了解

活動形式：直播/點播/秒殺/抽獎…

重點場景：不同活動重點不一樣，彈幕互動、抽獎、送禮

活動對外鏈接：全鏈路保障

活動推送：站內(nèi)推送、彈窗推送

活動后的場景：直轉(zhuǎn)點、二次熱點

時間線

容量預估

• 基礎(chǔ)資源

交換機帶寬、源站帶寬

靜動態(tài)CDN

• 業(yè)務資源

PaaS、laaS

Cache、MQ

壓測&演練

內(nèi)部壓測分三輪：

第一輪：現(xiàn)有資源下壓業(yè)務瓶頸；

第二輪：資源就緒后按照之前的預估人數(shù)做容量壓測；

第三輪：所有優(yōu)化和保障方案上線后壓測演練。

演練層面兩部分：

預案演練

故障演練：包括上下游依賴、中間件依賴、節(jié)點故障、HPA能力。

復盤清單

活動清單檢查

關(guān)閉混部

關(guān)閉VPA

活動鏈路服務開啟HPA

技保能力&預案

技術(shù)保障能力是側(cè)重問題發(fā)生前的，你具備哪些高可用能力，有哪些能力保障業(yè)務穩(wěn)定性。比如多活、跨機房降級、熔斷等等，還有HPA、VPA等等。預案是問題發(fā)生之后應該怎么辦，它們倆有不同側(cè)重點，預案做攻擊、容量、服務故障等三方面預案。

現(xiàn)場重保&復盤

看好監(jiān)控大盤，把活動核心指標做定時同步，比如S賽，一場比賽結(jié)束之后就把這場比賽數(shù)據(jù)同步一下，包含前面講的技術(shù)資源、業(yè)務資源、服務有沒有出現(xiàn)一些高可用問題，比如有沒有出現(xiàn)一些異常、限流。把活動中問題變更記錄下來，復盤時不僅做活動當天復盤，還把活動從前期準備的問題統(tǒng)一復盤。

SLO 實踐與反思

SLO

前面講的是穩(wěn)定性保障、高可用，服務可用性怎么度量？

我們先看一下 Google 的定義：

SLO 為服務可靠性設(shè)立了一個目標級別，它是可靠性決策的關(guān)鍵因素，是 SRE 實踐的核心。

Google 甚至說沒有 SLO 就沒有SRE。為了使采用基于 SLO 的錯誤預算的可靠性工程方法，服務利益相關(guān)方認可 SLO，甚至服務可以達到 SLO。

基于 Google 的理論，B站基于現(xiàn)有分為兩部分：服務分級與SLO系統(tǒng)。

服務等級分四級，L0-L3。對象包含業(yè)務(產(chǎn)品）=> 應用 => API。

業(yè)務就是產(chǎn)品，比如評論等級是 L0，評論下是應用，應用的等級不能超過產(chǎn)品等級。應用下有 API（發(fā)評論/拉評論)，API的等級也不會超過應用的等級。

等級出來之后用于服務標準化、變革流程管控、報警測量，不同服務等級報警測量/穩(wěn)定性要求不一樣，比如服務有沒有降級能力/多活能力。

SLO 系統(tǒng)提供的核心能力就是做 SLO 指標的選擇/計算/定義。

服務分級&SLO

這是實踐 SLO 的流程，首先創(chuàng)建業(yè)務&定級&定SLO；然后創(chuàng)建應用&定級；之后創(chuàng)建接口&定級&算SLI指標；最后基于接口聚合到業(yè)務上。

這種模型沒有運轉(zhuǎn)下去。

我們的反思：

• 分級模型太理想，定級成本非常高；
• 各種元信息關(guān)聯(lián)不及時，數(shù)據(jù)準確率低；
• 開始做 SLO 計算只算公網(wǎng)服務，也只算了在接入層（SLB層）指標，單條 Metrics 沒辦法覆蓋所有業(yè)務場景；
• 部分內(nèi)網(wǎng)服務不對外，導致沒有 SLI 數(shù)據(jù)；
• SLI 數(shù)據(jù)除了當報表外，也沒人看

新的模式：

• 分級模型優(yōu)化
• SLI模型優(yōu)化
• SLO報警治理?

說一下現(xiàn)在的玩法：創(chuàng)建一個業(yè)務只對業(yè)務主場景定級，比如評論核心就是發(fā)評論/拉評論（對這個場景定級）。應用不再需要定級，只需要打標。算 SLI 對多個對象/多條SLI指標做計算，某個API就是業(yè)務某一個具體波動的體現(xiàn)，也算它的指標數(shù)據(jù)。對業(yè)務指標，比如業(yè)務一些在線人數(shù)、播放量、發(fā)送的評論這是業(yè)務，我們會算三個維度的SLI指標。對這些指標做SLO的運營和質(zhì)量運營。

僅度量SLI是沒有任何意義的，核心是SLO報警和質(zhì)量運營。

甚至SLO報警的重要性比質(zhì)量運營更高，因為質(zhì)量運營和SLI度量都不能幫業(yè)務提供什么東西，但 SLO 報警會幫業(yè)務第一時間發(fā)現(xiàn)問題，提升報警準確率。

事故定級

優(yōu)化服務分級之后，也解決了事故定級中的問題。事故定級以前有兩個指標，業(yè)務損失&服務等級：故障時間&PV損失，因為之前分級模型比較復雜，有業(yè)務/應用/接口，出現(xiàn)故障哪個等級作為故障的等級，我們經(jīng)常在這里扯皮不清。

對業(yè)務分級做了優(yōu)化之后，只對主場景定級，事故時看業(yè)務損失&業(yè)務定級&業(yè)務主場景系數(shù)。

主場景故障系數(shù)是故障功能對主場景影響程度，這種模型完全把服務分級復雜模型包進去，不用在故障時扯皮。

SRE的培養(yǎng)與轉(zhuǎn)型

工作分層

工作分層：最上面是比較傳統(tǒng)的日常答疑、變更、報警處理等。再往下是 SRE 橫向的串聯(lián)、協(xié)作、拉通，再往下是SRE或運維核心，對業(yè)務做支持，比如業(yè)務遷移重構(gòu)&改造，中間件推廣、技術(shù)運營、應急響應等等。基于上面三層抽象出穩(wěn)定性體系，再將各種穩(wěn)定性實踐整合成穩(wěn)定性體系。

對 SRE 的能力要求：

• 運維能力：基本運維能力、網(wǎng)絡(luò)、OS/內(nèi)核、架構(gòu)能力
• 開發(fā)能力：工具開發(fā)、運維平臺開發(fā)、工程能力等
• 合作共贏：項目管理能力、團隊協(xié)作、同理心、情商與運營意識
• 個人潛質(zhì)：學習能力、好奇心、逆向思維能力
• 責任心與擔當。

培養(yǎng)與轉(zhuǎn)型

SRE 培養(yǎng)有四方面：

• SRE文化：團隊要認可SRE文化，從團隊Title和組織名稱可以看到對SRE的重視；從上到下傳達SRE的轉(zhuǎn)型；SRE職級序列；
• SRE方法論：學習 SRE 理論知識，主要是《SRE工作解密》《SRE工作手冊》；
• SRE討論會：SRE方法論專題分享。基于理論做實踐落地。方法論掌握之后再拉大家做討論會，討論SRE的章節(jié)、內(nèi)容，包括SRE穩(wěn)定性、基礎(chǔ)運維架構(gòu)的知識；
• 開發(fā)轉(zhuǎn)型：SRE 繞不開開發(fā)，內(nèi)部也鼓勵做開發(fā)轉(zhuǎn)型，B站基于Golang，SRE 也是基于 Golang，鼓勵 SRE 先做工具開發(fā)，能力達標之后會分配專業(yè)開發(fā)導師，參與 SRE 平臺開發(fā)實踐，最終開發(fā)平臺又提升了SRE工作效率，實現(xiàn)正向循環(huán)。

作者簡介

武安闖，2016年加入B站，深度參與B站微服務拆分、云原生改造、高可用建設(shè)、SRE轉(zhuǎn)型和穩(wěn)定性體系落地等項目。當前主要關(guān)注B站在線業(yè)務的SRE穩(wěn)定性體系建設(shè)和推廣，對SRE的實踐有深入的探索與思考。