昨晚，B 站崩了！
昨晚 10 點多，我朋友圈突然熱鬧了起來，很多人都在轉(zhuǎn)發(fā) B 站無法訪問的消息，各種截圖滿天飛。
不只是 B 站，包括 A 站和豆瓣在內(nèi)的產(chǎn)品都出現(xiàn)了無法訪問的情況。很多人說，睡前的快樂沒有了。
很快，B 站崩了的消息登上了微博熱搜。
也難怪，一個月活 2 億多的產(chǎn)品突然宕機半小時，正好又趕上晚上活躍高峰期，引起的關注度自然也特別高。
凌晨 2 點多，B 站官方在微博發(fā)布了道歉聲明。
在這個聲明中并沒有提及具體的事故原因，只說是因為部分服務器機房發(fā)生故障導致無法訪問。
相對來說，這次宕機時間之長、影響范圍之大，估計怎么說也是個 P0 級別的線上事故了。
這個夜晚，B 站的產(chǎn)品經(jīng)理、程序員、測試、運維、公關們估計都沒睡好覺。
吃瓜歸吃瓜，不過我相信更多人還是會好奇這種大范圍的技術故障到底是怎么產(chǎn)生的？
不過，我覺得首先可以排除掉的就是什么機房被燒了、程序員刪庫跑路之類的說法。
像這種大型產(chǎn)品都不會把自家的服務器放在一個機房，數(shù)據(jù)也不會僅此一份，多地多機房多副本是常規(guī)操作，但凡一個機房出問題，會立馬切換到其他可用的服務上。
即便是某一個云服務提供商出了問題，他們也一般會切換到其他可用的云服務上去。
很多公司都會同時使用多個云服務商提供的服務，比如阿里云、騰訊云、金山云等等，怕的就是其中一家出毛病。
截止到目前，官方依然沒有給出具體的事故原因。所以，只能基于看到的現(xiàn)象來做一些推測。
首先，B 站、A站、豆瓣同時出現(xiàn)無法訪問的情況，說明問題出在他們所使用的公共技術服務上，比如云服務。而其中出問題概率最大的，或許就是 CDN。
關于 CDN，我之前寫過一篇文章介紹過，簡單說就是用來應對高并發(fā)和大流量訪問的內(nèi)容分發(fā)系統(tǒng)。
其次，B 站先是報出了 404 異常，然后又報出了 502 異常，這些狀態(tài)碼也反映了系統(tǒng)出現(xiàn)的一些可能性問題。
以前我做技術時，在開發(fā)階段和改 bug 的時候就經(jīng)常遇到 404 或 502，但這類錯誤碼是一個合集，并不能因此定位到準確的具體問題。
404 代表的是找不到可訪問的系統(tǒng)資源，比如網(wǎng)頁不存在、文件錯誤、接口 URL 異常等，但前提是服務可用。
而 502 的出現(xiàn)意味著網(wǎng)關錯誤，可能是服務器異常導致的系統(tǒng)故障。
簡單說，碰上 404 時說明系統(tǒng)還是可用的，只是其中一個功能失效了。碰上 502 則表示系統(tǒng)不可用了，崩掉了。
回到前面說的，這次線上事故如果是因為第三方 CDN 服務商的問題，那使用他們服務的這些產(chǎn)品就會受到集體影響。
CDN 失效，大量的網(wǎng)絡請求直接繞過它作用在應用服務器上，服務器請求量激增超過了自身的承載極限，于是開始啟動容災降級策略。
所謂的「降級」，就是服務器根據(jù)策略設置進行的自我保護，原本能提供 100 分的服務，現(xiàn)在因為特殊情況降為只提供 80 分的服務，以確保自身能夠安全運行。
按理說，B 站這樣的大型系統(tǒng)也會有這樣的機制，但不知道為啥沒起作用。
可能 CDN 失效后大量的請求過來后直接把服務器干崩了，還沒等容災啟動，一個接一個，然后全崩了。
當雪崩來臨時，沒有一臺服務器是無辜的。
最后，在 A 站和豆瓣相繼恢復系統(tǒng)使用后，B 站仍然無法訪問，說明他們的內(nèi)部系統(tǒng)對異常處理和容災機制的差異。
我看朋友圈有做技術的朋友轉(zhuǎn)了一篇 B 站的技術負責人曾經(jīng)做過的架構分享，其中提到 B 站的容災系統(tǒng)是自研的，并沒有直接使用第三方服務，或許這也是他們恢復較慢的可能原因。
同樣從現(xiàn)象推測原因。
11 點多的時候我打開 B 站的網(wǎng)頁，首頁陸續(xù)能刷出一些內(nèi)容來了，但這時候基本處于「只讀」狀態(tài)，只能看，包括一些操作和登錄功能都沒法用。
這可能是運維在恢復數(shù)據(jù)時的刻意控制，目的是防止恢復過程中因為數(shù)據(jù)寫入導致的數(shù)據(jù)紊亂。
過了一會兒再刷新時，登錄狀態(tài)就出來了，且我還是處于登錄狀態(tài)。
雖然我平時不怎么刷 B 站，但之前留下的搜索記錄和瀏覽行為也讓 B 站對我進行了用戶畫像，所以推薦的內(nèi)容基本都是和我感興趣的相關的。
但這次打開的首頁內(nèi)容基本都是我不感興趣的，而且類型比較多。我也問了下朋友，他們說看到的內(nèi)容差不多。
這說明了一個可能的原因，B 站的容災啟動了，但重啟恢復有一個過程，先確保整體可用是第一步。
這時候，可能推薦系統(tǒng)的服務還沒恢復，所以大家看到的東西差不多，是公共池里的內(nèi)容，沒有個性化。
又過了一段時間，當再次打開刷新時，推薦的內(nèi)容發(fā)生了變化，和之前正常推薦邏輯下的內(nèi)容基本差不多了。
這說明，系統(tǒng)在恢復初期依然處于容災降級狀態(tài)，之后才慢慢恢復其他服務。
足以可見，技術系統(tǒng)是一個多么龐大且復雜的工程。我們看到的往往只是冰山一角，更多的復雜性都在看不到的背后。
以上，只是對于現(xiàn)象的一個推測，不構成結論。再說，B 站官方大概率也不會公布真實的故障原因，即便說了，普通用戶也不理解。索性用機房服務器異常來給出解釋。
包括在產(chǎn)品上的體現(xiàn)，也只是提示服務器不可用或數(shù)據(jù)異常，并沒有把一些復雜的技術代碼和錯誤信息展示出來，這也是一種處理機制。
通常，如果是在代碼層面出現(xiàn)的問題，系統(tǒng)報出的異常都是一堆別人看不懂的亂碼。
程序員會根據(jù)產(chǎn)品經(jīng)理的定義把這些亂碼翻譯成用戶可理解的文案，比如密碼錯誤、服務器異常。
但是，如果想找到異常的真實原因，光看產(chǎn)品表現(xiàn)層的文案提示是沒用的，還是得到技術層面去看。
所以，出現(xiàn)這樣的問題，只要不是產(chǎn)品邏輯的錯誤，最忙最緊張的應該就是程序員和運維了。當然，還有測試。
沒出事不可怕，線上事故最要命。
真正體驗過一次處理線上事故的過程，才知道那種緊張而刺激的切身感受。
B 站的兄弟們，辛苦了！
················· 唐韌出品 ·················
昨天京東普調(diào)，從 14 薪逐步調(diào)整到 16 薪，沒想到朋友圈京東的朋友沒一個出來歡呼的。
真是應了那句話，你沒錢的時候巴不得全世界知道，你有錢的時候巴不得全世界都不知道，哈哈！