- B站半夜崩潰 企業云容災預警沒做好？
- 2021年07月15日 來源：新浪財經
提要：7月13日深夜，微博、朋友圈等社交平臺紛紛在熱議一個話題——B站怎么崩了？“B站崩了”話題一度在微博熱搜第一名上，并呈現“爆了”的狀態。
7月13日深夜，微博、朋友圈等社交平臺紛紛在熱議一個話題——B站怎么崩了？“B站崩了”話題一度在微博熱搜第一名上，并呈現“爆了”的狀態。
與此同時，很多網友反映，A站、豆瓣、晉江……都崩了。
互聯網企業難免宕機。尷尬的是，B站的修復進展緩慢，讓網友十分著急上火。子夜時分，“后浪”們的吐槽在社交媒體上發酵。
7月14日凌晨0時20分，A站發微博稱，“在修復了”。4分鐘后，即0時24分稱“已修復，歡迎來玩”。
在宕機約三個小時后，7月14日凌晨2時20分，B站（09626.HK）通過其官方微博就“部分服務器機房發生故障造成無法訪問”致歉，稱：“昨晚，B站的部分服務器機房發生故障，造成無法訪問。技術團隊隨即進行了問題排查和修復，現在服務已經陸續恢復正常。耽誤大家看視頻了，對不起。”
但至于服務器機房發生故障的具體原因，B站并未進一步詳細說明。盡管遭遇突發事件，B站港股股價表現尚可，14日微跌收于863.5港元。
具體宕機原因不明
“B站崩了”引發熱議后，其背后原因也引發多方猜測。當晚，上海消防第一時間回應稱，“經了解，位于上海市政立路485號國正中心內的嗶哩嗶哩彈幕網B站（總部）未出現火情，未接到相關報警。”
此前，B站技術總監毛劍在公開分享中表示，在應對連鎖故障時，要做到——盡可能避免過載；通過一些手段去做限流，以及在無法正常服務時，通過有損服務犧牲掉一些非核心服務去保證關鍵服務做到優雅降級；重試策略上，在微服務內盡可能做退避，盡可能考慮到重試放大的流量倍數對下游的沖擊；考慮在移動端用戶無法使用某個功能的情況下，通常頻繁刷新頁面產生流量沖擊，在移動端進行配合來做流控等方式。
但是在現實案例里，B站對突發事件的應對顯然不夠迅速，有網友在分享帖子下評論稱“三個多小時才陸續恢復，這次絕對是一級事故”。
更多猜測聚焦在技術層面。多位接受第一財經記者采訪的技術人員表示，B站采用混合云模式，內容分發網絡（CDN）也是采用的騰訊云而非自建，因此目前從B站自身角度來考慮的話，更大可能是物理層面的問題，如網絡問題、數據中心光纖被挖斷、光纜被損害等。
騰訊云在官網客戶案例中介紹稱，B站采用騰訊云自研GSLB調度體系，結合全網實時監控數據，將用戶請求精準調度至最優接入節點，最大程度降低用戶訪問時延和減少視頻卡頓，最終用戶用相同的帶寬可以流暢地觀看更高清的直播視頻，提升用戶體驗，建立平臺品牌形象。
實際上除了B站，此前諸多網站均發生過網絡事故。
2019年6月1日，亞馬遜旗下云服務商AWS中國區的許多互聯網公司發生宕機，受影響的包括亞馬遜中國官網、VIPKID、流利說、三星應用商店等。后根據AWS的官方調查，AWS北京區域一處道路施工中有幾處光纜被切斷，導致可用區無法鏈接網絡。
行業人士認為，AWS因光纜被切斷便導致近12小時大面積服務癱瘓，是沒有做好網絡冗余設計，即為確保業務正常運轉，除配置主線路外，同時做好第二種、第三種線路的部署。
2020年，AWS宕機又來。去年12月25日，AWS出現大范圍宕機，影響軟件企業Adobe、流媒體終端商Roku等服務。AWS稱，由于處理大量串流數據的Kinesis服務遭遇問題，導致好幾個網站錯誤率提高，并影響更新網站頁面的能力，已著手緊急修復。
2020年2月，微盟（02013.HK）收到系統監控警報，經排查后獲悉是微盟研發中心運維部核心運維人員賀某通過個人VPN登入公司內網跳板機，對微盟線上生產環境進行了惡意的破壞。隨后，微盟諸多客戶的小程序電商商城均處于宕機狀態，當時恰逢線上購物高峰期，宕機與數據丟失對微盟及其合作商家產生了極為負面的影響。
警醒容災準備必要性
不論是AWS還是B站、微盟，其宕機事故所帶來的負面影響均需引發警惕。
另外，目前企業數字化轉型漸成大趨勢，5G、物聯網、工業互聯網、云計算、人工智能等新技術在各行各業中的應用越來越多，所產生的海量數據(13.460,?-0.31,?-2.25%)正呈指數級增長。一旦發生數據丟失與網站崩潰，對業務極有可能產生致命性危機。
對于每家公司的運維團隊來說，降低容災TCO、簡化容災方案、業務快速恢復，都是極大挑戰。
萬博智云首席技術官（CTO）孫琦對第一財經記者表示，雖然互聯網應用架構已經從應用層實現了高可靠和冗余的特性，但是面對物理層面或應用邏輯的異常時，也無法全身而退。近幾年，云上構建的應用架構的最佳實踐已經非常完善，多可用區、彈性可擴展的方式為應用構建提供了便捷。
除了阿里云、騰訊云，主流云服務廠商均提供各種災備方案。中國電信天翼云的方案為“2+31+X”資源部署，以內蒙古、貴州兩大數據中心為核心，定位為冷數據存儲、海量密集計算、遠程災備基地；在全國31個省份進行一省一池的核心部署，定位為溫數據存儲、屬地集中計算、專屬云等業務；X指下沉到地市甚至區縣的邊緣節點，定位為熱數據高速緩存，邊緣計算等業務，承載屬地化要求極高的業務。
UCloud優刻得(37.810,?-0.68,?-1.77%)的容災解決方案顯示，在國內，該公司以北京、上海、廣州為中心節點，中心之間的網絡實現雙環、異路、全互聯，每個中心下會分布多個可用區、可用區下又有多個數據中心，可以實現同城多活，異地容災。
UCloud創始人兼CEO季昕華曾在接受記者采訪時表示：“云計算公司有四大謊言，分別是云計算先服務于內部客戶，再服務于外部客戶；云計算能保證100%的安全；云計算消耗大量資金；云計算是不盈利的。”
季昕華稱：“云計算雖然比本地研發更安全，但不可能是100%。就算微軟、亞馬遜、谷歌、阿里、騰訊一樣都會出問題。所以用戶更愿意使用多家云來服務，多云戰略是未來的重要方向。”
在具體容災落地過程中，騰訊云技術運營服務工程師康開元在騰訊大講堂上表示，做容災首先要梳理當前系統“災”主要有哪些痛點，并對其優先級排序。如單點隱患、難擴展性、運維成本高等現狀。而異地容災的核心特征在于——范圍上地域粒度的容災；流量分布上單地域承載100%業務流量；數據存儲方面在數據庫及存儲均在異地做冷備，數據單向同步；常見使用場景主要在數據層安全級別容災，業務層較少異地部署。
孫琦告訴第一財經，面對極端情況，如果云上的應用沒有合理規劃災備，也一定會造成業務中斷，甚至數據丟失，造成更大的損失。所以，云上的應用架構除了利用云原生的服務能力為應用創造更快的迭代速度，還要考慮云原生服務在單元多區域，甚至多云多區域之間的災備，才能實現最高級別的業務連續性。
