阿里云發(fā)布香港可用區C服務(wù)中斷事件說(shuō)明，稱(chēng)將盡快處理賠償事宜

12月25日，阿里云發(fā)布香港Region可用區C服務(wù)中斷事件說(shuō)明，并向所有受到故障影響的客戶(hù)公開(kāi)致歉，稱(chēng)將盡快處理賠償事宜。阿里云表示，將盡一切努力從此次事件中吸取經(jīng)驗教訓，持續提升云服務(wù)的穩定性。在說(shuō)明中，阿里云公布了本次事件的故障情況、問(wèn)題分析和改進(jìn)措施，具體如下：

處理過(guò)程 

12月18日08:56，阿里云監控到香港Region可用區C機房包間通道溫控告警，阿里云工程師介入應急處理，通知機房服務(wù)商進(jìn)行現場(chǎng)排查。09:01，阿里云監控到該機房多個(gè)包間溫升告警，此時(shí)工程師排查到冷機異常。09:09，機房服務(wù)商按應急預案對異常冷機進(jìn)行4+4主備切換以及重啟，但操作失敗，冷水機組無(wú)法恢復正常。09:17，依照故障處理流程，啟動(dòng)制冷異常應急預案，進(jìn)行輔助散熱和應急通風(fēng)。嘗試對冷機控制系統逐個(gè)進(jìn)行隔離和手工恢復操作，但發(fā)現無(wú)法穩定運行，聯(lián)系冷機設備供應商到現場(chǎng)排查。此時(shí)，由于高溫原因，部分服務(wù)器開(kāi)始受到影響。

自10:30開(kāi)始，為避免可能出現的高溫消防問(wèn)題，阿里云工程師陸續對整個(gè)機房計算、存儲、網(wǎng)絡(luò )、數據庫、大數據集群進(jìn)行降載處理。期間，繼續多次對冷機設備進(jìn)行操作，但均不能保持穩定運行。

12:30，冷機設備供應商到場(chǎng)，在多方工程師診斷下，對冷塔、冷卻水管路及冷機冷凝器進(jìn)行手工補水排氣操作，但系統仍然無(wú)法保持穩定運行。阿里云工程師對部分高溫包間啟動(dòng)服務(wù)器關(guān)機操作。14:47，冷機設備供應商對設備問(wèn)題排查遇到困難，其中一個(gè)包間因高溫觸發(fā)了強制消防噴淋。15:20，經(jīng)冷機設備商工程師現場(chǎng)手工調整配置，冷機群控解鎖完成并獨立運行，第1臺冷機恢復正常，溫度開(kāi)始下降。工程師隨后繼續通過(guò)相同方法對其他冷機進(jìn)行操作。18:55，4臺冷機恢復到正常制冷量。19:02，分批啟動(dòng)服務(wù)器，并持續觀(guān)察溫升情況。19:47，機房溫度趨于穩定。同時(shí)，阿里云工程師開(kāi)始進(jìn)行服務(wù)啟動(dòng)恢復，并進(jìn)行必要的數據完整性檢查。

21:36，大部分機房包間服務(wù)器陸續啟動(dòng)并完成檢查，機房溫度穩定。其中一個(gè)包間因消防噴淋啟動(dòng)，未進(jìn)行服務(wù)器上電。因為保持數據的完整性至關(guān)重要，工程師對這個(gè)包間的服務(wù)器進(jìn)行了仔細的數據安全檢查，這里花費了一些必要的時(shí)間。22:50，數據檢查以及風(fēng)險評估完成，最后一個(gè)包間依據安全性逐步進(jìn)行供電恢復和服務(wù)器啟動(dòng)。

服務(wù)影響

12月18日09:23，香港Region可用區C部分ECS服務(wù)器開(kāi)始出現停機，觸發(fā)同可用區內宕機遷移。隨著(zhù)溫度繼續升高，受影響的服務(wù)器停機數量持續增加，客戶(hù)業(yè)務(wù)開(kāi)始受到影響，影響面擴大到香港可用區C的EBS、OSS、RDS等更多云服務(wù)。

阿里云香港可用區C的故障，沒(méi)有直接影響客戶(hù)在香港其他可用區運行的業(yè)務(wù)，但影響了香港Region ECS管控服務(wù)（Control Plane）的正常使用。因大量可用區C的客戶(hù)在香港其他可用區新購ECS實(shí)例，從12月18日14:49開(kāi)始，ECS管控服務(wù)觸發(fā)限流，可用性最低跌至20%?？蛻?hù)在使用RunInstances/CreateInstance API購買(mǎi)新ECS實(shí)例時(shí)，如果指定了自定義鏡像，部分實(shí)例在購買(mǎi)成功之后會(huì )出現啟動(dòng)失敗的現象，由于自定義鏡像數據服務(wù)依賴(lài)可用區C的單AZ冗余版本的OSS服務(wù)，無(wú)法通過(guò)重試解決。此時(shí)，部分Dataworks、k8s用戶(hù)控制臺操作也受到了故障影響。API完全恢復可用為當日23:11。

12月18日10:37，阿里云香港可用區C的部分存儲服務(wù)OSS開(kāi)始受到停機影響，此時(shí)客戶(hù)暫不會(huì )感知，但持續高溫會(huì )導致磁盤(pán)壞道，影響數據安全，工程師對服務(wù)器進(jìn)行停機操作，從11:07至18:26中斷了服務(wù)。阿里云在香港Region可用區C提供了2種類(lèi)型的OSS服務(wù)，一種是OSS本地冗余LRS服務(wù)（通常叫單AZ冗余服務(wù)），僅部署在可用區C；另一種是OSS同城冗余ZRS服務(wù)（通常叫3AZ冗余服務(wù)），部署在可用區B、C和D。在此次故障中，OSS同城冗余ZRS服務(wù)基本沒(méi)有受到影響?？捎脜^C的OSS本地冗余服務(wù)中斷時(shí)間較長(cháng)，因不支持跨可用區切換，需要依賴(lài)故障機房的恢復。從18:26開(kāi)始，存儲服務(wù)器重新分批啟動(dòng)。其中，單AZ本地冗余LRS服務(wù)有部分服務(wù)器因消防問(wèn)題需要做隔離處理?；謴头?wù)前，我們必須要確保數據可靠性，花費了較多的時(shí)間進(jìn)行完整性檢驗工作。直至12月19日00:30，這部分OSS服務(wù)（單AZ冗余服務(wù)）才恢復了對外服務(wù)能力。

阿里云網(wǎng)絡(luò )少量單可用區產(chǎn)品（如：VPN、Privatelink以及少量GA實(shí)例）在此次故障中受到影響。12月18日11:21，工程師啟動(dòng)網(wǎng)絡(luò )產(chǎn)品可用區容災逃逸，12:45完成SLB等大部分網(wǎng)絡(luò )產(chǎn)品可用區容災逃逸，13:47NAT產(chǎn)品完成收尾逃逸。除上述少量單可用區產(chǎn)品以外，各網(wǎng)絡(luò )產(chǎn)品在故障期間保持了業(yè)務(wù)連續性，NAT有分鐘級業(yè)務(wù)受損。

12月18日10:17開(kāi)始，阿里云香港Region可用區C部分RDS實(shí)例出現不可用的報警。隨著(zhù)該可用區受故障影響的主機范圍擴大，出現服務(wù)異常的實(shí)例數量隨之增加，工程師啟動(dòng)數據庫應急切換預案流程。截至12:30，RDS MySQL與Redis、MongoDB、DTS等跨可用區實(shí)例完成跨可用區切換。部分單可用區實(shí)例以及單可用區高可用實(shí)例，由于依賴(lài)單可用區的數據備份，僅少量實(shí)例實(shí)現有效遷移。少量支持跨可用區切換的RDS實(shí)例沒(méi)有及時(shí)完成切換。經(jīng)排查是由于這部分RDS實(shí)例依賴(lài)了部署在香港Region可用區C的代理服務(wù)，由于代理服務(wù)不可用，無(wú)法通過(guò)代理地址訪(fǎng)問(wèn)RDS實(shí)例。我們協(xié)助相關(guān)客戶(hù)通過(guò)臨時(shí)切換到使用RDS主實(shí)例的地址訪(fǎng)問(wèn)來(lái)進(jìn)行恢復。隨著(zhù)機房制冷設備恢復，21:30左右絕大部分數據庫實(shí)例恢復正常。對于受故障影響的單機版實(shí)例及主備均在香港Region可用區C的高可用版實(shí)例，我們提供了克隆實(shí)例、實(shí)例遷移等臨時(shí)性恢復方案，但由于底層服務(wù)資源的限制，部分實(shí)例的遷移恢復過(guò)程遇到一些異常情況，需要花費較長(cháng)的時(shí)間來(lái)處理解決。

我們注意到，同時(shí)在多個(gè)可用區運行業(yè)務(wù)的客戶(hù)，在這次事件中依然可以維持業(yè)務(wù)運行。對于業(yè)務(wù)需要絕對高可用的客戶(hù)，我們持續建議您采用全鏈路多可用區的業(yè)務(wù)架構設計，以應對各種可能的意外事件。

問(wèn)題分析與改進(jìn)措施

1、冷機系統故障恢復時(shí)間過(guò)長(cháng)  

原因分析：機房冷卻系統缺水進(jìn)氣形成氣阻，影響水路循環(huán)導致4臺主冷機服務(wù)異常，啟動(dòng)4臺備冷機時(shí)因主備共用的水路循環(huán)系統氣阻導致啟動(dòng)失敗。水盤(pán)補水后，因機房冷卻系統的群控邏輯，無(wú)法單臺獨立啟動(dòng)冷機，手工修改冷機配置，將冷機從群控調整為獨立運行后，陸續啟動(dòng)冷機，影響了冷卻系統的恢復時(shí)長(cháng)。整個(gè)過(guò)程中，原因定位耗時(shí)3小時(shí)34分鐘，補水排氣耗時(shí)2小時(shí)57分鐘，解鎖群控邏輯啟動(dòng)4臺冷機耗時(shí)3小時(shí)32分鐘。

改進(jìn)措施：全面檢查機房基礎設施管控系統，在監控數據采集層面，擴大覆蓋度，提升精細度，提高對故障的排查和定位速度；在設施管控邏輯層面，確保系統自動(dòng)切換邏輯符合預期，同時(shí)保證手工切換的準確性，防止內部狀態(tài)死鎖從而影響故障的恢復。

2、現場(chǎng)處置不及時(shí)導致觸發(fā)消防噴淋  

原因分析：隨著(zhù)機房冷卻系統失效，包間溫度逐漸升高，導致一機房包間溫度達到臨界值觸發(fā)消防系統噴淋，電源柜和多列機柜進(jìn)水，部分機器硬件損壞，增加了后續恢復難度和時(shí)長(cháng)。

改進(jìn)措施：加強機房服務(wù)商管理，梳理機房溫升預案及標準化執行動(dòng)作，明確溫升場(chǎng)景下的業(yè)務(wù)側關(guān)機和機房強制關(guān)電的預案，力求更簡(jiǎn)單有效，并通過(guò)常態(tài)化演練強化執行。

3、客戶(hù)在香港地域新購ECS等管控操作失敗  

原因分析：ECS管控系統為B、C可用區雙機房容災，C可用區故障后由B可用區對外提供服務(wù)，由于大量可用區C的客戶(hù)在香港其他可用區新購實(shí)例，同時(shí)可用區C的ECS實(shí)例拉起恢復動(dòng)作引入的流量，導致可用區 B 管控服務(wù)資源不足。新擴容的ECS管控系統啟動(dòng)時(shí)依賴(lài)的中間件服務(wù)部署在可用區C機房，導致較長(cháng)時(shí)間內無(wú)法擴容。ECS管控依賴(lài)的自定義鏡像數據服務(wù)，依賴(lài)可用區C的單AZ冗余版本的OSS服務(wù)，導致客戶(hù)新購實(shí)例后出現啟動(dòng)失敗的現象。

改進(jìn)措施：全網(wǎng)巡檢，整體優(yōu)化多AZ產(chǎn)品高可用設計，避免出現依賴(lài)OSS單AZ和中間件單AZ的問(wèn)題。加強阿里云管控平面的容災演練，進(jìn)一步提升云產(chǎn)品高可用容災逃逸能力。

4、故障信息發(fā)布不夠及時(shí)透明  

原因分析：故障發(fā)生后阿里云啟動(dòng)對客釘群、公告等通知手段，由于現場(chǎng)冷機處理進(jìn)展緩慢，有效信息不夠。Status Page頁(yè)面信息更新不及時(shí)引發(fā)客戶(hù)困惑。

改進(jìn)措施：提升故障影響和客戶(hù)影響的快速評估和識別拉取能力。盡快上線(xiàn)新版的阿里云服務(wù)健康狀態(tài)頁(yè)面（Status Page），提高信息發(fā)布的速度，讓客戶(hù)可以更便捷地了解故障事件對各類(lèi)產(chǎn)品服務(wù)的影響。