2023年年末，「崩」似乎成了部分網路大廠的收尾詞，前有阿里雲「史詩級」的故障，後有滴滴大範圍宕機，再如近日騰訊視頻會員的崩潰，皆在網上掀起熱議波瀾。近期，大廠頻繁故障上演的“連續劇”，不禁讓人心生疑問：它們怎麼了？業界專家汪斌（化名）告訴《IT時報》記者，系統出現Bug並不奇怪，但持續時間過長，意味著緊急計畫相關手冊並沒有完全覆蓋問題。

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

管理背鍋

強推中台留隱患

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

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

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

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

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

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

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

技術歸咎

架構設計與維運制度欠考量

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

詳看阿里雲先前公佈的問題報告－AK在讀取白名單資料時出現讀取異常，因處理讀取異常的程式碼有邏輯缺陷，產生了一份不完整的白名單，導致不在此白名單中的有效請求失敗，影響雲端產品控制台及管控API服務出現異常，同時部分依賴AK服務的產品因不完整的白名單出現部分服務而運作異常。

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

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

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

根據《北京日報》報道，無論是本地運算或雲端運算，網路的服務資料終究要流向資料中心，匯集到幾個中心節點，這種實體屬性決定了資料中心無法規避外界因素，也就無法做到永不宕機，而企業的安全冗餘和災備能力受「投入產出比」影響，也不可能無限進行備援。

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