前不久，國際數(shù)據(jù)公司 IDC 發(fā)布了《中國公有云服務市場（2023 上半年）跟蹤》報告。該報告顯示，2023 年上半年中國公有云服務整體市場規(guī)模（IaaS/PaaS/SaaS）為 190.1 億美元。其中，IaaS（基礎設施即服務）市場規(guī)模為 112.9 億美元，同比增速 13.2%；PaaS（平臺即服務）市場規(guī)模為 32.9 億美元，同比增速為 26.3%。

伴隨著 AIGC 技術的崛起，云計算市場增長迅速。但另一方面我們也不得不注意到，最近半年來互聯(lián)網(wǎng)基礎設施宕機事件頻發(fā)，服務器這個曾經(jīng)被我們視為堅不可摧的巨人，如今卻倒在了自己的重量之下。它的宕機，像一座大山瞬間崩塌，帶來的震動與影響遠遠超出了人們的想象。

當宕機事件發(fā)生，我們就猶如被困在了一座孤島上，只能眼睜睜地看著外面的世界在不斷運轉(zhuǎn)，這些曾經(jīng)熟悉的工具都變得遙不可及，也給客戶帶來了無盡的失望和不滿。

最后，我們開始反思這一切的根源。是什么導致了這場技術災難？是技術不夠先進，還是管理存在問題？是對風險的評估有誤，還是對備份方案的準備不足？

本文總結(jié)了近半年來的云宕機事故，以期能沉淀出更加清醒的認知，降低類似事件發(fā)生的頻率。

12 月 3 日晚，騰訊視頻出現(xiàn)網(wǎng)絡故障，有網(wǎng)友反饋出現(xiàn)首頁無法加載內(nèi)容、VIP 用戶看不了會員視頻等情況。稍晚些時候，@騰訊視頻就“App 崩了”發(fā)布致歉聲明：

除了騰訊視頻，近期遭遇宕機事件的還有滴滴、語雀、Boss、釘釘、淘寶、閑魚盤等多個 App。

阿里云一個月內(nèi)崩完了再崩

11 月 27 日，阿里云服務器遭遇了近兩小時的中斷，影響到中國和美國的客戶，這是該業(yè)務一個月內(nèi)第二次宕機。

隨后，11 月 28 日，阿里云在網(wǎng)站上發(fā)布的聲明中表示，北京時間 2023 年 11 月 27 日 09 時 16 分起，阿里云監(jiān)控檢測到資料庫產(chǎn)品的控制臺和 OpenAPI 訪問異常，稱問題已于當天 10 點 58 分解決。

受到此次事件影響的主要是北京、上海、杭州、深圳、青島、香港以及美東、美西等多個地區(qū)的數(shù)據(jù)庫產(chǎn)品，包括 PostgreSQL、Redis 和 MySQL 等。

而類似的事故，在雙十一剛過的第二天，也就是 11 月 12 日剛剛發(fā)生過。

11 月 12 日，阿里云發(fā)生了宕機，旗下的釘釘、淘寶、閑魚等產(chǎn)品皆受到了不同程度的影響，此次事故還影響到了使用阿里云的一些企業(yè)級客戶，受影響地區(qū)從東亞和東南亞，覆蓋到了中東和北美。經(jīng)過數(shù)小時的修復后，服務恢復正常。

有人猜測，阿里云 11 月 27 日的宕機甚至可能造成了滴滴出行 App 崩了一夜，但業(yè)內(nèi)人士認為這種情況概率比較低。

滴滴崩了一夜

11 月 27 日深夜，上海、北京、廣州等多地滴滴用戶反饋，滴滴出行 App 無法使用，顯示網(wǎng)絡異常，地圖無法加載，用戶無法使用定位功能且無法打車。

“滴滴崩了”的話題也登上微博熱搜。熱搜話題下不少用戶發(fā)帖表達自己在使用滴滴 App 過程中遇到的“離譜”問題。

有用戶反饋雖然打到了車，但同時來了好幾輛車，有的用戶遇到來了三輛、有用戶遇到來了四輛車，無法取消，無法聯(lián)系客服。

從各平臺上的反饋來看，此次滴滴平臺在接單、定位、計費等環(huán)節(jié)上都出現(xiàn)了問題。

有網(wǎng)約車司機表示，昨晚 App 崩潰時剛好在接單，“從晚上 10 點 20 分開始什么都做不了，客服電話也進不了線。目前恢復了少部分功能，但不能正常使用，很多錯單亂單，還出現(xiàn)了多位司機接同一單的現(xiàn)象。”

27 日深夜，滴滴出行對滴滴 App 服務出現(xiàn)異常進行了回復，滴滴出行稱：非常抱歉，由于系統(tǒng)故障，今天晚間滴滴 App 服務出現(xiàn)異常，技術目前正陸續(xù)恢復中。由此給廣大用戶和司機師傅們造成不便，再次向大家致歉。

經(jīng)過一夜維修，滴滴在 28 日早上 7:31 分做出回應稱“滴滴網(wǎng)約車等服務已恢復”。

語雀突發(fā) P0 級事故，宕機 8 小時

10 月 23 日 14 時左右，在程序員節(jié)的前一天，螞蟻集團旗下的在線文檔編輯與協(xié)同工具語雀發(fā)生服務器故障，在線文檔和官網(wǎng)目前均無法打開。當日 15 時，語雀發(fā)布官方聲明稱，“目前因網(wǎng)絡故障，出現(xiàn)無法訪問的情況。此故障不會影響用戶在語雀存儲的數(shù)據(jù)，不會引起數(shù)據(jù)丟失，我們正在緊急恢復中，再次抱歉給你帶來的損失。”

隨后，“語雀崩了”登上話題熱搜，有網(wǎng)友表示自己的公司項目文檔都在語雀上，文檔打不開嚴重影響工作進度；有網(wǎng)友將自己整理的面試題放在了語雀上，宕機時正好趕上電話面試，想查答案都無從下手；也有網(wǎng)友對語雀的運維提出質(zhì)疑，認為“長時間的故障明顯是存儲出現(xiàn)了問題，用戶數(shù)據(jù)可能丟失了，在緊急恢復”。

從故障發(fā)生到完全恢復正常，語雀整個宕機時間將近 8 小時，如此長時間的宕機已經(jīng)達到了 P0 級事故，并在網(wǎng)絡上引發(fā)巨大討論。

肯德基 App 崩了，13 元買五人餐

11 月 14 日，“肯德基 App 崩了”沖上微博熱搜第一。有網(wǎng)友爆料稱，肯德基 App 崩潰期間，還出現(xiàn)了大 Bug，14.9 元 +139 元的套餐同時加入購物車，領取“-10 的優(yōu)惠券”，再把那個雙人餐退掉，就可以 13 元買五人餐。

當日晚些時候，肯德基官方客服表示，剛才系統(tǒng)確實崩潰了，但目前已經(jīng)修復完成，用戶可以重新登錄使用。

月活用戶超 4000 萬，BOSS 崩了

9 月 15 日，據(jù)媒體報道，在線招聘 App BOSS 直聘崩了。當天 11 時前后，許多用戶涌入“BOSS 直聘”官微的最新博文中留言，抱怨無法刷新頁面，發(fā)信息也發(fā)不出去，給客服反饋也沒有任何回應。

有網(wǎng)友透露，這已經(jīng)是 BOSS 直聘今年第三次出現(xiàn)網(wǎng)絡崩潰。隨后網(wǎng)絡上流傳一張截圖顯示：9 月 15 日 10 點 15 分 26 秒，在線統(tǒng)計超過 4700 萬人在刷 BOSS 直聘，導致服務器超荷載，正努力維護中。隨后 BOSS 直聘官博辟謠，稱服務器崩了是真的，網(wǎng)傳數(shù)據(jù)是假的，BOSS 直聘月活為 4360 萬人。

不僅是國內(nèi)，國外的互聯(lián)網(wǎng)大廠內(nèi)也頻頻出現(xiàn)宕機事件，ChatGPT 多次出現(xiàn)了服務器崩潰。

探究大廠 App 排隊宕機背后的真相  

在互聯(lián)網(wǎng)大廠的 App 頻繁出現(xiàn)宕機后，一眾網(wǎng)友將宕機背后的原因歸結(jié)為裁員、降本增效等行為，以此來諷刺互聯(lián)網(wǎng)大廠缺乏穩(wěn)定性的系統(tǒng)服務，但這真的是事件背后的真相嗎？

我們特別邀請了云器科技聯(lián)合創(chuàng)始人兼 CTO 關濤、貝聯(lián)珠貫合伙人王元良、趣丸科技技術保障部負責人劉亞丹，圍繞“穩(wěn)定性出了大問題，是降本增效的鍋？”相關話題展開討論。

降本會帶來哪些問題？

在全球降本增效的大環(huán)境下，在一定程度上降低成本成為了所有公司的普遍共識，也是一種顯而易見的大趨勢，那么降本會帶來哪些問題呢？

趣丸科技技術保障部負責人劉亞丹認為：降本主要涉及兩個維度——砍人和砍資源，而不同緯度則會帶來不同的問題。

在砍人的維度上，可能會出現(xiàn)以下問題：

• 測試不充分：由于人員減少，測試可能無法覆蓋到所有的情況，導致上線出現(xiàn)問題；
• 開發(fā)人員不足：開發(fā)人員減少可能導致項目延遲，影響整體進度；

• 上線驗收不完整：由于人手不足，上線后的驗收可能不夠嚴格，存在潛在問題；

如果資源被砍，則可能會出現(xiàn)以下問題：

• 容量不足：預估的用戶量超過實際承載能力，導致系統(tǒng)崩潰或性能下降；

• 配置問題：上線后需要配置驗收，但由于資源減少，可能存在配置不當?shù)那闆r。

穩(wěn)定性問題到底是不是降本造成的？

那么，是不是不降本，就能保證穩(wěn)定性了？云器科技聯(lián)合創(chuàng)始人兼 CTO 關濤認為，穩(wěn)定性的危機一直存在，雖然我們能夠察覺到一些故障，但未顯露的潛在問題更為龐大，顯露出的問題只是冰山一角。即便選擇不走“降本”的路徑，穩(wěn)定性問題仍然存在。

只是，如果選擇了降低成本，那么就要在保證穩(wěn)定性的前提下進行成本優(yōu)化，這就需要在事前進行詳細評估，事中制定相應的預案并進行演練，然后在確保這些工作完成后，再考慮進行降本操作。

比如在進行降本操作前，需要對目標進行詳細的評估，思考能否成功節(jié)省 80% 的成本，或者是否可以先推高 5% 的 Cluster。還需要假設系統(tǒng)的任何一個部分都可能發(fā)生故障，并制定相應的預案。例如，如果資源調(diào)度模塊出現(xiàn)故障，應如何恢復等，這些都需要提前考慮清楚。

誰是穩(wěn)定性第一責任人？宕機了誰該背鍋？

盡管考慮到了種種可能出現(xiàn)的問題，但系統(tǒng)在運行時到底會發(fā)生什么突發(fā)意外卻是未知的，一旦出現(xiàn)了問題，該有誰來負責？

就此問題，王元良表示，從首席執(zhí)行官（CEO）的角度來說，穩(wěn)定性是 CTO 的責任。

如果 CTO 重視穩(wěn)定性的問題，這將會對整個企業(yè)產(chǎn)生影響，包括內(nèi)部的各個層面。管理者可以將自己的理念、血液或者說靈魂注入整個組織，并且大多數(shù)公司面對故障時都應該去思考如何改進，而不是追責。

關濤則稱，“的確應該由公司一號位來負責，但比起對事故負責，對發(fā)生的故障進行復盤更為重要。”

“第一責任人應該位于公司的首位，這并非是要完全推卸責任，而是在一般情況下確實存在資源投入比例的問題。

 

也就是說，公司需要在穩(wěn)定性、業(yè)務開發(fā)以及技術底座沉淀上進行資源投入，而這個投入的比例不同確實會影響整個公司的發(fā)展方向。

 

因此，從這個角度來看，如果一定要明確個第一責任人，那一定是公司的一號位。”

此外，就如何拆分穩(wěn)定性的問題關濤也給出了他的方法論。他表示，首先，要區(qū)分研發(fā)和運維的責任。明確這個故障究竟是研發(fā)的問題還是運維的問題。其次，要明確到底是誰負責解決問題。

在云器科技，如果將故障分成 P1、P2、P3、P4，最底層 P4 是最不嚴重的故障，最不嚴重的故障會交給一線的研發(fā)同學來解決。也就是說，如果故障真的是研發(fā)的 Bug 或者 SRE 操作失誤，那么這個責任就在最底層。P3 層交給一線的 Leader，到了三級可能就不再是某一個程序人員的責任，而是一線 Leader 的責任。

之所以造成此類故障，可能是故障發(fā)生之前沒有做好事前預判，故障中也沒有抓住穩(wěn)定性問題，事后缺乏兜底措施，演練不夠，爆炸半徑控制不夠等一系列問題。P1、P2 的故障就需要 TO（Technical Owner）來負責，也就是當更大的故障發(fā)生時，說明在機制、防范措施以及整個公司資源調(diào)配方面沒有做好，包括 SRE 和研發(fā)的協(xié)同層面。

因此，在云器科技內(nèi)部，采用的是這種模式來看待故障。關濤表示，目前來看，這種模式運行狀況還不錯，也沒有出現(xiàn)特別大的問題，可以為行業(yè)提供一些參考。

同時，關濤也表示，這種波動性在公司的運營中是很常見的。有時候，公司可能會因為對系統(tǒng)穩(wěn)定性的過度自信或者資源限制等原因，而沒有對系統(tǒng)進行適當?shù)臄U展或者備份。然而，當系統(tǒng)遇到超出預期的流量或者負載時，就可能出現(xiàn)故障。

這種經(jīng)驗通常是非常寶貴的。在事后分析中，公司可以更深入地了解故障的原因，包括系統(tǒng)瓶頸、潛在的容量不足以及其他可能的問題。這些信息可以用來改進系統(tǒng)的設計和運營策略，以增強系統(tǒng)的穩(wěn)定性和性能。

小結(jié)：降本勢在必行，但我們要“健康”降本

以目前企業(yè)總體經(jīng)營狀況來看，降本在一段時間內(nèi)仍是一個勢在必行的方向，但更重要的是要實現(xiàn)“健康”降本。這里的“健康”降本是指在企業(yè)進行降本的過程中，不能以犧牲系統(tǒng)的穩(wěn)定性和性能為代價。

在實現(xiàn)“健康”降本時，一些關鍵的考慮因素必須要提前考慮清楚：

首先，是合理規(guī)劃。在降本之前，需要進行全面的規(guī)劃和評估。這包括對當前系統(tǒng)的穩(wěn)定性、性能和容量進行深入的分析，以及評估所需的資源和預算。

王元良認為，在數(shù)字化領域，能力、成本、人力和硬件等因素都至關重要。然而，對于許多企業(yè)來說，尤其是那些大型傳統(tǒng)企業(yè)，他們往往無法清晰地呈現(xiàn)成本。盡管這些企業(yè)擁有強大的流程功能，但他們無法明確說明每個部門使用了哪些成本以及云服務的具體部分，這使得他們難以做出明智的決策。

為了解決這個問題，最首要做的就是清晰地了解賬單。然而，目前看來，從首席執(zhí)行官到單個使用節(jié)點的整個評估過程尚未完全打通。這不僅影響了企業(yè)的決策過程，也阻礙了他們優(yōu)化運營成本的能力。因此，建立一個完善的評估體系，使得從首席執(zhí)行官到單個使用節(jié)點的所有層面都能明確自己的成本和責任，是非常必要的。

隨著數(shù)字化和信息化程度的提高，IT 成本、硬件人力成本以及一些運維手段成本逐年增加。特別是隨著大語言模型的推出，這種趨勢對企業(yè)的運營產(chǎn)生了深遠的影響。因此，將成本可視化并建立完善的評估體系可能是未來企業(yè)的必然選擇。

其次，是充分了解風險。我們需要有一個成本決策中心，將財務、研發(fā)、運維和產(chǎn)品的資源管理方案整合在一起，然后設立一個機制，在這個機制中對過去發(fā)生的花費以及未來可能采取的技術手段、優(yōu)化等方面達成共識。

劉亞丹強調(diào)說，共識不僅僅是關于省下多少錢，其背后省下的錢所帶來的風險也是大家需要了解的。

再次，以創(chuàng)新技術代替粗暴地亂砍項目。關濤認為：穩(wěn)定性是健康的 FinOps（降本增效）的前提，不穩(wěn)定的 FinOps 是危險的，甚至可能是致命的。

FinOps 不僅僅是砍成本，很多 FinOps 是靠技術手段去解決。就比如說調(diào)度系統(tǒng)的混部技術，是用技術手段高效率地實現(xiàn)在線和離線的混合使用，同時做到成本最低。它更多的是一個技術問題，而不是砍人或者砍項目的問題