昨晚，B 站崩了！

昨晚 10 點多，我朋友圈忽然熱鬧了起來，不少人都在轉發 B 站沒法訪問的消息，各類截圖滿天飛。

 

不僅是 B 站，包括 A 站和豆瓣在內的產品都出現了沒法訪問的狀況。不少人說，睡前的快樂沒有了。

 

很快，B 站崩了的消息登上了微博熱搜。

 

也難怪，一個月活 2 億多的產品忽然宕機半小時，正好又遇上晚上活躍高峯期，引發的關注度天然也特別高。

 

凌晨 2 點多，B 站官方在微博發佈了道歉聲明。

 

在這個聲明中並無說起具體的事故緣由，只說是由於部分服務器機房發生故障致使沒法訪問。

 

相對來講，此次宕機時間之長、影響範圍之大，估計怎麼說也是個 P0 級別的線上事故了。

 

這個夜晚，B 站的產品經理、程序員、測試、運維、公關們估計都沒睡好覺。

 

吃瓜歸吃瓜，不過我相信更多人仍是會好奇這種大範圍的技術故障究竟是怎麼產生的？

 

不過，我以爲首先能夠排除掉的就是什麼機房被燒了、程序員刪庫跑路之類的說法。

 

像這種大型產品都不會把自家的服務器放在一個機房，數據也不會僅此一份，多地多機房多副本是常規操做，但凡一個機房出問題，會立馬切換到其餘可用的服務上。

 

即使是某一個雲服務提供商出了問題，他們也通常會切換到其餘可用的雲服務上去。

 

不少公司都會同時使用多個雲服務商提供的服務，好比阿里雲、騰訊雲、金山雲等等，怕的就是其中一家出毛病。

 

截止到目前，官方依然沒有給出具體的事故緣由。因此，只能基於看到的現象來作一些推測。

 

首先，B 站、A站、豆瓣同時出現沒法訪問的狀況，說明問題出在他們所使用的公共技術服務上，好比雲服務。而其中出問題機率最大的，或許就是 CDN。

 

關於 CDN，我以前寫過一篇文章介紹過，簡單說就是用來應對高併發和大流量訪問的內容分發系統。

 

其次，B 站先是報出了 404 異常，而後又報出了 502 異常，這些狀態碼也反映了系統出現的一些可能性問題。

 

之前我作技術時，在開發階段和改 bug 的時候就常常遇到 404 或 502，但這類錯誤碼是一個合集，並不能所以定位到準確的具體問題。

 

404 表明的是找不到可訪問的系統資源，好比網頁不存在、文件錯誤、接口 URL 異常等，但前提是服務可用。

 

而 502 的出現意味着網關錯誤，多是服務器異常致使的系統故障。

 

簡單說，碰上 404 時說明系統仍是可用的，只是其中一個功能失效了。碰上 502 則表示系統不可用了，崩掉了。

 

回到前面說的，此次線上事故若是是由於第三方 CDN 服務商的問題，那使用他們服務的這些產品就會受到集體影響。

 

CDN 失效，大量的網絡請求直接繞過它做用在應用服務器上，服務器請求量激增超過了自身的承載極限，因而開始啓動容災降級策略。

 

所謂的「降級」，就是服務器根據策略設置進行的自我保護，本來能提供 100 分的服務，如今由於特殊狀況降爲只提供 80 分的服務，以確保自身可以安全運行。

 

按理說，B 站這樣的大型系統也會有這樣的機制，但不知道爲啥沒起做用。

 

可能 CDN 失效後大量的請求過來後直接把服務器幹崩了，還沒等容災啓動，一個接一個，而後全崩了。

 

當雪崩來臨時，沒有一臺服務器是無辜的。

 

最後，在 A 站和豆瓣相繼恢復系統使用後，B 站仍然沒法訪問，說明他們的內部系統對異常處理和容災機制的差別。

 

我看朋友圈有作技術的朋友轉了一篇 B 站的技術負責人曾經作過的架構分享，其中提到 B 站的容災系統是自研的，並無直接使用第三方服務，或許這也是他們恢復較慢的可能緣由。

 

一樣從現象推測緣由。

 

11 點多的時候我打開 B 站的網頁，首頁陸續能刷出一些內容來了，但這時候基本處於「只讀」狀態，只能看，包括一些操做和登陸功能都無法用。

 

這多是運維在恢復數據時的刻意控制，目的是防止恢復過程當中由於數據寫入致使的數據紊亂。

 

過了一下子再刷新時，登陸狀態就出來了，且我仍是處於登陸狀態。

 

雖然我平時不怎麼刷 B 站，但以前留下的搜索記錄和瀏覽行爲也讓 B 站對我進行了用戶畫像，因此推薦的內容基本都是和我感興趣的相關的。

 

但此次打開的首頁內容基本都是我不感興趣的，並且類型比較多。我也問了下朋友，他們說看到的內容差很少。

 

這說明了一個可能的緣由，B 站的容災啓動了，但重啓恢復有一個過程，先確保總體可用是第一步。

 

這時候，可能推薦系統的服務還沒恢復，因此你們看到的東西差很少，是公共池裏的內容，沒有個性化。

 

又過了一段時間，當再次打開刷新時，推薦的內容發生了變化，和以前正常推薦邏輯下的內容基本差很少了。

 

這說明，系統在恢復初期依然處於容災降級狀態，以後才慢慢恢復其餘服務。

 

足以可見，技術系統是一個多麼龐大且複雜的工程。咱們看到的每每只是冰山一角，更多的複雜性都在看不到的背後。

 

以上，只是對於現象的一個推測，不構成結論。再說，B 站官方大機率也不會公佈真實的故障緣由，即使說了，普通用戶也不理解。索性用機房服務器異常來給出解釋。

 

包括在產品上的體現，也只是提示服務器不可用或數據異常，並無把一些複雜的技術代碼和錯誤信息展現出來，這也是一種處理機制。

 

一般，若是是在代碼層面出現的問題，系統報出的異常都是一堆別人看不懂的亂碼。

 

程序員會根據產品經理的定義把這些亂碼翻譯成用戶可理解的文案，好比密碼錯誤、服務器異常。

 

可是，若是想找到異常的真實緣由，光看產品表現層的文案提示是沒用的，仍是獲得技術層面去看。

 

因此，出現這樣的問題，只要不是產品邏輯的錯誤，最忙最緊張的應該就是程序員和運維了。固然，還有測試。

 

沒出事不可怕，線上事故最要命。

 

真正體驗過一次處理線上事故的過程，才知道那種緊張而刺激的切身感覺。

 

B 站的兄弟們，辛苦了！

 

················· 唐韌出品 ·················

安可時刻

昨天京東普調，從 14 薪逐步調整到 16 薪，沒想到朋友圈京東的朋友沒一個出來歡呼的。

 

真是應了那句話，你沒錢的時候恨不得全世界知道，你有錢的時候恨不得全世界都不知道，哈哈！