昨天下午，2024年04月08日，騰訊雲出現了一場全球性的大故障，用騰訊雲官方的說法，崩了74分鐘（15:31–16:45），波及全球17個區域與數十款服務。
事實影響是什麼
但這與我觀察到的事實不符——從故障範圍上來說，這次的故障幾乎是去年阿里雲雙十一史詩級大故障的翻版——小道消息是整個管控面 GG，雲 API掛了，所以現象與去年阿里雲如出一轍：依賴雲 API的雲產品控制台不能用了。
被管控的純資源，如雲伺服器 CVM，雲資料庫 RDS，設置了公開讀寫訪問對象存儲 COS不受影響可以繼續使用。然而依賴認證與API的各種雲 PaaS服務，例如標準的私有讀寫的對象存儲 COS，就抓瞎了。
因為阿里雲至今沒有做一個像樣的事後故障復盤，因此在《我們能從阿里雲史詩級故障中學到什麼》中，我為阿里雲的這次故障做了非官方的技術復盤。同樣的判斷邏輯完全也適用於這次故障——這樣的爆炸半徑，根因出在 Auth上的概率很大。目前，騰訊雲仍然沒有給出官方的事後故障復盤報告，也可能不會有了。
忽悠人的狀態頁
我的朋友楊攀曾寫過一篇《中國雲服務走向全球？先把 Status Page搞定》，討論了 Status Page（服務健康狀態頁）對於公有雲服務的重要性，各家本土雲廠商也跟進了這一特性，包括騰訊雲。——狀態頁能在服務宕機的情況下有效減少客戶的焦慮，降低溝通成本，但它的核心價值在於「建立與客戶的信任關係」。
看上去，騰訊雲與阿里雲的 Status Page反應都比較遲緩，在故障發生後三四十分鐘才開始更新。而不是像 Cloudflare等產品一樣及時更新故障，或採用自動化方式監測到故障後立即推送。但不同於阿里雲——雖慢卻誠實地標記了所有服務受到影響，騰訊雲的 Status Page連基本的真實性與準確性都堪稱稀爛。
例如，受到影響的對象存儲 COS服務，在有用戶上報問題的幾個可用區中，我並沒有看到 Status標紅。而這樣的例子還有更多。事實上如果問題真出在管控 API上，那麼影響的範圍應該和阿里雲一樣——所有服務的控制面。因此，這樣雞賊的做法只會給客戶留下：「不透明、有貓膩「的負面印象。
撒謊的三無公告
在故障出現40～50分鐘後，騰訊雲終於發出了第一份故障公告，也是截止到目前 Status Page上唯一一份公告。但其內容就一句話——三無公告：無時間（故障時間），無地點（可用區/AZ），無範圍（影響服務）。而且姍姍來遲，比我替它發的公告《【騰訊】雲端運算史詩級二翻車來了》還晚了十分鐘。
但這份公告最致命的問題是真實性與準確性：首先，故障絕對不僅僅是「控制台」，而是整個控制面。作為一個專業的雲端運算服務供應商，一字之差天壤之別，混淆兩者區別的原因，要麼是蠢（缺乏專業素養，台面混為一談）。要麼是壞（避重就輕，推卸責任）。
請問，一個全身休克的人，說他「面色異常」，這是一個真誠的回覆嗎？請問，一台被砸爛的筆記型電腦，說它「敲擊鍵盤沒有反應」是一個有意義的描述嗎？同理，一個控制面爆炸的公有雲，說自己「控制台異常」，是一個認真的回覆嗎？
其次，從事後官微的發布與用戶群的反饋來看，在這個時間，「目前故障已恢復」是在撒謊。至少相當一部分服務的可用性事件是在16:45標記恢復的，在17點前後，騰訊雲產品吐槽群中也仍然有一些問題上報。
我認為這份對騰訊雲帶來的傷害遠比服務宕機要大的多——首先，在及時性，準確性上體現出了極差的專業素養。其次，在真實性上有意做手腳，會傷及公有雲，或者說一切生意的根本——誠信。這對品牌形象是一個摧毀性打擊。
災難級別的公關
按理說，出現了這麼嚴重的故障，應當用誠懇認真的態度去處理，但騰訊雲官方微博居然還在抖機靈——堪稱災難級別的公關水平。
這條微博也再次扇了騰訊雲自己官網公告的大嘴巴子——16:45分發第一條帖子時，「工程師仍在緊急修復中」，17:16，距離第一次報告故障的15:31已經過去近兩個小時，「已經整體恢復」。然而，根據騰訊雲官網16:21發布的公告[1]聲稱：「故障已恢復」。從實際情況來看，再次證明了官網公告在說謊。
阿里雲雙十一大故障的時候，剛剛開完雲棲大會，打臉了吹下的極致高可用的牛逼，但畢竟隔了一周了。而騰訊雲這次大故障的同時還在開發布會吹牛逼，還找特大號發了一篇軟文：《太意外了！國內80%大模型都存在鵝廠！》，發布時間16:19，2分鐘後官網發出故障通告，堪稱光速打臉二次方。
與之形成鮮明對照的是，去年11月 Cloudflare的故障，Cloudflare CEO Matthew親自出來對故障進行道歉與復盤，相比之下，國內雲廠商的危機公關堪稱災難級別——徹底做實了草台班子的稱號。
實錘的草台班子
請允許我引用瑞典馬工的一句名言：「阿里雲是個工程質量差勁的正經雲，但騰訊雲是一群業餘銷售加業務碼農玩遊戲」。所謂光鮮亮麗的大廠，在裡面也不過是一個又一個的草台班子。
