2021.07.13 B站是這樣崩的

2021年7月13日22:52，SRE收到大量服務(wù)和域名的接入層不可用報(bào)警，客服側(cè)開始收到大量用戶反饋B站無(wú)法使用，同時(shí)內(nèi)部同學(xué)也反饋B站無(wú)法打開，甚至APP首頁(yè)也無(wú)法打開。

基于報(bào)警內(nèi)容，SRE第一時(shí)間懷疑機(jī)房、網(wǎng)絡(luò)、四層LB、七層SLB等基礎(chǔ)設(shè)施出現(xiàn)問題，緊急發(fā)起語(yǔ)音會(huì)議，拉各團(tuán)隊(duì)相關(guān)人員開始緊急處理（為了方便理解，下述事故處理過程做了部分簡(jiǎn)化）。

22:55 遠(yuǎn)程在家的相關(guān)同學(xué)登陸VPN后，無(wú)法登陸內(nèi)網(wǎng)鑒權(quán)系統(tǒng)（B站內(nèi)部系統(tǒng)有統(tǒng)一鑒權(quán)，需要先獲取登錄態(tài)后才可登陸其他內(nèi)部系統(tǒng)），導(dǎo)致無(wú)法打開內(nèi)部系統(tǒng)，無(wú)法及時(shí)查看監(jiān)控、日志來定位問題。

22:57 在公司Oncall的SRE同學(xué)（無(wú)需VPN和再次登錄內(nèi)網(wǎng)鑒權(quán)系統(tǒng)）發(fā)現(xiàn)在線業(yè)務(wù)主機(jī)房七層SLB（基于OpenResty構(gòu)建） CPU 100%，無(wú)法處理用戶請(qǐng)求，其他基礎(chǔ)設(shè)施反饋未出問題，此時(shí)已確認(rèn)是接入層七層SLB故障，排除SLB以下的業(yè)務(wù)層問題。

23:07 遠(yuǎn)程在家的同學(xué)緊急聯(lián)系負(fù)責(zé)VPN和內(nèi)網(wǎng)鑒權(quán)系統(tǒng)的同學(xué)后，了解可通過綠色通道登錄到內(nèi)網(wǎng)系統(tǒng)。

23:17 相關(guān)同學(xué)通過綠色通道陸續(xù)登錄到內(nèi)網(wǎng)系統(tǒng)，開始協(xié)助處理問題，此時(shí)處理事故的核心同學(xué)（七層SLB、四層LB、CDN）全部到位。

23:20  SLB運(yùn)維分析發(fā)現(xiàn)在故障時(shí)流量有突發(fā)，懷疑SLB因流量過載不可用。因主機(jī)房SLB承載全部在線業(yè)務(wù)，先Reload SLB未恢復(fù)后嘗試拒絕用戶流量冷重啟SLB，冷重啟后CPU依然100%，未恢復(fù)。

23:22  從用戶反饋來看，多活機(jī)房服務(wù)也不可用。SLB運(yùn)維分析發(fā)現(xiàn)多活機(jī)房SLB請(qǐng)求大量超時(shí)，但CPU未過載，準(zhǔn)備重啟多活機(jī)房SLB先嘗試止損。

23:23  此時(shí)內(nèi)部群里同學(xué)反饋主站服務(wù)已恢復(fù)，觀察多活機(jī)房SLB監(jiān)控，請(qǐng)求超時(shí)數(shù)量大大降低，業(yè)務(wù)成功率恢復(fù)到50%以上。此時(shí)做了多活的業(yè)務(wù)核心功能基本恢復(fù)正常，如APP推薦、APP播放、評(píng)論&彈幕拉取、動(dòng)態(tài)、追番、影視等。非多活服務(wù)暫未恢復(fù)。

23:25 - 23:55 未恢復(fù)的業(yè)務(wù)暫無(wú)其他立即有效的止損預(yù)案，此時(shí)嘗試恢復(fù)主機(jī)房的SLB。

• 我們通過Perf發(fā)現(xiàn)SLB CPU熱點(diǎn)集中在Lua函數(shù)上，懷疑跟最近上線的Lua代碼有關(guān)，開始嘗試回滾最近上線的Lua代碼。

• 近期SLB配合安全同學(xué)上線了自研Lua版本的WAF，懷疑CPU熱點(diǎn)跟此有關(guān)，嘗試去掉WAF后重啟SLB，SLB未恢復(fù)。

• SLB兩周前優(yōu)化了Nginx在balance_by_lua階段的重試邏輯，避免請(qǐng)求重試時(shí)請(qǐng)求到上一次的不可用節(jié)點(diǎn)，此處有一個(gè)最多10次的循環(huán)邏輯，懷疑此處有性能熱點(diǎn)，嘗試回滾后重啟SLB，未恢復(fù)。

• SLB一周前上線灰度了對(duì) HTTP2 協(xié)議的支持，嘗試去掉 H2 協(xié)議相關(guān)的配置并重啟SLB，未恢復(fù)。

00:00  SLB運(yùn)維嘗試回滾相關(guān)配置依舊無(wú)法恢復(fù)SLB后，決定重建一組全新的SLB集群，讓CDN把故障業(yè)務(wù)公網(wǎng)流量調(diào)度過來，通過流量隔離觀察業(yè)務(wù)能否恢復(fù)。

00:20  SLB新集群初始化完成，開始配置四層LB和公網(wǎng)IP。

01:00  SLB新集群初始化和測(cè)試全部完成，CDN開始切量。SLB運(yùn)維繼續(xù)排查CPU 100%的問題，切量由業(yè)務(wù)SRE同學(xué)協(xié)助。

01:18  直播業(yè)務(wù)流量切換到SLB新集群，直播業(yè)務(wù)恢復(fù)正常。

01:40  主站、電商、漫畫、支付等核心業(yè)務(wù)陸續(xù)切換到SLB新集群，業(yè)務(wù)恢復(fù)。

01:50  此時(shí)在線業(yè)務(wù)基本全部恢復(fù)。

01:00 SLB新集群搭建完成后，在給業(yè)務(wù)切量止損的同時(shí)，SLB運(yùn)維開始繼續(xù)分析CPU 100%的原因。

01:10 - 01:27 使用Lua 程序分析工具跑出一份詳細(xì)的火焰圖數(shù)據(jù)并加以分析，發(fā)現(xiàn) CPU 熱點(diǎn)明顯集中在對(duì) lua-resty-balancer 模塊的調(diào)用中，從 SLB 流量入口邏輯一直分析到底層模塊調(diào)用，發(fā)現(xiàn)該模塊內(nèi)有多個(gè)函數(shù)可能存在熱點(diǎn)。

01:28 - 01:38 選擇一臺(tái)SLB節(jié)點(diǎn)，在可能存在熱點(diǎn)的函數(shù)內(nèi)添加 debug 日志，并重啟觀察這些熱點(diǎn)函數(shù)的執(zhí)行結(jié)果。

01:39 - 01:58 在分析 debug 日志后，發(fā)現(xiàn) lua-resty-balancer模塊中的 _gcd 函數(shù)在某次執(zhí)行后返回了一個(gè)預(yù)期外的值：nan，同時(shí)發(fā)現(xiàn)了觸發(fā)誘因的條件：某個(gè)容器IP的weight=0。

01:59 - 02:06 懷疑是該 _gcd 函數(shù)觸發(fā)了 jit 編譯器的某個(gè) bug，運(yùn)行出錯(cuò)陷入死循環(huán)導(dǎo)致SLB CPU 100%，臨時(shí)解決方案：全局關(guān)閉 jit 編譯。

02:07 SLB運(yùn)維修改SLB 集群的配置，關(guān)閉 jit 編譯并分批重啟進(jìn)程，SLB CPU 全部恢復(fù)正常，可正常處理請(qǐng)求。同時(shí)保留了一份異?，F(xiàn)場(chǎng)下的進(jìn)程core文件，留作后續(xù)分析使用。

02:31 - 03:50 SLB運(yùn)維修改其他SLB集群的配置，臨時(shí)關(guān)閉 jit 編譯，規(guī)避風(fēng)險(xiǎn)。

11:40 在線下環(huán)境成功復(fù)現(xiàn)出該 bug，同時(shí)發(fā)現(xiàn)SLB 即使關(guān)閉 jit 編譯也仍然存在該問題。此時(shí)我們也進(jìn)一步定位到此問題發(fā)生的誘因：在服務(wù)的某種特殊發(fā)布模式中，會(huì)出現(xiàn)容器實(shí)例權(quán)重為0的情況。

12:30 經(jīng)過內(nèi)部討論，我們認(rèn)為該問題并未徹底解決，SLB 仍然存在極大風(fēng)險(xiǎn)，為了避免問題的再次產(chǎn)生，最終決定：平臺(tái)禁止此發(fā)布模式；SLB 先忽略注冊(cè)中心返回的權(quán)重，強(qiáng)制指定權(quán)重。

13:24 發(fā)布平臺(tái)禁止此發(fā)布模式。

14:06 SLB 修改Lua代碼忽略注冊(cè)中心返回的權(quán)重。

14:30 SLB 在UAT環(huán)境發(fā)版升級(jí)，并多次驗(yàn)證節(jié)點(diǎn)權(quán)重符合預(yù)期，此問題不再產(chǎn)生。

15:00 - 20:00 生產(chǎn)所有 SLB 集群逐漸灰度并全量升級(jí)完成。

B站在19年9月份從Tengine遷移到了OpenResty，基于其豐富的Lua能力開發(fā)了一個(gè)服務(wù)發(fā)現(xiàn)模塊，從我們自研的注冊(cè)中心同步服務(wù)注冊(cè)信息到Nginx共享內(nèi)存中，SLB在請(qǐng)求轉(zhuǎn)發(fā)時(shí)，通過Lua從共享內(nèi)存中選擇節(jié)點(diǎn)處理請(qǐng)求，用到了OpenResty的lua-resty-balancer模塊。到發(fā)生故障時(shí)已穩(wěn)定運(yùn)行快兩年時(shí)間。

在故障發(fā)生的前兩個(gè)月，有業(yè)務(wù)提出想通過服務(wù)在注冊(cè)中心的權(quán)重變更來實(shí)現(xiàn)SLB的動(dòng)態(tài)調(diào)權(quán)，從而實(shí)現(xiàn)更精細(xì)的灰度能力。SLB團(tuán)隊(duì)評(píng)估了此需求后認(rèn)為可以支持，開發(fā)完成后灰度上線。

• 在某種發(fā)布模式中，應(yīng)用的實(shí)例權(quán)重會(huì)短暫的調(diào)整為0，此時(shí)注冊(cè)中心返回給SLB的權(quán)重是字符串類型的"0"。此發(fā)布模式只有生產(chǎn)環(huán)境會(huì)用到，同時(shí)使用的頻率極低，在SLB前期灰度過程中未觸發(fā)此問題。
  

• SLB 在balance_by_lua階段，會(huì)將共享內(nèi)存中保存的服務(wù)IP、Port、Weight 作為參數(shù)傳給lua-resty-balancer模塊用于選擇upstream server，在節(jié)點(diǎn) weight = "0" 時(shí)，balancer 模塊中的 _gcd 函數(shù)收到的入?yún)?b 可能為 "0"。

• Lua 是動(dòng)態(tài)類型語(yǔ)言，常用習(xí)慣里變量不需要定義類型，只需要為變量賦值即可。

• Lua在對(duì)一個(gè)數(shù)字字符串進(jìn)行算術(shù)操作時(shí)，會(huì)嘗試將這個(gè)數(shù)字字符串轉(zhuǎn)成一個(gè)數(shù)字。

• 在 Lua 語(yǔ)言中，如果執(zhí)行數(shù)學(xué)運(yùn)算 n % 0，則結(jié)果會(huì)變?yōu)?nan（Not A Number）。

• _gcd函數(shù)對(duì)入?yún)]有做類型校驗(yàn)，允許參數(shù)b傳入："0"。同時(shí)因?yàn)?0" != 0，所以此函數(shù)第一次執(zhí)行后返回是 _gcd("0",nan)。如果傳入的是int 0，則會(huì)觸發(fā)[ if b == 0 ]分支邏輯判斷，不會(huì)死循環(huán)。

• _gcd("0",nan)函數(shù)再次執(zhí)行時(shí)返回值是 _gcd(nan,nan)，然后Nginx worker開始陷入死循環(huán)，進(jìn)程 CPU 100%。

1. 為何故障剛發(fā)生時(shí)無(wú)法登陸內(nèi)網(wǎng)后臺(tái)？

事后復(fù)盤發(fā)現(xiàn)，用戶在登錄內(nèi)網(wǎng)鑒權(quán)系統(tǒng)時(shí)，鑒權(quán)系統(tǒng)會(huì)跳轉(zhuǎn)到多個(gè)域名下種登錄的Cookie，其中一個(gè)域名是由故障的SLB代理的，受SLB故障影響當(dāng)時(shí)此域名無(wú)法處理請(qǐng)求，導(dǎo)致用戶登錄失敗。流程如下：

事后我們梳理了辦公網(wǎng)系統(tǒng)的訪問鏈路，跟用戶鏈路隔離開，辦公網(wǎng)鏈路不再依賴用戶訪問鏈路。

2. 為何多活SLB在故障開始階段也不可用？

多活SLB在故障時(shí)因CDN流量回源重試和用戶重試，流量突增4倍以上，連接數(shù)突增100倍到1000W級(jí)別，導(dǎo)致這組SLB過載。后因流量下降和重啟，逐漸恢復(fù)。此SLB集群日常晚高峰CPU使用率30%左右，剩余Buffer不足兩倍。如果多活SLB容量充足，理論上可承載住突發(fā)流量， 多活業(yè)務(wù)可立即恢復(fù)正常。此處也可以看到，在發(fā)生機(jī)房級(jí)別故障時(shí)，多活是業(yè)務(wù)容災(zāi)止損最快的方案，這也是故障后我們重點(diǎn)投入治理的一個(gè)方向。

3. 為何在回滾SLB變更無(wú)效后才選擇新建源站切量，而不是并行？

我們的SLB團(tuán)隊(duì)規(guī)模較小，當(dāng)時(shí)只有一位平臺(tái)開發(fā)和一位組件運(yùn)維。在出現(xiàn)故障時(shí)，雖有其他同學(xué)協(xié)助，但SLB組件的核心變更需要組件運(yùn)維同學(xué)執(zhí)行或review，所以無(wú)法并行。

4. 為何新建源站切流耗時(shí)這么久？

我們的公網(wǎng)架構(gòu)如下：

此處涉及三個(gè)團(tuán)隊(duì)：

• SLB團(tuán)隊(duì)：選擇SLB機(jī)器、SLB機(jī)器初始化、SLB配置初始化

• 四層LB團(tuán)隊(duì)：SLB四層LB公網(wǎng)IP配置

• CDN團(tuán)隊(duì)：CDN更新回源公網(wǎng)IP、CDN切量

SLB的預(yù)案中只演練過SLB機(jī)器初始化、配置初始化，但和四層LB公網(wǎng)IP配置、CDN之間的協(xié)作并沒有做過全鏈路演練，元信息在平臺(tái)之間也沒有聯(lián)動(dòng)，比如四層LB的Real Server信息提供、公網(wǎng)運(yùn)營(yíng)商線路、CDN回源IP的更新等。所以一次完整的新建源站耗時(shí)非常久。在事故后這一塊的聯(lián)動(dòng)和自動(dòng)化也是我們的重點(diǎn)優(yōu)化方向，目前一次新集群創(chuàng)建、初始化、四層LB公網(wǎng)IP配置已經(jīng)能優(yōu)化到5分鐘以內(nèi)。

5. 后續(xù)根因定位后證明關(guān)閉jit編譯并沒有解決問題，那當(dāng)晚故障的SLB是如何恢復(fù)的？

當(dāng)晚已定位到誘因是某個(gè)容器IP的weight="0"。此應(yīng)用在1:45時(shí)發(fā)布完成，weight="0"的誘因已消除。所以后續(xù)關(guān)閉jit雖然無(wú)效，但因?yàn)檎T因消失，所以重啟SLB后恢復(fù)正常。

如果當(dāng)時(shí)誘因未消失，SLB關(guān)閉jit編譯后未恢復(fù)，基于定位到的誘因信息：某個(gè)容器IP的weight=0，也能定位到此服務(wù)和其發(fā)布模式，快速定位根因。

此事故不管是技術(shù)側(cè)還是管理側(cè)都有很多優(yōu)化改進(jìn)。此處我們只列舉當(dāng)時(shí)制定的技術(shù)側(cè)核心優(yōu)化改進(jìn)方向。

在23:23時(shí)，做了多活的業(yè)務(wù)核心功能基本恢復(fù)正常，如APP推薦、APP播放、評(píng)論&彈幕拉取、動(dòng)態(tài)、追番、影視等。故障時(shí)直播業(yè)務(wù)也做了多活，但當(dāng)晚沒及時(shí)恢復(fù)的原因是：直播移動(dòng)端首頁(yè)接口雖然實(shí)現(xiàn)了多活，但沒配置多機(jī)房調(diào)度。導(dǎo)致在主機(jī)房SLB不可用時(shí)直播APP首頁(yè)一直打不開，非?？上АＭㄟ^這次事故，我們發(fā)現(xiàn)了多活架構(gòu)存在的一些嚴(yán)重問題：

多活基架能力不足

• 機(jī)房與業(yè)務(wù)多活定位關(guān)系混亂。

• CDN多機(jī)房流量調(diào)度不支持用戶屬性固定路由和分片。

• 業(yè)務(wù)多活架構(gòu)不支持寫，寫功能當(dāng)時(shí)未恢復(fù)。

• 部分存儲(chǔ)組件多活同步和切換能力不足，無(wú)法實(shí)現(xiàn)多活。

  
  

業(yè)務(wù)多活元信息缺乏平臺(tái)管理

• 哪個(gè)業(yè)務(wù)做了多活？

• 業(yè)務(wù)是什么類型的多活，同城雙活還是異地單元化？

• 業(yè)務(wù)哪些URL規(guī)則支持多活，目前多活流量調(diào)度策略是什么？

• 上述信息當(dāng)時(shí)只能用文檔臨時(shí)維護(hù)，沒有平臺(tái)統(tǒng)一管理和編排。

  
  

多活切量容災(zāi)能力薄弱

• 多活切量依賴CDN同學(xué)執(zhí)行，其他人員無(wú)權(quán)限，效率低。

• 無(wú)切量管理平臺(tái)，整個(gè)切量過程不可視。

• 接入層、存儲(chǔ)層切量分離，切量不可編排。

• 無(wú)業(yè)務(wù)多活元信息，切量準(zhǔn)確率和容災(zāi)效果差。

  
  

我們之前的多活切量經(jīng)常是這么一個(gè)場(chǎng)景：業(yè)務(wù)A故障了，要切量到多活機(jī)房。SRE跟研發(fā)溝通后確認(rèn)要切域名A+URL A，告知CDN運(yùn)維。CDN運(yùn)維切量后研發(fā)發(fā)現(xiàn)還有個(gè)URL沒切，再重復(fù)一遍上面的流程，所以導(dǎo)致效率極低，容災(zāi)效果也很差。 

所以我們多活建設(shè)的主要方向：

多活基架能力建設(shè)

• 優(yōu)化多活基礎(chǔ)組件的支持能力，如數(shù)據(jù)層同步組件優(yōu)化、接入層支持基于用戶分片，讓業(yè)務(wù)的多活接入成本更低。

• 重新梳理各機(jī)房在多活架構(gòu)下的定位，梳理Czone、Gzone、Rzone業(yè)務(wù)域。

• 推動(dòng)不支持多活的核心業(yè)務(wù)和已實(shí)現(xiàn)多活但架構(gòu)不規(guī)范的業(yè)務(wù)改造優(yōu)化。

  
  

多活管控能力提升

• 統(tǒng)一管控所有多活業(yè)務(wù)的元信息、路由規(guī)則，聯(lián)動(dòng)其他平臺(tái)，成為多活的元數(shù)據(jù)中心。

• 支持多活接入層規(guī)則編排、數(shù)據(jù)層編排、預(yù)案編排、流量編排等，接入流程實(shí)現(xiàn)自動(dòng)化和可視化。

• 抽象多活切量能力，對(duì)接CDN、存儲(chǔ)等組件，實(shí)現(xiàn)一鍵全鏈路切量，提升效率和準(zhǔn)確率。

• 支持多活切量時(shí)的前置能力預(yù)檢，切量中風(fēng)險(xiǎn)巡檢和核心指標(biāo)的可觀測(cè)。

架構(gòu)治理

• 故障前一個(gè)機(jī)房?jī)?nèi)一套SLB統(tǒng)一對(duì)外提供代理服務(wù)，導(dǎo)致故障域無(wú)法隔離。后續(xù)SLB需按業(yè)務(wù)部門拆分集群，核心業(yè)務(wù)部門獨(dú)立SLB集群和公網(wǎng)IP。

• 跟CDN團(tuán)隊(duì)、四層LB&網(wǎng)絡(luò)團(tuán)隊(duì)一起討論確定SLB集群和公網(wǎng)IP隔離的管理方案。

• 明確SLB能力邊界，非SLB必備能力，統(tǒng)一下沉到API Gateway，SLB組件和平臺(tái)均不再支持，如動(dòng)態(tài)權(quán)重的灰度能力。

  
  

運(yùn)維能力

• SLB管理平臺(tái)實(shí)現(xiàn)Lua代碼版本化管理，平臺(tái)支持版本升級(jí)和快速回滾。

• SLB節(jié)點(diǎn)的環(huán)境和配置初始化托管到平臺(tái)，聯(lián)動(dòng)四層LB的API，在SLB平臺(tái)上實(shí)現(xiàn)四層LB申請(qǐng)、公網(wǎng)IP申請(qǐng)、節(jié)點(diǎn)上線等操作，做到全流程初始化5分鐘以內(nèi)。

• SLB作為核心服務(wù)中的核心，在目前沒有彈性擴(kuò)容的能力下，30%的使用率較高，需要擴(kuò)容把CPU降低到15%左右。

• 優(yōu)化CDN回源超時(shí)時(shí)間，降低SLB在極端故障場(chǎng)景下連接數(shù)。同時(shí)對(duì)連接數(shù)做極限性能壓測(cè)。

  
  

自研能力

• 運(yùn)維團(tuán)隊(duì)做項(xiàng)目有個(gè)弊端，開發(fā)完成自測(cè)沒問題后就開始灰度上線，沒有專業(yè)的測(cè)試團(tuán)隊(duì)介入。此組件太過核心，需要引入基礎(chǔ)組件測(cè)試團(tuán)隊(duì)，對(duì)SLB輸入?yún)?shù)做完整的異常測(cè)試。

• 跟社區(qū)一起，Review使用到的OpenResty核心開源庫(kù)源代碼，消除其他風(fēng)險(xiǎn)?；贚ua已有特性和缺陷，提升我們Lua代碼的魯棒性，比如變量類型判斷、強(qiáng)制轉(zhuǎn)換等。

• 招專業(yè)做LB的人。我們選擇基于Lua開發(fā)是因?yàn)長(zhǎng)ua簡(jiǎn)單易上手，社區(qū)有類似成功案例。團(tuán)隊(duì)并沒有資深做Nginx組件開發(fā)的同學(xué)，也沒有做C/C++開發(fā)的同學(xué)。

本次事故中，業(yè)務(wù)多活流量調(diào)度、新建源站速度、CDN切量速度&回源超時(shí)機(jī)制均不符合預(yù)期。所以后續(xù)要探索機(jī)房級(jí)別的故障演練方案：

• 模擬CDN回源單機(jī)房故障，跟業(yè)務(wù)研發(fā)和測(cè)試一起，通過雙端上的業(yè)務(wù)真實(shí)表現(xiàn)來驗(yàn)收多活業(yè)務(wù)的容災(zāi)效果，提前優(yōu)化業(yè)務(wù)多活不符合預(yù)期的隱患。

• 灰度特定用戶流量到演練的CDN節(jié)點(diǎn)，在CDN節(jié)點(diǎn)模擬源站故障，觀察CDN和源站的容災(zāi)效果。

• 模擬單機(jī)房故障，通過多活管控平臺(tái)，演練業(yè)務(wù)的多活切量止損預(yù)案。

B站一直沒有NOC/技術(shù)支持團(tuán)隊(duì)，在出現(xiàn)緊急事故時(shí)，故障響應(yīng)、故障通報(bào)、故障協(xié)同都是由負(fù)責(zé)故障處理的SRE同學(xué)來承擔(dān)。如果是普通事故還好，如果是重大事故，信息同步根本來不及。所以事故的應(yīng)急響應(yīng)機(jī)制必須優(yōu)化：

• 優(yōu)化故障響應(yīng)制度，明確故障中故障指揮官、故障處理人的職責(zé)，分擔(dān)故障處理人的壓力。

• 事故發(fā)生時(shí)，故障處理人第一時(shí)間找backup作為故障指揮官，負(fù)責(zé)故障通報(bào)和故障協(xié)同。在團(tuán)隊(duì)里強(qiáng)制執(zhí)行，讓大家養(yǎng)成習(xí)慣。

• 建設(shè)易用的故障通告平臺(tái)，負(fù)責(zé)故障摘要信息錄入和故障中進(jìn)展同步。

  
  

本次故障的誘因是某個(gè)服務(wù)使用了一種特殊的發(fā)布模式觸發(fā)。我們的事件分析平臺(tái)目前只提供了面向應(yīng)用的事件查詢能力，缺少面向用戶、面向平臺(tái)、面向組件的事件分析能力：

• 跟監(jiān)控團(tuán)隊(duì)協(xié)作，建設(shè)平臺(tái)控制面事件上報(bào)能力，推動(dòng)更多核心平臺(tái)接入。

• SLB建設(shè)面向底層引擎的數(shù)據(jù)面事件變更上報(bào)和查詢能力，比如服務(wù)注冊(cè)信息變更時(shí)某個(gè)應(yīng)用的IP更新、weight變化事件可在平臺(tái)查詢。

• 擴(kuò)展事件查詢分析能力，除面向應(yīng)用外，建設(shè)面向不同用戶、不同團(tuán)隊(duì)、不同平臺(tái)的事件查詢分析能力，協(xié)助快速定位故障誘因。

此次事故發(fā)生時(shí)，B站掛了迅速登上全網(wǎng)熱搜，作為技術(shù)人員，身上的壓力可想而知。事故已經(jīng)發(fā)生，我們能做的就是深刻反思，吸取教訓(xùn)，總結(jié)經(jīng)驗(yàn)，砥礪前行。

此篇作為“713事故”系列之第一篇，向大家簡(jiǎn)要介紹了故障產(chǎn)生的誘因、根因、處理過程、優(yōu)化改進(jìn)。后續(xù)文章會(huì)詳細(xì)介紹“713事故”后我們是如何執(zhí)行優(yōu)化落地的，敬請(qǐng)期待。

最后，想說一句：多活的高可用容災(zāi)架構(gòu)確實(shí)生效了。