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

先來看一下網(wǎng)上披露官方報告。

原因

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

改進措施

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

問題回顧

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

處理過程

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

這里的主要原因

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

暴露出來的問題 

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

最后

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

優(yōu)化點：

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

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

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