B站崩了：事情不大，影響不小

做者 | Tina

7 月 13 日晚間，B 站因沒法訪問登上熱搜榜。

昨天深夜，B 站出現訪問故障，沒法打開，頁面提示加載失敗。除了網站和移動端顯示加載錯誤以外，B 站出品的輕視頻、剪輯軟件必剪等均沒法打開，顯示頁面加載出錯。

 

一個網站的短暫崩潰，竟然引發這麼大的聲響？

公司 2020 年第三季度財報顯示，去年 8 月，B 站的月活用戶突破 2 億。最新數據則顯示，B 站月活用戶爲 2.23 億，其中 35 歲及如下的月活用戶比重超過 86%。

B 站故障以後，消息迅速擴散，「B 站崩了」衝上了各類熱搜榜。微博熱搜第一，知乎的提問下截至目前爲止，總共有 12727 個回覆。連朋友圈裏，都被 B 站技術總監分享過的「高可用架構實踐」演講刷屏。

故障持續了一個多小時，同時崩潰的還有老牌二次元網站 AcFun（A 站）以及豆瓣、晉江，但豆瓣、A 站等很快就得以恢復了。

一個網站的「崩潰」，讓無數習慣了互聯網生活的人睡不着覺，也有很多網友一塊兒幫忙分析究竟是互聯網的哪一個環節出了問題，甚至還所以驚動了消防局。

對於網傳「B 站崩了是由於有火情發生」，上海消防闢謠道：「經瞭解，位於上海市政立路 485 號國正中心內的嗶哩嗶哩彈幕網 B 站（總部）未出現火情，未接到相關報警。具體狀況以站方公佈爲準。」

今年 3 月份，曾發生過數據中心失火形成 360 萬網站下線的事故，所以有人猜想是雲海數據服務中心發生了火情，消防也對此表示了極大關注。

 

什麼緣由會致使網站宕機？

至 14 日凌晨 2 點 15 分，B 站全部功能均恢復正常。B 站官方 7 月 14 日凌晨發佈消息稱，昨（7 月 13 日）晚，B 站的部分服務器機房發生故障，形成沒法訪問。技術團隊隨即進行了問題排查和修復，如今服務已經陸續恢復正常。

可是對於具體宕機緣由，B 站並未做說明。InfoQ 聯繫了 B 站相關技術人員詢問具體狀況，截止發稿前仍然沒有獲得答覆。

對於網站宕機常見緣由，開源基礎軟件公司 Zilliz 的質量保障團隊負責人喬燕良認爲，主要可分爲軟件服務引發的故障和硬件服務引發的故障。

軟件服務故障通常可理解爲代碼邏輯缺陷，常見的是新增或更新某個功能而引入缺陷致使整個服務中斷；硬件服務故障通常是因爲某些服務設備的損壞形成服務中斷，好比光纖被挖斷了。

互聯網服務中鏈路的每一個環節都有可能致使問題發生，據另外一位數據庫專家分析，由於此次 B 站主站都掛了，應該和數據庫沒有關係；宕機發生的時候，經過技術分析，能夠看出 CDN 查不到相關機房的數據。由此推測，B 站此次應該屬於機房級別的故障，須要加強多機房容災能力。

此次故障，對 B 站的影響不小，綜合損失應該也不小，但若是去提高業務的連續性，還須要很大成本。常見的可用性一般以百分比表示，這也意味着高可用性不是絕對的。換句話說，100% 的可用性是不可能達到的，可用性從 99.99% 提高到 99.999%，每提高一個 9，須要十倍百倍的成本。可用性的效果和開銷對應的比例並非線性增加的，每提升一點可用性，所花費的成本都會遠超以前。

雖然企業須要在這個非線性增長的成本和可用性之間進行權衡，但對於一些公司來說，確定還會去嘗試得到更多的 「9」，減小應用的宕機時間，下降宕機成本。

如何用合適手段下降宕機風險、提升服務的高可用呢？喬燕良認爲：「首先從架構上，建議採用雲原生架構，實現自動容錯機制和故障隔離，可以在服務出現故障時快速遷移或回滾。對於網站來講，實現數據服務高可用的挑戰可能會比較突出，由於目前架構下多數服務都是無狀態的、能夠完成平滑遷移，而數據服務每每是有狀態的，雲原生服務（如目前的一些雲原生數據庫）一般具備很好的自動容錯、彈性伸縮、安全隔離等功能。其次爲防止硬件故障類風險，須要有完善的災備方案。針對傳統服務架構已經有比較成熟的同城雙活和異地災備方案，而基於雲原生的高可用方案，好比 kubeadm 也已經比較成熟，只是國內企業在這塊投入比較‘節約’。」

就像人工智能沒法替代人類同樣，目前的軟件仍然是不可徹底信任的。咱們的世界瞬息萬變，咱們的軟件（包括人工智能）只是對世界當前場景的理解和判斷，隨着時間的推動，某一時刻這些理解判斷的邏輯會出現不適用甚至錯誤。這一時刻什麼時候到來、環境又會變得怎樣，將永遠是最不可預測的因素。

 

有道無術，術可成；有術無道，止於術