騰訊雲發佈4月8日故障覆盤:持續近87分鐘,共有1957個客戶報障

4月14日,騰訊雲發佈4月8日故障覆盤及情況說明:4月8日15點23分,騰訊雲團隊收到告警信息,雲API服務處於異常狀態;隨即在騰訊雲工單、售後服務羣以及微博等渠道開始大量出現騰訊雲控制檯登錄不上的客戶反饋。

經過故障定位發現,客戶登錄不上控制檯正是由雲API異常所導致。故障發生後,依賴雲API提供產品能力的部分公有云服務,也因爲雲API的異常出現了無法使用的情況,比如雲函數、文字識別、微服務平臺、音頻內容安全、驗證碼等。此次故障一共持續了近87分鐘,期間共有1957個客戶報障。

問題覆盤

整個處理過程如下:

1. 15:23,監測到故障,立即執行服務的恢復,同時進行原因的排查;

2. 15:47,發現通過回滾版本沒能完全恢復服務,進一步定位問題;

3. 15:57,定位出故障根因是配置數據出現錯誤,緊急設計數據修復方案;

4. 16:02,對全地域進行數據修復工作,API服務逐地域恢復中;

5. 16:05,觀測到除上海外的地域API服務均已恢復,進一步定位上海地域的恢復問題;

6. 16:25,定位到上海的技術組件存在API循環依賴問題,決定通過流量調度至其他地域來恢復;

7. 16:45,觀測到上海地域恢復了,此時API和依賴API的PaaS服務徹底恢復,但控制檯流量劇增,按九倍容量進行了擴容;

8. 16:50,請求量逐漸恢復到正常水平,業務穩定運行,控制檯服務全部恢復;

9. 17:45,持續觀察一小時,未發現問題,按預案處理過程完畢。

故障的原因是雲API服務新版本向前兼容性考慮不夠和配置數據灰度機制不足的問題。

本次API升級過程中,由於新版本的接口協議發生了變化,在後臺發佈新版本之後對於舊版本前端傳來的數據處理邏輯異常,導致生成了一條錯誤的配置數據,由於灰度機制不足導致異常數據快速擴散到了全網地域,造成整體API使用異常。

發生故障後,按照標準回滾方案將服務後臺和配置數據同時回滾到舊版本,並重啓API後臺服務,但此時因爲承載API服務的容器平臺也依賴API服務才能提供調度能力,即發生了循環依賴,導致服務無法自動拉起。通過運維手工啓動方式才使API服務重啓,完成整個故障恢復。

騰訊雲表示,綜合盤點這次故障,最根本的原因是在版本變更過程中,沒有有效執行沙箱驗證和預案演練,暴露了在變更管理上的不足,接下來將快速進行改進和完善——包括提升系統韌性、強化變更管理與保護措施、增強故障響應與溝通能力,以減少故障的影響範圍和影響時長。