阿里云故障过去一段时间了，阿里目前原因基本确认了；相关原因和反思可以重新思考一下看看有哪些是云故值得借鉴和反思的地方。

先来看一下网上披露官方报告。障解

原因

访问密钥服务 (AK）在读取白名单数据时出现读取异常，密和因处理读取异常的反思代码存在逻辑缺陷，生成了一份不完整白名单，阿里导致不在此白名单中的云故有效请求失败，影响云产品控制台及管控 API 服务出现异常，障解同时部分依赖 AK 服务的密和产品因不完整的白名单出现部分服务运行异常。

改进措施

增加 AK 服务白名单生成结果的反思校验及告警拦截能力。增加 AK 服务白名单更新的阿里灰度验证逻辑，提前发现异常。云故增加 AK 服务白名单的障解快速恢复能力。加强云产品侧的密和联动恢复能力。

问题回顾

2023 年 11 月 12 日 17:39 起，反思阿里云云产品控制台访问及管控 API 调用出现异常、部分云产品服务访问异常，工程师排查故障原因与访问密钥服务 (AK) 异常有关。工程师修订白名单版本后，采取分批重启 AK 服务的措施，于 18:35 开始陆续恢复，19:20 绝大部分 Region 产品控制台和管控 API 恢复。b2b信息网

处理过程

17:39：阿里云云产品控制台访问及管控 API 调用出现异常。17:50：工程师确认故障是 AK 服务异常导致，影响云产品控制台、管控 API 调用异常，以及依赖 AK 服务的云产品服务运行异常。18:01：工程师定位到根因。18:07：开始执行恢复措施，包括修订白名单版本、重启 AK 服务。18:35：杭州等 Region 开始恢复正常。19:20：绝大部分 Region 的云产品控制台和管控 API 调用恢复正常。

这里的主要原因

数据没有隔离虽然服务层面做了隔离。但是数据层生成白名单之后没有做隔离，做了全球的推全因为用户的权限是全球的，所有在用户层面没有做隔离，全球推全之后造成了全球故障白名单是故障时什么导致的网上没有披露

暴露出来的问题 

隔离：所有用户，所有地区；服务做了隔离，但是数据没有做隔离；分级：数据上线前检查：数据直接推全，没有做提前检查，云服务器提供商没有分级也没有做检查必然影响所有的用户。

最后

我们一定不要抱着吃瓜的态度去看这个问题，冷嘲热讽，如果事件发生在我们头上能做哪些优化 

优化点：

隔离：数据层面一定要想办法做隔离；分级：数据推送线上环境之前一定要做检查和分级，比如我可以在一个小的地区和国家先推送，没问题再推送；检查：在上线前一定要做case回归。

关于稳定性的一些个人思考：

我工作大概10年了一直在处理着各种各样的故障；越是重大的故障其实越是简单，越是简单的事情就越难得老板的认可；其实我觉这个也是需要老板去思考的，一味的追求高大上，很难应对简单的故障；简单的事情往往又很难得到职级和薪资待遇的提升。如何取得平衡是需要思考的。