#B站崩了# ，崩的是服務器嗎？不！是又“攤上大事”的程序員！

梯度雲

7月13日晚11點左右，網友發現B站崩了！

一波未平一波又起，隨著B站“崩了”，A站、豆瓣、晉江等平台紛紛跟上，由B站領銜主演的《崩了》激情上演。

7月14日2點20分，B站發表動態回應：

昨晚，B站的部分服務器機房發生故障，造成無法訪問。技術團隊隨即進行了問題排查和修複，現在服務已經陸續恢複正常。耽誤大家看視頻了，對不起！

歷時3個多小時“搶修”，B站功能恢複正常。

對於這次服務器集體“崩潰”事件，互聯網上的討論堪稱現象級，熱搜榜上的“爆”字樣更是為“頂流社區”蓋章認證。

但這個問題仍困擾著我們：B站到底為什麼會“崩”呢？

B站為什麼會“崩”？

網友們紛紛揣測關於B站崩了的原因：

有火災說、刪庫跑路說、刑事案件說、服務器供應商說、黑客攻擊說、大樓坍塌說、外星人說……

在“B站崩了”發生後的三個小時內，B站的功能都沒有完全恢複，如此“宕機”時間，不少專業人士直言，B站崩了的事故等級已經達到了P0級（最高級別事故），B站的研發及運維人員“攤上大事了”。

猝不及防的宕機背後都是程序員小哥哥的一把辛酸淚啊！

從官方道歉聲明看，B站方面並沒有對具體的事故原因作出回應，不過不少網友的高贊回答都提到了雲服務供應商出現問題的可能性。

雲服務提供商提供的CDN出現意外之後，大量請求繞過CDN直接打到網關，網關收到大量請求，自動啟動了容災策略。

容災策略啟動服務降級。服務降級了但沒完全降，CDN掛了，網關也跟著掛了，服務雪崩，一直崩到整個環境。

史上嚴重的服務宕機事件：最高損失上億美元

今年 3 月，歐洲最大雲服務商 OVH 的數據中心大樓起火，導致超過 350 萬個網站下線。

350 萬個，是什麼概念呢。包括政府機構、門戶網站、銀行、商店、新聞網站在內，統統崩了，沒商量。

其中，視頻遊戲開發商 Rust 所有數據瞬間消失，並且無法恢複，整個公司長時間的努力，付之東流。

相比起來，B 站這回損失似乎算輕了。

7月14日，信達證券以B站事件為契機發布通信行業相關研報，並在報告中表示，B站事件折射出IDC（互聯網數據中心）機房安全性、穩定性的重要性，認為互聯網企業需要非常專業化的、經驗豐富、技術領先的 IDC 團隊。

顯然經過這次故障，大家對構建高可用高容災的IT系統和建設IT災備系統的意識將得到進一步提升。

如果要降低宕機風險，就需要提高服務的高可用性。首先，從架構上建議采用雲原生架構，實現自動容錯機制和故障隔離，從而能夠在服務出現故障時快速遷移或回滾。

其次，為防止硬件故障類風險，需要有完善的災備方案，同城雙活或異地災備目前都已經有比較成熟的方案，企業在這塊的投入應當提前進行考慮。