記者梳理發(fā)現(xiàn)，2023年以來，包括阿里、騰訊、百度、滴滴、抖音、B站等各大平臺均發(fā)生過“崩了”事件。

一

12月3日晚，騰訊視頻“崩了”登上微博熱搜。騰訊視頻方面回應(yīng)稱，出現(xiàn)了短暫技術(shù)問題，正在加緊修復(fù)，各項功能在逐步恢復(fù)中。

11月27日晚間，滴滴App系統(tǒng)發(fā)生故障，全國大面積崩潰，服務(wù)無法正常使用。11月29日，滴滴方面發(fā)表聲明稱，各項服務(wù)已經(jīng)恢復(fù)，初步確定，這起事故的起因是底層系統(tǒng)軟件發(fā)生故障，并非網(wǎng)傳的“遭受攻擊”。

作為月活（月度活躍用戶數(shù)）破億的社交平臺，B站此前多次因為“崩了”登上熱搜。據(jù)記者不完全統(tǒng)計，B站在2023年“崩了”兩次，最近一次是在6月28日，當天下午不少用戶反映“B站崩了”，該詞條隨后登上熱搜。此次受影響的主要是番劇和影視頁面，用戶反映“追番一直提示獲取視頻內(nèi)容失敗”“顯示頁面加載失敗”“看番看一半加載不出來”。該問題持續(xù)一小時左右。

如果不是滴滴的長時間崩潰造成大范圍的負面影響與討論度，非行業(yè)人士不會將某款軟件的暫時“崩了”作為熱點討論。

萬博智云CTO孫琦表示，滴滴事件僅是一個個案，但該事件故障級別較大，確實影響到了一定規(guī)模普通群眾的生活。實際上，很多用戶看不到的軟件故障正在每天發(fā)生，這在行業(yè)內(nèi)是一個較為常見的問題。

二

一位軟件工程師告訴記者，目前隨著行業(yè)技術(shù)的逐漸成熟，各大廠一般都會自建數(shù)據(jù)中心，云服務(wù)也多采用多云策略，配有標準容災(zāi)機制，出現(xiàn)崩潰問題大多發(fā)生在自身算法、硬件，或自身技術(shù)團隊層面。

以B站崩潰為例，其技術(shù)團隊在解讀文章中表示，運維團隊作項目有個弊端，開發(fā)完成自測沒問題后就開始灰度上線（產(chǎn)品試用收集意見），沒有專業(yè)的測試團隊介入，“此組件太過核心，需要引入基礎(chǔ)組件測試團隊，對SLB（服務(wù)器負載均衡）輸入?yún)?shù)作完整的異常測試”。

對于后續(xù)改進，B 站技術(shù)團隊認為要“招專業(yè)的人”，“我們選擇基于Lua（一種網(wǎng)絡(luò)源代碼形式）開發(fā)是因為Lua簡單易上手，社區(qū)有類似成功案例。團隊并沒有資深做Nginx（一種網(wǎng)絡(luò)源代碼形式）組件開發(fā)的同學(xué)，也沒有做C/C++（一種網(wǎng)絡(luò)源代碼形式）開發(fā)的同學(xué)”。

此外，文章里還寫道：“B站一直沒有NOC（網(wǎng)絡(luò)操作中心）/技術(shù)支持團隊，在出現(xiàn)緊急事故時，故障響應(yīng)、故障通報、故障協(xié)同都是由負責(zé)故障處理的SRE（網(wǎng)站可靠性工程師）來承擔。如果是普通事故還好，如果是重大事故，信息同步根本來不及，所以，事故的應(yīng)急響應(yīng)機制必須優(yōu)化?！?/p>

另以滴滴事件為例，多個獨立信息源向記者發(fā)來一份討論截圖，稱一個規(guī)模非常大的K8s 集群進行在線熱升級，因為某些原因，所有 Pod（容器）損壞，而 K8s 的元數(shù)據(jù)已經(jīng)被新版本K8s 修改，無法回滾，因此恢復(fù)時間拉得很長。K8s（Kubernetes）是一個開源的容器編排平臺，可以自動化地部署、擴展和管理容器化應(yīng)用程序。

云猿生數(shù)據(jù)創(chuàng)始人兼CEO、前阿里云數(shù)據(jù)庫總經(jīng)理曹偉在其個人公眾號發(fā)文解讀稱，該說法并非毫無依據(jù)。滴滴團隊近兩個月正將公司內(nèi)部的 K8s 從1.12版本升級到1.20。前者于2018年9月發(fā)布，后者是2020年12月，對高速發(fā)展的K8s項目來說，兩個版本間存在相當大差距。K8s 官方推薦的方法是沿著一個個版本升上去。但滴滴團隊認為多次升級風(fēng)險更高，采取了跨越8個版本直接升級策略，同時為了避免中斷業(yè)務(wù)，在不重啟容器的情況下原地升級，滴滴團隊還修改了其他代碼。曹偉認為，該策略理論上可行，但中間可能遭遇到意外因素，如運維誤操作，才導(dǎo)致了最終的大規(guī)模故障。

曹偉的建議是，當一個集群規(guī)模很大時，很容易在意想不到的地方發(fā)生類似的問題，那么在設(shè)計系統(tǒng)時，應(yīng)把集群的規(guī)?？刂圃谝粋€合理的范圍，但擴大集群數(shù)量。例如，可以把兩個一萬節(jié)點的集群拆成十個兩千節(jié)點的集群，管理成本沒有增加，而運行風(fēng)險和（故障的）爆炸半徑得到極大的降低。

11月12日，阿里云出現(xiàn)了一次影響所有區(qū)域的全局大故障。以這次阿里云的故障為例，曹偉稱，對象存儲的關(guān)鍵路徑里依賴看RAM（內(nèi)存）的鑒權(quán)邏輯，因此，RAM出現(xiàn)故障時，也造成了對象存儲的不可用。其實，數(shù)據(jù)面的可用性如果和控制面解耦（耦合是指兩個或兩個以上體系運行中相互影響而產(chǎn)生的聯(lián)合起來的現(xiàn)象。解耦即是用數(shù)字方法解決處理這一問題），那么控制面掛掉對數(shù)據(jù)面的影響很輕微。否則，要么要不斷去提高控制面的可用性，要么就要接受故障的級聯(lián)發(fā)生。因此總結(jié)來說，曹偉建議各平臺技術(shù)團隊盡量做到控制規(guī)模、避免單點、擁抱重啟、保證數(shù)據(jù)面的可用性和控制面解耦。

孫琦對記者表示，如今各大互聯(lián)網(wǎng)平臺基礎(chǔ)架構(gòu)層已經(jīng)很成熟，極少出現(xiàn)因技術(shù)革新導(dǎo)致影響整個架構(gòu)的事故，但在現(xiàn)有技術(shù)支撐、業(yè)務(wù)并發(fā)量不會暴漲的情況下，在團隊穩(wěn)定的前提下，類似問題理應(yīng)不會頻繁出現(xiàn)。

（摘自《第一財經(jīng)日報》呂倩、劉曉潔）