一、背景

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

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

二、活動場景

• 案例1

在SRE的某次活動保障中，突然聽到運(yùn)營同學(xué)說某某時(shí)刻微信、頭條等APP會上線活動的推廣鏈接。考慮到微信和頭條APP的用戶量級，SRE擔(dān)心新用戶到來會對基礎(chǔ)資源和業(yè)務(wù)服務(wù)帶來沖擊。但因?yàn)槭掳l(fā)突然，短時(shí)間大家也無法預(yù)估接下來的用戶量級。所幸最終推廣帶來的用戶增長有限，未對活動產(chǎn)生影響。

• 案例2

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

• 案例3

在SRE的某次活動保障時(shí)，峰值流量已成功過去，活動保障進(jìn)入收尾階段，大家已經(jīng)準(zhǔn)備收拾東西下班了。突然多個(gè)服務(wù)發(fā)生報(bào)警，服務(wù)不可用。SRE緊急介入排查，發(fā)現(xiàn)是活動后運(yùn)營做了一個(gè)推送，導(dǎo)致用戶集中去訪問一個(gè)非活動鏈路中的服務(wù)，此服務(wù)未納入活動保障中，導(dǎo)致容量過載，服務(wù)不可用。

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

1、活動形式

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

2、重點(diǎn)場景

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

了解重點(diǎn)場景，可以指導(dǎo)SRE后續(xù)跟研發(fā)共建服務(wù)端保障的重點(diǎn)預(yù)估在線人數(shù)。

3、預(yù)估在線人數(shù)

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

有哪些在線人數(shù)轉(zhuǎn)化的路徑。

4、活動對外鏈接

WEB、APP內(nèi)的活動入口是什么？

站外有哪些引流入口？

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

5、活動推送

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

6、活動后場景

活動結(jié)束時(shí)有沒有特殊行為，比如直播間自動跳轉(zhuǎn)點(diǎn)播頁面？

活動后有什么運(yùn)營事件、有什么二次熱點(diǎn)？

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

7、時(shí)間線

活動前期上線、外宣、預(yù)熱的時(shí)間線。

活動中的開始、推送、抽獎、口播、結(jié)束等時(shí)間線。

三、資源準(zhǔn)備

根據(jù)前一步跟運(yùn)營、研發(fā)了解的活動內(nèi)容，我們已經(jīng)知道本次活動預(yù)估的在線人數(shù)，根據(jù)此在線人數(shù)和歷史活動的容量數(shù)據(jù)，我們可以初步預(yù)測本次活動需要的資源。SRE把資源分為兩類：基礎(chǔ)資源和業(yè)務(wù)資源。

1、基礎(chǔ)資源

主要是基礎(chǔ)設(shè)施對應(yīng)的資源，如下，一般是要確認(rèn)CPU資源和帶寬資源：

• DNS
• DCDN（動態(tài)CDN）
• 靜態(tài)CDN帶寬
• 直播彈幕帶寬
• 高防
• 源站四層LB
• 源站七層SLB
• WAF
• IDC-云專線帶寬
• IDC間專線帶寬
• NAT帶寬
• 網(wǎng)絡(luò)硬件帶寬
• 日志/監(jiān)控

在這里對最后兩項(xiàng)作出解釋：

1）日志/監(jiān)控

活動期間大家格外關(guān)注監(jiān)控?cái)?shù)據(jù)，需要基于監(jiān)控?cái)?shù)據(jù)來執(zhí)行預(yù)案，所以監(jiān)控的保障非常重要，需要納入SRE的管理；日志類似，活動期間，查詢各種數(shù)據(jù)，用戶行為，業(yè)務(wù)異常等，也需要日志系統(tǒng)穩(wěn)定。

2）網(wǎng)絡(luò)硬件帶寬

因?yàn)榛顒又袠I(yè)務(wù)流量突發(fā)，歷史活動中曾出現(xiàn)過網(wǎng)絡(luò)硬件設(shè)備帶寬被突發(fā)打滿的情況。所以對于業(yè)務(wù)的核心鏈路（機(jī)房入口—> 業(yè)務(wù)API GW —> 存儲類服務(wù) —> 基礎(chǔ)設(shè)施）來說，確認(rèn)這一步也非常有必要。

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

• 使用容量和對應(yīng)時(shí)間點(diǎn)
• 目前的使用水位
• 是否擴(kuò)容、原因
• 彈性擴(kuò)容方案、排期
• 擴(kuò)容后水位
• 活動中容量預(yù)案
• 活動結(jié)束后方案
• 負(fù)責(zé)人

如下表：

經(jīng)過如上的信息梳理，SRE跟基礎(chǔ)設(shè)施各團(tuán)隊(duì)確定后續(xù)擴(kuò)容方案，SRE對基礎(chǔ)設(shè)施的資源已經(jīng)有了全局掌握。接下來SRE會跟業(yè)務(wù)團(tuán)隊(duì)確認(rèn)業(yè)務(wù)資源情況。

2、業(yè)務(wù)資源

業(yè)務(wù)所直接使用的PAAS、IAAS、緩存、DB資源等。一般需要確認(rèn)的資源如下：

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

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

四、壓測&演練

1、性能壓測

每次活動前業(yè)務(wù)都有多次壓測，一般分為三輪。

第一輪：基于現(xiàn)有系統(tǒng)資源壓力，發(fā)現(xiàn)系統(tǒng)瓶頸和待優(yōu)化項(xiàng)（部分活動可能沒有這一輪）

第二輪：資源交付、業(yè)務(wù)擴(kuò)容、服務(wù)優(yōu)化后按活動目標(biāo)壓測（每個(gè)活動都會有這一輪）

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

在每輪壓測中，SRE的關(guān)注點(diǎn)并不相同。

1）第一輪

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

這一輪的壓測重點(diǎn)是關(guān)注壓測工具本身和業(yè)務(wù)服務(wù)的性能瓶頸，跟研發(fā)一起確定后續(xù)的改進(jìn)方案。2）第二輪

• 關(guān)注活動目標(biāo)是否可以達(dá)到。
• 關(guān)注基礎(chǔ)設(shè)施資源容量水位，確保安全。
• 關(guān)注業(yè)務(wù)資源情況，確保安全。
• 關(guān)注全鏈路上下游服務(wù)的瓶頸、中間件瓶頸。

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

2）第二輪

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

• 服務(wù)框架配置一個(gè)活動預(yù)期流量的限流閾值，基于活動實(shí)際峰值壓力再動態(tài)調(diào)整。
• API GW配置一個(gè)比服務(wù)框架寬松但保證服務(wù)不會過載的限流閾值。
• SLB配置一個(gè)保護(hù)API GW的限流閾值，一般是API GW限流閾值的兩倍以上。

在第二輪壓測階段，活動部門一般是關(guān)注自己業(yè)務(wù)場景的壓測。但活動也會給其他的基礎(chǔ)系統(tǒng)帶來壓力，如搜索、賬號、支付等，SRE此時(shí)會跨部門協(xié)調(diào)這些業(yè)務(wù)團(tuán)隊(duì)也執(zhí)行一次壓測，確保各系統(tǒng)容量皆是安全的，萬無一失。第二輪壓測后，各種保障方案也會確定配置上線的時(shí)間。

3）第三輪

第三輪壓測不是必須的。對于有第三輪壓測的業(yè)務(wù)，常見場景有三種：

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

這一輪壓測中SRE關(guān)注的重點(diǎn)是線上保障方案是否有效，預(yù)案是否符合預(yù)期，業(yè)務(wù)第二輪的壓測結(jié)果在這一輪是否能繼續(xù)達(dá)到，以及是否要調(diào)整各種預(yù)案。

2、演練

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

• 節(jié)點(diǎn)級故障：既支持PAAS環(huán)境的K8S節(jié)點(diǎn)，也支持裸跑業(yè)務(wù)的物理機(jī) IAAS環(huán)境。
• 硬件資源爭搶：節(jié)點(diǎn)上的CPU負(fù)載、內(nèi)存占用、磁盤占滿、網(wǎng)絡(luò)異常
• 上下游故障：服務(wù)間調(diào)用延遲、丟包、失敗
• 中間件故障：服務(wù)調(diào)用中間件，如CACHE、KV存儲、DB、MQ等延遲、丟包、失敗

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

• 直播業(yè)務(wù)S11核心場景故障演練
• UGC業(yè)務(wù)場景對中間件依賴故障演練
• OGV業(yè)務(wù)場景上下游應(yīng)用依賴故障演練
• 消息隊(duì)專項(xiàng)故障演練
• 電商業(yè)務(wù)場景的自動化故障測試
• ......

累計(jì)執(zhí)行故障演練3000+次，發(fā)現(xiàn)服務(wù)隱患200+，對提升服務(wù)的可用性有非常顯著的效果。

發(fā)現(xiàn)的典型問題如下：

• 服務(wù)對下游服務(wù)應(yīng)該是弱依賴，但編碼成了強(qiáng)依賴
• 服務(wù)調(diào)用下游服務(wù)失敗后，熔斷或降級方案未按預(yù)期生效
• 服務(wù)調(diào)用緩存超時(shí)或異常時(shí)，接口失敗，導(dǎo)致用戶請求失敗
• 服務(wù)調(diào)用消息隊(duì)列失敗，導(dǎo)致用戶寫操作失敗
• ......

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

• 服務(wù)上下游調(diào)用失敗

服務(wù)間的強(qiáng)弱依賴是否合理，降級、熔斷機(jī)制是否生效。

• 服務(wù)對中間件的調(diào)用失敗

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

• 服務(wù)所在宿主機(jī)節(jié)點(diǎn)故障

驗(yàn)證服務(wù)是否具有狀態(tài)，是否可接受單點(diǎn)故障。

• 服務(wù)POD故障，POD里的某個(gè)sidecar故障

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

• 服務(wù)POD的CPU負(fù)載注入

驗(yàn)證服務(wù)的HPA策略是否生效，HPA策略是否合理。

通過故障演練，SRE既保障了服務(wù)的容量和性能，也進(jìn)一步提升了服務(wù)的可用性，提前發(fā)現(xiàn)服務(wù)架構(gòu)中的脆弱環(huán)節(jié)，同時(shí)驗(yàn)證了預(yù)案的有效性和監(jiān)控、報(bào)警的準(zhǔn)確率。

五、以史為鑒

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

• 之前活動壓測遺漏了WEB端的服務(wù)鏈路，確保以后不會再犯。
• 活動期間，在離線混布沒有關(guān)閉，對在線服務(wù)的突發(fā)有一定壓力。以后活動時(shí)，要把在線核心業(yè)務(wù)場景的機(jī)器離線混布任務(wù)關(guān)閉。
• 活動期間關(guān)閉K8S的VPA策略，避免因?yàn)榛顒又蟹?wù)壓力增加，導(dǎo)致第二天服務(wù)的request增加，資源池?zé)o資源可調(diào)度。
• 活動核心鏈路上有服務(wù)未開啟HPA，導(dǎo)致活動中需要手動擴(kuò)容，效率較低。
• .....

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

六、技術(shù)保障

我們經(jīng)常說業(yè)務(wù)高可用，也經(jīng)常說業(yè)務(wù)可用性提升了，到底是業(yè)務(wù)運(yùn)氣好沒出問題，還是因?yàn)槲覀兊募夹g(shù)保障能力避免了業(yè)務(wù)出現(xiàn)問題？SRE到底有那些手段、能力、方案來保障業(yè)務(wù)的高可用呢？這里就來盤點(diǎn)下我們部分核心組件的業(yè)務(wù)保障能力。

1、DCDN

1）CDN緩存

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

B站對于同城雙活類服務(wù)的調(diào)度是在DCDN層面實(shí)現(xiàn)的。對于支持了同城雙活的服務(wù)，DCDN可以動態(tài)調(diào)度多機(jī)房的流量比例。如果某個(gè)機(jī)房的服務(wù)出現(xiàn)問題，可快速切換用戶流量到其他機(jī)房。

2、七層SLB

1）全局限流

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

2）多或服務(wù)故障自動降級

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

3、WAF

1）單IP限頻率

可配置單個(gè)IP對某個(gè)URL或域名在一段時(shí)間內(nèi)訪問次數(shù)超過限制后封禁一定時(shí)間，一般用于接口防刷，用于保護(hù)服務(wù)端，提前攔截?zé)o用請求。

2）惡意IP封禁

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

4、PaaS

1）HPA橫向擴(kuò)容：Horizontal Pod Autoscaler

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

2）VPA縱向擴(kuò)容：Vertical Pod Autoscaler

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

3）混合云

• 如果資源池總體CPU使用率水位已經(jīng)達(dá)到50%，此時(shí)不宜再用VPA能力繼續(xù)超分。
• SRE會給業(yè)務(wù)預(yù)留一個(gè)基于云K8S的資源池用作兜底擴(kuò)容。如果IDC內(nèi)的資源池容量不足，可10分鐘實(shí)現(xiàn)云K8S節(jié)點(diǎn)初始化并加入云資源池提供調(diào)度。

5、Cache

1）容量保障

• 數(shù)據(jù)層擴(kuò)容一般耗時(shí)都比較久，建議業(yè)務(wù)基于前期壓測，提前擴(kuò)好足夠的容量。
• 如果需要緊急擴(kuò)容，SRE建議臨時(shí)增加單節(jié)點(diǎn)內(nèi)存大小，盡量避免擴(kuò)容節(jié)點(diǎn)。Redis擴(kuò)容節(jié)點(diǎn)時(shí)Slot的遷移對業(yè)務(wù)有輕微的影響。

2）熱KEY、大KEY監(jiān)控

• 如果服務(wù)使用了Cache proxy，可通過proxy側(cè)的埋點(diǎn)數(shù)據(jù)來發(fā)現(xiàn)熱KEY和大KEY。
• 如果服務(wù)直連了Redis，可通過Redis平臺臨時(shí)采樣抓取一段時(shí)間內(nèi)的請求來分析熱KEY和大KEY。

6、DB

1）服務(wù)降級

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

2）異常攔截

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

3）負(fù)載均衡

把其他機(jī)房的從庫加入到讀負(fù)載，臨時(shí)提高讀請求的吞吐能力。

7、監(jiān)控大盤

• SRE跟監(jiān)控、業(yè)務(wù)研發(fā)一起，做了活動全鏈路監(jiān)控Dashboard，一般包含業(yè)務(wù)大盤數(shù)據(jù)、基礎(chǔ)資源容量、業(yè)務(wù)監(jiān)控、中間件監(jiān)控等數(shù)據(jù)，內(nèi)容會隨著具體活動而微調(diào)。
• 此大盤在活動現(xiàn)場保障時(shí)會用于現(xiàn)場投屏，大家一起緊盯監(jiān)控大盤里的異常。

上述保障能力是我們保障體系中核心的部分能力，完整能力不再展開描述。SRE也會跟業(yè)務(wù)研發(fā)團(tuán)隊(duì)盤點(diǎn)業(yè)務(wù)架構(gòu)的上技術(shù)保障能力有哪些，這里不再展開描述。

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

七、預(yù)案能力

如果活動中出現(xiàn)了異?；蛘吖收?，SRE或業(yè)務(wù)研發(fā)團(tuán)隊(duì)該如何選擇對應(yīng)的技術(shù)保障能力，或者如何應(yīng)急處理呢？預(yù)案能力的提前盤點(diǎn)也非常重要。預(yù)案是側(cè)重于已經(jīng)發(fā)生問題時(shí)快速止損的能力。技術(shù)保障能力和預(yù)案能力的區(qū)別是：前者側(cè)重于問題發(fā)生前，后者側(cè)重于問題發(fā)生后。下面列出SRE在活動保障中關(guān)注的部分重要故障預(yù)案。

上面這些預(yù)案只是SRE側(cè)預(yù)案的一部分。除基礎(chǔ)設(shè)施、組件類的預(yù)案外，SRE還會跟業(yè)務(wù)研發(fā)團(tuán)隊(duì)梳理業(yè)務(wù)側(cè)的預(yù)案，業(yè)務(wù)側(cè)的預(yù)案分為兩種：

• 業(yè)務(wù)熔斷、降級、限流等高可用類的預(yù)案
• 活動玩法、功能降級等產(chǎn)品體驗(yàn)類預(yù)案

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

• 概率：TOP3類故障場景的預(yù)案優(yōu)先。
• 生效時(shí)間：生效時(shí)間越快，止損效果越好。
• 是否有損：預(yù)案是否對業(yè)務(wù)有損，優(yōu)先損失較小的預(yù)案。
• 復(fù)雜度：預(yù)案執(zhí)行的復(fù)雜度。
• 冪等性：預(yù)案多次執(zhí)行的結(jié)果是否一樣，優(yōu)先選擇不確定性較小的預(yù)案。

八、復(fù)盤改進(jìn)

大型活動結(jié)束后，SRE會組織各團(tuán)隊(duì)做活動復(fù)盤總結(jié)，如S11總決賽。SRE會提供一份活動復(fù)盤模板，模板內(nèi)容大致如下：

1、項(xiàng)目目標(biāo)

本次xx活動，SRE團(tuán)隊(duì)的目標(biāo)是：

• 首先，xx活動不能出現(xiàn)主流程事故。
• 其次，相關(guān)業(yè)務(wù)都不能出現(xiàn)主流程事故。
• 再者，不能出現(xiàn)基礎(chǔ)技術(shù)事故。

2、過程回顧

這個(gè)階段，我們的核心目標(biāo)是做活動開始前準(zhǔn)備階段的復(fù)盤總結(jié)。千萬不要只做活動中和活動后的復(fù)盤，活動準(zhǔn)備階段也有很多非常有價(jià)值的優(yōu)化改進(jìn)項(xiàng)。

3、數(shù)據(jù)總結(jié)

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

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

4、問題復(fù)盤

這個(gè)階段，SRE會記錄活動中出現(xiàn)的問題，并做復(fù)盤總結(jié)，確定后續(xù)改進(jìn)方案?；顒颖Ｕ现兴a(chǎn)生的Todo，SRE會專項(xiàng)跟進(jìn)，定時(shí)確認(rèn)進(jìn)度，確保優(yōu)化方案都執(zhí)行落地。

5、反思總結(jié)

這個(gè)階段，SRE會思考整個(gè)活動保障項(xiàng)目中做的好的一面，不好的一面，進(jìn)行整體的反思。比如活動后資源的回收目前就做的不好，后續(xù)需加到活動保障流程中去。同時(shí)也會重點(diǎn)更新我們活動模板中的以史為鑒checklist和其他內(nèi)容。

九、總結(jié)展望

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