B站崩了，多大點事兒？有容災備份絲毫不慌

B站崩了，多大點事兒？有容災備份絲毫不慌

7 月 13 日 23 時許，B站客戶端和網頁端均出現訪問故障，無法打🐓開，頁面提示“正在玩命加載數據”。

崩潰界面

難道是各位用戶熱情太高漲，視頻刷太多，把嗶哩嗶哩整崩了？

逐一排查，網絡 OK，手機 OK，其他 App 也 OK。

速速上微博一看，原來大家都崩了。

一時間網上猜ꦓ測、議論不斷，#B站崩了#迅速沖上微博熱榜，有說是機房著火的，也有擔心軟件被未知攻擊的，當然還有“蒙古上單”說。

微博熱搜

部分 IT 工作者看到貌似比較靠譜的“機房著火”說，心中竊喜꧒，連夜爬起來寫簡歷，準備投 B站架構崗。就算是著火停電也不至于中斷啊，除非把應用服務器都放在同一個地方，沒有任何災備措施，如ꦏ果真是這樣，那 B站架構師可以思考人生了。

隨后上海消防也迅速出來辟謠，表示未見火情。

上海消防辟謠

“著火說”排除，技術宅、段子手、“B站難民”涌入其他平臺，于是就有了如下連鎖反應：

B站崩了 A站崩，A站崩完豆瓣崩，豆瓣崩完...

微博運維：你以為你很幽默？

好在微博技術人員夠給力，挺住了蜂擁而至的夜間流量。

隨后，約在 23 時 45 分，B站網頁端和 App 才恢復正常。對于此次長時間宕機的原👍因，B站方面暫無回應。

官方回復

部分“熬夜🐟冠軍”們是早睡了，但是 B站的技術團隊還沒有睡，四十分鐘內恢復運營，也是夠拼。嗶哩嗶哩彈幕網微博評論🎶區也熱鬧起來：

四十分鐘太長，建議抽獎。

經此一事才意識到，原來 B站平時承受了遠超于大家想象的瀏覽量。

這么晚了，還要加班，給小電視的技術人員一鍵三連！！

鬧歸鬧，服務器宕機常見原因要知道，多知道一點，說不定某安全架構崗就是你的了。

運行環境問題導致服務器宕機

服務器運行環境包括操作系統，數據庫，應用程序，應用程序 bug，網絡數據等，以上軟件ᩚᩚᩚᩚᩚᩚ⁤⁤⁤⁤ᩚ⁤⁤⁤⁤ᩚ⁤⁤⁤⁤ᩚ𒀱ᩚᩚᩚ系統故障會引起𒊎服務器宕機現象。

解決辦法：查找分析系統、應用程序相關日志來找出真正的原因。

服務器性能問題導致服務器宕機

服務器性能好壞也是引發宕機的一個因素，因為 IDC 提供商的服務器有些不是品牌服務器，是組裝型的服務器，采購的硬件也不是品牌的，多用于雜牌硬件，難免會因硬件兼容性、CPU、內存等性能൩不好，導致宕機。

解決辦法：查看服務器硬件信息，使用工具測試相關硬件꧑配件，或更換配件測試服務器硬件問題，在租用或選購時盡量用配置高的服務器。

數據丟失或損壞問題導致服務器宕機

數據丟失包括人為錯刪除數據，磁盤壞道導致數據丟失，磁盤寫滿等原因可導致服務器系統崩潰宕機。

解決辦法：做好數據備份，對磁盤進行實時監控

當然，流量洪峰下要做好高服務質量的架構是極具挑戰的事情。高可用，業務連續性的基礎是異地災備，異地數據備份、災備機房必須要設計。需要綜合考慮地理環境、系統特點、人員配備、現有資源等多🅘方面因素，是一個ജ長期的系統性工程。

臨時抱佛腳不可取，容災備份的知識積累也是一個長期的系統性工程。

以上就是B站崩了，多大點事兒？有容災備份絲毫不慌的介紹，億聯云除了容災備份外還提供網絡優化服務、MPLS服務、全球服務器托管（IDC）&服務器租賃服務、企業私有云&混合云搭建方案、云直連專線服務、SD-WAN服務、企業云視頻會議服務等相關應用場景。