B站崩了,一群跟著躺槍!盤點史上嚴重的服務宕機事件

一夜之間,最愛的彈幕影片網站突然崩潰了半小時,隨後A站、豆瓣也如出一轍。有網友稱「著火」所至,但上海消防隊隨後出來闢謠。究竟是怎麼回事?

崩了!

勞累了一天的年輕人們,正準備躺平拿出手機,開啟那熟悉的小破站App,一鍵三連自己最喜愛的up主的最新影片。突然發現:

B站崩了,一群跟著躺槍!盤點史上嚴重的服務宕機事件

瞬間,「B站崩了」的訊息登上熱搜,微博運維心頭一緊。

B站崩了,一群跟著躺槍!盤點史上嚴重的服務宕機事件

部分網友表示:A站、豆瓣等網站也出現訪問故障,重連Wi-Fi也沒有用。

今日凌晨,B 站釋出公告稱,昨晚,B 站的部分伺服器機房發生故障,造成無法訪問。技術團隊隨即進行了問題排查和修復,現在服務已經陸續恢復正常。

B站崩了,一群跟著躺槍!盤點史上嚴重的服務宕機事件

「小破站」發生什麼事了?

這份模稜兩可的宣告顯然無法阻擋住吃瓜群眾的熱情。

短短几分鐘,關於B站的各種揣測訊息就變成了百家講壇:

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

B站崩了,一群跟著躺槍!盤點史上嚴重的服務宕機事件

還有人煞有介事地Po出了B站運營小妹的朋友圈,說B站停電了……

B站崩了,一群跟著躺槍!盤點史上嚴重的服務宕機事件

隨後立刻有專業人士指出:B站作為一個上市的網際網路公司,伺服器多地備份是最最起碼的事,樓裡停電這個解釋,估計只能騙騙沒有學過資料庫的高中生。

至於A站和晉江文學網為什麼會掛,很可能是因為B站掛了,大批使用者無片可看,就湧入A站和豆瓣,

造成網站的流量激增,哪怕A站和B站不共用雲服務,也可能被壓垮。

B站7000多萬日活網友的威力可見一斑。

B站崩了,一群跟著躺槍!盤點史上嚴重的服務宕機事件

下面我們看看幾個相對靠譜的猜測:

知乎作者@黃珏珅

盲猜了一下,應該是etcd掛了。

通常來說,能造成幾乎所有請求都502的,要不就是前端和後端之間的網路通路全掛了,要不就是後端的服務全都掛了。

那麼現在的大型網際網路公司的基礎設施是怎樣的呢,大多數使用了kubernetes,實現全國各地的資料中心的容器編排、網路虛擬化等。

而kubernetes的設計上,網路外掛和pod編排又是相對獨立的。

如果只是網路外掛出問題了,那麼部分伺服器上的網路外掛的快取還在,一定有部分使用者還能正常使用。

現在所有的都掛了,那隻能是etcd掛掉,導致反向代理無法透過etcd找到對應的pod的虛擬ip,又無法透過網路外掛與對應的pod通訊。

知乎作者@k8seasy

則認為這個基本屬於站點本身故障。

從恢復時間看30分鐘左右,並且幾乎100%恢復,說明應該是某個核心元件崩潰了,導致核心服務不可用。

出現這種可能的不少,最有可能的原因是上線新版本,開始沒問題,升級了部分叢集,結果新版本有bug,到了某個時刻直接掛了,老版本的壓力一大也沒扛住。然後緊急定位,回滾解決。

也有網友提出,

此次事件與雲服務商離不開干係:

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

容災策略啟動服務降級。服務降級了但沒完全降,CDN掛了,閘道器也跟著掛了,

服務雪崩,一直崩到整個環境。

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

在網際網路歷史上,「小破站」這樣的宕機事件只能算是「灑灑水」~

來看看其他網際網路大咖們是如何玩轉宕機的。

7小時不能上微信:

2013年7月22日,微信服務宕機,造成了將近7個小時的網路中斷。據微信官方公佈資訊,由於上海一支施工隊挖斷了通訊光纜,導致騰訊華東資料處理中心的業務請求紛紛轉向華南和華北,進而導致了業務的全面癱瘓。

用支付寶「剁手」失敗:

2015年5月27日下午,部分使用者反映其支付寶出現網路故障,賬號無法登入或支付。支付寶官方表示,故障是由於杭州市蕭山區某地光纖被挖斷導致,該事件造成部分使用者無法使用支付寶。隨後支付寶工程師緊急將使用者請求切換至其他機房,受影響的使用者開始逐步恢復。到了晚上7點20分,支付寶方面宣佈使用者服務已經完全恢復正常。

B站崩了,一群跟著躺槍!盤點史上嚴重的服務宕機事件

而在國外,網路宕機的事件更是屢見不鮮。

亞馬遜雲服務罷工:

2015年9月,亞馬遜的雲伺服器因收到來自新上線的DynamoDB功能帶來的大量資料請求,導致其因過載而宕機。於是,包括Reddit、Tinder、Netflix和IMDB在內的眾多流行應用和網址直接罷工了數小時。

除了Netflix,絕大多數亞馬遜雲服務的客戶在此次“突擊檢查”中,都被發現毫無準備。而Netflix此前已經使用過一種名為“混沌工程”的技術來模擬類似服務中斷事件的發生,使得這起事故對其影響降到了最小。

B站崩了,一群跟著躺槍!盤點史上嚴重的服務宕機事件

納斯達克停擺:

2013年8月22日,由於納斯達克交易所的備用伺服器中出現了一個嚴重的bug,直接導致納斯達克停擺了3個多小時。當其恢復運作時,已經引起了市場恐慌,大量交易員湧向交易視窗,出售交易所運營商納斯達克OMX集團的股票,導致OMX集團的股價當日一度大跌逾5%。

事後有人評估,由於納斯達克停擺造成的經濟損失可能達數億美元。

B站崩了,一群跟著躺槍!盤點史上嚴重的服務宕機事件

全美大宕機:

2016年10月21日早晨,許多美國使用者突然發現包括Twitter、CNN、Spotify等大型網站均無法登陸。這場網路癱瘓從美國東部開始,一路蔓延至全美區域。事後發現查明,

原因是伺服器遭受了駭客的DDoS攻擊。

關於B站宕機事故,開源基礎軟體公司Zilliz的質量保障團隊負責人喬燕良做了較為專業客觀的分析:

現在的網站故障造成的原因主要可分為軟體服務引起的故障和硬體服務引起的故障。

軟體服務故障一般可理解為程式碼邏輯缺陷,常見的是新增或更新某個功能而引入缺陷導致整個服務中斷,硬體服務故障一般是由於某些服務裝置的損壞造成的服務中斷,比如光纖被挖斷了。

如果要降低宕機風險,

就需要提高服務的高可用性。

首先從架構上,建議採用雲原生架構,實現自動容錯機制和故障隔離,從而能夠在服務出現故障時快速遷移或回滾。

其次為防止硬體故障類風險,需要有完善的災備方案,同城雙活或異地災備目前都已經有比較成熟的方案,國內企業在這塊投入相對比較“節約”。

Bilibili,下次一定!

參考資料:

http://www。zhihu。com/question/472065470