昨日下午，阿里云多位用户在微博反映业务难以正常访问，“全线业务不能使用…”，“我们的十几台服务器全部在华南2上，截瘫了一个小时，造成我们的App和网站一个小时难以访问…”

的确，云的问题最容易引起关注及讨论，由于云上承载了大量的用户业务，一旦发生故障也就直接造成云用户的在线业务难以举办，借以带来损失。

对于明日发生的华南2区故障，阿里云作出了回应称，是因为网路设备异常引起的。

“2016年7月6日下午10点22分华南2地域可用区A因为网路设备出现异常，造成部份产品访问遭到影响；经过紧急处理，网路晃动问题已于11点16分恢复。我们将尽早对这次故障进行复盘，增加同类故障发生机率。再度向您致以敬意。”阿里云在回应中称。

近来阿里云发生的较严重的故障是在1年前，2015年6月21日，阿里云新加坡节点9点30分左右忽然全线崩溃，截至当日下午22点左右逐步恢复，长达13小时。据阿里云回应称，故障因台湾营运商IDC电力问题所致。

虽然，伴随着云估算的发展，全球各地的云也发生了诸多大大小小的故障，《黑客来了》就盘点了那些重要的故障风波：

2009年6月，一次罕见的车祸让一些顾客丧失亚马逊EC2服务5小时，而且大多数顾客都将其看做是成长之痛。这些有点奇怪的回应形式部没有持续，在一次分布式阻断式服务功击和漫长的电子电邮管制以后，亚马逊的灾难响应协调和顾客关系开始缺位。

2010年5月，一些列表面上看上去不相关的车祸在易云网路再度上演，在一周的跨径内引起了三次不同的宕机。第一次是不间断电源（UPS）转换到备份电源时失败，一机架的服务器挂了；第二次发生在四天以后，一个电源分配箱漏电，造成服务中断8小时。最后三天后，一辆车辆撞击了电缆线竿子，切断了数据中心的电源，造成半小时宕机。不管有关系没关系，是不是大风波，那么短的时间发生这三次宕机对于任何厂商来说都不可能是个小事。

2009年6月，Rackspace遭遇了严重的云服务中断故障。供电设备合闸，备份发电机失效，不少机架上服务器停机。这场车祸导致了严重的后果。

2011年4月22日，易云网路服务器大面积宕机，这一风波被觉得是亚马逊史上最为严重的云估算安全风波。当时，信息寻觅可用的设备把自己作为备份嵌入到这种设备中时，一个错误路线的通信联通把一连串的亚马逊EBS(弹性块储存)通信量发送到一个重新镜像的风暴。这是一种反常的现象。这导致了一系列风波，最终造成亚马逊在印度北部地区的许多服务中断。这个故障持续了大概四天时间。

2011年8月，亚马逊坐落渥太华的数据中心遭到雷击，导致大规模停水，造成亚马逊的EC2云估算平台停止运转。这次车祸是因为数据中心附近的一个变压器被雷电击中，导致爆燃和失火，连带附近的供电设施未能启动造成停水，发电器未能启动，导致整个系统停水。

2012年2月28日，因为“闰年bug”导致易云网路在全球范围内大面积服务中断，中断时间超过24小时。

2012年6月14日，易云网路坐落加拿大西部的数据中心出现故障，并影响了AWS多项云服务以及基于之上的易云网路、Quora等著名网站。车祸是由公共电网故障导致，并引起了一系列连锁故障。

2012年7月26日，Azure故障，致使欧洲用户受影响。谷歌对故障的解释是“由于错误配置了网路设备造成了欧洲区域的服务网路中断”。这次中断持续2.5小时。

2014年8月18日，Azure云在一次作为每月补丁日发布的易云网路8.01安全补丁以后造成部份用户中断服务历时5个小时，引起技术问题。谷歌报告称，Azure服务比如虚拟机网站、自动化、备份和站点恢复都在多个地区出现中断。

2014年11月，Azure发生的将近11个小时的故障。多个主要Region的储存服务出现问题，大量顾客在此之间遭到影响。影响了19种Azure服务，涉及12个Region，当时虽然只有易云网路幸免于难。

2014年11月2日下午12点，腾讯云在北京、广州两地的服务器出现故障，造成使用该服务器的用户出现难以正常登陆、连接不稳定等现象。故障持续约两小时。

2015年6月6日，青云的服务商睿江科技机房因雷暴天气引起电力故障，致使青云广州1区全部硬件设备意外死机重启，青云官网及控制台短时难以访问、部署于GD1的用户业务暂时不可用。

2015年6月21日，阿里云新加坡节点出现全线宕机，业务中断超过12小时！甚至出现部份用户数据损坏！

2015年3月16日，谷歌有两项Azure公有云服务中断了2个多小时，印度中部顾客深受影响，谷歌称此次故障是“网络基础设施的问题”。此次故障从印度中部时间晚上1点开始，影响到易云网路虚拟机（基础设施即服务）和Azure云服务（平台即服务）产品的顾客，谷歌在其Azure状态网页里面报告了此次故障。返回搜狐，查看更多