写点什么

阿里云出现大规模宕机,原因系 IO HANG,或将做出赔偿

2019 年 3 月 03 日

阿里云出现大规模宕机,原因系IO HANG,或将做出赔偿

事件回溯


据网友爆料,3 月 2 日 23:55 分左右,阿里云疑似出现大规模故障情况,华北相当多互联网公司都炸了,一众 APP 和网站陷入瘫痪,一大波程序员、运营和运维人员都赶去公司加班。晚些时候,阿里云对此作出回应称:华北 2 地域可用区 C 部分 ECS 实例状态异常,导致该区域众多网站和 APP 都无法正常使用,不少公司就此事在微博刊登出回应公告:



阿里云方面暂无确切故障原因并尚未给出具体受影响范围,其工程师正在进行紧急排查处理,并表示如果有进展会及时向用户同步:



对此,不少程序员在微博吐槽,一时之间该话题之下哀鸿遍野。有网友怀疑是部分磁盘出现问题,凡是读写故障盘的系统软件或服务程序均会受到影响。


对于此事,某公司市场总监在微博表示,一直以为阿里云是公有云稳定的代名词,但出现这种事件让没有配套私服的中小公司措手不及,如果有完善的备用方案,不至于出现大规模宕机。



截止发稿时,阿里云方面回应称:服务器等出现 IO HANG,正在处理并将对受影响的客户进行赔偿。


云服务 99.99%的安全性是否靠谱?


据了解,这不是阿里云第一次出现宕机事故。


2018 年 6 月 27 日 16:21 左右,阿里云也曾出现重大技术故障,16:50 分开始陆续恢复,官方给出的故障时间为 30 分钟左右,恢复时间大概花费一小时。经过技术复盘,阿里给出的故障原因为工程师团队上线自动化运维新功能时,执行了一项变更验证操作,该操作在测试环境中未发生问题,上线后触发未知 bug。


本次事故被定义为 S1 级别,即核心业务重要功能不可用,影响部分用户,造成一定损失。阿里云发布官方声明,表示“对于这次故障,没有借口,我们不能也不该出现这样的失误!我们将认真复盘改进自动化运维技术和发布验证流程,敬畏每一行代码,敬畏每一份托付。”


根据笔者统计,仅去年一年,全球主流云计算厂商就曾发生数十起宕机事故,原因更是五花八门,谷歌云曾因自动化失效导致宕机、AWS 曾因数据中心出现硬件问题导致宕机、微软 Azure 爱尔兰数据中心曾因高温和打雷陷入宕机、腾讯云因运营和硬盘故障陷入宕机…


众多安全事故频发,云厂商承诺的 99.99%的安全可靠性是如何定义的?


不久前,笔者曾就云服务的可靠性一事询问阿里云相关技术专家的看法,他表示,云计算厂商得出 99.99%可靠性这一数字是经过验证的,通过客户部署反馈,确实故障率在 0.01%以下。并且,一旦出现故障,云厂商也都有非常完善的容灾方案,目前主流云厂商已经在提供一定程度上的异构灾备能力,比如,阿里云的 3AZ 容灾方案,同城一定距离的地方,用户可以自己搭建跨 DC 方案,技术上能够满足异构容灾需求。如果客户追求极致容灾能力,有可能建设混合云或者采购多家云厂商,架构会带来很大成本压力,但这种选择应该比较少,就好比对安全可靠性要求极高的金融数据库领域,也很少有客户同时选择两种数据库方案。


随着云计算使用量的持续增长,很多企业纷纷开始选择放弃一些控制权,以降低成本。从业界来看,美国大多数互联网企业已经放弃自建数据中心而大规模应用云技术,例如 NetFlix 大规模应用谷歌云服务,专注于专有云和 IaaS 的 Cloudera 和 Hortonworks 合并过冬。


单一云平台被企业大规模应用同时,这也意味着一旦出现问题,给企业带来的损失和影响是巨大的,多云再次成为重要讨论话题。


多云可以解决所有问题吗?


根据 Gartner 调查,2018 年全球公有云市场整体增长为 21.4%,以亚马逊 AWS、微软 Azure 和阿里云为首的全球云计算“3A”阵营占据超七成市场份额。根据 IDC 数据,在中国市场上,阿里云市场份额相当于第 2 到 9 名的总和。在全球市场,阿里云已超过 Google 和 IBM 的云业务。


据统计,目前 40% 的中国 500 强企业、近一半中国上市公司、80% 中国科技类公司在使用阿里云,其数据中心也在全球范围内增长。可见,国内企业选择阿里云较多,这也让单一云平台绑定问题受到用户关注。


中国平安运维部负责人曾在接受采访时表示,很多大企业如今都会分散选择云服务商。一般情况下,小型企业受限于资金或人员等因素,可能会将所有服务放在同一云计算平台,但大多数中型企业还是倾向于选择多个厂商。


就目前的发展现状而言,云计算服务将越来越趋向于标准化,企业可以轻松得在不同云平台之间进行数据或者应用迁移,多云管理的门槛将被大大降低,如何选择云供应商将完全取决于企业实际需求和业务成本。


就目前国内云计算的应用进程来看,多云对企业带来的挑战非常大,具备容灾意识,尤其是重要业务的灾备方案一定要做好,比如依靠 API 快速升级扩容切换服务,配合完善的持续集成部署,完全依靠云供应商的长时间不间断服务是不可能的,云上也有故障率,具备完善的灾备意识是现阶段企业负责任的上云态度。


2019 年 3 月 03 日 08:5119323
用户头像
赵钰莹 InfoQ高级编辑

发布了 654 篇内容, 共 387.9 次阅读, 收获喜欢 2109 次。

关注

评论 1 条评论

发布
用户头像
同城灾备,异地灾备
2019 年 04 月 03 日 23:06
回复
没有更多了
发现更多内容

分布式服务框架的选择-《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》

Man

分布式架构 中台架构

第九周学习总结

晴空万里

极客大学架构师训练营

面试官:Mybatis里的设计模式有哪些?我一口气答了8种

田维常

mybatis

架构师训练营 2 期 Week09 作业

Calvin

架构师训练营第2期 第9周总结

月下独酌

极客大学架构师训练营

成为架构师 - 架构师训练营第 08 周

陈永龙Vincent

两个周末整理的垃圾回收知识,我要吐血了

moon聊技术

JVM JVM垃圾回收原理

增强产业链供应链自主可控能力

CECBC区块链专委会

供应链

架构师训练营 week10 课后作业

花果山

极客大学架构师训练营

架构师训练营第 1 期 -- 第十三周作业

发酵的死神

极客大学架构师训练营

第十三周作业

orchid9

架构师训练营 week9 课后作业

花果山

极客大学架构师训练营

架构师训练营 - 第十三周 - 作业一

行者

架构师训练营第13周总结

邓昀垚

架构师训练营第 1 期 - 第十三周作业

Todd-Lee

极客大学架构师训练营

《JAVA并发编程核心方法与框架》.pdf

田维常

并发编程

互操作性如何助推区块链接入互联网基础设施

CECBC区块链专委会

区块链 密码学

【架构师训练营第 1 期 13 周】 作业

Bear在挨踢

极客大学架构师训练营

南昌“舞动”区块链

CECBC区块链专委会

区块链 基础设施

C语言学习你要的都在这里

C语言与CPP编程

c++ 学习 编程 C语言

架构师训练营 week10 学习笔记

花果山

极客大学架构师训练营

第十三周总结

orchid9

【架构师训练营第 1 期 13 周】 学习总结

Bear在挨踢

极客大学架构师训练营

架构师训练营第13周作业

邓昀垚

架构师训练营第 1 期 - 第十三周总结

Todd-Lee

极客大学架构师训练营

week9 性能优化(三)作业和学习总结

杨斌

作业-第9周

arcyao

redis的I/O多路复用

en

redis 多路复用 epoll

架构师训练营第九周作业

李日盛

架构

盘点2020 | 我要为分布式数据库mongodb在国内影响力提升及推广做点事

杨亚洲(专注mongodb及高性能中间件)

数据库 mongodb 盘点2020 分布式数据库mongodb

成为架构师 - 架构师训练营第 07 周

陈永龙Vincent

阿里云出现大规模宕机,原因系IO HANG,或将做出赔偿-InfoQ