北京時間2022年12月18日，阿里(li)云香港Region可用區(qu)C發生(sheng)大(da)(da)規(gui)模服(fu)務中斷事件。經過復盤，我們(men)在這(zhe)里(li)向大(da)(da)家進一步(bu)說明故障(zhang)情(qing)況、問題分析和改進措施。
處理過程
12月(yue)18日08:56，阿里(li)云(yun)監(jian)控到(dao)(dao)香港Region可用區C機(ji)(ji)(ji)(ji)房包(bao)間通道溫控告警，阿里(li)云(yun)工(gong)(gong)程師介入(ru)應(ying)急處理(li)，通知機(ji)(ji)(ji)(ji)房服務(wu)商進(jin)(jin)行(xing)現場(chang)排查(cha)。09:01，阿里(li)云(yun)監(jian)控到(dao)(dao)該機(ji)(ji)(ji)(ji)房多(duo)個包(bao)間溫升告警，此(ci)時工(gong)(gong)程師排查(cha)到(dao)(dao)冷機(ji)(ji)(ji)(ji)異(yi)常。09:09，機(ji)(ji)(ji)(ji)房服務(wu)商按(an)應(ying)急預(yu)(yu)案(an)對(dui)異(yi)常冷機(ji)(ji)(ji)(ji)進(jin)(jin)行(xing)4+4主(zhu)備(bei)切(qie)換(huan)以及重啟，但操作失敗，冷水機(ji)(ji)(ji)(ji)組(zu)無(wu)(wu)法恢復正常。09:17，依照故障處理(li)流程，啟動制(zhi)冷異(yi)常應(ying)急預(yu)(yu)案(an)，進(jin)(jin)行(xing)輔(fu)助散熱和(he)應(ying)急通風。嘗試(shi)對(dui)冷機(ji)(ji)(ji)(ji)控制(zhi)系統逐個進(jin)(jin)行(xing)隔離和(he)手(shou)工(gong)(gong)恢復操作，但發(fa)現無(wu)(wu)法穩定運行(xing)，聯(lian)系冷機(ji)(ji)(ji)(ji)設備(bei)供應(ying)商到(dao)(dao)現場(chang)排查(cha)。此(ci)時，由于高溫原(yuan)因，部分服務(wu)器開始受到(dao)(dao)影(ying)響。
自10:30開始，為(wei)避免可能(neng)出現的高溫消防問題，阿里(li)云工程(cheng)師陸續對(dui)整個機房計算、存儲、網(wang)絡、數據(ju)庫、大數據(ju)集群進行降(jiang)載(zai)處理。期間，繼(ji)續多次對(dui)冷機設備進行操作，但均不能(neng)保持穩定運(yun)行。
12:30，冷(leng)(leng)機(ji)(ji)設備(bei)供應商到(dao)場，在多方工(gong)(gong)程(cheng)師(shi)診斷(duan)下，對(dui)(dui)冷(leng)(leng)塔、冷(leng)(leng)卻水(shui)管(guan)路及冷(leng)(leng)機(ji)(ji)冷(leng)(leng)凝器進行(xing)手(shou)工(gong)(gong)補水(shui)排氣(qi)操作，但系統仍然無法保持穩定運(yun)行(xing)。阿里云工(gong)(gong)程(cheng)師(shi)對(dui)(dui)部分高溫(wen)(wen)包間啟動(dong)(dong)服(fu)務(wu)器關機(ji)(ji)操作。14:47，冷(leng)(leng)機(ji)(ji)設備(bei)供應商對(dui)(dui)設備(bei)問題排查遇到(dao)困難，其(qi)中(zhong)一個包間因(yin)高溫(wen)(wen)觸發了強制消防噴(pen)淋。15:20，經冷(leng)(leng)機(ji)(ji)設備(bei)商工(gong)(gong)程(cheng)師(shi)現場手(shou)工(gong)(gong)調整(zheng)配置，冷(leng)(leng)機(ji)(ji)群控解鎖完成并獨立(li)運(yun)行(xing)，第1臺冷(leng)(leng)機(ji)(ji)恢復(fu)正常，溫(wen)(wen)度(du)開(kai)始(shi)下降。工(gong)(gong)程(cheng)師(shi)隨后繼續(xu)通過相同(tong)方法對(dui)(dui)其(qi)他冷(leng)(leng)機(ji)(ji)進行(xing)操作。18:55，4臺冷(leng)(leng)機(ji)(ji)恢復(fu)到(dao)正常制冷(leng)(leng)量。19:02，分批啟動(dong)(dong)服(fu)務(wu)器，并持續(xu)觀(guan)察溫(wen)(wen)升(sheng)情況。19:47，機(ji)(ji)房溫(wen)(wen)度(du)趨于穩定。同(tong)時，阿里云工(gong)(gong)程(cheng)師(shi)開(kai)始(shi)進行(xing)服(fu)務(wu)啟動(dong)(dong)恢復(fu)，并進行(xing)必要的(de)數據完整(zheng)性檢查。
21:36，大部(bu)分(fen)機房(fang)包(bao)間(jian)(jian)(jian)服(fu)務器(qi)(qi)陸續啟(qi)動并完成檢(jian)查(cha)，機房(fang)溫度穩(wen)定。其中一個包(bao)間(jian)(jian)(jian)因(yin)消防噴淋啟(qi)動，未(wei)進(jin)(jin)行服(fu)務器(qi)(qi)上電(dian)。因(yin)為保持(chi)數(shu)據的(de)(de)(de)完整(zheng)性至關(guan)重要(yao)，工程(cheng)師對這個包(bao)間(jian)(jian)(jian)的(de)(de)(de)服(fu)務器(qi)(qi)進(jin)(jin)行了仔細的(de)(de)(de)數(shu)據安全(quan)檢(jian)查(cha)，這里(li)花費了一些必(bi)要(yao)的(de)(de)(de)時間(jian)(jian)(jian)。22:50，數(shu)據檢(jian)查(cha)以及風(feng)險評估(gu)完成，最后一個包(bao)間(jian)(jian)(jian)依據安全(quan)性逐步進(jin)(jin)行供(gong)電(dian)恢復和服(fu)務器(qi)(qi)啟(qi)動。
服務影響
12月18日09:23，香(xiang)港Region可(ke)用(yong)區C部分(fen)ECS服務(wu)器開(kai)始(shi)出現(xian)停機，觸發同可(ke)用(yong)區內宕(dang)機遷移。隨著溫度繼續升高，受影響的(de)服務(wu)器停機數(shu)量持續增加，客(ke)戶業務(wu)開(kai)始(shi)受到影響，影響面擴大到香(xiang)港可(ke)用(yong)區C的(de)EBS、OSS、RDS等更多(duo)云服務(wu)。
阿里(li)云香(xiang)港(gang)可(ke)(ke)(ke)(ke)用(yong)(yong)區C的(de)故障，沒有(you)直(zhi)接(jie)影響(xiang)客(ke)戶在(zai)(zai)香(xiang)港(gang)其(qi)他可(ke)(ke)(ke)(ke)用(yong)(yong)區運行的(de)業務(wu)(wu)，但影響(xiang)了(le)(le)香(xiang)港(gang)Region ECS管控(kong)服(fu)務(wu)(wu)（Control Plane）的(de)正常使用(yong)(yong)。因大(da)量(liang)可(ke)(ke)(ke)(ke)用(yong)(yong)區C的(de)客(ke)戶在(zai)(zai)香(xiang)港(gang)其(qi)他可(ke)(ke)(ke)(ke)用(yong)(yong)區新購ECS實(shi)(shi)(shi)例，從(cong)12月(yue)18日(ri)14:49開始，ECS管控(kong)服(fu)務(wu)(wu)觸(chu)發限流，可(ke)(ke)(ke)(ke)用(yong)(yong)性最低跌至20%。客(ke)戶在(zai)(zai)使用(yong)(yong)RunInstances/CreateInstance API購買新ECS實(shi)(shi)(shi)例時，如果(guo)指定了(le)(le)自定義鏡(jing)像，部分(fen)實(shi)(shi)(shi)例在(zai)(zai)購買成功之后會出現啟動失敗的(de)現象，由于自定義鏡(jing)像數據服(fu)務(wu)(wu)依賴可(ke)(ke)(ke)(ke)用(yong)(yong)區C的(de)單AZ冗(rong)余版(ban)本的(de)OSS服(fu)務(wu)(wu)，無法通過重(zhong)試解決。此時，部分(fen)Dataworks、k8s用(yong)(yong)戶控(kong)制臺操作也受到了(le)(le)故障影響(xiang)。API完全恢復(fu)可(ke)(ke)(ke)(ke)用(yong)(yong)為當日(ri)23:11。
12月18日10:37，阿(a)里(li)云香港(gang)可(ke)用區(qu)(qu)C的(de)部分存儲服(fu)(fu)務(wu)(wu)(wu)OSS開始受到停(ting)機影響(xiang)(xiang)，此(ci)時客戶暫不會感知(zhi)，但持(chi)續高溫會導(dao)致磁盤壞道，影響(xiang)(xiang)數(shu)(shu)據安全，工程師對服(fu)(fu)務(wu)(wu)(wu)器(qi)進(jin)行停(ting)機操作，從11:07至(zhi)18:26中斷(duan)了服(fu)(fu)務(wu)(wu)(wu)。阿(a)里(li)云在香港(gang)Region可(ke)用區(qu)(qu)C提(ti)供(gong)了2種(zhong)類型的(de)OSS服(fu)(fu)務(wu)(wu)(wu)，一(yi)種(zhong)是(shi)OSS本地(di)冗(rong)余(yu)LRS服(fu)(fu)務(wu)(wu)(wu)（通(tong)常叫單AZ冗(rong)余(yu)服(fu)(fu)務(wu)(wu)(wu)），僅部署在可(ke)用區(qu)(qu)C；另一(yi)種(zhong)是(shi)OSS同(tong)城冗(rong)余(yu)ZRS服(fu)(fu)務(wu)(wu)(wu)（通(tong)常叫3AZ冗(rong)余(yu)服(fu)(fu)務(wu)(wu)(wu)），部署在可(ke)用區(qu)(qu)B、C和(he)D。在此(ci)次(ci)故(gu)障中，OSS同(tong)城冗(rong)余(yu)ZRS服(fu)(fu)務(wu)(wu)(wu)基(ji)本沒有受到影響(xiang)(xiang)。可(ke)用區(qu)(qu)C的(de)OSS本地(di)冗(rong)余(yu)服(fu)(fu)務(wu)(wu)(wu)中斷(duan)時間(jian)較(jiao)長，因不支持(chi)跨可(ke)用區(qu)(qu)切換，需要依賴故(gu)障機房(fang)的(de)恢(hui)復(fu)。從18:26開始，存儲服(fu)(fu)務(wu)(wu)(wu)器(qi)重新(xin)分批啟動。其(qi)中，單AZ本地(di)冗(rong)余(yu)LRS服(fu)(fu)務(wu)(wu)(wu)有部分服(fu)(fu)務(wu)(wu)(wu)器(qi)因消防問題需要做隔離處理。恢(hui)復(fu)服(fu)(fu)務(wu)(wu)(wu)前(qian)，我們必須要確(que)保(bao)數(shu)(shu)據可(ke)靠性，花(hua)費了較(jiao)多的(de)時間(jian)進(jin)行完整性檢驗工作。直(zhi)至(zhi)12月19日00:30，這部分OSS服(fu)(fu)務(wu)(wu)(wu)（單AZ冗(rong)余(yu)服(fu)(fu)務(wu)(wu)(wu)）才恢(hui)復(fu)了對外(wai)服(fu)(fu)務(wu)(wu)(wu)能力。
阿里云(yun)網(wang)絡少(shao)量單可(ke)用(yong)區(qu)(qu)產(chan)(chan)品(pin)(pin)（如：VPN、Privatelink以及少(shao)量GA實(shi)例）在此(ci)次故(gu)(gu)障中受(shou)到影響。12月18日(ri)11:21，工程(cheng)師啟(qi)動網(wang)絡產(chan)(chan)品(pin)(pin)可(ke)用(yong)區(qu)(qu)容(rong)災逃逸(yi)，12:45完(wan)成SLB等大部分網(wang)絡產(chan)(chan)品(pin)(pin)可(ke)用(yong)區(qu)(qu)容(rong)災逃逸(yi)，13:47NAT產(chan)(chan)品(pin)(pin)完(wan)成收尾逃逸(yi)。除上述少(shao)量單可(ke)用(yong)區(qu)(qu)產(chan)(chan)品(pin)(pin)以外，各(ge)網(wang)絡產(chan)(chan)品(pin)(pin)在故(gu)(gu)障期間保(bao)持(chi)了業務連續性，NAT有分鐘級業務受(shou)損。
12月18日10:17開(kai)始，阿里(li)云香港Region可(ke)(ke)(ke)(ke)用(yong)(yong)區(qu)(qu)C部(bu)(bu)分(fen)(fen)RDS實(shi)例(li)(li)(li)(li)(li)(li)出現不可(ke)(ke)(ke)(ke)用(yong)(yong)的(de)(de)(de)報警。隨(sui)著該(gai)可(ke)(ke)(ke)(ke)用(yong)(yong)區(qu)(qu)受故障影響(xiang)的(de)(de)(de)主(zhu)機范圍(wei)擴大，出現服務(wu)異(yi)常的(de)(de)(de)實(shi)例(li)(li)(li)(li)(li)(li)數量隨(sui)之增加，工程(cheng)師啟動數據庫(ku)應(ying)急切(qie)換(huan)預案(an)流(liu)程(cheng)。截(jie)至12:30，RDS MySQL與Redis、MongoDB、DTS等(deng)大部(bu)(bu)分(fen)(fen)跨可(ke)(ke)(ke)(ke)用(yong)(yong)區(qu)(qu)實(shi)例(li)(li)(li)(li)(li)(li)完成跨可(ke)(ke)(ke)(ke)用(yong)(yong)區(qu)(qu)切(qie)換(huan)。部(bu)(bu)分(fen)(fen)單(dan)可(ke)(ke)(ke)(ke)用(yong)(yong)區(qu)(qu)實(shi)例(li)(li)(li)(li)(li)(li)以及(ji)單(dan)可(ke)(ke)(ke)(ke)用(yong)(yong)區(qu)(qu)高可(ke)(ke)(ke)(ke)用(yong)(yong)實(shi)例(li)(li)(li)(li)(li)(li)，由(you)(you)于依賴單(dan)可(ke)(ke)(ke)(ke)用(yong)(yong)區(qu)(qu)的(de)(de)(de)數據備(bei)(bei)份(fen)，僅(jin)少量實(shi)例(li)(li)(li)(li)(li)(li)實(shi)現有效遷(qian)移。少量支(zhi)持(chi)跨可(ke)(ke)(ke)(ke)用(yong)(yong)區(qu)(qu)切(qie)換(huan)的(de)(de)(de)RDS實(shi)例(li)(li)(li)(li)(li)(li)沒(mei)有及(ji)時完成切(qie)換(huan)。經排(pai)查是由(you)(you)于這部(bu)(bu)分(fen)(fen)RDS實(shi)例(li)(li)(li)(li)(li)(li)依賴了部(bu)(bu)署在(zai)香港Region可(ke)(ke)(ke)(ke)用(yong)(yong)區(qu)(qu)C的(de)(de)(de)代理服務(wu)，由(you)(you)于代理服務(wu)不可(ke)(ke)(ke)(ke)用(yong)(yong)，無法通過(guo)代理地(di)址(zhi)訪問RDS實(shi)例(li)(li)(li)(li)(li)(li)。我(wo)們協(xie)助(zhu)相關客(ke)戶通過(guo)臨(lin)時切(qie)換(huan)到使用(yong)(yong)RDS主(zhu)實(shi)例(li)(li)(li)(li)(li)(li)的(de)(de)(de)地(di)址(zhi)訪問來進行恢(hui)復(fu)。隨(sui)著機房(fang)制冷設備(bei)(bei)恢(hui)復(fu)，21:30左右絕大部(bu)(bu)分(fen)(fen)數據庫(ku)實(shi)例(li)(li)(li)(li)(li)(li)恢(hui)復(fu)正常。對于受故障影響(xiang)的(de)(de)(de)單(dan)機版實(shi)例(li)(li)(li)(li)(li)(li)及(ji)主(zhu)備(bei)(bei)均在(zai)香港Region可(ke)(ke)(ke)(ke)用(yong)(yong)區(qu)(qu)C的(de)(de)(de)高可(ke)(ke)(ke)(ke)用(yong)(yong)版實(shi)例(li)(li)(li)(li)(li)(li)，我(wo)們提供了克隆實(shi)例(li)(li)(li)(li)(li)(li)、實(shi)例(li)(li)(li)(li)(li)(li)遷(qian)移等(deng)臨(lin)時性恢(hui)復(fu)方(fang)案(an)，但由(you)(you)于底層服務(wu)資源的(de)(de)(de)限制，部(bu)(bu)分(fen)(fen)實(shi)例(li)(li)(li)(li)(li)(li)的(de)(de)(de)遷(qian)移恢(hui)復(fu)過(guo)程(cheng)遇到一些異(yi)常情(qing)況，需要花費較長的(de)(de)(de)時間來處理解決。
我們(men)注(zhu)意到(dao)，同時在多個可用區(qu)運行業務(wu)(wu)的客戶，在這(zhe)次(ci)事(shi)件(jian)中(zhong)依然可以維持業務(wu)(wu)運行。對(dui)于(yu)業務(wu)(wu)需要絕對(dui)高可用的客戶，我們(men)持續建(jian)議您(nin)采(cai)用全鏈(lian)路多可用區(qu)的業務(wu)(wu)架構設計(ji)，以應對(dui)各(ge)種可能的意外(wai)事(shi)件(jian)。
問題分析與改進措施
1、冷機系統故障恢復時間過長
原因分(fen)析：機(ji)房冷(leng)(leng)(leng)卻系(xi)(xi)統缺(que)水(shui)(shui)進(jin)氣形成(cheng)氣阻，影響(xiang)水(shui)(shui)路(lu)循環導致4臺主冷(leng)(leng)(leng)機(ji)服務異常(chang)，啟(qi)(qi)動(dong)(dong)(dong)4臺備(bei)冷(leng)(leng)(leng)機(ji)時(shi)(shi)因主備(bei)共用的(de)水(shui)(shui)路(lu)循環系(xi)(xi)統氣阻導致啟(qi)(qi)動(dong)(dong)(dong)失敗。水(shui)(shui)盤補水(shui)(shui)后，因機(ji)房冷(leng)(leng)(leng)卻系(xi)(xi)統的(de)群控(kong)邏(luo)(luo)輯(ji)，無法單臺獨立(li)啟(qi)(qi)動(dong)(dong)(dong)冷(leng)(leng)(leng)機(ji)，手工修(xiu)改冷(leng)(leng)(leng)機(ji)配置，將(jiang)冷(leng)(leng)(leng)機(ji)從群控(kong)調整為獨立(li)運行后，陸續啟(qi)(qi)動(dong)(dong)(dong)冷(leng)(leng)(leng)機(ji)，影響(xiang)了冷(leng)(leng)(leng)卻系(xi)(xi)統的(de)恢(hui)復時(shi)(shi)長(chang)。整個過(guo)程中，原因定位耗(hao)時(shi)(shi)3小(xiao)時(shi)(shi)34分(fen)鐘(zhong)，補水(shui)(shui)排氣耗(hao)時(shi)(shi)2小(xiao)時(shi)(shi)57分(fen)鐘(zhong)，解鎖群控(kong)邏(luo)(luo)輯(ji)啟(qi)(qi)動(dong)(dong)(dong)4臺冷(leng)(leng)(leng)機(ji)耗(hao)時(shi)(shi)3小(xiao)時(shi)(shi)32分(fen)鐘(zhong)。
改進措施：全面(mian)檢查機房基礎設施管控(kong)系(xi)統(tong)，在監控(kong)數(shu)據采集層(ceng)面(mian)，擴大覆蓋度(du)，提升精細度(du)，提高對故(gu)障的(de)(de)排(pai)查和定位速度(du)；在設施管控(kong)邏輯層(ceng)面(mian)，確保系(xi)統(tong)自動切換邏輯符合預期，同時保證手工切換的(de)(de)準(zhun)確性，防(fang)止內部(bu)狀態死鎖從而影(ying)響故(gu)障的(de)(de)恢(hui)復。
2、現(xian)場(chang)處置不及時導致觸發消(xiao)防噴淋(lin)
原因分析：隨著機房冷卻系(xi)統失效，包(bao)間溫度(du)逐(zhu)漸升高，導致一機房包(bao)間溫度(du)達到臨(lin)界(jie)值(zhi)觸發消防系(xi)統噴淋，電(dian)源(yuan)柜(ju)和多列機柜(ju)進(jin)水(shui)，部分機器硬件(jian)損(sun)壞，增加了(le)后(hou)續恢復難度(du)和時長。
改進措施：加強機(ji)(ji)房(fang)服務商管理，梳理機(ji)(ji)房(fang)溫(wen)升(sheng)預案及標準化執(zhi)行動作，明確(que)溫(wen)升(sheng)場景下的(de)業務側(ce)關(guan)機(ji)(ji)和機(ji)(ji)房(fang)強制關(guan)電的(de)預案，力求更簡單有(you)效，并通(tong)過常態化演練強化執(zhi)行。
3.客戶在香港地域新購(gou)ECS等管控(kong)操作失(shi)敗
原因分(fen)析(xi)：ECS管(guan)控(kong)系統為B、C可(ke)(ke)用(yong)(yong)區(qu)(qu)(qu)雙機(ji)(ji)房容災(zai)，C可(ke)(ke)用(yong)(yong)區(qu)(qu)(qu)故(gu)障后由(you)B可(ke)(ke)用(yong)(yong)區(qu)(qu)(qu)對外提供服(fu)務(wu)，由(you)于大量可(ke)(ke)用(yong)(yong)區(qu)(qu)(qu)C的客戶在香港(gang)其他可(ke)(ke)用(yong)(yong)區(qu)(qu)(qu)新購(gou)實(shi)例，同時可(ke)(ke)用(yong)(yong)區(qu)(qu)(qu)C的ECS實(shi)例拉起恢復動(dong)作(zuo)引入(ru)的流量，導致可(ke)(ke)用(yong)(yong)區(qu)(qu)(qu) B 管(guan)控(kong)服(fu)務(wu)資(zi)源不足。新擴容的ECS管(guan)控(kong)系統啟(qi)動(dong)時依賴的中間件服(fu)務(wu)部署(shu)在可(ke)(ke)用(yong)(yong)區(qu)(qu)(qu)C機(ji)(ji)房，導致較長時間內無法擴容。ECS管(guan)控(kong)依賴的自(zi)定(ding)義鏡(jing)像數據服(fu)務(wu)，依賴可(ke)(ke)用(yong)(yong)區(qu)(qu)(qu)C的單(dan)AZ冗(rong)余版本(ben)的OSS服(fu)務(wu)，導致客戶新購(gou)實(shi)例后出現啟(qi)動(dong)失敗(bai)的現象(xiang)。
改進措施：全網巡檢，整體(ti)優(you)化多AZ產(chan)品(pin)高可用設計，避免出現依賴OSS單AZ和(he)中(zhong)間件單AZ的(de)問(wen)題。加強阿(a)里云管(guan)控平面的(de)容災演(yan)練(lian)，進一(yi)步提升云產(chan)品(pin)高可用容災逃(tao)逸能(neng)力。
4、故障信息發布(bu)不(bu)夠及時透明
原因分析：故障發(fa)生后阿(a)里(li)云啟動對客釘群、公告(gao)等通知手段(duan)，由于(yu)現場冷(leng)機(ji)處理進展緩慢(man)，有效(xiao)信息不夠。Status Page頁面信息更新不及時引發(fa)客戶困惑(huo)。
改(gai)進措施：提(ti)升故障影響(xiang)(xiang)和客(ke)戶影響(xiang)(xiang)的(de)快(kuai)速(su)評(ping)估和識別拉取能力。盡快(kuai)上(shang)線(xian)新版的(de)阿里云服務(wu)健康狀(zhuang)態頁面（Status Page），提(ti)高信息發(fa)布的(de)速(su)度，讓(rang)客(ke)戶可以更便(bian)捷地了(le)解故障事件(jian)對各(ge)類產品服務(wu)的(de)影響(xiang)(xiang)。
總結
最(zui)后，我(wo)(wo)們(men)要向(xiang)所有受(shou)到故(gu)障影響的(de)(de)客戶(hu)公(gong)開致歉(qian)，并(bing)盡快處理賠償事(shi)宜。此次(ci)香港Region可用區(qu)C服務(wu)中(zhong)(zhong)斷事(shi)件，對(dui)很多(duo)客戶(hu)的(de)(de)業務(wu)產生重大(da)影響，也是(shi)阿(a)里云(yun)(yun)運營十多(duo)年來持(chi)(chi)續時間(jian)最(zui)長的(de)(de)一(yi)次(ci)大(da)規模(mo)故(gu)障。穩定性是(shi)云(yun)(yun)服務(wu)的(de)(de)生命線，對(dui)我(wo)(wo)們(men)的(de)(de)客戶(hu)至(zhi)關(guan)重要。我(wo)(wo)們(men)將(jiang)盡一(yi)切努力從此次(ci)事(shi)件中(zhong)(zhong)吸(xi)取經驗(yan)教訓，持(chi)(chi)續提升云(yun)(yun)服務(wu)的(de)(de)穩定性，不辜負客戶(hu)所托！
阿里云 2022年12月25日
