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

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

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

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

穩(wěn)定性保障

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

高可用

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

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

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

接入層

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

常見的故障有幾種：

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

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

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

服務(wù)故障：SLB/API GW 所代理的服務(wù)等；

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

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

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

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

服務(wù)層

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

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

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

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

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

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

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

中間件

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

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

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

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

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

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

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

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

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

---

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

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

2021.7.13 故障

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

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

當(dāng)時(shí)選擇新建一套 SLB，嘗試隔離流量恢復(fù)業(yè)務(wù)。之后驗(yàn)證流量隔離是有效的。

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

這里能看到很多問題：

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

通過 7.13 故障能看到：

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

高可用 - 多活

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

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

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

高可用 - 同城雙活

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

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

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

GZS：Invoker

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

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

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

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

業(yè)務(wù)和業(yè)務(wù)域。業(yè)務(wù)域（直播/電商/社區(qū)），業(yè)務(wù)域下會(huì)有業(yè)務(wù)(社區(qū)有評(píng)論/彈幕/點(diǎn)贊等），切量編排是對流量編排或存儲(chǔ)編排。

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

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

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

容量管理

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

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

對 SRE 來講，容量管理的核心應(yīng)該是應(yīng)用。

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

不同角色關(guān)注是不一樣的，比如研發(fā)/SRE/平臺(tái)/預(yù)算團(tuán)隊(duì)等等。

目標(biāo)收益是做之前要想清楚的。這里是每個(gè)角色對容量管理的預(yù)期：

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

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

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

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

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

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

配額管理，沒有合池每個(gè)部門只能看到獨(dú)立資源的物理資源，合池之后看不到物理資源（只能看邏輯資源，LIKE云平臺(tái)），Limit 作指標(biāo)。

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

容量管理 - VPA

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

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

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

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

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

做活動(dòng)時(shí)整個(gè)資源池應(yīng)用CPU使用率會(huì)增加，這個(gè)時(shí)候開啟VPA，會(huì)導(dǎo)致第二天資源池分配的 CPU request 會(huì)增加，導(dǎo)致資源池沒資源可用。

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

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

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

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

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

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

活動(dòng)保障流程主要是活動(dòng)了解->容量預(yù)估->壓測演練->復(fù)盤清單->技保能力&預(yù)案。

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

活動(dòng)保障流程主要是活動(dòng)了解->容量預(yù)估->壓測演練->復(fù)盤清單->技保能力&預(yù)案。

活動(dòng)重保

活動(dòng)開始前做活動(dòng)了解

活動(dòng)形式：直播/點(diǎn)播/秒殺/抽獎(jiǎng)…

重點(diǎn)場景：不同活動(dòng)重點(diǎn)不一樣，彈幕互動(dòng)、抽獎(jiǎng)、送禮

活動(dòng)對外鏈接：全鏈路保障

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

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

時(shí)間線

容量預(yù)估

• 基礎(chǔ)資源

交換機(jī)帶寬、源站帶寬

靜動(dòng)態(tài)CDN

• 業(yè)務(wù)資源

PaaS、laaS

Cache、MQ

壓測&演練

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

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

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

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

演練層面兩部分：

預(yù)案演練

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

復(fù)盤清單

活動(dòng)清單檢查

關(guān)閉混部

關(guān)閉VPA

活動(dòng)鏈路服務(wù)開啟HPA

技保能力&預(yù)案

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

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

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

SLO 實(shí)踐與反思

SLO

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

我們先看一下 Google 的定義：

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

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

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

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

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

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

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

服務(wù)分級(jí)&SLO

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

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

我們的反思：

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

新的模式：

• 分級(jí)模型優(yōu)化
• SLI模型優(yōu)化
• SLO報(bào)警治理?

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

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

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

事故定級(jí)

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

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

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

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

工作分層

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

對 SRE 的能力要求：

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

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

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

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

作者簡介

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

標(biāo)題名稱：2021.7.13故障后，嗶哩嗶哩SRE穩(wěn)定性保障揭秘
網(wǎng)頁URL：http://uogjgqi.cn/article/dhcgcce.html