盘点：2014年十大云故障

本杰明•富兰克林曾经说过，这个世界上有两件事情不可避免，死亡和纳税。但如果这位伟大的政治家和发明家活在我们的现代世界，也许服务器停机也会进入这个名单。

[[125642]]

不管底层技术再怎么好，也不管托管提供商再多么能干，云总是会发生故障。

以下这个名单恐怕是这些公司不想看到的：CRN的2014年前10大云故障。

Dropbox，2014年1月10日

这家云存储公司在在1月10日美国东部时间晚上8：30开始出现全球宕机。

事后Dropbox表示，当时他们在对某些设备进行操作系统更新操作，这个系统中保存了图片集共享和相机上传功能所使用的数据库，但并非文件存储的核心业务。升级脚本中的一个小错误导致操作系统在一台动态设备上重新安装，导致系统失控。

Dropbox的网站返回服务器错误信息，台式机和移动设备无法进行文件同步。

大多数服务器通过备份在3个小时内恢复，但是完整的核心服务用了两天时间才完全恢复。

三星，4月21日

当天，韩国南部Gwacheo的一座数据中心起火，在接下来的几个小时内，全球范围的三星智能手机和平板电脑都无法获取他们的数据。

第四层的起火还导致了信用卡服务、三星Smart TV和其他采用三星服务器的设备出现故障。

专家提出质疑，为什么这么多的服务器被放置在了同一个地方，而没有在其他地点提供系统冗余。

Internap，5月16日

在纽约地区的一次公共电力故障后，Internap位于纽约的一个不间断供电系统停机了。停机发生在凌晨三点，对使用托管和IP连接服务的客户造成了影响。

在接下来的7个小时内，Internap一直处于停机状态。

这次停机影响到流视频平台Livestream和StackExchange网络站点。

微软Lync，6月23日;微软Exchange，6月24日

Lync是微软的即时消息和VoIP服务，也是微软云业务产品Office 365套件的一部分，该服务于美国东部时间6月23日在北美洲大部分地区发生中断。

微软称这次中断是由“外部网络故障”所导致，部分用户受影响长达8个小时。

第二天，Lync继续影响Office 365用户，微软的托管电子邮件服务Exchange Online也遭遇相同的命运，部分客户电子邮件服务中断长达9个小时。

微软表示这次中断与Office 365故障无关。

Verizon Wireless，6月27日

Verizon Wireles遭遇了一次广泛的故障，导致其部分计费系统停机，使客户无法访问他们的在线帐户、支付账单，在某些情况下无法升级手机。

系统范围的停机从周五就开始了，持续了大约一天时间，不仅对使用My Verizon 在线账户的客户造成了影响，还影响到Verizon自己的零售商店客户。

No-IP.com恶意中断，6月30日

如果按规模经济生产力衡量的话(+微信关注网络世界)，这并不是一次严重的停机时间，但该事件比其他更令人气愤，因为这是人为造成的停机。

No-IP.com是一家总部在美国内华达州里诺的免费动态DNS服务提供商。微软以打击网络犯罪为由接管了No-IP.com的23个网域，在此过程中，微软还造成180万No-IP.com的合法客户服务中断超过2天。

这些客户中包括SonicWall，一家被戴尔2012年收购的网络安全厂商，该公司表示其数百家客户掉线，包括那些安装了使用No-IP.com动态DNS服务以中继视频输入的安全监控摄像头的建筑物。

联邦法院将对于这些网域的DNS权交于微软，后者称他们遭受了恶意软件的攻击。

微软Azure，8月18日

Azure云在一次作为每月补丁日发布的Windows 8.01安全补丁之后导致部分用户中断服务长达5个小时，引发技术问题。

微软报告称，Azure服务例如虚拟机网站、自动化、备份和站点恢复都在多个地区出现中断。

一些分析师抱怨软件巨头微软事后并未对该事件进行完整检查。

微软Azure，11月18日

正如Gartner知名分析师Lydia Leong在11月这次停机时间之后的抱怨称，“微软无法让Azure服务中断只局限于一个地区，这为很多考虑Azure的企业亮起了红灯。”

11月18日的中断事件影响到全球范围内使用各种Azure服务的客户，而这主要是由云存储服务一次性能升级中出现的小故障所导致。

微软最终确定人为错误是罪魁祸首。

Amazon Web Services CloudFront DNS，11月26日

Amazon Web Services的CloudFront DNS服务器从美国东部时间下午7：15开始持续了近2个小时。在下午9点之后DNS服务器开始恢复备份。

部分网站和云服务发生掉线，在这期间内容交付网络无法完成DNS请求。没有发生什么大事，但是值得列入该榜单，因为它涉及到全球最大的也是运行时间最长的云。

Xen漏洞重启：AWS、Rackspace、IBM SoftLayer，11月下旬

这不是某一次云故障，而是多个公有云[注]被迫进行紧急重启，这次发生在11月下旬的故障中断了很多客户的运营。

Xen开源管理程序中的一个安全漏洞导致了这次重启。

AWS、Rackspace和SoftLayer都向客户发出了警告——有些情况下仅数个小时——称将会出现暂时脱机的情况，然后他们需要重新启动他们的云服务。

所有云提供商完成补丁安装之后向公众发了一则咨询建议。