一、背景

B站每年都會有多次大型活動，如拜年紀、最美的夜、LOL全球總決賽、電商626、919秒殺等其他活動。其中最美的夜和LOL全球總決賽是在線流量最高的活動。在S11總決賽過程中，全站整體平穩運行，無基礎設施、組件故障和服務核心鏈穩定性故障，抗住了遠超預期的在線人數和流量，直播同時在線人數突破千萬。

一場成功的活動保障離不開多個團隊的共同付出和努力。SRE在背后是如何支持保障這些活動并不斷完善我們的活動保障體系的呢？接下來就為大家揭曉。

二、活動場景

• 案例1

在SRE的某次活動保障中，突然聽到運營同學說某某時刻微信、頭條等APP會上線活動的推廣鏈接。考慮到微信和頭條APP的用戶量級，SRE擔心新用戶到來會對基礎資源和業務服務帶來沖擊。但因為事發突然，短時間大家也無法預估接下來的用戶量級。所幸最終推廣帶來的用戶增長有限，未對活動產生影響。

• 案例2

在某次活動事前溝通中，SRE從研發側得知運營要在活動中對全站在線用戶做一次站內Push：對打開App的所有用戶推送一個App內的彈窗。此方式會快速推送到幾千萬量級的在線用戶。如果用戶點進活動鏈接，那瞬間帶來的流量會擊垮活動業務，甚至對我們的基礎設施也會帶來壓力。SRE跟運營和研發三方確認后，認為此方案風險太大，最終取消。

• 案例3

在SRE的某次活動保障時，峰值流量已成功過去，活動保障進入收尾階段，大家已經準備收拾東西下班了。突然多個服務發生報警，服務不可用。SRE緊急介入排查，發現是活動后運營做了一個推送，導致用戶集中去訪問一個非活動鏈路中的服務，此服務未納入活動保障中，導致容量過載，服務不可用。

還有非常多類似的案例。所以對SRE來說，為了能成功的保障一場活動，除了技術上的保障和跟研發溝通外，還要主動跟運營、產品確認活動形式、玩法、外宣方式等，SRE得離業務近一點。SRE目前會收集活動如下的信息：

1、活動形式

活動的具體玩法是什么：是一個直播間、還是一個秒殺、還是一個互動等，不同的玩法所需要重點保障的業務場景完全不一樣。

2、重點場景

同一個活動，但重點場景可能不一樣。比如某一場直播的重要場景是在線人數和彈幕，但另一場直播的核心可能是用戶送禮和抽獎。

了解重點場景，可以指導SRE后續跟研發共建服務端保障的重點預估在線人數。

3、預估在線人數

活動本次預估在線人數是多少，如何預估出來的。

有哪些在線人數轉化的路徑。

4、活動對外鏈接

WEB、APP內的活動入口是什么？

站外有哪些引流入口？

了解用戶訪問路徑，SRE才能做到全鏈路的可用性保障。

5、活動推送

活動中一共有幾次推送？推送的形式是什么？用戶轉化率是多少？

6、活動后場景

活動結束時有沒有特殊行為，比如直播間自動跳轉點播頁面？

活動后有什么運營事件、有什么二次熱點？

這些事件所對應的用戶訪問路徑和服務都需要SRE去重點保障，不然會有始無終，顧頭不顧尾（這都是血淚的教訓）。

7、時間線

活動前期上線、外宣、預熱的時間線。

活動中的開始、推送、抽獎、口播、結束等時間線。

三、資源準備

根據前一步跟運營、研發了解的活動內容，我們已經知道本次活動預估的在線人數，根據此在線人數和歷史活動的容量數據，我們可以初步預測本次活動需要的資源。SRE把資源分為兩類：基礎資源和業務資源。

1、基礎資源

主要是基礎設施對應的資源，如下，一般是要確認CPU資源和帶寬資源：

• DNS
• DCDN（動態CDN）
• 靜態CDN帶寬
• 直播彈幕帶寬
• 高防
• 源站四層LB
• 源站七層SLB
• WAF
• IDC-云專線帶寬
• IDC間專線帶寬
• NAT帶寬
• 網絡硬件帶寬
• 日志/監控

在這里對最后兩項作出解釋：

1）日志/監控

活動期間大家格外關注監控數據，需要基于監控數據來執行預案，所以監控的保障非常重要，需要納入SRE的管理；日志類似，活動期間，查詢各種數據，用戶行為，業務異常等，也需要日志系統穩定。

2）網絡硬件帶寬

因為活動中業務流量突發，歷史活動中曾出現過網絡硬件設備帶寬被突發打滿的情況。所以對于業務的核心鏈路（機房入口—> 業務API GW —> 存儲類服務 —> 基礎設施）來說，確認這一步也非常有必要。

基于上面這些資源，會按如下的格式來確認信息：

• 使用容量和對應時間點
• 目前的使用水位
• 是否擴容、原因
• 彈性擴容方案、排期
• 擴容后水位
• 活動中容量預案
• 活動結束后方案
• 負責人

如下表：

經過如上的信息梳理，SRE跟基礎設施各團隊確定后續擴容方案，SRE對基礎設施的資源已經有了全局掌握。接下來SRE會跟業務團隊確認業務資源情況。

2、業務資源

業務所直接使用的PAAS、IAAS、緩存、DB資源等。一般需要確認的資源如下：

• PAAS（容器資源）
• IAAS（裸跑物理機資源）
• CACHE中間件
• MQ中間件
• KV 存儲
• DB 存儲

SRE構建了容量管理系統，可快速獲取業務部門資源的整體容量和使用水位、剩余Buffer可用等數據，確認活動所需資源缺口。業務資源通過采購機器或者混合云來滿足。待資源就緒后交付業務或交付給平臺擴容，在業務使用時動態擴容或提前擴容即可，后續通過性能壓測來驗證預估是否符合預期。

四、壓測&演練

1、性能壓測

每次活動前業務都有多次壓測，一般分為三輪。

第一輪：基于現有系統資源壓力，發現系統瓶頸和待優化項（部分活動可能沒有這一輪）

第二輪：資源交付、業務擴容、服務優化后按活動目標壓測（每個活動都會有這一輪）

第三輪：所有優化方案和保障方案上線后，再次壓測，驗證預案的有效性和服務最終能力，這次之后非必要需求不上線

在每輪壓測中，SRE的關注點并不相同。

1）第一輪

• 關注壓測工具、壓測鏈路是否穩定，是否滿足活動壓測需求；如壓測肉雞擴容；調整限流，以免攔截壓測流量。
• 發現有性能瓶頸的服務、接口，跟研發一起分析瓶頸點。
• 確認中間件是否有性能瓶頸，如Redis 熱KEY，DB 熱點SQL。
• 發現跨部門上下游服務鏈路中的瓶頸。

這一輪的壓測重點是關注壓測工具本身和業務服務的性能瓶頸，跟研發一起確定后續的改進方案。2）第二輪

• 關注活動目標是否可以達到。
• 關注基礎設施資源容量水位，確保安全。
• 關注業務資源情況，確保安全。
• 關注全鏈路上下游服務的瓶頸、中間件瓶頸。

這一輪壓測會有多次，中間伴隨著多次優化，直到滿足活動目標，容量水位安全，各依賴服務不再成為瓶頸。

2）第二輪

第二輪壓測過后，活動業務系統基本已滿足要求，SRE會跟研發確認各業務模塊和接口的限流配置，并討論限流執行的層級：七層SLB、業務API GW、服務框架層皆可支持限流配置。我們的最佳實踐是：

• 服務框架配置一個活動預期流量的限流閾值，基于活動實際峰值壓力再動態調整。
• API GW配置一個比服務框架寬松但保證服務不會過載的限流閾值。
• SLB配置一個保護API GW的限流閾值，一般是API GW限流閾值的兩倍以上。

在第二輪壓測階段，活動部門一般是關注自己業務場景的壓測。但活動也會給其他的基礎系統帶來壓力，如搜索、賬號、支付等，SRE此時會跨部門協調這些業務團隊也執行一次壓測，確保各系統容量皆是安全的，萬無一失。第二輪壓測后，各種保障方案也會確定配置上線的時間。

3）第三輪

第三輪壓測不是必須的。對于有第三輪壓測的業務，常見場景有三種：

• 比如S11，有1/8決賽，1/4決賽，根據前面比賽的真實數據，再次預估線上系統的總決賽壓力，對線上的系統做壓力復核，同時也驗證總決賽前業務上線的需求性能。
• 在線上的各種保障方案上線后，再次壓測，確保系統運行符合預期，如：HPA能自動擴容，各種限流可以生效，多機房分流符合預期等。
• 對服務做極限壓測，觀察服務的極限瓶頸，評估業務系統預期能支持的極限在線人數。如果業務支持的在線人數上限比較高，會給業務設置一個超出預期在線人數的限流配置。

這一輪壓測中SRE關注的重點是線上保障方案是否有效，預案是否符合預期，業務第二輪的壓測結果在這一輪是否能繼續達到，以及是否要調整各種預案。

2、演練

這里的演練是指預案演練和故障演練，這里重點講下故障演練。B站的故障演練，即混沌工程是在19年 SRE開始起步建設的，基于阿里開源的chaosblade工具打造，跟內部平臺集成，目前支持：

• 節點級故障：既支持PAAS環境的K8S節點，也支持裸跑業務的物理機 IAAS環境。
• 硬件資源爭搶：節點上的CPU負載、內存占用、磁盤占滿、網絡異常
• 上下游故障：服務間調用延遲、丟包、失敗
• 中間件故障：服務調用中間件，如CACHE、KV存儲、DB、MQ等延遲、丟包、失敗

目前混沌工程平臺既提供了面向研發、QA側的控制面故障注入能力，也提供了集成到自動化故障測試的API能力。SRE基于建設的混沌工程平臺，跟多個部門業務做了多期故障演練和自動化測試，如：

• 直播業務S11核心場景故障演練
• UGC業務場景對中間件依賴故障演練
• OGV業務場景上下游應用依賴故障演練
• 消息隊專項故障演練
• 電商業務場景的自動化故障測試
• ......

累計執行故障演練3000+次，發現服務隱患200+，對提升服務的可用性有非常顯著的效果。

發現的典型問題如下：

• 服務對下游服務應該是弱依賴，但編碼成了強依賴
• 服務調用下游服務失敗后，熔斷或降級方案未按預期生效
• 服務調用緩存超時或異常時，接口失敗，導致用戶請求失敗
• 服務調用消息隊列失敗，導致用戶寫操作失敗
• ......

對于大型活動場景，我們所演練的故障場景也比較類似，如下：

• 服務上下游調用失敗

服務間的強弱依賴是否合理，降級、熔斷機制是否生效。

• 服務對中間件的調用失敗

對中間件是否具有降級方案，降級方案是否生效。

• 服務所在宿主機節點故障

驗證服務是否具有狀態，是否可接受單點故障。

• 服務POD故障，POD里的某個sidecar故障

驗證平臺的failover能力是否符合預期，主容器對sidecar的依賴是否合理。

• 服務POD的CPU負載注入

驗證服務的HPA策略是否生效，HPA策略是否合理。

通過故障演練，SRE既保障了服務的容量和性能，也進一步提升了服務的可用性，提前發現服務架構中的脆弱環節，同時驗證了預案的有效性和監控、報警的準確率。

五、以史為鑒

在梳理我們的保障能力之前，SRE會先檢查《以史為鑒》環節的內容。SRE會把之前活動保障中做的不好的地方總結為歷史教訓，形成checklist，確保本次活動中相同的問題絕不會再次出現，如：

• 之前活動壓測遺漏了WEB端的服務鏈路，確保以后不會再犯。
• 活動期間，在離線混布沒有關閉，對在線服務的突發有一定壓力。以后活動時，要把在線核心業務場景的機器離線混布任務關閉。
• 活動期間關閉K8S的VPA策略，避免因為活動中服務壓力增加，導致第二天服務的request增加，資源池無資源可調度。
• 活動核心鏈路上有服務未開啟HPA，導致活動中需要手動擴容，效率較低。
• .....

通過checklist模式的確認，SRE能確保相同的問題不會再次出現，這種模式類似于Google SRE中提到的《發布檢查列表》。

六、技術保障

我們經常說業務高可用，也經常說業務可用性提升了，到底是業務運氣好沒出問題，還是因為我們的技術保障能力避免了業務出現問題？SRE到底有那些手段、能力、方案來保障業務的高可用呢？這里就來盤點下我們部分核心組件的業務保障能力。

1、DCDN

1）CDN緩存

如果業務可接受一定的數據延遲，可在DCDN上添加接口緩存，降低源站服務壓力和帶寬，如視頻彈幕列表、直播禮物道具等。2）多活服務的多機房交流

B站對于同城雙活類服務的調度是在DCDN層面實現的。對于支持了同城雙活的服務，DCDN可以動態調度多機房的流量比例。如果某個機房的服務出現問題，可快速切換用戶流量到其他機房。

2、七層SLB

1）全局限流

• B站的七層SLB基于OpenResty和部分自研功能實現。
• 前面有提到SLB的限流能力主要是為了保護業務API GW不過載。對于沒有API GW的服務，SLB限流直接保護服務不過載。

2）多或服務故障自動降級

• 如果一個多活服務的單機房出現問題，為了業務快速止損，切量到其他機房是最快的預案。
• 如果在DCDN層面切量，是需要手動執行切量操作的，目前執行時間在5分鐘左右。
• 為了實時止損，SLB會發現服務所有機房的節點，如果某個機房的節點無法處理請求時，SLB會把請求自動降級到其他多活機房/可用區。
• 這種降級能力目前需要手動開啟，適用于完整實現了同城雙活的服務。
• 對于活動場景的核心請求，SRE會跟研發提前溝通，在SLB上配置此降級能力。
• 此自動降級功能后來也做到了API GW的功能里，實現原理比較簡單，如下：

3、WAF

1）單IP限頻率

可配置單個IP對某個URL或域名在一段時間內訪問次數超過限制后封禁一定時間，一般用于接口防刷，用于保護服務端，提前攔截無用請求。

2）惡意IP封禁

可基于請求的某一特征，比如UA或者Referer，定向封禁活動中的刷子用戶。

4、PaaS

1）HPA橫向擴容：Horizontal Pod Autoscaler

• PaaS平臺是基于K8S構建的，支持基于服務的CPU、Memory、GPU等指標來彈性伸縮。
• 有些活動的時間會比較長，流量增長比較平緩，比如直播LOL賽事，就很適合添加HPA策略，讓服務容量根據壓力動態伸縮。
• 有些活動場景，比如電商手辦的秒殺，活動持續時間是秒級，可能活動已經結束了，但HPA還沒擴容生效，這種場景就不適合HPA。而是應該提前擴容容量，配置好限流閾值，做好容量保護。

2）VPA縱向擴容：Vertical Pod Autoscaler

• 資源池總的可調度資源是有限的，如果在活動時有業務臨時擴容或觸發HPA擴容導致資源池無資源可調度，此時遇到BUG需要服務發布或其他服務擴容，豈不是就無法處理了？這里就突出VPA的重要性了（VPA的概念可參考K8S文檔，這里不再贅述）。
• 正常情況下，在線業務資源使用率是較低的，峰值CPU使用率不會超過40%。只要資源池整體CPU使用率是安全的，我們就可以動態調整服務的request，釋放出資源給其他服務調度，這就是超分/超賣的邏輯。
• 前面有提到SRE的容量管理系統，此系統同樣支持對PaaS服務的VPA管理和動態執行，一條VPA策略的核心配置例如：選定一批服務，基于此服務過去1天cpu使用量的99分位值，設置cpu_used / cpu request * 100% = 50%；此策略可立即下發生效。
• 只要資源池總體CPU使用率水位是安全的，SRE就可以在服務無資源可調度時通過VPA能力快速釋放可調度資源，大大提升了SRE容量治理的靈活度和控制力。

3）混合云

• 如果資源池總體CPU使用率水位已經達到50%，此時不宜再用VPA能力繼續超分。
• SRE會給業務預留一個基于云K8S的資源池用作兜底擴容。如果IDC內的資源池容量不足，可10分鐘實現云K8S節點初始化并加入云資源池提供調度。

5、Cache

1）容量保障

• 數據層擴容一般耗時都比較久，建議業務基于前期壓測，提前擴好足夠的容量。
• 如果需要緊急擴容，SRE建議臨時增加單節點內存大小，盡量避免擴容節點。Redis擴容節點時Slot的遷移對業務有輕微的影響。

2）熱KEY、大KEY監控

• 如果服務使用了Cache proxy，可通過proxy側的埋點數據來發現熱KEY和大KEY。
• 如果服務直連了Redis，可通過Redis平臺臨時采樣抓取一段時間內的請求來分析熱KEY和大KEY。

6、DB

1）服務降級

在主從延遲比較大的時候(大于 120 秒) 觸發 DBA 的自動降級保護邏輯，犧牲一部分宕機場景的數據一致性( 最大 1s)，來提高從庫性能。

2）異常攔截

服務接入DB proxy后，支持異常 SQL 黑名單攔截。通過此能力已多次在線上快速攔截慢SQL讓業務快速止損。

3）負載均衡

把其他機房的從庫加入到讀負載，臨時提高讀請求的吞吐能力。

7、監控大盤

• SRE跟監控、業務研發一起，做了活動全鏈路監控Dashboard，一般包含業務大盤數據、基礎資源容量、業務監控、中間件監控等數據，內容會隨著具體活動而微調。
• 此大盤在活動現場保障時會用于現場投屏，大家一起緊盯監控大盤里的異常。

上述保障能力是我們保障體系中核心的部分能力，完整能力不再展開描述。SRE也會跟業務研發團隊盤點業務架構的上技術保障能力有哪些，這里不再展開描述。

SRE通過對上述技術保障能力的梳理，可以很清晰的知道目前我們有什么能力來保障活動的穩定性。SRE盤點完這些技術保障方案后，對SRE本身的能力也是一個全方位的提升。

七、預案能力

如果活動中出現了異常或者故障，SRE或業務研發團隊該如何選擇對應的技術保障能力，或者如何應急處理呢？預案能力的提前盤點也非常重要。預案是側重于已經發生問題時快速止損的能力。技術保障能力和預案能力的區別是：前者側重于問題發生前，后者側重于問題發生后。下面列出SRE在活動保障中關注的部分重要故障預案。

上面這些預案只是SRE側預案的一部分。除基礎設施、組件類的預案外，SRE還會跟業務研發團隊梳理業務側的預案，業務側的預案分為兩種：

• 業務熔斷、降級、限流等高可用類的預案
• 活動玩法、功能降級等產品體驗類預案

對于技術預案，這里再多聊一下。常見的預案有：切量、降級、限流、回滾、重啟、擴容等。在確定預案的優先級時，我們要從如下幾個方面來考慮：

• 概率：TOP3類故障場景的預案優先。
• 生效時間：生效時間越快，止損效果越好。
• 是否有損：預案是否對業務有損，優先損失較小的預案。
• 復雜度：預案執行的復雜度。
• 冪等性：預案多次執行的結果是否一樣，優先選擇不確定性較小的預案。

八、復盤改進

大型活動結束后，SRE會組織各團隊做活動復盤總結，如S11總決賽。SRE會提供一份活動復盤模板，模板內容大致如下：

1、項目目標

本次xx活動，SRE團隊的目標是：

• 首先，xx活動不能出現主流程事故。
• 其次，相關業務都不能出現主流程事故。
• 再者，不能出現基礎技術事故。

2、過程回顧

這個階段，我們的核心目標是做活動開始前準備階段的復盤總結。千萬不要只做活動中和活動后的復盤，活動準備階段也有很多非常有價值的優化改進項。

3、數據總結

此階段匯總活動中的一些核心數據，如最終在線人數，基礎資源使用容量水位、業務資源使用容量水位等。數據有兩部分重要用途：

• 用于后續活動中SRE做容量預估。
• 基于數據曲線挖掘活動中的一些預期外行為，如帶寬突刺，流量突刺等。

4、問題復盤

這個階段，SRE會記錄活動中出現的問題，并做復盤總結，確定后續改進方案。活動保障中所產生的Todo，SRE會專項跟進，定時確認進度，確保優化方案都執行落地。

5、反思總結

這個階段，SRE會思考整個活動保障項目中做的好的一面，不好的一面，進行整體的反思。比如活動后資源的回收目前就做的不好，后續需加到活動保障流程中去。同時也會重點更新我們活動模板中的以史為鑒checklist和其他內容。

九、總結展望

對SRE來說，參與一次活動保障，可快速了解整個系統中的基礎設施、組件能力、技術保障、預案、應急響應等，個人技術能力和綜合能力會得到極大的提升。大型活動同時也是對基礎架構和技術保障的一次大練兵。通過上述的活動保障體系，SRE已成功保障了B站近幾年所有的大型活動，包括流量遠超預期的S11總結賽千萬級用戶在線。在目前的保障中，部分保障措施還未自動化，人耗較高，如基礎資源的梳理。后續要把保障體系中人工的工作部分沉淀到活動保障平臺中，讓SRE可以更高效的保障大型活動。