根据网友在群里的反馈, 本次阿里云好像是人员优化引起的大雪崩, 云产品控制台服务不断发出异常消息, 各个和阿里云沾边的厂商APP出现了API接口不响应、存储雪崩、界面卡顿甚至是钉钉都无法打卡的现象。
进展更新
17:50 阿里云已确认故障原因与某个底层服务组件有关，工程师正在紧急处理中。
18:54 经过工程师处理，杭州、北京等地域控制台及API服务已恢复，其他地域控制台服务逐步恢复中。
19:20 工程师通过分批重启组件服务，绝大部分地域控制台及API服务已恢复。
19:43 异常管控服务组件均已完成重启，除个别云产品（如消息队列MQ、消息服务MNS）仍需处理，其余云产品控制台及API服务已恢复。
20:12 北京、杭州等地域消息队列MQ已完成重启，其余地域逐步恢复中。
21:11 受影响云产品均已恢复，因故障影响部分云产品的数据（如监控、账单等）可能存在延迟推送情况，不影响业务运行。
阿里云对外公开故障不同时间线处理流程信息中写道:
【异常（处理中）】阿里云云产品控制台服务异常
尊敬的客户：
您好！北京时间2023年11月12日17:44起，阿里云监控发现云产品控制台访问及AP调用出现异常，阿里云工程师正在紧急介入排查。非常抱歉给您的使用带来不便，若有任何问题，请随时联系我们。
--进展更新
50 阿里云已确认故障原因与某个底层服务组件有关，工程师正在紧急处理中。
54 经过工程师处理，杭州、北京等地域控制台已恢复，其他地域控制台服务逐步恢复中。
20 工程师通过分批重启组件服务，绝大部分地域控制台服务已恢复访问。
接下来是标记为已恢复的
【异常（已恢复）】阿里云云产品控制台服务异常
尊敬的客户：
您好！北京时间2023年11月12日17:44起，阿里云监控发现云产品控制台访问及APi调用出现异常，阿里云工程师正在紧急介入排查。非常抱歉给您的使用带来不便，若有任何问题，请随时联系我们。
—-进展更新
50 阿里云已确认故障原因与某个底层服务组件有关，工程师正在紧急处理中。
54 经过工程师处理，杭州、北京等地域控制台及API服务已恢复，其他地域控制台服务逐步恢复中。
20 工程师通过分批重启组件服务，绝大部分地域控制台及API服务已恢复。
43 异常管控服务组件均已完成重启，除个别云产品（如消息队列MQ、消息服务MNS）仍需处理，其余云产品控制台及API服务已恢复。
12 北京、杭州等地域消息队列MQ已完成重启，其余地域逐步恢复中。
11 受影响云产品均已恢复，因故障影响部分云产品的数据（如监控、账单等）可能存在延迟推送情况，不影响业务运行。
从上面我们能看到故障状态，由“处理中”到“已恢复”，所以大家从这个图能很清晰的知道当前故障所处的状态。
从阿里云给出的对外故障公告来看，故障持续三个半小时，从大批量重启基础组件来看面肯定不会小。
故障影响
故障时间长：从阿里云给出的对外故障公告来看，故障总体持续了三个半小时
产品影响面大：网上用户反馈如下，影响阿里自家的服务：淘宝、钉钉、云盘、语雀、饿了么、咸鱼等，影响了使用阿里云产品的客户：瑞幸、蜜雪冰城、虎牙、京东、人人等。
赔偿款估计不小：服务稳定性和资损都影响巨大，后续还会有客户SLA不达标、客户资损等赔偿，赔偿款估计也不小。
影响地域广：从下面截图来看，影响了N多可用区和N多Region
长远影响：给用户多云或迁云埋下种子。
当时故障截图：
与此同时, 据网友反映，天猫精灵、学浪、芒果、蜜雪冰城、人人网、闲鱼也出现了不同程度的崩溃和卡顿的情况。
故障原因
以下原因是作者猜测，具体原因以官网为准
从产品网盘、OSS不可用，多个机房可用区受雪崩影响，应该是一个全球都在用的某个Java鉴权用基础服务出现了问题。
可能的方向有：存储、网络、鉴权服务
存储、网络一般来说都是SET化部署或可用区部署，即使有问题也不会影响全球，排除。那很可能是鉴权服务出问题了，OSS和消息队列对鉴权服务依赖较大，而且全球都在用。
Java在高并发时GC性能真空的问题会凸显，也可以导致消息队列服务出现雪崩的现象。具体是什么导致鉴权服务出问题，那就不得而知了，反正是猜测。
故障级别
1. 影响有核心产品，淘宝、阿里云、钉钉等，而且还影响一大批阿里云用户;
2. 故障总时长达3.5小时;
3. 影响用户量巨大，双十一热度还没过呢;
据传, 本次故障级别被评定为：P0级别。据传张勇派发了公司邮件声称兼任运维相关高级岗位，张剑锋等高管在阿里的任职受到影响。
改进措施
对于使用阿里云的客户来说，多云部署，比如同城多云，网络延迟小相对好实现。
对于阿里云企业本身来说, 应当在力所能及的情况下减少使用老掉牙的Java服务, 多使用c++ rust高性能程序服务迭代, 减少内卷，裁员时按能力从低到高实施而不是无脑卡35岁, 可以更多避免出现此类的情况。
