作者 | 艾塔
編輯 | 蘇建勛
沒想到B站倒閉，讓整個互聯網都經歷了一場深夜狂歡。
7月13日23:00左右，B站主站、App、小程序均出現訪問失敗，無法正常使用。頁面提示“正在加載數據”。B站、A站的鄰居，以及錦江、豆瓣也有不同程度的故障，加載顯示404、502等。
B站的倒塌，才讓大家意識到，原來“小坡站”的流量竟然如此驚人。無法訪問網站、無法觀看直播的“B站難民”紛紛涌向知乎、微博和著名游戲網站NGA�！癇站崩盤”、“陳�！�、“豆瓣崩盤”等詞迅速走紅，就連大名鼎鼎的B站“蒙古頂單”也霸占了微博熱搜，傳遍了全網，相當壯觀。
微博熱搜
23時45分，B站網站和APP初步恢復正常訪問，但直播、會員購買等板塊以及部分現場互動、評論、投幣等功能仍無法正常使用。
B站倒閉后，網上流傳多張故障頁面截圖。但究竟是什么導致了服務器故障，很快就出現了多個帳戶。不過，無論是最初的停電，還是背后的嗶哩嗶哩/上海云海服務器中心發生火災，傳聞很快都被辟謠了。
上海消防局辟謠B站總部大樓著火
直到凌晨2點20分，B站正式發表聲明稱，由于部分機房故障瀏覽器老顯示崩潰是什么原因，無法訪問機房。經過排查修復，逐漸恢復正常。不過，更具體的原因并未在 B 站透露。
服務器宕機幾個小時，災備還沒做好？
企業IT架構日益復雜也意味著失敗的原因往往是系統性問題，不能歸結為單一原因。在B站的崩潰中，除了服務器問題外，補救的備份方案大概率沒有迅速應用。
故障通�？梢詮膬蓚�方面來分析：硬件故障和軟件故障——硬件故障是機房、服務器等物理因素；而軟件故障可能來自版本升級、代碼錯誤等。
雖然不同行業存在差異，但互聯網大平臺的技術架構基本不缺核心部件。最簡單的訪問路徑是客戶端和網站之間的直接交互。比如客戶端發出一個視頻訪問請求，經過一系列處理后，到達B站的前端、后端服務器、分布式存儲等組件。請求后返回。
當晚的情況是B站宕機，網友收到的頁面大部分顯示502，基本是服務器故障造成的。
但目前尚不清楚哪些服務器出現故障。對于B站規模的視頻平臺來說，上云是肯定的，也會采用公有云+私有云的架構。也就是說，故障服務器可能在B站自己的機房或托管，也可能在公有云服務商的機房。
如果您自己的機房出現問題，一個可能的原因是版本升級和網站維護失敗，導致緊急解決版本回滾。如果恰好是核心業務不在云上，需要運維人員手動修復，耗時較長。知乎回答者“k8seasy”認為，B站核心業務的恢復時間在30分鐘左右，幾乎100%恢復，說明B站某核心組件崩潰，導致核心業務不可用�？赡艿脑蚴切掳姹驹贐站上線的時候出現bug，不可用后緊急回滾到老版本沒有承受訪問壓力，最終網站環境崩潰。
如果公有云廠商出現問題，同一個服務器集群服務的其他企業也會出現類似問題。但A站、錦江、豆瓣等大流量APP當晚迅速恢復服務，故障程度與B站不在一個數量級。另外，為B站提供云服務的廠商包括阿里云、騰訊云、京東云、金山云。公有云廠商一起出現問題的概率極小。
分析原因后，再看補救措施。服務器崩潰后的第一道防線是企業的容災備份，可以保證核心業務盡快恢復，將損失降到最低。
B站當晚數小時未能完全恢復。顯然，備災并沒有起到太大的作用，這條防線也沒有得到很好的防御。
容災等級一般可以按照同城/異地、備份中心的數量來劃分。選擇不同的備份方式（如熱備份/冷備份/溫備份，成本不同）也會影響恢復時間。一位云計算從業者對 36 氪表示：“對于類似 B 站這樣的平臺，必須做容災，但還沒有經受住考驗。比如數據準備好機器沒有，或者機器準備好了但是鏈條沒有，如果道路沒有準備好，短時間內很難恢復。
B站作為視頻直播平臺，對高可用/高并發的要求很高。企業容災服務商、英國軟件營銷總監黃亮告訴36氪，高可用架構有兩種：異地容災和負載均衡。故障很可能是B站只關注負載均衡，沒有做太多的異地容災�！澳壳�，企業使用同城數據中心架構進行負載均衡，比如在上海的同一個數據中心，”他說。
災難恢復沒有及時進行瀏覽器老顯示崩潰是什么原因，可能是出于成本考慮。黃亮說，負載均衡需要很高的實時性。如果需要去異地容災，成本非常高。比如A公司在上海有數據中心，同時在貴州設立異地容災中心。上海機房宕機，貴州可以接手。對于穩定性要求高的行業，比如銀行、醫院等，會有強制性的監管要求，其他企業一般都力所能及。
脆弱的企業IT架構未來將如何演進？
雖然B站的恢復時間是幾個小時，但好在半夜的流量低谷發生了故障，網友的幫助讓B站再次出圈：一個網站崩潰了，其龐大的流量可以使其他網站紛紛效仿。
這讓市場看到了B站用戶可怕的沖浪能力。7月13日，B站股價出現短線下跌，盤中漲幅收窄至最低3.26%。截至收盤，可維持3.18%的漲幅，110.$38/股。截至發稿，B站市值為424億美元。