云计算服务在这个时代被吹捧成为IT圣者，所有的服务都可以被“云”化。随着云技术逐渐成熟，云提供商也日益成熟，在大多数情况下，云的整体正常运行时间和稳定性也在提高。

虽然云故障不像过去几年那么特别普遍了，但它给企业客户带来的伤害却比以前更大了。每次故障，不管如何迅速补救，都会对技术信誉造成一定影响，阻碍客户更广泛的采用。

小编在这里用近年来发生的一些数据中心故障事件总结一下几大故障类型，也许能让你看到，即便是计算机也会在所难免地出错，再保险的措施似乎也只能把安全事件控制在一个小概率范围内。

断网类型一：系统故障

典型事件1：亚马逊AWS平安夜断网

故障原因：弹性负载均衡服务故障

2011年8月6日，在北爱尔兰都柏林出现的闪电引起亚马逊和微软在欧洲的云计算网络因为数据中心停电而出现大规模宕机。闪电击中都柏林数据中心附近的变压器，导致其爆炸。爆炸引发火灾，使所有公用服务机构的工作暂时陷入中断，导致整个数据中心出现宕机。

典型事件2：超级飓风“桑迪”袭击数据中心

故障原因：风暴和洪水导致数据中心停止运行

2012年10月29日，超级飓风“桑迪”袭击了纽约和新泽西州的数据中心，这次自然灾害所带来的恶劣影响包括为曼哈顿下城地区的洪水和一些设施的停机，周围地区数据中心发电机运行失常。飓风桑迪所带来的影响超出了一般单一的中断事故，为受灾地区数据中心产业带来了规模空前的灾难。事实上，柴油已然成为了数据中心恢复工作的生命线，作为备用电源系统接管了整个地区的负荷，促使特别措施，保持发电机的燃料。随着眼前的工作重点逐步转移到灾后重建，我们有必要长期就数据中心的选址、工程和灾难恢复进行探讨，这一话题可能将持续几个月，甚至几年。

断网类型三：人为因素

典型事件1：Hosting.com服务中断事故

故障原因：服务供应商执行断路器操作顺序不正确造成的UPS关闭

2012年7月28日Hosting.com停运事件。人为错误通常被认为是数据中心停机的主导因素之一。Hosting.com中断事件造成 1100名客户服务中断就是一个例子。停机事故的发生是由于该公司位于特拉华州纽瓦克的数据中心正进行UPS系统预防性维护，“服务供应商执行断路器操作顺序不正确造成的UPS关闭是造成数据中心套房内的设施损失的关键因素之一。

典型事件2：微软爆发BPOS服务中断事件

故障原因：微软在美国、欧洲和亚洲的数据中心的一个没有确定的设置错误造成的

2010年9月，微软在美国西部几周时间内出现至少三次托管服务中断事件向用户致歉。这是微软首次爆出重大的云计算事件。
事故当时，用户访问BPOS服务的时候，如果使用微软北美设施访问服务的客户可能遇到了问题，这个故障持续了两个小时。微软当时声称：“这次数据突破事件是由于微软在美国、欧洲和亚洲的数据中心的一个没有确定的设置错误造成的。”

断网类型四：系统Bug

典型事件1：Gmail电子邮箱爆发全球性故障

事故原因：数据中心例行性维护时，新程序代码的副作用

2009年2月24日，谷歌的Gmail电子邮箱爆发全球性故障，服务中断时间长达4小时。谷歌解释事故的原因：在位于欧洲的数据中心例行性维护之时，有些新的程序代码有些副作用，导致欧洲另一个资料中心过载，于是连锁效应就扩及到其它数据中心接口，最终酿成全球性的断线，导致其他数据中心也无法正常工作。

典型事件2：“5.19宕机事件”

事故原因：客户端软件Bug，上网终端频繁发起域名解析请求，引发DNS拥塞

2009年5月19日的21：50，江苏、安徽、广西、海南、甘肃、浙江等六省用户申告访问网站速度变慢或无法访问。经过工信部相关单位调查通报称，此次全国六省网络中断事故，原因是国内某公司推出的客户端软件存在缺陷，在该公司域名授权服务器工作异常的情况下，导致安装该软件的上网终端频繁发起域名解析请求，引发DNS拥塞，造成大量用户访问网站慢或网页打不开。

目前来看，解决的办法大致可以从两个角度出发，对于企业级客户来说，务必在采用云服务的同时定期备份云端的数据，拥有第二套解决方案，以备不时之需。

而对于我们（fs.com）提供商来说，既然各种宕机事件是人为不可控制因素，我们就必须为我们的客户思考种种对策，将用户的损失降到最低，对故障事件的响应效率提升到极致。

更多有趣的内容和扎实的干货，欢迎来找我，坐标在图片上哦~