騰訊雲4月8日故障覆盤及情況說明

首頁 > 科技

騰訊雲4月8日故障覆盤及情況說明

來源:龍貓 釋出時間:2024-04-14 11:54

騰訊雲4月8日故障覆盤及情況說明

4月

8日15點23分,騰訊雲團隊收到告警資訊,雲API服務處於異常狀態;隨即在騰訊雲工單、售後服務群以及微博等渠道開始大量出現騰訊雲控制檯登入不上的

客戶

反饋。

經過故障定位發現,客戶登入不上控制檯正是由雲API異常所導致。雲API是雲上統一的開放介面集合,客戶可以透過API以程式設計方式管理和操控雲端資源,雲控制檯透過組合雲API提供互動式的網頁功能。

故障發生後,依賴雲API提供產品能力的部分公有云服務,也因為雲API的異常出現了無法使用的情況,比如雲函式、文字識別、微服務平臺、音訊內容安全、驗證碼等。此次故障一共持續了近87分鐘,期間共有1957個客戶報障。

 

從客戶的視角來看,雲服務大概可以分為資料面和控制面,資料面承載客戶自身的業務,控制面負責操作雲上不同產品。比如目前使用最廣泛的IaaS服務基本上都是以直接面向資料面為主,控制面僅在客戶購買或需要對資源層面進行調整操作時會涉及。此次發生故障的控制檯和雲API是對控制面的影響。

 

通俗來講,如果把雲服務類比為酒店,控制檯相當於酒店的前臺,是一個統一的服務入口。一旦酒店前臺發生故障,會導致入住、續住等管理能力不可用,但已入住的客房不受影響。

 

這次故障中客戶已經配置好的伺服器等IaaS資源,包括已經部署執行的業務,沒有受到雲API異常的影響。其他以非雲 API 方式提供服務的PaaS和SaaS服務,處於正常服務的狀態。從資料上也驗證了這一點。如圖1顯示,當天全產品進出流量趨勢沒有明顯變化。

圖 1:騰訊雲全產品進出流量趨勢圖

但是,用API提供的服務類產品(需要“酒店前臺服務“)有不同程度的影響,比如騰訊雲端儲存服務呼叫當天有明顯下

滑。期間售後團隊協助部分客戶做了業務容災預案的實施,將受影響服務做排程以快速恢復客戶的業務服務。從圖2可以看出,當天儲存服務調

用有一個明顯的波動。

圖 2:儲存服務呼叫資料趨勢圖

問題覆盤

整個處理過程如下:

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服務重啟,完成整個故障恢復。

改進措施

綜合盤點這次故障,最根本的原因是在版本變更過程中,沒有有效執行沙箱驗證和預案演練,暴露了在變更管理上的不足,接下來將從以下幾個方面快速進行改進和完善,以減少故障的影響範圍和影響時長。

 

第一,提升系統韌性

1、定期執行預定的變更策略模擬演練,確保在真實故障發生時,能夠迅速切換到恢復模式,最小化服務中斷時間。

2、最佳化服務部署架構,透過分層架構、程式碼審查和監控等手段, 避免API服務中潛在的迴圈依賴問題。

3、提供API服務逃生通道,當故障發生時,可供呼叫方快速切換。

第二,強化變更管理與保護措施

1、完善自動化測試用例庫,在系統變更前透過沙箱環境對變更內容進行嚴格驗證。

2、實施灰度釋出策略,逐步推廣新功能或配置更改,按叢集、可用區、地域逐步生效,以便在發現問題時能夠迅速回滾。

3、引入異常自動熔斷機制,當檢測到系統異常時,能夠立即中斷變更過程。

第三,增強故障響應與溝通能力

1、對故障處理流程進行全面升級,確保實時更新故障處理進度和預計恢復時間點,提升故障報告發布效率。

2、在對外發布的故障通知中,清晰闡述受影響的業務範圍、故障根因及預計修復時長,保持透明度。

3、最佳化騰訊雲健康狀態看板(StatusPage)的資訊展示邏輯,解除對雲API等雲服務的依賴,透過引入快取和容災機制,確保即使在雲服務出現故障時,能準確、及時地傳遞故障資訊。

騰訊雲4月8日故障覆盤及情況說明

4月

8日15點23分,騰訊雲團隊收到告警資訊,雲API服務處於異常狀態;隨即在騰訊雲工單、售後服務群以及微博等渠道開始大量出現騰訊雲控制檯登入不上的

客戶

反饋。

經過故障定位發現,客戶登入不上控制檯正是由雲API異常所導致。雲API是雲上統一的開放介面集合,客戶可以透過API以程式設計方式管理和操控雲端資源,雲控制檯透過組合雲API提供互動式的網頁功能。

故障發生後,依賴雲API提供產品能力的部分公有云服務,也因為雲API的異常出現了無法使用的情況,比如雲函式、文字識別、微服務平臺、音訊內容安全、驗證碼等。此次故障一共持續了近87分鐘,期間共有1957個客戶報障。

 

從客戶的視角來看,雲服務大概可以分為資料面和控制面,資料面承載客戶自身的業務,控制面負責操作雲上不同產品。比如目前使用最廣泛的IaaS服務基本上都是以直接面向資料面為主,控制面僅在客戶購買或需要對資源層面進行調整操作時會涉及。此次發生故障的控制檯和雲API是對控制面的影響。

 

通俗來講,如果把雲服務類比為酒店,控制檯相當於酒店的前臺,是一個統一的服務入口。一旦酒店前臺發生故障,會導致入住、續住等管理能力不可用,但已入住的客房不受影響。

 

這次故障中客戶已經配置好的伺服器等IaaS資源,包括已經部署執行的業務,沒有受到雲API異常的影響。其他以非雲 API 方式提供服務的PaaS和SaaS服務,處於正常服務的狀態。從資料上也驗證了這一點。如圖1顯示,當天全產品進出流量趨勢沒有明顯變化。

圖 1:騰訊雲全產品進出流量趨勢圖

騰訊雲4月8日故障覆盤及情況說明

4月

8日15點23分,騰訊雲團隊收到告警資訊,雲API服務處於異常狀態;隨即在騰訊雲工單、售後服務群以及微博等渠道開始大量出現騰訊雲控制檯登入不上的

客戶

反饋。

經過故障定位發現,客戶登入不上控制檯正是由雲API異常所導致。雲API是雲上統一的開放介面集合,客戶可以透過API以程式設計方式管理和操控雲端資源,雲控制檯透過組合雲API提供互動式的網頁功能。

故障發生後,依賴雲API提供產品能力的部分公有云服務,也因為雲API的異常出現了無法使用的情況,比如雲函式、文字識別、微服務平臺、音訊內容安全、驗證碼等。此次故障一共持續了近87分鐘,期間共有1957個客戶報障。

 

從客戶的視角來看,雲服務大概可以分為資料面和控制面,資料面承載客戶自身的業務,控制面負責操作雲上不同產品。比如目前使用最廣泛的IaaS服務基本上都是以直接面向資料面為主,控制面僅在客戶購買或需要對資源層面進行調整操作時會涉及。此次發生故障的控制檯和雲API是對控制面的影響。

 

通俗來講,如果把雲服務類比為酒店,控制檯相當於酒店的前臺,是一個統一的服務入口。一旦酒店前臺發生故障,會導致入住、續住等管理能力不可用,但已入住的客房不受影響。

 

這次故障中客戶已經配置好的伺服器等IaaS資源,包括已經部署執行的業務,沒有受到雲API異常的影響。其他以非雲 API 方式提供服務的PaaS和SaaS服務,處於正常服務的狀態。從資料上也驗證了這一點。如圖1顯示,當天全產品進出流量趨勢沒有明顯變化。

圖 1:騰訊雲全產品進出流量趨勢圖

上一篇:保“胃”健康... 下一篇:馬斯克Grok1....
猜你喜歡
熱門閱讀
同類推薦