背景和目標(biāo)

英雄聯(lián)盟全球總決賽是英雄聯(lián)盟賽事每年度最受矚目的節(jié)點(diǎn)，也是B站全年賽事熱度最高的時(shí)段。第13屆英雄聯(lián)盟全球總決賽（下文簡(jiǎn)稱S13）今年繼續(xù)在B站進(jìn)行直播，本文主要分享S13賽事保障的實(shí)踐和思考。

S13的業(yè)務(wù)主目標(biāo)是觀賽用戶達(dá)到1.2億，可拆解到賽前、賽中、賽后三個(gè)階段：

• 賽前重在流量蓄水，擴(kuò)大目標(biāo)用戶，通過(guò)賽事活動(dòng)預(yù)熱、資源位投放、預(yù)約/Push召回，將流量引流到S13賽事主房間（下文簡(jiǎn)稱主房間）觀賽。
• 賽中用戶集中在主房間，重點(diǎn)在提升用戶觀賽以及互動(dòng)體驗(yàn)，提高用戶的轉(zhuǎn)化率和留存率。
• 賽后引導(dǎo)觀賽用戶會(huì)到稿件播放頁(yè)觀看回放，在評(píng)論區(qū)參與選手打分，在動(dòng)態(tài)/話題持續(xù)發(fā)表自己對(duì)賽事的觀后感。

圖1 S13整體介紹

因此，我們的保障目標(biāo)是保證系統(tǒng)在洪峰流量下為用戶提供穩(wěn)定的功能和流暢的觀賽體驗(yàn)，配合業(yè)務(wù)側(cè)達(dá)成業(yè)務(wù)目標(biāo)。面臨的挑戰(zhàn)概括為兩點(diǎn)：

1. 洪峰流量大：難點(diǎn)在如何估算業(yè)務(wù)指標(biāo)、如何正確將業(yè)務(wù)指標(biāo)轉(zhuǎn)換為技術(shù)指標(biāo)、以及如何應(yīng)對(duì)高并發(fā)流量。
2. 牽扯的業(yè)務(wù)范圍廣：難點(diǎn)在如何不缺不漏、以及如何在業(yè)務(wù)迭代壓力大的背景下盡可能提效的完成保障。

接下來(lái)讓我們一起探討本次保障是如何落地的，以及在大型活動(dòng)保障上帶來(lái)了怎樣的思考。

制定保障計(jì)劃的思路

通過(guò)上文對(duì)業(yè)務(wù)主目標(biāo)的介紹和拆解，可看到業(yè)務(wù)目標(biāo)的達(dá)成依托于賽事各階段為用戶提供的功能和體驗(yàn)，保障業(yè)務(wù)主目標(biāo)達(dá)成也就是保障S13所有要落地使用的業(yè)務(wù)功能。因此，制定技術(shù)保障計(jì)劃的思路是：首先確定S13要使用的業(yè)務(wù)功能范圍和各功能的業(yè)務(wù)指標(biāo)（如曝光量/轉(zhuǎn)化率等），其次將其轉(zhuǎn)化為技術(shù)鏈路和技術(shù)指標(biāo)（如QPS/TPS），最后運(yùn)用技術(shù)手段對(duì)齊進(jìn)行保障。

下圖為S13的保障計(jì)劃和時(shí)間線，下文也將逐步介紹我們是實(shí)踐和落地的：

圖2 S13整體保障計(jì)劃

業(yè)務(wù)場(chǎng)景地圖和核心業(yè)務(wù)指標(biāo)

業(yè)務(wù)場(chǎng)景地圖指的是S13所有落地要使用的業(yè)務(wù)功能，圈定了我們要保障的業(yè)務(wù)范圍；核心業(yè)務(wù)指標(biāo)在S13中指的是PCU（Peak Concurrent Users 直播間峰值在線人數(shù))，作為直播場(chǎng)景重要的指標(biāo)，決定了我們要保障的高并發(fā)量級(jí)。

項(xiàng)目立項(xiàng)后的第一時(shí)間，產(chǎn)運(yùn)研測(cè)各方一起討論敲定了業(yè)務(wù)場(chǎng)景地圖，共60+的業(yè)務(wù)功能，為便于下文具體講解如何將業(yè)務(wù)場(chǎng)景地圖/業(yè)務(wù)指標(biāo)轉(zhuǎn)化為技術(shù)鏈路/技術(shù)指標(biāo)、以及使用的技術(shù)保障手段，首先將S13核心功能介紹下：

表1 業(yè)務(wù)場(chǎng)景示意圖

• 活動(dòng)頁(yè)：S13投放了多個(gè)活動(dòng)頁(yè)提高用戶的參與度，如用戶可以在主活動(dòng)頁(yè)上追蹤賽程信息，觀賽的同時(shí)參與預(yù)測(cè)、觀看、分享、簽到等任務(wù)。
• 流量入口：S13作為一年一度的重要活動(dòng)，投放在多個(gè)資源位，用戶從這些入口進(jìn)入主房間；賽后，用戶從主房間退出再次返回這些流量入口。該場(chǎng)景需要關(guān)注返回時(shí)的自動(dòng)刷新機(jī)制帶來(lái)的尖刺流量。
• 主房間：S13最核心還是在直播間內(nèi)，包含流的觀看和功能互動(dòng)兩部分。流觀看從穩(wěn)定性來(lái)看，上行流和下行流需要保證穩(wěn)定可靠容災(zāi)；從帶寬成本來(lái)看，還需要考慮P2P覆蓋率、轉(zhuǎn)碼技術(shù)。此外，每次進(jìn)房需要獲取房間底層信息、功能數(shù)據(jù)（如榜單/運(yùn)營(yíng)位/底部Tab/歷史彈幕等），在比賽期間，還有天選時(shí)刻、熱力特效、Combo彈幕等互動(dòng)玩法。其次，房間內(nèi)的發(fā)彈幕/送禮特效等功能均依賴長(zhǎng)連接，而長(zhǎng)連接的壓力是PCU級(jí)別的放大效應(yīng)。最后，終端的性能表現(xiàn)、播放的質(zhì)量監(jiān)控也是保證用戶觀賽體驗(yàn)重要的一環(huán)。
• 稿件播放頁(yè)/動(dòng)態(tài)等：S13不僅是觀賽后就結(jié)束了，B站作為一個(gè)業(yè)務(wù)形態(tài)十分豐富的平臺(tái)，用戶還可以去觀看直播回放、知名解說(shuō)、在動(dòng)態(tài)話題評(píng)論等參與討論。

圖3 S13核心業(yè)務(wù)場(chǎng)景

實(shí)際執(zhí)行中，我們建議利用表格形式將業(yè)務(wù)場(chǎng)景地圖和業(yè)務(wù)指標(biāo)羅列出來(lái)：

表2 S13業(yè)務(wù)場(chǎng)景地圖一覽表表頭參考

表3 S13賽事各階段PCU預(yù)估

流量預(yù)估模型與優(yōu)化

流量預(yù)估模型

將業(yè)務(wù)核心指標(biāo)轉(zhuǎn)化為技術(shù)指標(biāo)，指的是利用曝光量/轉(zhuǎn)化率/點(diǎn)擊率等轉(zhuǎn)換成技術(shù)指標(biāo)QPS/TPS。S13的業(yè)務(wù)指標(biāo)PCU可等價(jià)于曝光量，一個(gè)業(yè)務(wù)功能對(duì)房間在線用戶同時(shí)曝光。根據(jù)我們的經(jīng)驗(yàn)，基本可以按照目標(biāo)QPS=曝光量*轉(zhuǎn)化率1*......*轉(zhuǎn)化率n/分?jǐn)倳r(shí)長(zhǎng)=PCU*轉(zhuǎn)化率1*......*轉(zhuǎn)化率n/分?jǐn)倳r(shí)長(zhǎng)。

圖4 技術(shù)指標(biāo)QPS/TPS的流量預(yù)估模型

下面通過(guò)幾個(gè)典型場(chǎng)景具體說(shuō)明該模型的運(yùn)用，以及主房間這類高在線房間遇到的瓶頸問(wèn)題，我們是如何通過(guò)熱門房間緩存、流量打散、流量隔離和下滑預(yù)加載等技術(shù)手段解決的：

進(jìn)房場(chǎng)景

功能概述：用戶從閃屏、首頁(yè)推薦、全量Push、小黃條等資源位進(jìn)入主房間時(shí)，終端向服務(wù)端請(qǐng)求流地址/房間底層信息/歷史彈幕等數(shù)據(jù)，使主房間成為高在線房間，帶來(lái)單房間熱點(diǎn)問(wèn)題。

QPS預(yù)估：總進(jìn)房QPS=各資源位進(jìn)房QPS之和。以全量Push為例，Push進(jìn)房QPS=全量用戶數(shù)*送達(dá)率*點(diǎn)擊率/推送時(shí)長(zhǎng)（全量用戶數(shù)*送達(dá)率=Push曝光量，推送時(shí)長(zhǎng)=分?jǐn)倳r(shí)長(zhǎng)）。

圖5 進(jìn)房場(chǎng)景QPS趨勢(shì)圖

技術(shù)優(yōu)化：?jiǎn)畏块g熱點(diǎn)問(wèn)題使得系統(tǒng)內(nèi)獲取房間維度數(shù)據(jù)成為瓶頸，優(yōu)化手段是通過(guò)PCU指標(biāo)高低判定是否為高在線房間，通過(guò)將高在線房間加入熱門房間內(nèi)存緩存來(lái)承接高并發(fā)請(qǐng)求。

圖6 高在線房間進(jìn)房場(chǎng)景優(yōu)化

圖7 進(jìn)房場(chǎng)景緩存命中率

天選時(shí)刻

功能概述：開啟天選時(shí)刻，主房間彈出天選參與框，用戶若點(diǎn)擊一鍵參與則參與本次天選，用戶若點(diǎn)擊關(guān)閉則放棄本次天選，到達(dá)設(shè)定時(shí)間后，從所有參與本次天選的用戶中選出中獎(jiǎng)用戶。

圖8 直播間天選時(shí)刻

QPS預(yù)估：參與天選接口的QPS=PCU*點(diǎn)擊參與轉(zhuǎn)化率。

技術(shù)優(yōu)化：當(dāng)PCU是百萬(wàn)千萬(wàn)級(jí)別時(shí)，該場(chǎng)景存在寫瓶頸。優(yōu)化手段是通過(guò)流量打散，將參與框?qū)τ脩舻膹棾鰰r(shí)間錯(cuò)開，分?jǐn)傇谝欢〞r(shí)間內(nèi)對(duì)所有用戶展示完（分?jǐn)倳r(shí)間不會(huì)影響用戶的參與時(shí)間），并且根據(jù)PCU來(lái)自適應(yīng)調(diào)整分?jǐn)倳r(shí)長(zhǎng)。經(jīng)調(diào)整，QPS=PCU*點(diǎn)擊參與轉(zhuǎn)化率/分?jǐn)倳r(shí)長(zhǎng)，有效化解了尖刺流量超出系統(tǒng)承受能力的問(wèn)題。

圖9 天選時(shí)刻打散

圖10 參與天選接口的尖刺流量

長(zhǎng)連接

功能概述：主房間內(nèi)多項(xiàng)功能依賴長(zhǎng)連接，例如用戶在主房間發(fā)送一條彈幕，長(zhǎng)連接會(huì)將此條彈幕廣播到所有與主房間建立連接的終端。

QPS預(yù)估：長(zhǎng)連接邊緣節(jié)點(diǎn)的壓力=N*PCU（N是同時(shí)發(fā)生的廣播事件）。一方面，N*PCU越大，帶寬成本越高；另一方面，實(shí)際并不會(huì)將所有事件都廣播出去，否則干擾用戶的觀看體驗(yàn)。

技術(shù)優(yōu)化：我們將主房間這類高在線房間的監(jiān)控和控制與其他房間隔離，針對(duì)主房間各廣播事件的QPS和Size單獨(dú)監(jiān)控、單獨(dú)限流，通過(guò)單獨(dú)調(diào)控主房間使系統(tǒng)壓力、帶寬成本和用戶體驗(yàn)達(dá)到一個(gè)平衡。

圖11 總帶寬和高在線房間帶寬隔離監(jiān)控

散場(chǎng)場(chǎng)景

功能概述：如前文介紹，主房間的散場(chǎng)路徑分別是退回至進(jìn)入房間之前的流量入口頁(yè)面和下滑至另外一個(gè)直播間。

QPS預(yù)估：

1. 散場(chǎng)路徑一為流量入口帶來(lái)的QPS=PCU*退回點(diǎn)擊率；
2. 散場(chǎng)路徑二為下滑的下一個(gè)直播間帶來(lái)的QPS=PCU*下滑轉(zhuǎn)化率。

與電影散場(chǎng)時(shí)觀眾同一時(shí)間集中走出觀影廳類似，上述兩個(gè)散場(chǎng)路徑的QPS是非常明顯的尖刺流量。

圖12 散場(chǎng)場(chǎng)景的尖刺流量

技術(shù)優(yōu)化：

1. 散場(chǎng)路徑一：出于推薦效果的考量，用戶停留在主房間超過(guò)一定時(shí)間后再回退至流量入口，部分流量入口會(huì)觸發(fā)自動(dòng)刷新機(jī)制。但并不是所有用戶回退后是繼續(xù)消費(fèi)最新推薦內(nèi)容。因此，采取的手段是在部分時(shí)間段避免觸發(fā)自動(dòng)刷新機(jī)制，更自動(dòng)化的手段是當(dāng)超出系統(tǒng)承受值時(shí)，自動(dòng)控制終端不觸發(fā)自動(dòng)刷新。
2. 散場(chǎng)路徑二：由于主房間的PCU過(guò)高，導(dǎo)致下滑的下一個(gè)房間也成為一個(gè)高在線房間，依賴高在線房間SDK可使該房間自動(dòng)進(jìn)入熱門房間緩存。但根據(jù)對(duì)推薦結(jié)果的分析，我們發(fā)現(xiàn)推薦的下一個(gè)房間聚集在有限的幾個(gè)賽事房間。為更安全的防御這類瞬時(shí)尖刺流量，優(yōu)化手段是基于推薦結(jié)果，利用這幾個(gè)賽事房間作為主房間下滑的房間候選池，并提前加入熱門房間內(nèi)存緩存。

圖13 散場(chǎng)路徑二優(yōu)化后緩存命中率效果

全局維度關(guān)注流量

同一個(gè)下游，可能被多個(gè)業(yè)務(wù)場(chǎng)景同時(shí)調(diào)用，該下游的流量是所有被調(diào)用之和。因此除了關(guān)注某個(gè)指定接口的QPS，還需以業(yè)務(wù)場(chǎng)景維度和整場(chǎng)活動(dòng)維度來(lái)關(guān)注，下文我們還會(huì)再探討實(shí)際操作上如何去做。

另外，從項(xiàng)目成本以及資源考慮，賽事期間的流量遠(yuǎn)高于日常，所需要的資源也遠(yuǎn)高于日常，需要提前盤點(diǎn)各階段成本、進(jìn)行資源的采買，因此全局估算流量也是資源容量預(yù)估的前提。

保障任務(wù)分工

確定業(yè)務(wù)場(chǎng)景地圖后，參與人和團(tuán)隊(duì)的確認(rèn)需要結(jié)合保障事項(xiàng)和組織架構(gòu)兩方面考慮。

參考RASIC原則，保障事項(xiàng)拆分為若干項(xiàng)子任務(wù)，每一項(xiàng)子任務(wù)需設(shè)立負(fù)責(zé)人以及明確責(zé)任邊界、目標(biāo)和DeadLine。另一方面，實(shí)際過(guò)程中不免存在交叉事項(xiàng)涉及多方資源協(xié)調(diào)，因此根據(jù)保障事項(xiàng)涉及到的部門，分別設(shè)立了部門級(jí)別的方向負(fù)責(zé)人，方向負(fù)責(zé)人被充分授權(quán)負(fù)責(zé)協(xié)調(diào)保障事宜。最后，建立定時(shí)定期同步進(jìn)展和風(fēng)險(xiǎn)的機(jī)制，也是整個(gè)項(xiàng)目順利運(yùn)行的重點(diǎn)。

圖14 保障接口人思路示意圖

實(shí)踐和思考

除了前文所述用戶強(qiáng)感知到的業(yè)務(wù)功能之外，還有基礎(chǔ)建設(shè)部分，如業(yè)務(wù)功能底層使用到的流媒體、長(zhǎng)連接、賬號(hào)、風(fēng)控等，我們將其歸納在業(yè)務(wù)基礎(chǔ)建設(shè)中分專項(xiàng)進(jìn)行保障。以及從B站的整體基礎(chǔ)架構(gòu)來(lái)看，各層基礎(chǔ)組件如動(dòng)態(tài)/靜態(tài)CDN、SLB、入侵防御WAF、統(tǒng)一網(wǎng)關(guān)APIGW、內(nèi)部服務(wù)發(fā)現(xiàn)Discovery、PaaS、存儲(chǔ)Redis/DB、異步消費(fèi)Databus、網(wǎng)絡(luò)、大數(shù)據(jù)等的資源預(yù)備、多活容災(zāi)能力、應(yīng)急預(yù)案，我們將其歸納在技術(shù)基礎(chǔ)建設(shè)中整體保障（見(jiàn)圖2）。

接下來(lái)我們將重點(diǎn)討論技術(shù)鏈路的梳理、故障演練、全鏈路壓測(cè)、預(yù)案SOP、變更管控和賽中跟蹤的實(shí)踐和思考：

圖15 重點(diǎn)保障事項(xiàng)時(shí)間線

技術(shù)鏈路梳理

技術(shù)鏈路梳理需要得到：

1. 該業(yè)務(wù)場(chǎng)景涉及到的請(qǐng)求接口以及每個(gè)接口的鏈路依賴
2. 這些請(qǐng)求接口以及鏈路依賴的QPS/TPS

故障演練、全鏈路壓測(cè)以及后續(xù)的SOP、監(jiān)控都依賴技術(shù)鏈路的梳理結(jié)果。根據(jù)代碼梳理技術(shù)鏈路是常用的方法：

Step1：梳理該業(yè)務(wù)場(chǎng)景下，涉及哪些用戶在什么時(shí)機(jī)下，在哪些位置上做什么動(dòng)作，即用戶、終端、服務(wù)端三者的交互。

Step2：根據(jù)交互流程，確定終端和服務(wù)端交互的接口。

Step3：下鉆每個(gè)交互接口的鏈路。

但在S13中，存在兩個(gè)問(wèn)題：

1. 時(shí)間成本高：根據(jù)經(jīng)驗(yàn)，完成一個(gè)場(chǎng)景的技術(shù)鏈路梳理需要0.5d~2d（與場(chǎng)景復(fù)雜度/熟悉程度相關(guān)），60+場(chǎng)景共需要100d左右。
2. 準(zhǔn)確性：人都有百密一疏，純靠人看代碼容易存在紕漏。

因此，聯(lián)同業(yè)務(wù)架構(gòu)團(tuán)隊(duì)，我們?cè)诜?wù)質(zhì)量保障平臺(tái)Advisor（下文簡(jiǎn)稱Advisor）上集成了輔助工具：在Advisor上定義S13涉及到的業(yè)務(wù)場(chǎng)景，通過(guò)抓包走一遍該業(yè)務(wù)場(chǎng)景下用戶的行為路徑，將抓包結(jié)果錄入系統(tǒng)，并根據(jù)Trace自動(dòng)輸出鏈路依賴，同時(shí)計(jì)算鏈路依賴的放大情況。

表3 Advisor場(chǎng)景管理

圖16 技術(shù)鏈路示意圖，其中每一個(gè)卡片標(biāo)記放大倍數(shù)

根據(jù)前文流量預(yù)估模型計(jì)算終端接口QPS和技術(shù)鏈路后，也可得到鏈路上各層依賴的QPS。也因?yàn)槠脚_(tái)上維護(hù)了技術(shù)鏈路元數(shù)據(jù)，讓前文提到的從業(yè)務(wù)場(chǎng)景維度和活動(dòng)全局維度關(guān)注流量成為一件可能實(shí)現(xiàn)的事情，否則以文檔形式記載技術(shù)鏈路，很難做到這一點(diǎn)。

圖17 Advisor上技術(shù)鏈路元數(shù)據(jù)模型

遺留的問(wèn)題是，某個(gè)業(yè)務(wù)場(chǎng)景可能由于版本不同、用戶身份不同導(dǎo)致技術(shù)鏈路不同，這里提供兩種解決方案：

方式1：構(gòu)造不同版本、不同用戶身份多次抓包，Advisor支持將多次抓包合并作為最終結(jié)果；在此基礎(chǔ)上，通過(guò)代碼檢查梳理結(jié)果是否全面。

方式2：Advisor根據(jù)線上真實(shí)請(qǐng)求匯總成完整的請(qǐng)求鏈路，再由技術(shù)同學(xué)從中擇選S13涉及到的鏈路。

圖18 基于完整鏈路擇選

故障演練

S13中希望通過(guò)故障演練平臺(tái)Fault（下文簡(jiǎn)稱Fault）達(dá)到的目的是：正確識(shí)別到技術(shù)鏈路上的強(qiáng)弱依賴，強(qiáng)依賴應(yīng)當(dāng)確保有發(fā)現(xiàn)機(jī)制和預(yù)案手段，弱依賴應(yīng)當(dāng)確?？梢宰詣?dòng)降級(jí)，且降級(jí)后不影響該業(yè)務(wù)場(chǎng)景的核心功能。建議故障演練放在前置工作：

1. 通過(guò)故障演練可識(shí)別S13的強(qiáng)依賴路徑，便于更有針對(duì)性的進(jìn)行壓測(cè)、SOP。
2. 故障演練發(fā)現(xiàn)的問(wèn)題涉及代碼改動(dòng)，壓測(cè)應(yīng)當(dāng)基于改動(dòng)后的代碼。

日常演練的做法是以接口維度將其中的故障點(diǎn)依次注入故障（可參考B站故障演練平臺(tái)實(shí)踐）。但S13的60+業(yè)務(wù)功能，逐一驗(yàn)證接口，時(shí)間成本太大。因此，將演練優(yōu)化為兩大步驟：

Step1：優(yōu)先確定面向終端的接口的強(qiáng)弱。如果某個(gè)接口故障并不影響該業(yè)務(wù)場(chǎng)景的核心功能，則定義為弱依賴。例如進(jìn)房場(chǎng)景，通過(guò)驗(yàn)證全屏/豎屏觀看、喚起禮物面板送禮、在彈幕區(qū)發(fā)送彈幕互動(dòng)等幾個(gè)核心功能，從20+個(gè)接口最終確定4個(gè)強(qiáng)依賴接口（見(jiàn)表3的強(qiáng)弱依賴標(biāo)注）。

Step2：針對(duì)Step1篩選出來(lái)的強(qiáng)依賴接口，聯(lián)同質(zhì)量工程效率團(tuán)隊(duì)建設(shè)了面向業(yè)務(wù)場(chǎng)景的故障演練，以業(yè)務(wù)場(chǎng)景維度整體驗(yàn)證。將Advisor的技術(shù)鏈路導(dǎo)入Fault，F(xiàn)ault自動(dòng)將標(biāo)注預(yù)期是弱依賴的依賴點(diǎn)組合排列，自動(dòng)依次注入故障和調(diào)用自動(dòng)化用例驗(yàn)證表現(xiàn)。

圖19 Step2示意圖

圖20 Fault業(yè)務(wù)場(chǎng)景演練

全鏈路壓測(cè)

S13通過(guò)全鏈路壓測(cè)平臺(tái)Melloi（下文簡(jiǎn)稱Melloi）來(lái)發(fā)現(xiàn)和驗(yàn)證高性能/高并發(fā)帶來(lái)的問(wèn)題，高在線房間存在的問(wèn)題也非常具有共性：

1. 熱點(diǎn)Key問(wèn)題：用戶集中在主房間，以房間Id/主播Id為 Key的緩存成為熱點(diǎn)Key。
2. 空緩存問(wèn)題：賽事期間用戶量相比平時(shí)翻了幾十上百倍，且存在不少一段時(shí)間內(nèi)沒(méi)有訪問(wèn)過(guò)直播的冷數(shù)據(jù)用戶，需要空緩存或者使用布隆過(guò)濾器防止緩存穿透造成DB的高并發(fā)，甚至部分場(chǎng)景需要預(yù)熱。
3. 消費(fèi)積壓?jiǎn)栴}：賽事活動(dòng)與用戶行為強(qiáng)相關(guān)，例如觀看達(dá)到X分鐘可獲獎(jiǎng)勵(lì)，主房間的觀看量百萬(wàn)千萬(wàn)級(jí)別，要求高性能消費(fèi)和削峰。

本文重點(diǎn)探討基于Advisor的技術(shù)鏈路信息，在壓測(cè)環(huán)節(jié)可做的優(yōu)化：

1. 提高壓測(cè)數(shù)據(jù)準(zhǔn)備的效率：純讀接口可根據(jù)Advisor信息從線上錄制流量回放作為壓測(cè)流量
2. 提高壓測(cè)結(jié)果回收的效率：可根據(jù)Advisor信息，與壓測(cè)流量對(duì)比，檢測(cè)壓測(cè)流量是否已覆蓋需要覆蓋的鏈路，以及技術(shù)鏈路上各層的指標(biāo)是否處于健康水位，并根據(jù)具體情況提供標(biāo)準(zhǔn)化解決方案的參考（例如熱Key問(wèn)題，可以提供統(tǒng)一的熱Key識(shí)別和解決方案）。

圖21 全鏈路提效示意圖

預(yù)案SOP

針對(duì)故障演練識(shí)別到的強(qiáng)依賴路徑，需要做好預(yù)案SOP?？梢钥s短MTTR為目標(biāo)，從1分鐘發(fā)現(xiàn)、5分鐘定位、10分鐘恢復(fù)的原則準(zhǔn)備預(yù)案：

表4 預(yù)案SOP模版

變更管控

基于安全變更要求，賽事直播保障期間，我們也啟用了變更管控封網(wǎng)，嚴(yán)格控制線上變更

數(shù)量，同時(shí)也需要支持必要的需求迭代變更，我們采取了以下措施：

1. 整個(gè)活動(dòng)保障期間：非強(qiáng)變更管控，根據(jù)前期場(chǎng)景梳理涉及到的業(yè)務(wù)功能，對(duì)其業(yè)務(wù)需求和技術(shù)需求上線變更要求進(jìn)行郵件報(bào)備。報(bào)備內(nèi)容需要包括變更內(nèi)容、變更的風(fēng)險(xiǎn)、如有問(wèn)題是否支持回滾、預(yù)案SOP等；
2. 關(guān)鍵賽事直播當(dāng)天：強(qiáng)變更管控，同樣來(lái)自前期場(chǎng)景梳理設(shè)計(jì)的業(yè)務(wù)應(yīng)用，通過(guò)“變更管控 ChangePilot”平臺(tái)進(jìn)行創(chuàng)建業(yè)務(wù)+服務(wù)等級(jí)的封網(wǎng)策略。同時(shí)支持緊急情況下的變更需求提供綠色通道。

圖22 強(qiáng)變更管控策略創(chuàng)建

賽中跟蹤

穩(wěn)定性可觀測(cè)：基于SLO體系的持續(xù)建設(shè)，我們實(shí)現(xiàn)了服務(wù)可用率、服務(wù)飽和度的觀測(cè)/告警覆蓋。賽事過(guò)程中通過(guò)穩(wěn)定性大盤我們能夠非常直觀的觀測(cè)到全站業(yè)務(wù)的穩(wěn)定性情況；當(dāng)服務(wù)出現(xiàn)可用率的下跌（10分鐘平均可用率N2），相關(guān)協(xié)同群會(huì)立即推送預(yù)警工單。同時(shí)提供相關(guān)錯(cuò)誤詳情和錯(cuò)誤根因推薦，大幅提高問(wèn)題排查定位效率；

圖23 SLO全網(wǎng)業(yè)務(wù)大盤

實(shí)時(shí)監(jiān)控大盤：除了全局業(yè)務(wù)穩(wěn)定性的觀測(cè)，賽事過(guò)程也同樣會(huì)關(guān)注PCU情況、核心場(chǎng)景的QPS、P90耗時(shí)、限流情況；以及核心場(chǎng)景涉及服務(wù)的容量水位；通過(guò)應(yīng)用APPID進(jìn)行元信息關(guān)聯(lián)，獲取直播場(chǎng)景下相關(guān)的緩存集群、數(shù)據(jù)庫(kù)實(shí)例、消息隊(duì)列等組件的信息，關(guān)聯(lián)實(shí)現(xiàn)組件容量水位的實(shí)時(shí)觀測(cè)。以上指標(biāo)均配置了不同檔位的閾值，能夠快速發(fā)現(xiàn)基礎(chǔ)資源容量風(fēng)險(xiǎn)。

圖24 賽事保障實(shí)時(shí)監(jiān)控大盤

基礎(chǔ)數(shù)據(jù)同步：基于業(yè)務(wù)SLO視角和大盤資源視角，我們會(huì)在賽事直播過(guò)程中進(jìn)行告警的應(yīng)急響應(yīng)處置、核心資源水位數(shù)據(jù)定時(shí)同步。直播后對(duì)告警事件處置情況以時(shí)間線方式導(dǎo)出，相關(guān)監(jiān)控?cái)?shù)據(jù)也會(huì)進(jìn)行持久化存儲(chǔ)，支持后續(xù)分析復(fù)盤。

展望

英雄聯(lián)盟總決賽今年已經(jīng)走到了第13個(gè)年頭，B站在每年的S賽保障上也逐漸積累了越來(lái)越多寶貴的經(jīng)驗(yàn)。此外，直播每年的大型活動(dòng)還有跨晚、拜年紀(jì)等，大型活動(dòng)保障的經(jīng)驗(yàn)如何以平臺(tái)化的方式沉淀下來(lái)，為后續(xù)的保障提高效率是我們需要進(jìn)一步考慮的。基于本次經(jīng)驗(yàn)，以及前文探討的直播特性問(wèn)題，對(duì)于一場(chǎng)活動(dòng)的保障可以考慮如下流程：

圖25 大型直播活動(dòng)保障平臺(tái)化

本期作者

趙丹丹嗶哩嗶哩資深開發(fā)工程師

吉翔 嗶哩嗶哩資深運(yùn)維工程師