企业客户越来越意识到,虽然公有云供应商并非完美,但对于IT基础架构也没有其它替代方案。因此,经历宕机事件之后,相对于重新评估是否拥抱公有云模式,企业往往更有兴趣了解宕机的根本原因,并认为无论出现什么问题,都会得到适当修复。
无论宕机是影响到企业工作负载或是热门消费者应用,用户更愿意看到供应商实现透明性并承担责任,而实时响应与事后分析活动往往是检验客户得失的差别所在。
供应商越大,它们的报告和修复标准就越高。无论是技术故障,人为错误或恶意攻击造成的,客户都希望对所建立的修复措施进行真实评估和解释,以确保不会再发生同样的情况。
1月26日,IBM
今年年初,IBM云的信用度受到影响,客户用于访问其Bluemix云基础架构(以前称为SoftLayer)的一个管理网站服务中断了数小时。
虽然底层基础架构没有真的出现故障,但用户发现他们无法管理自身的应用程序,添加或删除支持工作负载的云资源。IBM表示该问题是由于一次接口升级造成,只是间歇性的。
1月31日,GitLab
一些客户的生产数据最终丢失,包括对项目,评论与帐户的修改。
该公司在事件后表示:“我们最合理的估计是此次影响了约5000个项目,5000个评论和700个新用户帐户。“
GitLab CEO在向用户道歉时称,“丢失生产数据是让人无法接受的”。
2月9日,Instapaper
亚马逊RDS服务上的MySQL数据库文件大小限制引发了Pinterest服务器的长时间宕机。
之后,这家社交化书签网站称,其工程师从来不知晓在2014年4月之前创建的数据库RDS容量限制为2TB,并且AWS服务也没有发出表内存储其“书签”即将超过该限制容量的警告信息。
2月24日,Facebook
世界各地的一些用户Facebook账户被锁定了近三个小时,这让他们担心自己的帐户被劫持了。
Facebook给出的解释是为了预防黑客错将用户发送到恢复界面,让人觉得其他人登录了他们的帐户。而受影响的用户被阻止立即重新登录。
2月28日, AWS
这次宕机事件极为轰动,相信大家对此记忆尤深。当时是一位AWS工程师试图调试亚马逊的弗吉尼亚数据中心S3存储系统,但输入了一个错误指令,导致许多互联网——包括诸如Slack,Quora和Trello等众多企业平台宕机4个小时。
亚马逊在事件后分析表示,该员工当时当时打算将一小部分用于计费过程的托管子系统服务器删除。然而,错误命令导致了更多的服务器脱机,包括为数据存储功能提供特定请求所需的一个子系统和另一个分配新存储空间的子系统。
亚马逊坐拥约三分之一的全球云市场,因此这次宕机事件重新引发了关于公有云的风险论。
3月16日,Microsoft Azure
微软Azure公有云出现超过8小时的存储可用性问题,主要影响到美国东部的客户。有些用户无法配置新的存储空间或访问本地现有资源。之后,一个微软工程团队确认原因为断电导致的存储集群不可用。
除此之外,微软还在Azure状态页上列出了一个软件错误,该错误影响跨多个服务的存储配置超过一个小时。
3月21日,Microsoft Office 365
5月22日,在IBM云上的Lululemon
热门瑜伽网站Lululemon出现服务中断问题,其首席执行官将主要责任归咎于IBM的托管云服务。
Lululemon首席执行官,Laurent Potdevin在接受CNBC(美国全国广播公司财经频道)采访时直接指责在IBM云环境下电子商务销售额遭受了损失。并表示他的团队由于这个问题连续工作了36个小时,并已经向IBM CEO,Ginni Rometty表达了不满。
Potdevin在谈及对IBM云计算时称,“我们正在考虑我们的选择”。
6月19日,Microsoft Skype
主要分布在欧洲的微软Skype用户由于遭受明显的分布式阻断服务攻击,接连出现宕机问题。
6月19日,Skype用户开始抱怨多个小时的宕机问题。这次宕机持续到次日,用户在通信平台上无法连接,交流信息受阻。
虽然微软没有立即确认DDoS攻击的报道,但一个名为CyberTeam的黑客组织在推特上承认该事件是他们所为。
6月28日, 苹果iCloud
IDCsped 提供最新的IT互联网资讯,本着分享、传播的宗旨,我们希望能帮助更多人了解需要的信息!
部分文章转载自互联网、部分是IDCsped原创文章,如果转载,请注明出处:www.idcsped.com !销售电话:13430280788
Copyright © 2012-2017 | www.idcsped.com 版权所有