根据网友在群里的反馈, 本次阿里云好像是人员优化引起的大雪崩, 云产品控制台服务不断发出异常消息, 各个和阿里云沾边的厂商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岁, 可以更多避免出现此类的情况。