建站
咨詢
售后
建站咨詢
新聞中心
B站 SRE 發(fā)展的 5 年
B站2017年之前沒有SRE，當(dāng)時主要負(fù)責(zé)的事情就是效率優(yōu)先，需求響應(yīng)（比如變更、標(biāo)準(zhǔn)化、報警治理和瑣事優(yōu)化）。2018年引入SRE文化，開始理解業(yè)務(wù)架構(gòu)、推進讀的多活建設(shè)、探索 SRE 里的 Oncall 制度/復(fù)盤文化在B站的落地。
2019年正式進入落地，首先做了瑣事優(yōu)化（釋放人力），將工單變更通過平臺來自助審批。之后做了 SLO 體系探索，包括平臺、基于 SLO 的服務(wù)分級體系、應(yīng)急響應(yīng)制度、復(fù)盤平臺、問題管理制度建設(shè)等。
2020年 SRE 穩(wěn)定性體系初步完善，20年B站做了很多活動（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ù)分級、SLO都會在今年重新做優(yōu)化建設(shè)。全員現(xiàn)在在做 SRE 轉(zhuǎn)型。
穩(wěn)定性保障
下面介紹一下轉(zhuǎn)型過程中具體的解析。首先是穩(wěn)定性保障（高可用、多活、容量管理、活動保障）。
高可用
先看下整體架構(gòu)。用戶首先從 CDN 層到接入層，接入層有4層 LB/7層 SLB，還有逐漸推廣的 API GW。
之后進到服務(wù)層，服務(wù)側(cè)會有一個 BFF（服務(wù)網(wǎng)關(guān)），下面是 Service、Job、Admin等。
- 中間件主要是 MQ，數(shù)據(jù)同步 Canal、DTS，消息通知 Notify、緩存；
- 存儲層面是關(guān)系型數(shù)據(jù)庫、 KV、對象存儲、ES等等；
- 再往下是可觀測與效率體系；
- 底層是穩(wěn)定性體系，包括服務(wù)分級&SLO、混沌工程/故障演練、多活容災(zāi)/預(yù)案管理、問題管理/事件分析、容量/降本及活動保障。
接入層
這是接入層架構(gòu)，用戶通過 DNS 或降級 HTTP DNS 訪問 CDN，CDN 通過機房邊緣 POP 點匯聚流量到機房，機房有不同可用區(qū)(邏輯概念)，每個可用區(qū)主要是 SLB 和 API GW。
常見的故障有幾種：
網(wǎng)絡(luò)故障：邊緣節(jié)點回機房（運營商公網(wǎng)故障）；
機房故障：一般比較少遇到（主要看概率）；
組件故障：比如 SLB 節(jié)點發(fā)生故障等；
服務(wù)故障：SLB/API GW 所代理的服務(wù)等；
接入層的高可用方案，比如 DNS 降級 HTTP DNS、多 CDN 節(jié)點動態(tài)選路、APP邊緣節(jié)點網(wǎng)絡(luò)層故障降級第三方CDN重試；多 POP 點做流量匯聚，多線路做源站互備。
如果單可用區(qū) SLB 故障，支持 CDN 從其他可用區(qū)跨專線回源。
對于后端服務(wù)故障，SLB可發(fā)現(xiàn)服務(wù)區(qū)的所有節(jié)點；單可用區(qū)服務(wù)故障節(jié)點可以自動降級。SLB 也支持常見的降級、容災(zāi)與限流。
最后是 7.13 故障，SLB重建花了一個小時，故障后對 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)組件進行調(diào)用，服務(wù)部署了多活（可用區(qū)A和B），每個機房服務(wù)都是多節(jié)點部署，不同節(jié)點所運行的物理機（比如是CPU型號不一導(dǎo)致單核算力不一，要看 K8s 有沒有做算力規(guī)劃）。
這個過程可能出現(xiàn)問題，比如容器節(jié)點算力不一，服務(wù)B流量過載、可用區(qū)故障等，也有幾種高可用能力：
- 服務(wù)調(diào)用有 P2C 算法，服務(wù)A調(diào)用服務(wù)B，服務(wù)B會返回自己節(jié)點的 CPU 使用率情況，服務(wù)A基于這次響應(yīng)的 RT（包括服務(wù)B每個節(jié)點 CPU 使用率/成功率來選擇一個最優(yōu)的節(jié)點），雖然服務(wù)B不同節(jié)點 CPU 算力不一，但最終 CPU 使用率是一樣的；
- 熔斷，服務(wù)B故障時，服務(wù)A做一個熔斷；
- 降級的場景有兩種：
一是可用區(qū)的降級，當(dāng)服務(wù)B在某可用區(qū)故障，服務(wù)A調(diào)用B可以通過服務(wù)發(fā)現(xiàn)組件降級到其他可用區(qū)；另外是做多活的時候，服務(wù)在本可用區(qū)沒有做部署的情況下降級到其他可用區(qū)；
內(nèi)容質(zhì)量降級，服務(wù)B故障服務(wù)A可以訪問本地緩存/降級服務(wù)。在我們場景里，如果播放地址失敗會降級到災(zāi)備播放地址。B站首頁APP推薦可能是動態(tài)的，推薦系統(tǒng)故障也會降級給用戶熱門視頻。
- 限流有兩種，一種是微服務(wù)框架側(cè)全局限流，它在框架層面的攔截器，B站內(nèi)部主要是 Golang，使用 Kratos框架，基于框架做了分布式限流。第二部分是動態(tài)限流，不需要預(yù)先配置，基于 Google 的 TCP BBR 算法來實現(xiàn)的，會自動分析每個容器節(jié)點 CPU 使用率/成功 QPS 等來自適應(yīng)做一個保護。
中間件
服務(wù)還有一種故障場景是中間件的依賴。
看看核心服務(wù)對中間件依賴，比如服務(wù)寫數(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ēng)暴，之前搞拜年紀(jì)活動，活動一開始充電服務(wù)就故障了。后來發(fā)現(xiàn)，Jedis 的并發(fā)數(shù)量超過配置的 Total 之后，后續(xù)連接會變成短鏈接。redis單線程機制，長連接和和短連接性能相差10倍的數(shù)量級，一旦遇到短連接性能就會急劇下降。
我們用過各種語言，連 Redis 之后，往一個節(jié)點發(fā)一些cluster nodes 或者 slot 風(fēng)暴這種請求，甚至可能會固定往一個節(jié)點發(fā)請求，很快把一個節(jié)點打死了。
當(dāng)發(fā)生 cluster 風(fēng)暴，再遇到短連接就會出現(xiàn)雪崩，根本沒辦法恢復(fù)。想恢復(fù)只能重建緩存或做一個冷重啟。后來我們對緩存做了統(tǒng)一的 proxy 代理（sidecar 模式，或者通過 proxyless sdk），也是為了降本增效，把單容器改成 sdk 模式進行部署訪問。
消息隊列主要做臨時持久化，異步寫DB。集中式代理，不用 sidecar 模式部署，我們內(nèi)部支持 redis 和 gRPC 兩種協(xié)議。2020年B站做了很多擴圈活動，kafka topic數(shù)量急劇增加，當(dāng)時代理是 kafka 的 Sarama SDK，這個 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ù)、域名接入層報警不可用。
10:57分，Oncall 同學(xué)發(fā)現(xiàn) SLB 故障。
11:17，內(nèi)網(wǎng)登陸也受影響，17分核心成員才陸續(xù)進入內(nèi)網(wǎng)系統(tǒng)。
11:23分，讀多活業(yè)務(wù)基本恢復(fù)。多活機房 SLB 容量過載，多活機房服務(wù)層正常/接入層掛了（容量漲了4倍左右）。
11點之后流量逐漸下降，重啟恢復(fù)。當(dāng)時直播業(yè)務(wù)也做了多活，首頁接口沒做多機房流量分發(fā)（所以沒有恢復(fù)）。
11:17分登陸分析問題，開始懷疑是 SLB 組件問題，聯(lián)系最近在SLB層面做了三次引擎 Lua 層的變更，也沒有恢復(fù)。
此時面臨2個選擇，一是繼續(xù)排查問題（底層Debug，SLB具體是什么故障？)；二是給業(yè)務(wù)一個可以預(yù)期的止損手段。
當(dāng)時選擇新建一套 SLB，嘗試隔離流量恢復(fù)業(yè)務(wù)。之后驗證流量隔離是有效的。
1:00左右，新建 SLB 全部完成，開始做業(yè)務(wù)流量切換。
1:40左右，業(yè)務(wù)已經(jīng)全部切到新集群，核心業(yè)務(wù)全部恢復(fù)。
這里能看到很多問題：
- 用戶的鏈路和辦公網(wǎng)鏈路未徹底隔離，11:17分才陸續(xù)進入內(nèi)網(wǎng)系統(tǒng)，有些辦公網(wǎng)后臺直接放在公網(wǎng)對用戶訪問，辦公網(wǎng)放到公網(wǎng)也會用到公網(wǎng) SLB（沒有徹底隔離）。
- 多活未按預(yù)期立即生效。多活機房SLB流量過來，只支持讀，不支持寫。
- 人力不足。故障止損和排查無法并行。1點左右新建，后面才嘗試做故障排查。組件故障預(yù)案不完善、處理耗時久（集群的創(chuàng)建、配置的下發(fā)、公網(wǎng) IP 配置花了接近1個小時）。
- 復(fù)雜事故影響面積大，故障定位成本高。
- 同時也看到，多活是機房級故障時容災(zāi)止損最快方案！
通過 7.13 故障能看到：
- 多活基架能力不足。機房與業(yè)務(wù)多活定位關(guān)系混亂，流量調(diào)度層面不支持精細(xì)基于用戶特征做流量分片。
- 切量強依賴 CDN 平臺，多活的接入層/用戶流量調(diào)度分發(fā)層是在 CDN 層面實現(xiàn)，并沒有做一個多活統(tǒng)一管控平臺。
- 多活元信息也缺乏平臺管理，比如哪個業(yè)務(wù)做了多活（多活是同城雙活/異地容災(zāi)），業(yè)務(wù)有哪些規(guī)則支持多活。?
高可用 - 多活
對于多活元信息定義做了標(biāo)準(zhǔn)化，業(yè)務(wù)多活 CRG 的定義（CRG 定義參考了螞蟻的多活模式）。
- Gzone 服務(wù)（全局共享服務(wù)），可以在用戶間共享數(shù)據(jù)，一個可用區(qū)寫/其他可用區(qū)讀（數(shù)據(jù)強一致性）。B站場景里，視頻播放/番劇/影視/稿件信息/直播間信息數(shù)據(jù)都是平臺型數(shù)據(jù)，這種數(shù)據(jù)在用戶間共享不需要做單元化。
- Rzone 單元化業(yè)務(wù)（用戶流水型數(shù)據(jù)），多可用區(qū)分片寫/讀，用戶維數(shù)據(jù)在B站里就是社區(qū)類場景（評論/彈幕/動態(tài)等適合單元化的場景）。
- Czone 和 Gzone 有點類似，Czone 所有可用區(qū)都可以寫/讀（非單元化），介于 Gzone 和 Rzone 之間的，這種場景需要業(yè)務(wù)接受一定數(shù)據(jù)延遲和不一致。
對機房進行梳理，當(dāng)時上海有很多機房（都在一個地域內(nèi)，機房定位比較混亂）。梳理后將上海的4個機房劃成兩個邏輯可用區(qū)，同城雙活（Gzone 類型服務(wù)）部署在上海；把江蘇可用區(qū)作為 Rzone 單元化服務(wù)部署模擬異地；我們又規(guī)劃華北/華南的可用區(qū)，來做單元化、Czone 服務(wù)部署（30ms-40ms網(wǎng)絡(luò)延遲）。
高可用 - 同城雙活
組件層面也做了優(yōu)化。流量的 Router 是在 DCDN 層面，分發(fā)到各個機房，各個機房的服務(wù)在讀寫存儲，主要是 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)重。
- 服務(wù)原來的多活是不支持寫的，沒在多活機房做本地化部署和寫鏈路感覺。核心鏈路一定要在本地寫，微服務(wù)框架支持寫感知，弱依賴服務(wù)回到主機房。
- 存儲層面最早多活沒有 Proxy 組件，需要業(yè)務(wù)自己決定哪個機房讀/寫（管理成本特別高）。我們后來統(tǒng)一做 Proxy 做業(yè)務(wù)接入管理。
- KV 存儲原本不支持機房部署或者容災(zāi)切換，之后也做了改造優(yōu)化。包括 TIDB 也支持多機房容災(zāi)切換。
- GZS 通過 GZS 來管理業(yè)務(wù)多活元信息、多活定義、切量編排/可視化。?
GZS：Invoker
GZS 內(nèi)部叫 invoker，基于 API 的元信息管理，結(jié)合內(nèi)部 CMDB 系統(tǒng)（CMDB 存儲業(yè)務(wù)元信息/審批平臺)，同時聯(lián)動內(nèi)部幾個多活組件，比如 DCDN/KV存儲/DB存儲/API GW 組件來做流量切換。核心就是優(yōu)化上面四部分：
- 多活規(guī)則元信息獲取方式優(yōu)化
- 平臺多活和同城雙活切量演練
- 多活編排、接入流程優(yōu)化
- 審批、巡檢、可觀測能力加強
實際多活編排和切量流程是，編排先選擇業(yè)務(wù)（評論/彈幕/播放）、選擇業(yè)務(wù)類型（同城雙活/單元化）、編排接入層規(guī)則。
數(shù)據(jù)庫層編排是 KV、DB，要把多活各個維度資源編排出來，業(yè)務(wù)就可以發(fā)起切量。
業(yè)務(wù)和業(yè)務(wù)域。業(yè)務(wù)域（直播/電商/社區(qū)），業(yè)務(wù)域下會有業(yè)務(wù)(社區(qū)有評論/彈幕/點贊等），切量編排是對流量編排或存儲編排。
切量完成之后觸發(fā)審批。審批之后是巡檢，巡檢主要為三部分：
- 容量巡檢，CPU/MEM；連接池，流量切到另一個機房，流量可能會翻倍；還有數(shù)據(jù)庫/緩存連接池能否扛得??；限流，微服務(wù)框架也有很多限流配置，限流能否扛住。
- 延時巡檢，主要做存儲層面的巡檢，現(xiàn)在是同城雙活，延遲基本上沒啥問題。
- 隔離巡檢，存儲有沒有跨業(yè)務(wù)混用？比如評論的業(yè)務(wù)是否用一個動態(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 要想一個問題，要管什么容量？
- ?在整個系統(tǒng)架構(gòu)中有接入層（核心是帶寬）；
- 應(yīng)用層面核心就是計算資源；
- DB 和存儲，那是存儲資源。?
對 SRE 來講，容量管理的核心應(yīng)該是應(yīng)用。
容量管理做出之后誰關(guān)注？
不同角色關(guān)注是不一樣的，比如研發(fā)/SRE/平臺/預(yù)算團隊等等。
目標(biāo)收益是做之前要想清楚的。這里是每個角色對容量管理的預(yù)期：
- 研發(fā)核心是有資源擴容、自動擴容、發(fā)布/回滾不被資源限制。
- SRE既要關(guān)注服務(wù)資源使用率，還要關(guān)注彈性擴縮，部門資源水位、降本增效。
- 部門維度，關(guān)注部門資源水位、使用率、部門成本、部門 TopN 服務(wù)報表。
- 平臺維度，容器平臺關(guān)注 Buffer、平臺超賣、資源混部、資源利潤率、降本增效。
- 成本團隊就是資源用量、賬單這些事情。
思考這些問題之后，內(nèi)部圍繞 K8s 形成了容量管理，右邊是架構(gòu)圖。
底層是 K8s 平臺，上層是基于 K8s 應(yīng)用基礎(chǔ)數(shù)據(jù)搜集（集群容量/資源池容量/Node容量/應(yīng)用容量/應(yīng)用基本畫像）；
再往上是VPA/HPA/合池/配額管理。VPA 是面向 SRE平臺（對研發(fā)不可見），VPA 的好處是動態(tài)調(diào)整服務(wù) Request 指標(biāo)，提升 K8s 可調(diào)度資源數(shù)量；
HPA，橫向彈性伸縮，面向研發(fā)，解決服務(wù)擴容的問題；
合池，Buffer 復(fù)用，增加彈性資源能力。要解決機器維度的差異或者 Node 節(jié)點的差異；
配額管理，沒有合池每個部門只能看到獨立資源的物理資源，合池之后看不到物理資源（只能看邏輯資源，LIKE云平臺），Limit 作指標(biāo)。
最上面就是容量可視化和報表運營，底層的元數(shù)據(jù)和容量保障之上給業(yè)務(wù)提供統(tǒng)一可視化平臺/運營平臺，查詢部門資源容量/排序，某個組織/業(yè)務(wù)的容量和數(shù)據(jù)。
容量管理 - VPA
VPA 是降本增效的利器。首先看幾個概念，在應(yīng)用維度K8s有三個指標(biāo)，一個是CPU Used（實際用了多少CPU，比如Limit 配了8個C，Request能配4個C，超賣的2倍，業(yè)務(wù)實際應(yīng)用了2個c，Used 2c/Request 4c/Limit 8c；應(yīng)用 CPU Limit/CPU Request=業(yè)務(wù)超賣率）。B站一開始超賣是應(yīng)用維度超賣，就是給到研發(fā)自己配置。
遇到一些痛點，當(dāng) Request 分配完，Used 特別低時，資源池沒有資源可調(diào)度，SRE找研發(fā)按應(yīng)用維度調(diào)整超賣率，對研發(fā)來講想搶占資源，這個服務(wù)是穩(wěn)定的，不想把資源釋放出來，就導(dǎo)致共識很差，效率很低，收益特別小。后來把VPA改成平臺維度。
改造平臺維度之后，研發(fā)不關(guān)注超賣率，只關(guān)注 Limit，不再感知 Request，VPA 的指標(biāo)放到平臺維度，業(yè)務(wù)實際用了多少 CPU/CPU total=物理資源 CPU 使用率。CPU Limit/CPU Total=資源池超賣率。CPU Request/CPU Used=資源冗余度。內(nèi)部情況物理資源 CPU 使用率低于40%，會調(diào)整 VPA 策略，動態(tài)回收 Request，比如有一個業(yè)務(wù)部門資源使用率特別低，直接調(diào)整為 VPA 策略。
右邊是K8s與VPA聯(lián)動的架構(gòu)圖，上面是 VPA 管理平臺：策略管理/數(shù)據(jù)運營/黑名單/預(yù)警。
比如某些業(yè)務(wù)不適合VPA，比如Job類型/推送服務(wù)（一天只運行5-10分鐘），給這個服務(wù)做VPA沒有任何意義。
做活動時整個資源池應(yīng)用CPU使用率會增加，這個時候開啟VPA，會導(dǎo)致第二天資源池分配的 CPU request 會增加，導(dǎo)致資源池沒資源可用。
同時做 VPA 之后也對 VPA 做了很多預(yù)警策略，發(fā)現(xiàn)VPA是否符合預(yù)期。
中間是 VPA 與 K8s 聯(lián)動 VPA 策略引擎。
底層是 K8s 提供的 VPA API。VPA主要解決兩個場景。一是新增一個Pod，比如一臺機器掛了，pod做一個漂移很常見，這種場景通過 K8s 的 APIServer 層面 Webhook 對所有新增的 Pod 做VPA；二是下發(fā) VPA 策略對存量所有 Pod 做 updater，存量和新增的 Pod 都可以VPA。
規(guī)則按照這四個來：服務(wù)等級/服務(wù)畫像/資源類型/度量指標(biāo)。舉個例子，內(nèi)部L0服務(wù)，以CPU Used 7天P99指標(biāo)，來 VPA 所有容器 CPU 資源，L2服務(wù)既要做CPU的VPA，也要做內(nèi)存的 VPA?；?天的指標(biāo)來做就會更有利。
這是線上合池K8s資源使用率，有兩個指標(biāo)，一個是只看容器CPU使用率，另外是一看物理機維度CPU使用率怎么樣，在8月初，物理機使用率達到50%以上，整個容器層面也可以超過40%。在VPA之前，我們一個資源池CPU使用率高峰期可以達到20%-30%就不錯了。今年上半年都沒有加資源，就靠VPA滿足業(yè)務(wù)新增所有需求。
前面講了高可用、多活，B站每年會有很多活動，比如S11、跨網(wǎng)拜年紀(jì)。2021年S11當(dāng)天直播在線人數(shù)突破千萬。
活動保障流程主要是活動了解->容量預(yù)估->壓測演練->復(fù)盤清單->技保能力&預(yù)案。
前面講了高可用、多活，B站每年會有很多活動，比如S11、跨網(wǎng)拜年紀(jì)。2021年S11當(dāng)天直播在線人數(shù)突破千萬。
活動保障流程主要是活動了解->容量預(yù)估->壓測演練->復(fù)盤清單->技保能力&預(yù)案。
活動重保
活動開始前做活動了解
活動形式：直播/點播/秒殺/抽獎…
重點場景：不同活動重點不一樣，彈幕互動、抽獎、送禮
活動對外鏈接：全鏈路保障
活動推送：站內(nèi)推送、彈窗推送
活動后的場景：直轉(zhuǎn)點、二次熱點
時間線
容量預(yù)估
- 基礎(chǔ)資源
交換機帶寬、源站帶寬
靜動態(tài)CDN
- 業(yè)務(wù)資源
PaaS、laaS
Cache、MQ
壓測&演練
內(nèi)部壓測分三輪：
第一輪：現(xiàn)有資源下壓業(yè)務(wù)瓶頸；
第二輪：資源就緒后按照之前的預(yù)估人數(shù)做容量壓測；
第三輪：所有優(yōu)化和保障方案上線后壓測演練。
演練層面兩部分：
預(yù)案演練
故障演練：包括上下游依賴、中間件依賴、節(jié)點故障、HPA能力。
復(fù)盤清單
活動清單檢查
關(guān)閉混部
關(guān)閉VPA
活動鏈路服務(wù)開啟HPA
技保能力&預(yù)案
技術(shù)保障能力是側(cè)重問題發(fā)生前的，你具備哪些高可用能力，有哪些能力保障業(yè)務(wù)穩(wěn)定性。比如多活、跨機房降級、熔斷等等，還有HPA、VPA等等。預(yù)案是問題發(fā)生之后應(yīng)該怎么辦，它們倆有不同側(cè)重點，預(yù)案做攻擊、容量、服務(wù)故障等三方面預(yù)案。
現(xiàn)場重保&復(fù)盤
看好監(jiān)控大盤，把活動核心指標(biāo)做定時同步，比如S賽，一場比賽結(jié)束之后就把這場比賽數(shù)據(jù)同步一下，包含前面講的技術(shù)資源、業(yè)務(wù)資源、服務(wù)有沒有出現(xiàn)一些高可用問題，比如有沒有出現(xiàn)一些異常、限流。把活動中問題變更記錄下來，復(fù)盤時不僅做活動當(dāng)天復(fù)盤，還把活動從前期準(zhǔn)備的問題統(tǒng)一復(fù)盤。
SLO 實踐與反思
SLO
前面講的是穩(wěn)定性保障、高可用，服務(wù)可用性怎么度量？
我們先看一下 Google 的定義：
SLO 為服務(wù)可靠性設(shè)立了一個目標(biāo)級別，它是可靠性決策的關(guān)鍵因素，是 SRE 實踐的核心。
Google 甚至說沒有 SLO 就沒有SRE。為了使采用基于 SLO 的錯誤預(yù)算的可靠性工程方法，服務(wù)利益相關(guān)方認(rèn)可 SLO，甚至服務(wù)可以達到 SLO。
基于 Google 的理論，B站基于現(xiàn)有分為兩部分：服務(wù)分級與SLO系統(tǒng)。
服務(wù)等級分四級，L0-L3。對象包含業(yè)務(wù)(產(chǎn)品）=> 應(yīng)用 => API。
業(yè)務(wù)就是產(chǎn)品，比如評論等級是 L0，評論下是應(yīng)用，應(yīng)用的等級不能超過產(chǎn)品等級。應(yīng)用下有 API（發(fā)評論/拉評論)，API的等級也不會超過應(yīng)用的等級。
等級出來之后用于服務(wù)標(biāo)準(zhǔn)化、變革流程管控、報警測量，不同服務(wù)等級報警測量/穩(wěn)定性要求不一樣，比如服務(wù)有沒有降級能力/多活能力。
SLO 系統(tǒng)提供的核心能力就是做 SLO 指標(biāo)的選擇/計算/定義。
服務(wù)分級&SLO
這是實踐 SLO 的流程，首先創(chuàng)建業(yè)務(wù)&定級&定SLO；然后創(chuàng)建應(yīng)用&定級；之后創(chuàng)建接口&定級&算SLI指標(biāo)；最后基于接口聚合到業(yè)務(wù)上。
這種模型沒有運轉(zhuǎn)下去。
我們的反思：
- 分級模型太理想，定級成本非常高；
- 各種元信息關(guān)聯(lián)不及時，數(shù)據(jù)準(zhǔn)確率低；
- 開始做 SLO 計算只算公網(wǎng)服務(wù)，也只算了在接入層（SLB層）指標(biāo)，單條 Metrics 沒辦法覆蓋所有業(yè)務(wù)場景；
- 部分內(nèi)網(wǎng)服務(wù)不對外，導(dǎo)致沒有 SLI 數(shù)據(jù)；
- SLI 數(shù)據(jù)除了當(dāng)報表外，也沒人看
新的模式：
- 分級模型優(yōu)化
- SLI模型優(yōu)化
- SLO報警治理?
說一下現(xiàn)在的玩法：創(chuàng)建一個業(yè)務(wù)只對業(yè)務(wù)主場景定級，比如評論核心就是發(fā)評論/拉評論（對這個場景定級）。應(yīng)用不再需要定級，只需要打標(biāo)。算 SLI 對多個對象/多條SLI指標(biāo)做計算，某個API就是業(yè)務(wù)某一個具體波動的體現(xiàn)，也算它的指標(biāo)數(shù)據(jù)。對業(yè)務(wù)指標(biāo)，比如業(yè)務(wù)一些在線人數(shù)、播放量、發(fā)送的評論這是業(yè)務(wù)，我們會算三個維度的SLI指標(biāo)。對這些指標(biāo)做SLO的運營和質(zhì)量運營。
僅度量SLI是沒有任何意義的，核心是SLO報警和質(zhì)量運營。
甚至SLO報警的重要性比質(zhì)量運營更高，因為質(zhì)量運營和SLI度量都不能幫業(yè)務(wù)提供什么東西，但 SLO 報警會幫業(yè)務(wù)第一時間發(fā)現(xiàn)問題，提升報警準(zhǔn)確率。
事故定級
優(yōu)化服務(wù)分級之后，也解決了事故定級中的問題。事故定級以前有兩個指標(biāo)，業(yè)務(wù)損失&服務(wù)等級：故障時間&PV損失，因為之前分級模型比較復(fù)雜，有業(yè)務(wù)/應(yīng)用/接口，出現(xiàn)故障哪個等級作為故障的等級，我們經(jīng)常在這里扯皮不清。
對業(yè)務(wù)分級做了優(yōu)化之后，只對主場景定級，事故時看業(yè)務(wù)損失&業(yè)務(wù)定級&業(yè)務(wù)主場景系數(shù)。
主場景故障系數(shù)是故障功能對主場景影響程度，這種模型完全把服務(wù)分級復(fù)雜模型包進去，不用在故障時扯皮。
SRE的培養(yǎng)與轉(zhuǎn)型
工作分層
工作分層：最上面是比較傳統(tǒng)的日常答疑、變更、報警處理等。再往下是 SRE 橫向的串聯(lián)、協(xié)作、拉通，再往下是SRE或運維核心，對業(yè)務(wù)做支持，比如業(yè)務(wù)遷移重構(gòu)&改造，中間件推廣、技術(shù)運營、應(yīng)急響應(yīng)等等。基于上面三層抽象出穩(wěn)定性體系，再將各種穩(wěn)定性實踐整合成穩(wěn)定性體系。
對 SRE 的能力要求：
- 運維能力：基本運維能力、網(wǎng)絡(luò)、OS/內(nèi)核、架構(gòu)能力
- 開發(fā)能力：工具開發(fā)、運維平臺開發(fā)、工程能力等
- 合作共贏：項目管理能力、團隊協(xié)作、同理心、情商與運營意識
- 個人潛質(zhì)：學(xué)習(xí)能力、好奇心、逆向思維能力
- 責(zé)任心與擔(dān)當(dāng)。
培養(yǎng)與轉(zhuǎn)型
SRE 培養(yǎng)有四方面：
- SRE文化：團隊要認(rèn)可SRE文化，從團隊Title和組織名稱可以看到對SRE的重視；從上到下傳達SRE的轉(zhuǎn)型；SRE職級序列；
- SRE方法論：學(xué)習(xí) 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ā)，能力達標(biāo)之后會分配專業(yè)開發(fā)導(dǎo)師，參與 SRE 平臺開發(fā)實踐，最終開發(fā)平臺又提升了SRE工作效率，實現(xiàn)正向循環(huán)。
作者簡介
武安闖，2016年加入B站，深度參與B站微服務(wù)拆分、云原生改造、高可用建設(shè)、SRE轉(zhuǎn)型和穩(wěn)定性體系落地等項目。當(dāng)前主要關(guān)注B站在線業(yè)務(wù)的SRE穩(wěn)定性體系建設(shè)和推廣，對SRE的實踐有深入的探索與思考。
網(wǎng)頁名稱：2021.7.13故障后，嗶哩嗶哩SRE穩(wěn)定性保障揭秘
鏈接分享：http://www.dlmjj.cn/article/dhcgcce.html
