阿里云故障過(guò)去一段時(shí)間了，目前原因基本確認(rèn)了；相關(guān)原因和反思可以重新思考一下看看有哪些是值得借鑒和反思的地方。

先來(lái)看一下網(wǎng)上披露官方報(bào)告。

原因

訪問(wèn)密鑰服務(wù) (AK）在讀取白名單數(shù)據(jù)時(shí)出現(xiàn)讀取異常，因處理讀取異常的代碼存在邏輯缺陷，生成了一份不完整白名單，導(dǎo)致不在此白名單中的有效請(qǐng)求失敗，影響云產(chǎn)品控制臺(tái)及管控 API 服務(wù)出現(xiàn)異常，同時(shí)部分依賴(lài) AK 服務(wù)的產(chǎn)品因不完整的白名單出現(xiàn)部分服務(wù)運(yùn)行異常。

改進(jìn)措施

• 增加 AK 服務(wù)白名單生成結(jié)果的校驗(yàn)及告警攔截能力。
• 增加 AK 服務(wù)白名單更新的灰度驗(yàn)證邏輯，提前發(fā)現(xiàn)異常。
• 增加 AK 服務(wù)白名單的快速恢復(fù)能力。
• 加強(qiáng)云產(chǎn)品側(cè)的聯(lián)動(dòng)恢復(fù)能力。

問(wèn)題回顧

2023 年 11 月 12 日 17:39 起，阿里云云產(chǎn)品控制臺(tái)訪問(wèn)及管控 API 調(diào)用出現(xiàn)異常、部分云產(chǎn)品服務(wù)訪問(wèn)異常，工程師排查故障原因與訪問(wèn)密鑰服務(wù) (AK) 異常有關(guān)。工程師修訂白名單版本后，采取分批重啟 AK 服務(wù)的措施，于 18:35 開(kāi)始陸續(xù)恢復(fù)，19:20 絕大部分 Region 產(chǎn)品控制臺(tái)和管控 API 恢復(fù)。

處理過(guò)程

• 17:39：阿里云云產(chǎn)品控制臺(tái)訪問(wèn)及管控 API 調(diào)用出現(xiàn)異常。
• 17:50：工程師確認(rèn)故障是 AK 服務(wù)異常導(dǎo)致，影響云產(chǎn)品控制臺(tái)、管控 API 調(diào)用異常，以及依賴(lài) AK 服務(wù)的云產(chǎn)品服務(wù)運(yùn)行異常。
• 18:01：工程師定位到根因。
• 18:07：開(kāi)始執(zhí)行恢復(fù)措施，包括修訂白名單版本、重啟 AK 服務(wù)。
• 18:35：杭州等 Region 開(kāi)始恢復(fù)正常。
• 19:20：絕大部分 Region 的云產(chǎn)品控制臺(tái)和管控 API 調(diào)用恢復(fù)正常。

這里的主要原因

• 數(shù)據(jù)沒(méi)有隔離雖然服務(wù)層面做了隔離。但是數(shù)據(jù)層生成白名單之后沒(méi)有做隔離，做了全球的推全
• 因?yàn)橛脩?hù)的權(quán)限是全球的，所有在用戶(hù)層面沒(méi)有做隔離，全球推全之后造成了全球故障
• 白名單是故障時(shí)什么導(dǎo)致的網(wǎng)上沒(méi)有披露

暴露出來(lái)的問(wèn)題 

• 隔離：所有用戶(hù)，所有地區(qū)；服務(wù)做了隔離，但是數(shù)據(jù)沒(méi)有做隔離；
• 分級(jí)：數(shù)據(jù)上線(xiàn)前檢查：數(shù)據(jù)直接推全，沒(méi)有做提前檢查，沒(méi)有分級(jí)也沒(méi)有做檢查必然影響所有的用戶(hù)。

最后

我們一定不要抱著吃瓜的態(tài)度去看這個(gè)問(wèn)題，冷嘲熱諷，如果事件發(fā)生在我們頭上能做哪些優(yōu)化 

優(yōu)化點(diǎn)：

• 隔離：數(shù)據(jù)層面一定要想辦法做隔離；
• 分級(jí)：數(shù)據(jù)推送線(xiàn)上環(huán)境之前一定要做檢查和分級(jí)，比如我可以在一個(gè)小的地區(qū)和國(guó)家先推送，沒(méi)問(wèn)題再推送；
• 檢查：在上線(xiàn)前一定要做case回歸。

關(guān)于穩(wěn)定性的一些個(gè)人思考：

• 我工作大概10年了一直在處理著各種各樣的故障；
• 越是重大的故障其實(shí)越是簡(jiǎn)單，越是簡(jiǎn)單的事情就越難得老板的認(rèn)可；
• 其實(shí)我覺(jué)這個(gè)也是需要老板去思考的，一味的追求高大上，很難應(yīng)對(duì)簡(jiǎn)單的故障；
• 簡(jiǎn)單的事情往往又很難得到職級(jí)和薪資待遇的提升。如何取得平衡是需要思考的。