一、前言?

英雄聯(lián)盟全球總決賽是一年一度最為盛大的電子競(jìng)技比賽，在國(guó)內(nèi)關(guān)注度極高。11月6日，DRX戰(zhàn)隊(duì)以近乎奇跡的方式，一路從入圍賽披荊斬棘拿下了S12全球總決賽的冠軍。相當(dāng)勵(lì)志，恭喜DRX！

B站作為今年S12的官方直播渠道，嗶哩嗶哩賽事直播間實(shí)時(shí)人氣一度超過3.1億。如何保障整個(gè)S賽洪峰流量下系統(tǒng)的穩(wěn)定性和流暢性，給我們帶來了巨大挑戰(zhàn)。

為此，我們?cè)?月底成立了S12技術(shù)保障專項(xiàng)，展開了為期3個(gè)多月緊鑼密鼓的技術(shù)籌備，我們的目標(biāo)是可以實(shí)現(xiàn)“喝茶保障”。

二、如何實(shí)現(xiàn)

經(jīng)過盤點(diǎn)，我們把S12技術(shù)保障依賴的各項(xiàng)工作拆分為賽前、賽中、賽后三個(gè)階段，如下圖：

1、項(xiàng)目啟動(dòng)

S12技術(shù)保障需要公司多個(gè)技術(shù)團(tuán)隊(duì)之間的緊密配合，涉及業(yè)務(wù)研發(fā)、SRE、基礎(chǔ)架構(gòu)、DBA、大數(shù)據(jù)等近300人。從上游業(yè)務(wù)充分搜集S12相關(guān)資訊后，我們召集所有相關(guān)團(tuán)隊(duì)負(fù)責(zé)人召開了項(xiàng)目啟動(dòng)會(huì)，最終在S12技術(shù)保障目標(biāo)上達(dá)成一致，爭(zhēng)取做到全局步調(diào)一致。

2、資源預(yù)估

1）貼合業(yè)務(wù)

為了發(fā)揮資源的最大使用價(jià)值、提高資源利用率，我們與上游業(yè)務(wù)對(duì)齊了業(yè)務(wù)目標(biāo)PCU（最高在線用戶數(shù)）、后續(xù)宣發(fā)策略和規(guī)劃，方便技術(shù)側(cè)及時(shí)介入準(zhǔn)備、做出合理的資源估算。

2）合理估算

• 從B站SRE容量平臺(tái)查詢到去年S11服務(wù)器峰值用量a、去年8月日常峰值用量b，粗略算出同期增長(zhǎng)系數(shù)delta=(a-b)/b+1。
• 同時(shí)查詢到今年8月份日常峰值用量c，服務(wù)器當(dāng)前可用量d。因?yàn)槲覀円蠓?wù)器容量安全水位在40%以下，所以缺口資源量=c*delta/0.4-d。
• 產(chǎn)品功能在保障過程中也會(huì)有增加，因此這部分增加的功能所需的資源支持會(huì)在單獨(dú)評(píng)估資源缺口后追加申請(qǐng)。

3、資源池治理

去年以前，直播資源池都是直播專屬、與其他部門獨(dú)立的，當(dāng)直播資源池資源用盡后，需要從其他資源池協(xié)調(diào)機(jī)器->網(wǎng)絡(luò)測(cè)試->機(jī)器初始化->重新打label入直播池，全程人工、非常低效，經(jīng)常導(dǎo)致線上業(yè)務(wù)發(fā)布或擴(kuò)容阻塞、影響應(yīng)急響應(yīng)效率。

從全站視角看，大型賽事直播結(jié)束后大量用戶會(huì)從直播間轉(zhuǎn)向社區(qū)其他服務(wù)（稿件、評(píng)論、專欄、動(dòng)態(tài)等），類似“潮汐流量”，這部分服務(wù)器冗余可以通過合池來“降本”。合池的前提是機(jī)器運(yùn)行時(shí)的標(biāo)準(zhǔn)化：

1）服務(wù)去CPUSET

由于直播的實(shí)時(shí)性和對(duì)延遲的敏感性特征，我們的業(yè)務(wù)場(chǎng)景無法接受高概率的CPU Throttle帶來的超時(shí)。大量服務(wù)使用了CPUSET的綁核策略，CPUSET無法資源共享、無法合池、造成一定的資源浪費(fèi)。

內(nèi)核同事協(xié)助排查后發(fā)現(xiàn)，PHP服務(wù)的高概率CPU Throttle是因?yàn)橥瑫r(shí)并發(fā)執(zhí)行的R進(jìn)程過多，導(dǎo)致CPU Quota被擊穿。排查PHP基礎(chǔ)庫(kù)發(fā)現(xiàn)，直播PHP服務(wù)使用了Swoole多進(jìn)程模型，基礎(chǔ)庫(kù)會(huì)在每個(gè)Worker進(jìn)程內(nèi)設(shè)置一個(gè)定時(shí)器用來更新配置，1s檢查一次，多個(gè)進(jìn)程大概率會(huì)在同一時(shí)刻被喚醒。修復(fù)方案有兩個(gè)：1）打亂進(jìn)程定時(shí)器執(zhí)行的隨機(jī)性，減少“碰撞”；2）基于inotify進(jìn)行配置更新，廢棄基礎(chǔ)庫(kù)定時(shí)器。因?yàn)闃I(yè)務(wù)代碼里也大量使用了定時(shí)器用來對(duì)直播熱點(diǎn)數(shù)據(jù)做內(nèi)存預(yù)加載，所以最終是采用了方案1，更新基礎(chǔ)庫(kù)后效果非常明顯。

protected function funcWorkerStart(){        return function (\swoole_server $Server, $iWorkerID){            // 部分服務(wù)會(huì)在init_callback中注冊(cè)worker timer做配置加載            // 但是會(huì)帶來并發(fā)R過多導(dǎo)致cpu throttle，此處做下隨機(jī)sleep 10-500ms            mt_srand((microtime(true) + posix_getpid()) * 10000);            usleep(mt_rand(10000, 500000));
            Main::init();            //配置文件定期加載function () use ($C, $Server, $iWorkerID){                app(Metrics::class)->flush();
                // load  config...                 // config check...                // reload worker...            };            //注冊(cè)定時(shí)器            swoole_timer_tick(1000, $config_reload_cb);        };    }

對(duì)于Golang服務(wù)，我們引入了automaxprocs來自適應(yīng)調(diào)整在Linux CFS調(diào)度模式下的GOMAXPROCS，并對(duì)所有Go服務(wù)做了代碼lint檢測(cè)。

2）宿主機(jī)內(nèi)核升級(jí)

直播部分老機(jī)器內(nèi)核版本過低無法參與合池，并且存在cgroup泄漏問題[1]，造成業(yè)務(wù)超時(shí)抖動(dòng)。為了合池后不影響其他部門在線業(yè)務(wù)應(yīng)用，需要對(duì)老內(nèi)核機(jī)器進(jìn)行內(nèi)核升級(jí)。

B站操作系統(tǒng)團(tuán)隊(duì)統(tǒng)一了內(nèi)核版本，根治了困擾業(yè)務(wù)已久的cgroup泄漏問題，同時(shí)基于Group Identity對(duì)在離線業(yè)務(wù)混部做了CPU隔離優(yōu)化。

完成直播PAAS合池后，緩解了部門之間機(jī)器多份冗帶來的資源浪費(fèi)。在線業(yè)務(wù)使用B站SRE容量管理平臺(tái)按需分配，大大提高了資源利用率。

4、業(yè)務(wù)場(chǎng)景拆解

1）確定保障范圍

B站直播經(jīng)過8年的發(fā)展，已經(jīng)具備了多樣化的直播間玩法、能力，可以支持不同類型直播場(chǎng)景。今年的S12我們也推出了很多新玩法，涉及的各項(xiàng)能力要在對(duì)應(yīng)的后臺(tái)配置好后才會(huì)呈現(xiàn)給用戶，不同的功能玩法由不同的技術(shù)團(tuán)隊(duì)支持，所以首先要確認(rèn)S12用到的已有能力和新增玩法（共30+個(gè)），圈定保障范圍。

2）確定場(chǎng)景分級(jí)

分級(jí)標(biāo)準(zhǔn)如下：

① P0

• 部門核心用戶場(chǎng)景所對(duì)應(yīng)業(yè)務(wù)：需滿足月日均DAU >= xx W；如不滿足條件，降級(jí)到L1
• 部門營(yíng)收業(yè)務(wù)：需滿足月日均營(yíng)收 >= xx W；如不滿足條件，降級(jí)到L1
• 雖未達(dá)到上述要求，但業(yè)務(wù)屬于公司戰(zhàn)略級(jí)方向
• 強(qiáng)依賴下游業(yè)務(wù)

② P1

• 部門L0業(yè)務(wù)主場(chǎng)景使用中依賴的主要業(yè)
  
• 核心的二類業(yè)
  
• 不滿足L0的部門核心用戶場(chǎng)景所對(duì)應(yīng)業(yè)
  
• 不滿足L0的部門主要營(yíng)收業(yè)
  
• 強(qiáng)依賴下游業(yè)務(wù)

③ P2

• 部門給用戶提供的其他業(yè)
  
• 強(qiáng)依賴下游業(yè)務(wù)

如上所示，我們從DAU、營(yíng)收數(shù)據(jù)、依賴等維度定義了服務(wù)的分級(jí)標(biāo)準(zhǔn)，按照?qǐng)鼍安鸱执_定保障等級(jí)。最終根據(jù)S12涉及到的30+個(gè)功能拆解出10個(gè)P0場(chǎng)景、16個(gè)P1場(chǎng)景、9個(gè)P2場(chǎng)景。

對(duì)于P0和P1的場(chǎng)景要重點(diǎn)覆蓋混沌工程測(cè)試、客戶端性能測(cè)試、服務(wù)端性能壓測(cè)、生產(chǎn)多活演練、可觀測(cè)監(jiān)控等，保證服務(wù)架構(gòu)高可用。

3）梳理場(chǎng)景地圖

① 定義

場(chǎng)景拆解后，針對(duì)單一場(chǎng)景將關(guān)聯(lián)的業(yè)務(wù)邏輯（微服務(wù)調(diào)用關(guān)系、接口依賴等）進(jìn)行全局梳理形成場(chǎng)景地圖，幫助場(chǎng)景負(fù)責(zé)人和決策者快速了解服務(wù)本身的依賴情況。

② 梳理規(guī)范

• 場(chǎng)景名稱：xxx
• 場(chǎng)景等級(jí)：P0/P1/P2
• 場(chǎng)景介紹
• ?方式：通過抓包、代碼翻閱、負(fù)責(zé)人確認(rèn)的方式明確下述內(nèi)
  
• 方法：5w2h法（Who/When/Where/What/Why/How/How much
  
• 場(chǎng)景依賴：接口、服務(wù)、緩存、數(shù)據(jù)庫(kù)、消息隊(duì)列

有了場(chǎng)景地圖，對(duì)S12的技術(shù)治理和優(yōu)化會(huì)更有針對(duì)性。整理場(chǎng)景地圖的過程，一方面加深了研發(fā)、測(cè)試對(duì)于場(chǎng)景邏輯的認(rèn)識(shí)，一些歷史問題也會(huì)變得清晰；另一方面這些元數(shù)據(jù)有助于后面各項(xiàng)技術(shù)架構(gòu)優(yōu)化、監(jiān)控元數(shù)據(jù)的校準(zhǔn)。

5、高可用架構(gòu)

分布式架構(gòu)下微服務(wù)之間相互調(diào)用十分復(fù)雜，一個(gè)點(diǎn)位故障極有可能影響整條鏈路的穩(wěn)定性，為此我們做了長(zhǎng)足的架構(gòu)演進(jìn)準(zhǔn)備。

1）單點(diǎn)治理

分布式架構(gòu)下，單點(diǎn)本身不具備容災(zāi)能力，最容易出現(xiàn)問題。應(yīng)該優(yōu)先處理掉，主要有：

• 應(yīng)用單點(diǎn)：要求所有應(yīng)用都應(yīng)該多實(shí)例部署（>2）。
• JOB單點(diǎn)：基于XXL-JOB二次開發(fā)直播分布式任務(wù)調(diào)度系統(tǒng)，可以有效解決JOB無法多實(shí)例分片執(zhí)行的問題。
• 資源池單點(diǎn)：直播PAAS資源池單宿主機(jī)巡檢，避免機(jī)器單點(diǎn)故障后導(dǎo)致應(yīng)用無法重新調(diào)度成功。

2）高在線自適應(yīng)保護(hù)

千萬直播場(chǎng)景下，一場(chǎng)直播結(jié)束會(huì)有大量用戶退出直播間回到流量入口頁，對(duì)其他網(wǎng)關(guān)及下游帶來數(shù)倍的壓力放大。因?yàn)镻rometheus監(jiān)控有采集窗口，實(shí)際的請(qǐng)求“毛刺”比下圖所示還高。從流量轉(zhuǎn)化數(shù)據(jù)上看，其實(shí)80%的請(qǐng)求是不必要的，用戶可能已經(jīng)關(guān)閉APP了。

針對(duì)這類Case設(shè)計(jì)了高在線自適應(yīng)降級(jí)保護(hù)方案。通過服務(wù)端與客戶端協(xié)議打通，直接從源頭上避免不必要的用戶熱點(diǎn)行為、對(duì)后端服務(wù)器的流量沖擊。

目前已經(jīng)上線的保護(hù)策略如下，識(shí)別到當(dāng)前直播間熱點(diǎn)后：

• 退出直播間不自動(dòng)刷新流量頁
• 針對(duì)不重要的KV配置等請(qǐng)求，做隨機(jī)延遲打散
• 針對(duì)廣播集中觸發(fā)接口熱點(diǎn)請(qǐng)求，做隨機(jī)延遲打散
• 動(dòng)態(tài)調(diào)大離線數(shù)據(jù)上報(bào)間隔，降低服務(wù)器壓力
• API Gateway限流后自動(dòng)觸發(fā)客戶端流控

3）混沌工程

在生產(chǎn)環(huán)境中運(yùn)行分布式系統(tǒng)，難免會(huì)有各種不可預(yù)料的突發(fā)事件、故障發(fā)生，而微服務(wù)之間相互依賴，可能會(huì)產(chǎn)生異常連鎖反應(yīng)。我們應(yīng)該致力于在這些異常行為被觸發(fā)前，盡可能多地識(shí)別風(fēng)險(xiǎn)，然后針對(duì)性地加固防范，從而避免故障發(fā)生時(shí)所帶來的嚴(yán)重后果。

混沌工程正是這樣一套通過在分布式系統(tǒng)上進(jìn)行實(shí)驗(yàn)，主動(dòng)找出系統(tǒng)中脆弱環(huán)節(jié)的方法學(xué)。這種通過實(shí)證的驗(yàn)證方法可以為我們打造更具魯棒性的系統(tǒng)，同時(shí)讓我們更透徹的掌握系統(tǒng)運(yùn)行時(shí)的各種行為規(guī)律，也能在這個(gè)過程中及時(shí)針對(duì)性的補(bǔ)齊系統(tǒng)預(yù)案。

B站從去年開始引入混沌工程，基于chaosblade二次開發(fā)，融合監(jiān)控、問題管理形成初步滿足業(yè)務(wù)微服務(wù)治理的故障注入平臺(tái)。但漸漸發(fā)現(xiàn)chaosblade只能控制端口級(jí)別的故障，爆炸半徑過大，影響較大無法在生產(chǎn)環(huán)境執(zhí)行。今年自研了控制粒度更細(xì)、爆炸半徑更小的混沌演練平臺(tái)，可以控制到接口、用戶粒度的故障。詳見下圖：

針對(duì)S12核心L0/L1場(chǎng)景，我們?cè)谶M(jìn)房、送禮、發(fā)彈幕、首頁等場(chǎng)景進(jìn)行了故障演練、紅藍(lán)對(duì)抗，主動(dòng)發(fā)現(xiàn)并治理核心鏈路上的幾類非預(yù)期問題：

• 代碼問題，弱依賴被錯(cuò)誤地實(shí)現(xiàn)為強(qiáng)依賴，導(dǎo)致核心鏈路不通；
• 弱依賴未考慮降級(jí)方案，用戶體驗(yàn)不佳；
• 代碼問題，對(duì)于弱依賴的降級(jí)方案不生效；
• 對(duì)于強(qiáng)依賴故障，客戶端能否做到容錯(cuò)、友好提示，各端降級(jí)體驗(yàn)是否一致。

4）同城雙活

機(jī)房故障往往是災(zāi)難性的，會(huì)大大降低用戶體驗(yàn)甚至出現(xiàn)客訴，對(duì)用戶和公司來說都是巨大損失。多機(jī)房failover能力顯得至關(guān)重要，我們對(duì)直播核心業(yè)務(wù)場(chǎng)景實(shí)現(xiàn)了同城雙活（首頁、進(jìn)房、送禮、預(yù)開播等），保證在機(jī)房失聯(lián)、斷電、失火等極限情況下，可以快速?zèng)Q策并切流，最大限度保證用戶體驗(yàn)不受損。

吸取去年“B站713故障經(jīng)驗(yàn)和教訓(xùn)”，SRE平臺(tái)和基礎(chǔ)架構(gòu)團(tuán)隊(duì)研發(fā)了 Invoker多活切流平臺(tái)。經(jīng)過多次生產(chǎn)切流演練驗(yàn)證，單次切流平均時(shí)效5分鐘內(nèi)。大大提高了切流效率，避免故障影響面持續(xù)擴(kuò)大。

5）網(wǎng)關(guān)遷移

直播第一代API Gateway是基于Envoy二次開發(fā)，部署在IDC物理機(jī)。資源預(yù)估出現(xiàn)偏差時(shí)臨場(chǎng)擴(kuò)容非常耗時(shí)，需要服務(wù)樹掛載->審批->機(jī)器初始化->運(yùn)行時(shí)初始化->灰度->接量→測(cè)試→SLB灰度→SLB全量，平均耗時(shí)30分鐘+。

去年S11總決賽現(xiàn)場(chǎng)踩過這個(gè)坑，當(dāng)時(shí)靠手速擴(kuò)了20分鐘才擴(kuò)上8臺(tái)，擴(kuò)完之后一波突發(fā)流量差點(diǎn)兒炸了，CPU峰值90%了，好險(xiǎn)！

同時(shí)Envoy網(wǎng)關(guān)C++編寫、代碼結(jié)構(gòu)十分復(fù)雜、調(diào)試?yán)щy、很難維護(hù)，無法一鍵部署。今年我們將核心服務(wù)的BFF（Backend For Frontend）全部遷移到新的自研Golang API Gateway。主要有以下優(yōu)勢(shì)：

• 支持容器化部署
• 支持自動(dòng)彈性伸縮HPA，分鐘級(jí)別即可完成擴(kuò)容！
• 具備快速便捷的控制面能力：限流、降級(jí)
• HA：支持邏輯/物流集群隔離
• 支持全鏈路灰度

目前該項(xiàng)目已經(jīng)開源，感興趣可以學(xué)習(xí)：?https://github.com/go-kratos/gateway?

6、性能壓測(cè)

經(jīng)過前面的優(yōu)化，我們初步保障了整個(gè)技術(shù)底座的抗故障能力，接下來會(huì)通過幾輪周期性壓測(cè)來驗(yàn)證核心業(yè)務(wù)場(chǎng)景的極限QPS能否達(dá)到要求，未達(dá)標(biāo)的要分析出瓶頸并做技術(shù)優(yōu)化/擴(kuò)容。

1）壓測(cè)目標(biāo)

每年大型賽事活動(dòng)結(jié)束后，我們都會(huì)對(duì)比賽期間的關(guān)鍵數(shù)據(jù)做存檔，方便對(duì)明年目標(biāo)值做出合理預(yù)估。依據(jù)去年業(yè)務(wù)數(shù)據(jù)（在線人數(shù)、營(yíng)收數(shù)據(jù)）增長(zhǎng)比例和核心接口峰值QPS，結(jié)合接口實(shí)際調(diào)用時(shí)機(jī)，很容易估算出今年接口預(yù)期QPS。

假設(shè)去年同時(shí)最高在線N，A接口峰值QPS=a（A接口進(jìn)直播間必調(diào)一次、和在線人數(shù)線性相關(guān)），前面我們和上游業(yè)務(wù)方對(duì)齊業(yè)務(wù)數(shù)據(jù)目標(biāo)（同時(shí)最高在線=M），則今年A接口預(yù)期要扛QPS = a *（1 +（M-N）/ N）

2）壓測(cè)方案

通過抓包、代碼翻閱整理出今年S12核心場(chǎng)景最新的接口依賴和調(diào)用時(shí)序關(guān)系（是串行還是并行），B站自研的壓測(cè)平臺(tái)Melloi支持對(duì)同一個(gè)場(chǎng)景的相關(guān)依賴接口進(jìn)行編排。

今年的S12新增了很多用戶玩法功能給用戶帶來沉浸式的觀賽互動(dòng)體驗(yàn)，涉及很多寫接口的壓測(cè)，可能會(huì)對(duì)生產(chǎn)環(huán)境造成數(shù)據(jù)污染，產(chǎn)生輿情和客訴。

B站在去年自研了全鏈路壓測(cè)的方案，通過全鏈路壓測(cè)標(biāo)識(shí)Context傳遞，在數(shù)據(jù)寫入層的SDK做攔截策略，將壓測(cè)寫流量轉(zhuǎn)發(fā)到“Mirror數(shù)據(jù)隔離層”，實(shí)現(xiàn)壓測(cè)數(shù)據(jù)隔離。壓測(cè)結(jié)束后，壓測(cè)平臺(tái)聯(lián)動(dòng)數(shù)據(jù)庫(kù)、緩存、消息隊(duì)列等數(shù)據(jù)平臺(tái)，快速回收數(shù)據(jù)。

S12送禮、心跳等直播核心寫場(chǎng)景就采用了這個(gè)方案，通過對(duì)場(chǎng)景相關(guān)鏈路的上下游改造，借助于全鏈路壓測(cè)平臺(tái)真實(shí)摸底了數(shù)據(jù)庫(kù)和異步JOB/Consumer的負(fù)載上限情況，設(shè)置了合理的限流，有效地保障了大型活動(dòng)中寫服務(wù)的穩(wěn)定性。

3）壓測(cè)執(zhí)行

為了壓測(cè)數(shù)據(jù)的真實(shí)性，我們選擇低峰期在生產(chǎn)環(huán)境進(jìn)行集中發(fā)壓。雖然是在低峰期壓測(cè)，但還是有一些正常用戶流量，所以一定要注意避免壓死整個(gè)系統(tǒng)：

• 開始要慢慢施壓且壓測(cè)時(shí)間短一些(比如1分鐘)，以防止出現(xiàn)問題。
• 緊盯各項(xiàng)監(jiān)控(服務(wù)的監(jiān)控，Redis，Mysql，Tidb，Databus等)，如果有異常要立即停止壓測(cè)。
• 資源使用逼近極限，需要停止壓測(cè)。
• 記錄壓測(cè)過程中不同壓測(cè)QPS下各項(xiàng)資源的壓力情況，以供后續(xù)分析。

4）壓測(cè)報(bào)告

壓測(cè)后我們會(huì)系統(tǒng)整理壓測(cè)報(bào)告：壓測(cè)結(jié)果、目標(biāo)Review、問題跟進(jìn)等。

① 常見問題

② 擴(kuò)容最佳實(shí)踐

壓測(cè)結(jié)束后，根據(jù)如下公式合理估算要擴(kuò)容的副本數(shù)。

7、保障預(yù)案

保障預(yù)案主要分為兩個(gè)方面：業(yè)務(wù)層和技術(shù)層。

1）業(yè)務(wù)預(yù)案

通過場(chǎng)景地圖梳理、混沌工程、性能壓測(cè)發(fā)現(xiàn)并治理了很多技術(shù)風(fēng)險(xiǎn)點(diǎn)，回看這些問題關(guān)鍵鏈路的技術(shù)優(yōu)化，大多數(shù)鏈路降級(jí)調(diào)整依賴各種配置：服務(wù)配置、KV配置、上下游的配置。為了保障在整個(gè)S12進(jìn)程中及時(shí)響應(yīng)、關(guān)鍵鏈路不出問題，我們整理了各個(gè)場(chǎng)景中可能需要臨場(chǎng)執(zhí)行的各項(xiàng)預(yù)案。

我們針對(duì)15個(gè)S12核心場(chǎng)景做了保障預(yù)案，部分預(yù)案需要多個(gè)場(chǎng)景負(fù)責(zé)人進(jìn)行聯(lián)動(dòng)、協(xié)同，會(huì)在線下線上做預(yù)案演練并驗(yàn)證有效。

2）技術(shù)預(yù)案

① 網(wǎng)關(guān)限流：結(jié)合前期壓測(cè)的QPS，配置一個(gè)合理的限流QPS

② 服務(wù)Quota限流：支持按Zone、Caller進(jìn)行限流

③ 網(wǎng)關(guān)降級(jí)：支持按PATH和Query/Header進(jìn)行直接降級(jí)，不會(huì)將壓力傳遞到業(yè)務(wù)服務(wù)BFF

④ 資源彈性

• HPA：全稱是Horizontal Pod Autoscaler，水平自動(dòng)伸縮。當(dāng)業(yè)務(wù)POD CPU/內(nèi)存使用率超過設(shè)定閾值后，自動(dòng)觸發(fā)擴(kuò)容，無需人工干預(yù)。
• 混合云：防止自建IDC機(jī)房資源用滿，自動(dòng)彈到第三方混合云資源上，充分保證了資源可用。

8、質(zhì)量把控

S12八強(qiáng)賽后，我們啟動(dòng)了S12強(qiáng)管控升級(jí)。強(qiáng)管控期間，線上變更需要謹(jǐn)慎并報(bào)備到S12技術(shù)保障項(xiàng)目組進(jìn)行Review把關(guān)。具體分為兩個(gè)階段：

9、現(xiàn)場(chǎng)保障

1）可觀測(cè)性

往年的大型賽事保障活動(dòng)，投屏的監(jiān)控大盤無法直觀發(fā)現(xiàn)系統(tǒng)問題，業(yè)務(wù)監(jiān)控遍布在各個(gè)角落，排查問題非常不便。今年我們首先基于場(chǎng)景地圖梳理出了S12 L0/L1場(chǎng)景的核心依賴：

• 接口
• 應(yīng)用
• 數(shù)據(jù)庫(kù)
• 緩存
• 消息隊(duì)列

然后圍繞業(yè)務(wù)核心指標(biāo)PCU（最高在線用戶數(shù)）、核心場(chǎng)景SLO、核心應(yīng)用飽和度三個(gè)維度制作了新的健康監(jiān)測(cè)監(jiān)控大盤，1分鐘自動(dòng)更新一次。

① 業(yè)務(wù)核心指標(biāo)PCU

直播大部分系統(tǒng)和PCU線性相關(guān)，一旦有波動(dòng)要立即關(guān)注下游負(fù)載情況。

② 核心場(chǎng)景SLO

作為結(jié)果指標(biāo)，對(duì)于微服務(wù)故障有著決定性的指導(dǎo)作用，出現(xiàn)波動(dòng)一定是有問題了。對(duì)B站SLO體系建設(shè)感興趣可以閱讀：??要是還沒搞明白SLO，你算哪門子SRE呢？??

③ S12核心應(yīng)用飽和度

作為預(yù)警指標(biāo)，可分為三個(gè)檔位：

• 紅：異常，需要立即介入處理
• 橙：偏高，需要關(guān)注
• 綠：健康，無需關(guān)注

2）告警協(xié)同

保障現(xiàn)場(chǎng)出現(xiàn)最多的問題就是告警了，我們目前的告警存在告警等級(jí)不明確、告警接受人不準(zhǔn)確、處理狀態(tài)不透明、告警風(fēng)暴的問題，長(zhǎng)期會(huì)基于SLO做告警治理。短期我們自研開發(fā)了一套告警應(yīng)急協(xié)同平臺(tái)，方便研發(fā)、SRE協(xié)同處理告警，一目了然。

• 支持場(chǎng)景管
  
• 支持告警訂閱：按告警I
  
• 支持告警過濾：按告警ID、按告警權(quán)
  
• 支持告警聚合：相同告警10分鐘窗口內(nèi)自動(dòng)聚
  
• 支持告警處理協(xié)同：告警處理流轉(zhuǎn)狀態(tài)一目了然，方便協(xié)同

3）現(xiàn)場(chǎng)值班

① 現(xiàn)場(chǎng)指揮官

• 問題優(yōu)先級(jí)判斷
• 應(yīng)急響應(yīng)
• 技術(shù)判斷和決策

② 值班人員

• 業(yè)務(wù)：運(yùn)營(yíng)、審核
• 技術(shù)：研發(fā)
• 基礎(chǔ)架構(gòu)：SRE、DBA、網(wǎng)工

三、總結(jié)展望

今年是我加入B站的第5年，回想前幾年S賽技術(shù)保障現(xiàn)場(chǎng)大家手忙腳亂地處理告警（擴(kuò)容、限流、降級(jí)），現(xiàn)場(chǎng)非常混亂。即便是直播結(jié)束，告警和問題反饋也一直不斷。今年我們通過一系列的技術(shù)升級(jí)（內(nèi)核升級(jí)、去CPUSET、合池、網(wǎng)關(guān)容器化遷移、同城雙活、HPA）和服務(wù)治理（混沌工程、全鏈路壓測(cè)、告警協(xié)同治理），保障了整個(gè)S12直播過程中技術(shù)系統(tǒng)穩(wěn)定、流暢，沒有出現(xiàn)任何需要主動(dòng)限流、降級(jí)、熔斷等對(duì)用戶有損的技術(shù)干預(yù)手段，給用戶帶來了極致的觀賽和互動(dòng)體驗(yàn)，實(shí)現(xiàn)了技術(shù)人夢(mèng)寐以求的“喝茶保障”。后續(xù)我們會(huì)對(duì)技術(shù)保障過程中的各個(gè)環(huán)節(jié)進(jìn)行復(fù)盤，持續(xù)打磨技術(shù)中間件和平臺(tái)、建設(shè)多活單元化、全鏈路壓測(cè)覆蓋、優(yōu)化資源池調(diào)度、全面推進(jìn)B站基礎(chǔ)設(shè)施云原生落地。