文｜IT時報見習記者 孫永會

編輯｜郝俊慧 孫妍

2023年年末，“崩”似乎成了部分互聯網大廠的收尾詞，前有阿里云“史詩級”的故障，后有滴滴大范圍宕機，再如近日騰訊視頻會員的崩潰，皆在網上掀起熱議波瀾。

近期，大廠頻繁故障上演的“連續劇”，不禁讓人心生疑問：它們怎么了？

業內專家汪斌（化名）告訴《IT時報》記者，系統出現Bug并不奇怪，但持續時間過長，意味著應急預案相關手冊并沒有完全覆蓋問題。

另一位從大廠“畢業”的資深技術員工則將原因歸咎于前幾年流行的“中臺”，“一旦中臺存在設計缺陷和設計冗余，管理者與執行者之間割裂，很容易形成事故。”

管理背鍋，強推中臺留隱患

最近一個月內的連續故障，之所以引起喧嘩，在于其有著新特征：一損俱損。

阿里和滴滴都是旗下相關App出現了故障，意味著在核心層或底層出現問題，也有人將原因歸咎于這兩年大廠降本增效、技術型人才缺失，影響業務穩定開展。

技術研發者鄧為（化名）此前在某大廠架構部門任職，親歷過公司內部的業態無序后，他無奈離開。

“真的很離譜。”在他看來，近期大廠頻繁出問題與人員變動有不可分割的關系，近三年來，互聯網大廠的人員規模經歷了從擴張到縮減的過程，也留下了不少業務黑洞。

“技術腐敗”是他對自己在大廠工作期間經歷、見聞的總結。“前幾年形勢好的時候，大廠紛紛擴招，‘搶占’業務高地，但人員膨脹后，實際的需求規劃未準時到位，結果人招進來卻沒活干，需要自己找活，或者自己建項目。”鄧為表示，此前公司內部有很多項目屬于“巧立名目”，有的把簡單問題復雜化以消化多余人力，有的將外部項目拿進公司稍作修改，換個名字便視作新項目，還有的人將已有項目不斷合并、組合后成立新項目。

此外，幾年前興起的中臺概念也并不完美，并不是中臺設計動機有問題，而是打造中臺的過程需要行政強制要求配合搭建。但在執行過程中，缺失技術管理和決策問責機制，即使中臺存在設計缺陷和設計冗余，也沒有太好的修改機制。

“公司執行層和管理層的割裂是這種情況發生的關鍵所在。”鄧為說，執行層維持實際業務的運轉，管理層傾向于操控項目的概念和方案來維持績效，“決策一旦發生錯誤，最終復盤問責卻不會對管理層形成威脅，因為管理層不僅掌握人事權，也具有解釋權，結果最后故障出現后，關鍵技術人員往往是首先被追責的人，然后形成惡性循環。”

技術歸咎，架構設計和運維制度欠考量

當然，多次宕機事件背后，仍然有技術問題。

詳看阿里云此前公布的問題報告——AK在讀取白名單數據時出現讀取異常，因處理讀取異常的代碼存在邏輯缺陷，生成了一份不完整的白名單，導致不在此白名單中的有效請求失敗，影響云產品控制臺及管控API服務出現異常，同時部分依賴AK服務的產品因不完整的白名單出現部分服務而運行異常。

如何理解？“AK是一個服務功能，是構成阿里云平臺的基礎。”汪斌認為，下層服務的服務能力類似于中臺，可以為上層服務提供數據庫、存儲等功能，但會導致下層“變重”，即架構變得冗余和復雜，“當架構中的設計邏輯不清楚時，極容易出現問題，這對上層來說亦是災難。該企業頻繁發生故障，或因架構過于集中。”

再來看滴滴事故，官方宣稱是“底層系統發生故障”。據有關媒體報道，造成此次事故的原因是由升級K8S集群導致，即本應升級到1.12，但升級到了1.20，協議不兼容而引發連鎖反應。“這個問題則應該是運維制度管理欠缺考量，在操作過程中并未考慮災難發生的可能。”汪斌表示。

大大小小的宕機事件讓人產生此類事故是否無法避免的疑問。

據《北京日報》報道，無論是本地計算還是云計算，互聯網的服務數據終究要流向數據中心，匯集到幾個中心節點，這種物理屬性決定了數據中心無法規避外界因素，也就無法做到永不宕機，而企業的安全冗余和災備能力受“投入產出比”影響，也不可能無限進行備份。

“企業多數的規章制度多‘脫胎’于日常的經驗教訓，從這些事件中，我們能獲得的啟發是，一方面要健全運維制度，另一方面是強化操作流程，從中總結經驗。”汪斌說道。

排版／ 季嘉穎