【转】阿里云的严重事故,钉钉、闲鱼、淘宝、语雀等都崩了.....让我们全方位复盘一下
许多小伙伴应该都听说过,前两天在IT行业爆出了一个大瓜。是什么事情呢?在11月12日17:50-21:15。, 三个半小时的时间里,不但阿里云、钉钉、闲鱼、淘宝、语雀......甚至连某些高校的饮水机都崩了!
对于上云的用户:在过去的十年中,「上云」成为产业数字化的重要趋势,越来越多的业务已经迁移到云上。上云确实可以降低企业的运维成本,但是对云厂商的依赖也越来越大。可以采用「多云部署」。例如将业务部署在两个不同的云厂商上,那么这两个云之间的组件不会相互依赖,这样就可以避免一个云出现问题时整个产品都无法访问的情况。多云部署可能会带来一定的成本增加,例如资源成本和技术复杂性增加带来的成本。可以只将关键模块进行多云部署,成本就会更低。而且相比于提高稳定性所带来的收益,大多数企业都愿意接受这部分成本。一个云厂商的可用性是99.9%,那么两个云厂商同时宕机的概率是0.1%*0.1%=百万分之一,就可以解决了单云厂商的稳定性问题。
阿里云作为整个阿里产品线的技术底座,影响重大,对服务SLA的要求是非常高的。这三小时的故障造成的损失太大了。而且阿里云在中国云服务的市场占有率高达37%。2022年,阿里云占中国云市场份额的36%,排名第一,收入为109.08亿美元(752.97亿)。很多中小企业的所有服务都运行在阿里云上,直接会造成对应企业的业务停摆。
那么为什么造成这个现象呢?下面的网友神评论
希望互联网好起来,程序员不再「毕业」!~
故障现象
阿里的内部服务都是部署在阿里云上,所以阿里系的各个产品都出现了崩溃问题,一度冲上了微博热搜。
可以从阿里云的官方监控 阿里云健康状态[1] 看到亚太,欧美,中东各个地区在11-12日的所有产品都处于异常状态。其中比如容器服务Kubernetes版,轻量应用服务器这些底层服务是非常非常重要,一旦出现问题会直接导致服务完全不可用。
故障复盘
事故描述
事故开始时间:2023-11-13 17:44事故发现时间:2023-11-13 17:44事务恢复时间:2023-11-13 21:13TTD:由于影响范围很大,理论上很快就被发现了,应该在5分钟以内。TTE:由于是严重的线上问题,必须马上放下其他工作处理这个问题,应该在5分钟以内。TTM:3.5小时TTD (Time To Detect):指的是从故障发生到被检测到的时间。这是一个关键指标,因为它影响着整个故障响应过程的开始。TTE (Time To Engage):指从故障被检测到到相应团队或个人开始响应和处理这个问题的时间。它反映了组织对紧急情况的反应速度。TTM (Time To Mitigate):指从开始处理故障到故障被缓解或解决的时间。这个指标体现了解决问题的效率
时间线
官方故障公告:【异常(已恢复)】阿里云云产品控制台服务异常[2]
具体处理时间线如下:
详细故障原因阿里云官方还没有纰漏,所以暂时不知道问题链,责任链,改进线。后续会持续关注阿里云官方的公告。不过,这不妨碍我们对事故的原因进行一些猜测。
问题链猜测
由于影响范围比较大,覆盖了阿里云的所有产品,上面时间线也说了是一个底层服务组件发生了故障,再结合语雀的报错信息来看,很可能是阿里的鉴权服务出现问题.
阿里云主账号和子账号可以创建一个访问密钥(AccessKey)。在调用阿里云API时需要使用AccessKey完成身份验证。AccessKey包括AccessKey ID和AccessKey Secret。
- AccessKeyId:用于标识用户,相当于账号名称。
- AccessKeySecret:用于验证用户的密钥,相当于账号密码。
因为所有对云服务的请求都必须要进行身份认证,有权限才可以去操作对应的资源,没权限立即停止访问。所以这个底层服务的影响才会这么广。问题的原因我猜测是代码变更导致的,由于19:21分的时候重启就马上解决问题了。应该是回滚了上线的bug代码,但实例数量众多重启时间也较长。
改进线
对与云厂商:肯定是要保障自身的可用性,这次三个半小时时间的停机,今年99.99%(四个九)的可用性是保障不了,也会牵连到完全依赖阿里云其他应用也达不到四个九的可用性了。- 测试覆盖:代码上线前一定要经过单元测试,集成测试,系统测试,回归测试几步
- 灰度发布:全量上线之前先灰度发布到少量机器上,降低影响范围。灰度机器上的监控和测试没问题再上全量
- 服务降级:在鉴权服务不可用时,可实行服务降级。这可能意味着提供有限的功能或返回一个预设的默认响应,确保核心业务仍能运作。
- 服务熔断:当鉴权服务不可用时,可以实施服务熔断机制。这意味着临时关闭服务间的交互,防止错误的进一步蔓延。例如,如果鉴权服务响应超时或失败,系统可以暂时跳过鉴权过程,保持其他服务的可用性。
对于上云的用户:在过去的十年中,「上云」成为产业数字化的重要趋势,越来越多的业务已经迁移到云上。上云确实可以降低企业的运维成本,但是对云厂商的依赖也越来越大。可以采用「多云部署」。例如将业务部署在两个不同的云厂商上,那么这两个云之间的组件不会相互依赖,这样就可以避免一个云出现问题时整个产品都无法访问的情况。多云部署可能会带来一定的成本增加,例如资源成本和技术复杂性增加带来的成本。可以只将关键模块进行多云部署,成本就会更低。而且相比于提高稳定性所带来的收益,大多数企业都愿意接受这部分成本。一个云厂商的可用性是99.9%,那么两个云厂商同时宕机的概率是0.1%*0.1%=百万分之一,就可以解决了单云厂商的稳定性问题。
总结思考
阿里的产品众多,包括钉钉、支付宝、闲鱼、淘宝、语雀、饿了么、飞猪、菜鸟等等超级APP,用户众多。这三小时里,用钉钉办公的公司无法工作,用支付宝的用户无法付款,电商的客户无法下单。除了线上的场景,对线下场景的影响就更大了。在盒马超时购物的客户无法结账,停车系统无法抬杆,外卖骑手无法接单。
阿里云作为整个阿里产品线的技术底座,影响重大,对服务SLA的要求是非常高的。这三小时的故障造成的损失太大了。而且阿里云在中国云服务的市场占有率高达37%。2022年,阿里云占中国云市场份额的36%,排名第一,收入为109.08亿美元(752.97亿)。很多中小企业的所有服务都运行在阿里云上,直接会造成对应企业的业务停摆。
那么为什么造成这个现象呢?下面的网友神评论
人员不稳定确实会造成系统的不稳定,反正前人挖坑来后人填坑,自然系统质量越来越差。这几年互联网公司增速放缓,一直都在降本增效,很多公司的处理方式不是特别妥就会造成人员的不稳定。
希望互联网好起来,程序员不再「毕业」!~