大廠系統崩潰上演“連續劇” 技術的錯還是制度的鍋?
近日,多個APP頻繁陷入“崩潰”故障,大范圍宕機的背后,到底產生了什么問題?互聯網大廠們又如何解決呢?
2023年年末,“崩”似乎成了部分互聯網大廠的收尾詞,前有阿里云“史詩級”的故障,后有滴滴大范圍宕機,再如近日騰訊視頻會員的崩潰,皆在網上掀起熱議波瀾。
近期,大廠頻繁故障上演的“連續劇”,不禁讓人心生疑問:它們怎么了?
業內專家汪斌(化名)告訴《IT時報》記者,系統出現Bug并不奇怪,但持續時間過長,意味著應急預案相關手冊并沒有完全覆蓋問題。
另一位從大廠“畢業”的資深技術員工則將原因歸咎于前幾年流行的“中臺”,“一旦中臺存在設計缺陷和設計冗余,管理者與執行者之間割裂,很容易形成事故。”
一、管理背鍋,強推中臺留隱患
最近一個月內的連續故障,之所以引起喧嘩,在于其有著新特征:一損俱損。
阿里和滴滴都是旗下相關App出現了故障,意味著在核心層或底層出現問題,也有人將原因歸咎于這兩年大廠降本增效、技術型人才缺失,影響業務穩定開展。
技術研發者鄧為(化名)此前在某大廠架構部門任職,親歷過公司內部的業態無序后,他無奈離開。
“真的很離譜?!痹谒磥恚诖髲S頻繁出問題與人員變動有不可分割的關系,近三年來,互聯網大廠的人員規模經歷了從擴張到縮減的過程,也留下了不少業務黑洞。
“技術腐敗”是他對自己在大廠工作期間經歷、見聞的總結。“前幾年形勢好的時候,大廠紛紛擴招,‘搶占’業務高地,但人員膨脹后,實際的需求規劃未準時到位,結果人招進來卻沒活干,需要自己找活,或者自己建項目。”鄧為表示,此前公司內部有很多項目屬于“巧立名目”,有的把簡單問題復雜化以消化多余人力,有的將外部項目拿進公司稍作修改,換個名字便視作新項目,還有的人將已有項目不斷合并、組合后成立新項目。
此外,幾年前興起的中臺概念也并不完美,并不是中臺設計動機有問題,而是打造中臺的過程需要行政強制要求配合搭建。但在執行過程中,缺失技術管理和決策問責機制,即使中臺存在設計缺陷和設計冗余,也沒有太好的修改機制。
“公司執行層和管理層的割裂是這種情況發生的關鍵所在。”鄧為說,執行層維持實際業務的運轉,管理層傾向于操控項目的概念和方案來維持績效,“決策一旦發生錯誤,最終復盤問責卻不會對管理層形成威脅,因為管理層不僅掌握人事權,也具有解釋權,結果最后故障出現后,關鍵技術人員往往是首先被追責的人,然后形成惡性循環?!?/p>
二、技術歸咎,架構設計和運維制度欠考量
當然,多次宕機事件背后,仍然有技術問題。
詳看阿里云此前公布的問題報告——AK在讀取白名單數據時出現讀取異常,因處理讀取異常的代碼存在邏輯缺陷,生成了一份不完整的白名單,導致不在此白名單中的有效請求失敗,影響云產品控制臺及管控API服務出現異常,同時部分依賴AK服務的產品因不完整的白名單出現部分服務而運行異常。
如何理解?“AK是一個服務功能,是構成阿里云平臺的基礎?!蓖舯笳J為,下層服務的服務能力類似于中臺,可以為上層服務提供數據庫、存儲等功能,但會導致下層“變重”,即架構變得冗余和復雜,“當架構中的設計邏輯不清楚時,極容易出現問題,這對上層來說亦是災難。該企業頻繁發生故障,或因架構過于集中?!?/p>
再來看滴滴事故,官方宣稱是“底層系統發生故障”。據有關媒體報道,造成此次事故的原因是由升級K8S集群導致,即本應升級到1.12,但升級到了1.20,協議不兼容而引發連鎖反應。“這個問題則應該是運維制度管理欠缺考量,在操作過程中并未考慮災難發生的可能?!蓖舯蟊硎?。
大大小小的宕機事件讓人產生此類事故是否無法避免的疑問。
據《北京日報》報道,無論是本地計算還是云計算,互聯網的服務數據終究要流向數據中心,匯集到幾個中心節點,這種物理屬性決定了數據中心無法規避外界因素,也就無法做到永不宕機,而企業的安全冗余和災備能力受“投入產出比”影響,也不可能無限進行備份。
“企業多數的規章制度多‘脫胎’于日常的經驗教訓,從這些事件中,我們能獲得的啟發是,一方面要健全運維制度,另一方面是強化操作流程,從中總結經驗。”汪斌說道。
為我投票
我在參加人人都是產品經理2023年度評選,希望喜歡我的文章的朋友都能來支持我一下~
點擊下方鏈接進入我的個人參選頁面,點擊紅心即可為我投票。
每人每天最多可投30票,投票即可獲得抽獎機會,抽取書籍、人人都是產品經理紀念周邊&起點課堂會員等好禮哦!
投票傳送門:https://996.pm/YNxy4
作者:孫永會,編輯:郝俊慧,孫妍
來源公眾號:IT時報(ID:vittimes),做報紙,也懂互聯網。
本文由人人都是產品經理合作媒體 @IT時報 授權發布,未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!