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

先來看一下網上披露官方報告。

原因

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

改進措施

• 增加 AK 服務白名單生成結果的校驗及告警攔截能力。
• 增加 AK 服務白名單更新的灰度驗證邏輯，提前發現異常。
• 增加 AK 服務白名單的快速恢復能力。
• 加強云產品側的聯動恢復能力。

問題回顧

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

處理過程

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

這里的主要原因

• 數據沒有隔離雖然服務層面做了隔離。但是數據層生成白名單之后沒有做隔離，做了全球的推全
• 因為用戶的權限是全球的，所有在用戶層面沒有做隔離，全球推全之后造成了全球故障
• 白名單是故障時什么導致的網上沒有披露

暴露出來的問題 

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

最后

我們一定不要抱著吃瓜的態度去看這個問題，冷嘲熱諷，如果事件發生在我們頭上能做哪些優化 

優化點：

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

關于穩定性的一些個人思考：

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