最近各大厂商的云服务出现各种问题

最近大厂们的云服务集中爆发故障，浅浅的吐槽一下。

语雀(蚂蚁金服)

10月23日14时左右长达8个小时的P0级事故(14时10分至21时45分左右)

原因:
10月23日下午，服务语雀的数据存储韵味团队在进行升级操作时，由于运维团队的升级操作中出现了bug，导致存储服务器被误下线

处理:
    14:07 数据存储运维团队收到监控系统报警，定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线；
    14:15 联系硬件团队尝试将下线机器重新上线；
    15:00 确认因存储系统使用的机器类别较老，无法直接操作上线，立即调整恢复方案为从备份系统中恢复存储数据。
    15:10 开始新建存储系统，从备份中开始恢复数据，由于语雀数据量庞大，此过程历时较长，
    19 点完成数据恢复；同时为保障数据完整性，在完成恢复后，用时 2 个小时进行数据校验；
    21 点存储系统通过完整性校验，开始和语雀团队联调
    22 点恢复语雀全部服务。用户所有数据均未丢失。

to用户解决方案: 所有语雀的个人用户，赠送 6 个月的会员服务。

语雀并没有透露具体的原因，但是从处理事件和处理方案来说确实比较及时。但是这种庞大的数据量，从新建存储系统并从备份开始恢复及校验，确实是需要消耗大量的时间，最终导致长达8个小时的故障。只能说多做冗余吧，备份的系统不能直接上线，还需要恢复，这高可用确实是没做好啊。而且运维工具没有测试过就上线了吗？

好在语雀公告里写了改进措施,重点有两个:
1.做到更完善的技术风险保障和高可用架构设计 “可监控，可灰度，可回滚”
2.从同Region多副本容灾升级为两地三中心的高可用能力

虽然蚂蚁集团和阿里巴巴分割，蚂蚁成为独立公司，但仍不清楚蚂蚁的服务到底有没有彻底切割出来，用的谁的机房。后面两个阿里的事故也是重量级。

阿里云

11月12日17:39起阿里云底层授权模块(RAM)接近3个小时的服务不可用，涉及到阿里云几乎所有服务，全球的IDC区域
阿里云、淘宝、闲鱼、钉钉、饿了么、天猫精灵等阿里系APP全部崩了 P0级事故

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

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

11月27日09:16-10:58 接近2个小时的数据库管控故障，数据库产品的控制台和OpenAPI访问异常，还好数据库正常访问，涉及部分中国大陆、部分美国、中国香港地域
具体原因好像没有透露

阿里云的云服务SLA标准: https://www.aliyun.com/why-us/reliability

SLA计算
    1个9：(1-90%)*365=36.5天
    2个9：(1-99%)*365=3.65天
    3个9：(1-99.9%)*365*24=8.76小时，表示该软件系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。
    4个9：(1-99.99%)*365*24=0.876小时=52.6分钟，表示该软件系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
    5个9：(1-99.999%)*365*24*60=5.26分钟，表示该软件系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
    6个9：(1-99.9999%)*365*24*60*60=31秒

一个月内出现两次事故(不包含语雀)，可以说是开猿节流降本增笑嘛？而且11.12双十一才过去一天好端端的去动RAM服务？
幸好我个人没有放重要的服务在阿里云上，只放了一个不重要的OSS服务。之前在阿里云的域名解析也迁移到了腾讯云，否则DDNS脚本无法正常更新IP地址。

哎，近几年阿里事故确实不少。

滴滴

11月27日夜间22点 P0级故障发布故障
官方给出的原因: 故障是由于运维团队的升级操作中出现了bug，导致存储服务器被误下线
网传原因:

滴滴技术公众号2023-10-17表一篇文章《滴滴弹性云基于 K8S 的调度实践》，发现滴滴技术同学在做k8s集群升级：k8s 版本的升级：介绍到从 k8s 1.12 到 1.20 跨版本升级的方案

聊天截图:
截图1.虽然有多个机房，但这次升级的机房特别大，代码改动不多，但是k8s集群升级错版本了，相当于把k8s集群降级了。然后控制节点全被污染了，其他node节点离了master节点直接全部挂掉了，无法回滚。
截图2.应该升级到1.12的升级到1.20了协议不兼容kubelet把整个永顺机房的pod都kill了，最致命的是控制节点也在那个机房，控制节点挂了，服务都没法重新部署。

出处: 努力改掉拖延症的小白已于 2023-11-30 21:52:24 修改
https://blog.csdn.net/caoyuan666/article/details/134721748

这个发布计划就是一坨，涉及底层架构没有备案，干翻控制节点，回滚都回滚不了。