B站自曝去年伺服器大崩潰原因 就因為這？
不知道差友們還記不記得，去年的 7 月 13 日，B 站發生了一件大事。它毫無徵兆的崩了。。。（ 如果忘了的小夥伴，可以看 這篇文章 ）
至於為啥崩了，當時大家誰也心裡沒個底。不過吹起水來可是一套一套的，什麼停電啊，起火啊，程式設計師 rm -rf /* 跑路啊。。。說的是個天馬行空。
後來呢，隨著 B 站在凌晨兩點一頓修仙，把伺服器問題給慢慢解決，這件事情也算是告一段落了。
本以為這次 B 站崩了會和微博上無數崩了的網站一樣，成為我們衝浪生活中的一個笑談，僅留下一個大會員給我們 「 緬懷 」。
沒想到在今年的 7 月 13 日，B 站特意發了一篇文章，刨開心窩子來給我們講了一講，那個晚上，到底發生了什麼。
咱也看了一下這篇文章，好傢夥，讓整個 B 站崩潰的原因，竟然只是一行程式碼沒寫好？？？借著這篇文章，世超準備帶大家從 B 站的角度來回顧一下這件事情。放心，不會有生澀難懂的名詞，不會有犀利糊塗的黑話，保證小白也能看明白。 案情回溯： 意外，發生在 2021 年 7 月 13 日的 22 時 52 分。
負責搞定站點可靠性的工程師（SRE）和B站的客服都收到了大量網站打不開的報警。
而負責處理這些事故的同事已經下班了，當即準備在家裡通過 VPN 來登錄公司內網處理這些問題。
結果發現VPN 也崩了。。。壓根進不去系統。最後，還是在公司的整了個 「 綠色通道 」 才成功進去。你說這綠色通道不會是向日葵吧（一種遠程桌面軟體）
▼
而在綠色通道成功打通，負責各種業務的團隊就位之後，B 站也開始對問題進行分析定位。出問題的模組也很明顯，在線業務主機房的7層 SLB（負載均衡伺服器，用來處理多用戶，多業務的情況）的 CPU 跑滿了 100%。
簡單來說，就是 CPU 被不知道哪裡來的刺客給佔用光了算力，沒法處理業務了。
系統未響應.exe ▼
B 站最開始的嘗試方法呢，和咱們平時手機電腦卡機後做的操作一樣。
重啟就完事了，要相信重啟能解決 90% 的問題！
但很可惜，B 站這次是那個 10.5%。
說業務恢復了嘛，也沒有，主機房重啟後還是出現了CPU 跑滿 100%的問題。不過別的機房好起來了，雖然會卡，但是沒出現 CPU 跑滿的問題。
有一部分做了多活的業務（多站點同時提供服務）開始慢慢恢復。所以。。。重啟不能完全解決問題，但是這個問題既然過去沒出現過。
那會不會是新加入的程式碼問題呢？隨著時間在一分一秒的過去，藉助分析工具的幫助，問題被定位到了最近新上線的 Lua (一種程式語言，類似 Python，Java 這些) 函數上。
隨後，B 站開始進行了一波波緊張的回滾操作。
這一通工作弄下來，雖然好像找到幾個疑似出問題的部位，但伺服器還是該掛掛，距離 「 康復 」 還有那麼一些距離。
沒辦法，總得讓業務先跑起來吧。於是團隊開始兵分兩路。一隊繼續堅持排查問題，尋找原因，另一隊則是開始重建一個新的 SLB 服務。
在緊張刺激的一小時後，新的 SLB 配置成功，原本導向主站的流量也慢慢的開始遷移過去。
好在這次行了。
凌晨兩點，在崩潰了三小時之後，B 站的業務總算得到了恢復。 罪魁禍首： 上面這些，就是那個晚上 B 站發生的故事，雖然解決了表面問題，讓業務恢復了。
可是最根本的原因是啥呢？如果不找到根因，那遲早會二度暴雷。
負責排查問題的同學也沒讓人失望，在時間壓力大大放緩之後，找出了真相。沒有外星人，沒有起火，沒有斷電，和網友們想像的大相徑庭。B 站這次崩的根因，僅僅是因為一個求最大公約數的函數沒寫好。。。
咱先盤一下這個 「 萬惡之源 」 哈。
這是一個典型的 「 自己調用自己 」 的遞歸函數。a b兩數字輾轉求余，直到 b 等於 0 的時候函數終止。不然這個函數就會自己調用自己，重新再跑一遍。
看上去好像是一點點問題都沒有，既明確了遞歸的終止條件（b = 0），也沒有太多複雜的邏輯處理。但是既然事情能發展到這地步。。。那就說明是出大問題了。對編程有些了解的差友可能發現了不對：
你傳進去的 0，是個什麼 0？沒錯，在程式語言里，數字 0 和字元串 『 0 』 並不算是一個東西。為了防止獃獃的電腦語言把事情給搞混，像 C 語言，Java 這些靜態語言都會要求我們在創建新變數的時候聲明這個變數的類型。
搞清楚它到底是整數，還是小數，或者是一個字元。然而 Lua 是個非常智慧的語言，它沒有這個要求。麻煩的臟活累活讓它自動來做就好了，Lua 會根據程式的需求自動分配變數類型。
C語言示例：# 定義一個整型數據a，為它賦值1# 定義一個字元串數據b，為它賦值『1』int a = 0;char a = ‘0’;Lua示例：–定義 a 為數字0，b為字元串『0』a = 0b = ‘0’
所以，我們給參數 b 傳進去的數值，是數字 0 呢，還是字元 『 0 』 ？一旦前面數據驗證沒把好關，在執行某個功能的時候，把字元 『 0 』 給傳到了這個函數里。
地雷就被引爆了。字元串 『 0 』 不會等於數字 0，函數的終止條件判斷不通過。
所以程式進入遞歸模式，再次調用自己。在後續進行求余預算的時候，Lua 的 「 智慧 」 又突然起到了作用。Lua 一拍腦袋，咋會有人把字元 『 0 』 拿來做計算啊，肯定是想把這個參數當數字用。
於是發生了強制類型轉換。
所以咱們小學數學都會學到的。。。 把 0 當除數的事情就發生了。這要是古老的大哥 C 語言來干這活，可能直接就給一個 Floating point exception 報錯了。但是 Lua 不一樣，作為一個新時代的 「 智慧 」 的語言，它會優雅的返回一個 nan （Not A Numbewr）。
程式，繼續運行。更要命的是，nan 也不會等於0。。。程式的終止條件無法實現。這樣跑幾個循環之後，原本用來計算 a 和 b 的最大公約數的函數 _gcd(a,b) 就變成了一個停不下來的函數 _gcd(nan,nan)。
在停不下來的路上根本停不下來，直接把 CPU 資源給吃滿了。
太聰明也不是一件好事啊。。。
就這樣，被佔滿的 CPU 一口氣把別的業務也帶崩了。還得前面提到的在家的 B 站程式設計師沒法在家通過 VPN 來搶救網路么？沒錯，他們登錄內網的時候，其中有部分服務也需要通過內網來處理。。。
屬於是把鑰匙斷鎖眼裡，也是崩的理所當然了。 崩完之後： 最後，如果差友們對相關技術細節更感興趣的話，世超建議你看看 B 站發布的這篇2021.07.13 我們是這樣崩的除了對事故的起承轉合，還對未來技術的更進與反思都做了更加專業，全面的總結。
講道理，這樣的機會其實挺難得的。每年崩了的應用何其多，但是願意發出來給同行學習，給普羅大眾看個樂子的寥寥無幾。
向上滑動 ▼
B 站這次願意分享，直面自己的 「 傷疤 」 。也讓我們看到了互聯網運維上最真實的一面。這些經驗，可不會寫在任何教科書上。哦對，這篇文章發出來的晚上，B 站其實又偷偷小崩了一次。。。
不知道是不是團隊好好總結了去年經驗的緣故。這回還沒等大部分人反應過來。。。B 站已經把問題給解決了。
