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

《#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災備系統的意識將得到進一步提升。如果要降低宕機風險，就需要提高服務的高可用性。首先，從架構上建議采用雲原生架構，實現自動容錯機制和故障隔離，從而能夠在服務出現故障時快速遷移或回滾。其次，為防止硬件故障類風險，需要有完善的災備方案，同城雙活或異地災備目前都已經有比較成熟的方案，企業在這塊的投入應當提前進行考慮。
《#B站崩了# ，崩的是服務器嗎？不！是又“攤上大事”的程序員！》完，請繼續朗讀精采文章。
喜歡 小編的世界 e4to.com，請記得按讚、收藏及分享！