互聯網APP接連崩潰，技術維穩謹慎當先

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

一

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

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

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

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

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

二

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

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

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

此外，文章里還寫道：“B站一直沒有NOC（網絡操作中心）/技術支持團隊，在出現緊急事故時，故障響應、故障通報、故障協同都是由負責故障處理的SRE（網站可靠性工程師）來承擔。如果是普通事故還好，如果是重大事故，信息同步根本來不及，所以，事故的應急響應機制必須優化。”

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

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

曹偉的建議是，當一個集群規模很大時，很容易在意想不到的地方發生類似的問題，那么在設計系統時，應把集群的規模控制在一個合理的范圍，但擴大集群數量。例如，可以把兩個一萬節點的集群拆成十個兩千節點的集群，管理成本沒有增加，而運行風險和（故障的）爆炸半徑得到極大的降低。

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

孫琦對記者表示，如今各大互聯網平臺基礎架構層已經很成熟，極少出現因技術革新導致影響整個架構的事故，但在現有技術支撐、業務并發量不會暴漲的情況下，在團隊穩定的前提下，類似問題理應不會頻繁出現。

（摘自《第一財經日報》呂倩、劉曉潔）