大型直播活動保障S13的實踐和思考

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

S13的業務主目標是觀賽使用者達到1.2億，可拆解到賽前、賽中、賽後三個階段：

• 賽前重在流量蓄水，擴大目標使用者，透過賽事活動預熱、資源位投放、預約/Push召回，將流量引流到S13賽事主房間（下文簡稱主房間）觀賽。

• 賽中使用者集中在主房間，重點在提升使用者觀賽以及互動體驗，提高使用者的轉化率和留存率。

• 賽後引導觀賽使用者到稿件播放頁觀看回放，在評論區參與選手打分，在動態/話題持續發表自己對賽事的觀後感。

^{圖1 S13整體介紹}

因此，我們的保障目標是保證系統在洪峰流量下為使用者提供穩定的功能和流暢的觀賽體驗，配合業務側達成業務目標。面臨的挑戰概括為兩點：

1. 洪峰流量大：難點在如何估算業務指標、如何正確將業務指標轉換為技術指標、以及如何應對高併發流量。

2. 牽扯的業務範圍廣：難點在如何不缺不漏、以及如何在業務迭代壓力大的背景下儘可能提效的完成保障。

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

透過上文對業務主目標的介紹和拆解，可看到業務目標的達成依託於賽事各階段為使用者提供的功能和體驗，保障業務主目標達成也就是保障S13所有要落地使用的業務功能。因此，制定技術保障計劃的思路是：首先確定S13要使用的業務功能範圍和各功能的業務指標（如曝光量/轉化率等），其次將其轉化為技術鏈路和技術指標（如QPS/TPS），最後運用技術手段對齊進行保障。

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

^{圖2 S13整體保障計劃}

業務場景地圖指的是S13所有落地要使用的業務功能，圈定了我們要保障的業務範圍；核心業務指標在S13中指的是PCU（Peak Concurrent Users 直播間峰值線上人數)，作為直播場景重要的指標，決定了我們要保障的高併發量級。

專案立項後的第一時間，產運研測各方一起討論敲定了業務場景地圖，共60+的業務功能，為便於下文具體講解如何將業務場景地圖/業務指標轉化為技術鏈路/技術指標、以及使用的技術保障手段，首先將S13核心功能介紹下：

^{表1 業務場景示意圖}

• 活動頁：S13投放了多個活動頁提高使用者的參與度，如使用者可以在主活動頁上追蹤賽程資訊，觀賽的同時參與預測、觀看、分享、簽到等任務。

• 流量入口：S13作為一年一度的重要活動，投放在多個資源位，使用者從這些入口進入主房間；賽後，使用者從主房間退出再次返回這些流量入口。該場景需要關注返回時的自動重新整理機制帶來的尖刺流量。

• 主房間：S13最核心還是在直播間內，包含流的觀看和功能互動兩部分。流觀看從穩定性來看，上行流和下行流需要保證穩定可靠容災；從頻寬成本來看，還需要考慮P2P覆蓋率、轉碼技術。此外，每次進房需要獲取房間底層資訊、功能資料（如榜單/運營位/底部Tab/歷史彈幕等），在比賽期間，還有天選時刻、熱力特效、Combo彈幕等互動玩法。其次，房間內的發彈幕/送禮特效等功能均依賴長連線，而長連線的壓力是PCU級別的放大效應。最後，終端的效能表現、播放的質量監控也是保證使用者觀賽體驗重要的一環。

• 稿件播放頁/動態等：S13不僅是觀賽後就結束了，B站作為一個業務形態十分豐富的平臺，使用者還可以去觀看直播回放、知名解說、在動態話題評論等參與討論。

^{圖3 S13核心業務場景}

實際執行中，我們建議利用表格形式將業務場景地圖和業務指標羅列出來：

^{表2 S13業務場景地圖一覽表表頭參考}

^{表3 S13賽事各階段PCU預估}

將業務核心指標轉化為技術指標，指的是利用曝光量/轉化率/點選率等轉換成技術指標QPS/TPS。S13的業務指標PCU可等價於曝光量，一個業務功能對房間線上使用者同時曝光。根據我們的經驗，基本可以按照目標QPS=曝光量*轉化率1*......*轉化率n/分攤時長=PCU*轉化率1*......*轉化率n/分攤時長。

^{圖4 技術指標QPS/TPS的流量預估模型}

下面透過幾個典型場景具體說明該模型的運用，以及主房間這類高線上房間遇到的瓶頸問題，我們是如何透過熱門房間快取、流量打散、流量隔離和下滑預載入等技術手段解決的：

功能概述：使用者從閃屏、首頁推薦、全量Push、小黃條等資源位進入主房間時，終端向服務端請求流地址/房間底層資訊/歷史彈幕等資料，使主房間成為高線上房間，帶來單房間熱點問題。

QPS預估：總進房QPS=各資源位進房QPS之和。以全量Push為例，Push進房QPS=全量使用者數*送達率*點選率/推送時長（全量使用者數*送達率=Push曝光量，推送時長=分攤時長）。

^{圖5 進房場景QPS趨勢圖}

技術最佳化：單房間熱點問題使得系統內獲取房間維度資料成為瓶頸，最佳化手段是透過PCU指標高低判定是否為高線上房間，透過將高線上房間加入熱門房間記憶體快取來承接高併發請求。

^{圖6 高線上房間進房場景最佳化}

^{圖7 進房場景快取命中率}

功能概述：開啟天選時刻，主房間彈出天選參與框，使用者若點選一鍵參與則參與本次天選，使用者若點選關閉則放棄本次天選，到達設定時間後，從所有參與本次天選的使用者中選出中獎使用者。

^{圖8 直播間天選時刻}

QPS預估：參與天選介面的QPS=PCU*點選參與轉化率。

技術最佳化：當PCU是百萬千萬級別時，該場景存在寫瓶頸。最佳化手段是透過流量打散，將參與框對使用者的彈出時間錯開，分攤在一定時間內對所有使用者展示完（分攤時間不會影響使用者的參與時間），並且根據PCU來自適應調整分攤時長。經調整，QPS=PCU*點選參與轉化率/分攤時長，有效化解了尖刺流量超出系統承受能力的問題。

^{圖9 天選時刻打散}

^{圖10 參與天選介面的尖刺流量}

功能概述：主房間內多項功能依賴長連線，例如使用者在主房間傳送一條彈幕，長連線會將此條彈幕廣播到所有與主房間建立連線的終端。

QPS預估：長連線邊緣節點的壓力=N*PCU（N是同時發生的廣播事件）。一方面，N*PCU越大，頻寬成本越高；另一方面，實際並不會將所有事件都廣播出去，否則干擾使用者的觀看體驗。

技術最佳化：我們將主房間這類高線上房間的監控和控制與其他房間隔離，針對主房間各廣播事件的QPS和Size單獨監控、單獨限流，透過單獨調控主房間使系統壓力、頻寬成本和使用者體驗達到一個平衡。

^{圖11 總頻寬和高線上房間頻寬隔離監控}

功能概述：如前文介紹，主房間的散場路徑分別是退回至進入房間之前的流量入口頁面和下滑至另外一個直播間。

QPS預估：

1. 散場路徑一為流量入口帶來的QPS=PCU*退回點選率；

2. 散場路徑二為下滑的下一個直播間帶來的QPS=PCU*下滑轉化率。

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

^{圖12 散場場景的尖刺流量}

技術最佳化：

1. 散場路徑一：出於推薦效果的考量，使用者停留在主房間超過一定時間後再回退至流量入口，部分流量入口會觸發自動重新整理機制。但並不是所有使用者回退後是繼續消費最新推薦內容。因此，採取的手段是在部分時間段避免觸發自動重新整理機制，更自動化的手段是當超出系統承受值時，自動控制終端不觸發自動重新整理。

2. 散場路徑二：由於主房間的PCU過高，導致下滑的下一個房間也成為一個高線上房間，依賴高線上房間SDK可使該房間自動進入熱門房間快取。但根據對推薦結果的分析，我們發現推薦的下一個房間聚集在有限的幾個賽事房間。為更安全的防禦這類瞬時尖刺流量，最佳化手段是基於推薦結果，利用這幾個賽事房間作為主房間下滑的房間候選池，並提前加入熱門房間記憶體快取。

^{圖13 散場路徑二最佳化後快取命中率效果}

同一個下游，可能被多個業務場景同時呼叫，該下游的流量是所有被呼叫之和。因此除了關注某個指定介面的QPS，還需以業務場景維度和整場活動維度來關注，下文我們還會再探討實際操作上如何去做。

另外，從專案成本以及資源考慮，賽事期間的流量遠高於日常，所需要的資源也遠高於日常，需要提前盤點各階段成本、進行資源的採買，因此全域性估算流量也是資源容量預估的前提。

確定業務場景地圖後，參與人和團隊的確認需要結合保障事項和組織架構兩方面考慮。

參考RASIC原則，保障事項拆分為若干項子任務，每一項子任務需設立負責人以及明確責任邊界、目標和DeadLine。另一方面，實際過程中不免存在交叉事項涉及多方資源協調，因此根據保障事項涉及到的部門，分別設立了部門級別的方向負責人，方向負責人被充分授權負責協調保障事宜。最後，建立定時定期同步進展和風險的機制，也是整個專案順利執行的重點。

^{圖14 保障介面人思路示意圖}

除了前文所述使用者強感知到的業務功能之外，還有基礎建設部分，如業務功能底層使用到的流媒體、長連線、賬號、風控等，我們將其歸納在業務基礎建設中分專項進行保障。以及從B站的整體基礎架構來看，各層基礎元件如動態/靜態CDN、SLB、入侵防禦WAF、統一閘道器APIGW、內部服務發現Discovery、PaaS、儲存Redis/DB、非同步消費Databus、網路、大資料等的資源預備、多活容災能力、應急預案，我們將其歸納在技術基礎建設中整體保障（見圖2）。

接下來我們將重點討論技術鏈路的梳理、故障演練、全鏈路壓測、預案SOP、變更管控和賽中跟蹤的實踐和思考：

^{圖15 重點保障事項時間線}

技術鏈路梳理需要得到：

1. 該業務場景涉及到的請求介面以及每個介面的鏈路依賴

2. 這些請求介面以及鏈路依賴的QPS/TPS

故障演練、全鏈路壓測以及後續的SOP、監控都依賴技術鏈路的梳理結果。根據程式碼梳理技術鏈路是常用的方法：

Step1：梳理該業務場景下，涉及哪些使用者在什麼時機下，在哪些位置上做什麼動作，即使用者、終端、服務端三者的互動。

Step2：根據互動流程，確定終端和服務端互動的介面。

Step3：下鑽每個互動介面的鏈路。

但在S13中，存在兩個問題：

1. 時間成本高：根據經驗，完成一個場景的技術鏈路梳理需要0.5d~2d（與場景複雜度/熟悉程度相關），60+場景共需要100d左右。

2. 準確性：人都有百密一疏，純靠人看程式碼容易存在紕漏。

因此，聯同業務架構團隊，我們在服務質量保障平臺Advisor（下文簡稱Advisor）上整合了輔助工具：在Advisor上定義S13涉及到的業務場景，透過抓包走一遍該業務場景下使用者的行為路徑，將抓包結果錄入系統，並根據Trace自動輸出鏈路依賴，同時計算鏈路依賴的放大情況。

^{表3 Advisor場景管理}

^{圖16 技術鏈路示意圖，其中每一個卡片標記放大倍數}

根據前文流量預估模型計算終端介面QPS和技術鏈路後，也可得到鏈路上各層依賴的QPS。也因為平臺上維護了技術鏈路後設資料，讓前文提到的從業務場景維度和活動全域性維度關注流量成為一件可能實現的事情，否則以文件形式記載技術鏈路，很難做到這一點。

^{圖17 Advisor上技術鏈路後設資料模型}

遺留的問題是，某個業務場景可能由於版本不同、使用者身份不同導致技術鏈路不同，這裡提供兩種解決方案：

方式1：構造不同版本、不同使用者身份多次抓包，Advisor支援將多次抓包合併作為最終結果；在此基礎上，透過程式碼檢查梳理結果是否全面。

方式2：Advisor根據線上真實請求彙總成完整的請求鏈路，再由技術同學從中擇選S13涉及到的鏈路。

^{圖18 基於完整鏈路擇選}

S13中希望透過故障演練平臺Fault（下文簡稱Fault）達到的目的是：正確識別到技術鏈路上的強弱依賴，強依賴應當確保有發現機制和預案手段，弱依賴應當確保可以自動降級，且降級後不影響該業務場景的核心功能。建議故障演練放在前置工作：

1. 透過故障演練可識別S13的強依賴路徑，便於更有針對性的進行壓測、SOP。

2. 故障演練發現的問題涉及程式碼改動，壓測應當基於改動後的程式碼。

日常演練的做法是以介面維度將其中的故障點依次注入故障（可參考B站故障演練平臺實踐）。但S13的60+業務功能，逐一驗證介面，時間成本太大。因此，將演練最佳化為兩大步驟：

Step1：優先確定面向終端的介面的強弱。如果某個介面故障並不影響該業務場景的核心功能，則定義為弱依賴。例如進房場景，透過驗證全屏/豎屏觀看、喚起禮物皮膚送禮、在彈幕區傳送彈幕互動等幾個核心功能，從20+個介面最終確定4個強依賴介面（見表3的強弱依賴標註）。

Step2：針對Step1篩選出來的強依賴介面，聯同質量工程效率團隊建設了面向業務場景的故障演練，以業務場景維度整體驗證。將Advisor的技術鏈路匯入Fault，Fault自動將標註預期是弱依賴的依賴點組合排列，自動依次注入故障和呼叫自動化用例驗證表現。

^{圖19 Step2示意圖}

^{圖20 Fault業務場景演練}

S13透過全鏈路壓測平臺Melloi（下文簡稱Melloi）來發現和驗證高效能/高併發帶來的問題，高線上房間存在的問題也非常具有共性：

1. 熱點Key問題：使用者集中在主房間，以房間Id/主播Id為 Key的快取成為熱點Key。

2. 空快取問題：賽事期間使用者量相比平時翻了幾十上百倍，且存在不少一段時間內沒有訪問過直播的冷資料使用者，需要空快取或者使用布隆過濾器防止快取穿透造成DB的高併發，甚至部分場景需要預熱。

3. 消費積壓問題：賽事活動與使用者行為強相關，例如觀看達到X分鐘可獲獎勵，主房間的觀看量百萬千萬級別，要求高效能消費和削峰。

本文重點探討基於Advisor的技術鏈路資訊，在壓測環節可做的最佳化：

1. 提高壓測資料準備的效率：純讀介面可根據Advisor資訊從線上錄製流量回放作為壓測流量

2. 提高壓測結果回收的效率：可根據Advisor資訊，與壓測流量對比，檢測壓測流量是否已覆蓋需要覆蓋的鏈路，以及技術鏈路上各層的指標是否處於健康水位，並根據具體情況提供標準化解決方案的參考（例如熱Key問題，可以提供統一的熱Key識別和解決方案）。

^{圖21 全鏈路提效示意圖}

針對故障演練識別到的強依賴路徑，需要做好預案SOP。可以縮短MTTR為目標，從1分鐘發現、5分鐘定位、10分鐘恢復的原則準備預案：

^{表4 預案SOP模版}

基於安全變更要求，賽事直播保障期間，我們也啟用了變更管控封網，嚴格控制線上變更

數量，同時也需要支援必要的需求迭代變更，我們採取了以下措施：

1. 整個活動保障期間：非強變更管控，根據前期場景梳理涉及到的業務功能，對其業務需求和技術需求上線變更要求進行郵件報備。報備內容需要包括變更內容、變更的風險、如有問題是否支援回滾、預案SOP等；

2. 關鍵賽事直播當天：強變更管控，同樣來自前期場景梳理設計的業務應用，透過“變更管控 ChangePilot”平臺進行建立業務+服務等級的封網策略。同時支援緊急情況下的變更需求提供綠色通道。

^{圖22 強變更管控策略建立}

穩定性可觀測：基於SLO體系的持續建設，我們實現了服務可用率、服務飽和度的觀測/告警覆蓋。賽事過程中透過穩定性大盤我們能夠非常直觀的觀測到全站業務的穩定性情況；當服務出現可用率的下跌（10分鐘平均可用率N2），相關協同群會立即推送預警工單。同時提供相關錯誤詳情和錯誤根因推薦，大幅提高問題排查定位效率；

^{圖23 SLO全網業務大盤}

實時監控大盤：除了全域性業務穩定性的觀測，賽事過程也同樣會關注PCU情況、核心場景的QPS、P90耗時、限流情況；以及核心場景涉及服務的容量水位；透過應用APPID進行元資訊關聯，獲取直播場景下相關的快取叢集、資料庫例項、訊息佇列等元件的資訊，關聯實現元件容量水位的實時觀測。以上指標均配置了不同檔位的閾值，能夠快速發現基礎資源容量風險。

^{圖24 賽事保障實時監控大盤}

基礎資料同步：基於業務SLO視角和大盤資源視角，我們會在賽事直播過程中進行告警的應急響應處置、核心資源水位資料定時同步。直播後對告警事件處置情況以時間線方式匯出，相關監控資料也會進行持久化儲存，支援後續分析覆盤。

英雄聯盟總決賽今年已經走到了第13個年頭，B站在每年的S賽保障上也逐漸積累了越來越多寶貴的經驗。此外，直播每年的大型活動還有跨晚、拜年紀等，大型活動保障的經驗如何以平臺化的方式沉澱下來，為後續的保障提高效率是我們需要進一步考慮的。基於本次經驗，以及前文探討的直播特性問題，對於一場活動的保障可以考慮如下流程：

^{圖25 大型直播活動保障平臺化}

S13已完美落幕，賽事期間，超1.2億使用者在B站觀看英雄聯盟相關內容，決賽直播人氣峰值超4.6億，順利完成了業務目標。本文主要探討了S13保障的思路、落地手段，以及大型活動保障平臺未來發展的可能性。最後，感謝S13技術保障的每一位同學！