云安全事件回顾 云服务安全隐患何时休

　　云服务安全隐患何时休？这是业界普遍希望解决的难题，但是却一直是悬而未决的问题。借着盛大云安全事件，这里回顾一下过去多年发生的云安全事件。
　　
　　sidekick的严重事故
　　
　　SIDEKICK这次事故非常的严重，在2009年的那个冬天，微软拥有的SIDEKICK服务中断了一个星期，用户不能访问自己的邮箱，日历还有其他个人数据，更为严重的是这个错误持续了一个星期。微软随后承认这些数据无法恢复，因为技术人员忘记了备份，随着时间的发展，忘记备份这样的低级错误应该不会再发生，但这个教训是严重的，无论你是否使用的是云储存，都需要备份自己的数据。就像AlertSite公司负责监视产品的副总裁KenGodskind说的那样，使用云的机构不能仅仅假设因为它是在云中，业务持续性计划的全部责任已经交给了提供商。
　　
　　Gmail的故障
　　
　　Gmail这次的错误和每个人都息息相关，有十五万用户在登陆自己的GMAIL账号之后，看到的是一个空白页，用户们顿时晕眩了，谷歌修复这个故障的时候用了四天时间，谷歌负责工程的副总裁BenTreynor当时在博客中称，如果有你的数据的多个副本，怎么会发生这样的事情？在很少出现的情况下，软件瑕疵能够影响几份数据。那就是这里发生的事情。
　　
　　值得庆幸的是谷歌改用物理磁带备份以便恢复数据。最终，谷歌的多层数据保护确实发挥了作用，但是，仍有数千用户在后来的几天时间里无法访问其电子邮件。AlertSite公司的KenGodskind称，当你查看广泛的平均状况时，云的运行成功率远远高于你个人的运行成功率。这只是当你进入到Web规模时，故障的影响以更大的方式放大了。
　　
　　Hotmail的故障
　　
　　说完了谷歌，改论道Hotmail了，那是2010年年底，微软的Hotmail出现了数据库错误，这次事故导致数万个邮箱账户被清空，微软表示这是一个脚本错误造成的，他们为了创建一个删除虚拟账户的脚本吗，错误的删除了一万七千个真实账户。微软花了三天时间恢复了绝大多数的数据，但仍有将近8%的用户无法访问，最后完全恢复，大约花了一周的时间。微软有时候也会出很可笑的错误，这个解释似乎不是很能令人信服，用户当然也不会得到任何赔偿。。
　　
　　Intuit两次宕机
　　
　　Intuit的事故更具有典型性，这次事故深刻的反应了云计算服务器潜在的严重威胁，甚至是不可抗拒的。
　　
　　Intuit去年遭遇一次严重故障。它的基于云连接的服务，包括TurboTax、Quicken和QuickBooks等流行的平台在一个月内发生两次断网事故。最最糟糕的一次是去年6月的一次36小时断网事故。一次电源故障显然导致主要设备使用备用电源，该公司主要的和备份的系统完全断网。
　　
　　更糟糕的是，几个星期之后，又发生了一次明显的电源故障。此外，第二次中断显然引起了人们的大骂。
　　
　　一个用户当时在微博中称，25小时的断网是很难忍受的。Intuit的被动的、不透明的和无法接受的沟通没有帮助。
　　
　　PayPal断网故
　　
　　2009年夏季PayPal的断网故障是真的，让全球数百万台机器无法销售商品。这项服务在大约一个小时的时间里完全不可用，在后来的几个小时里仍是断断续续的。PayPal称，硬件故障是事故的原因。
　　
　　毫无疑问，这种中断故障是很少发生的。但是，这个不幸的断网故障使PayPal轻松在云计算的耻辱堂上赢得一个位置。
　　
　　微软商务办公在线套件故障
　　
　　当你的基于云的办公套件出现故障时，那是很难有办公效率的。那是几个星期前依赖微软商务云服务的机构发生的事情。微软BPOS服务开始出现断断续续地工作的情况。一些用户的电子邮件因此延迟了9个小时才收到。
　　
　　两天后，就在BPOS好像排除了故障的时候，延迟的现象又发生了，向外发出的信息也阻塞了。如果这个事故还不够的话，微软还经历了另一个故障，阻止用户登录基于Web的Outlook门户网站。
　　
　　微软在线服务部门副总裁在博客中称，我要因为这个故障引起的这些不便向你们、我们的客户和合作伙伴表示道歉。
　　
　　Salesforce服务中断
　　
　　一个小时的断网故障听起来也许不严重。但是，如果你的公司拥有数万家企业客户服务业务的关键，许多这样的机构肯定要把这60分钟看作是生命期。
　　
　　当去年1月数据中心关闭的时候，Salesforce.com吸取了深刻的教训。在进入新的一年刚刚四天的时候，Salesforce.com报告了一次全面的故障，也就是说服务、备份等全套服务都中断了。
　　
　　柯尼卡美能达的子公司AllCovered的首席信息官TimCrawford称，现实是基于云的数据中心也中断了。那一直是故障的原因并且总是这种情况。我们对此必须现实一些。
　　
　　Crawford称，成功的云计算需要一个与传统的服务器设置不同的思维方式。你要自己决定你的企业的数据是否能够承受偶尔的断网。如果不能承受，你要保证你的配置有避开断网故障所需要的弹性。
　　
　　当你选择一个云提供商的时候，你需要做家庭作业以理解他们如何提供这些服务，他们是否能够建立比你自己做的还要好的冗余水平。如果答案是否定的，那么，你为什么要使用这些云提供商呢？
　　
　　Rackspace宕机事故
　　
　　Rackspace在在2009年全年遭遇了四次引人瞩目的断网故障，使该公司的客户的断网时间达到几个小时。Rackspace不得不向用户赔偿了将近300万美元的服务费。
　　
　　Rackspace把这些事故称作“痛苦的和非常令人失望的”并且承诺以后在很长时间里都要高水平地提供服务。目前，该公司继续把重点放在运行时间方面，但是还帮助用户制定计划准备应对在云服务中不可避免地出现的混乱局面。
　　
　　云提供商Terremark严重事故
　　
　　最近，Terremark与Verizon之间的10亿美元的交易也许成为了重要新闻。但是，在2010年年初，主要报道的新闻是Terremark的断网事故。
　　
　　在2010年3月17日Terremark公司的vCloudExpress服务在那一天急转直下，在迈阿密的数据中心断网了大约7个小时。在这段时间里，用户不能访问存储在这个数据中心的数据。
　　
　　没有得到更多的冗余。但是，这带来的冗余的价值，让你的重要数据提供到不同数据中心的多台服务器，或者最好是提供到不同地区的多台服务器。作为一种故障保险，你还可以采取额外的步骤把数据分散到不同的提供者。
　　
　　亚马逊Web服务中断
　　
　　乏味的网络维护工作是令人讨厌的，但在操作系统还并不是非常成熟的前提下，贸然使用启动会维护有很高的风险，典型性设置和通用性设置的具体参数，都不为用户所熟知，一旦发生故障，用户立即会变得束手无措，因为他根本不知道那操作平台背后究竟隐藏着什么。亚马逊最严重的一次故障，在亚马逊美国北弗吉尼亚数据中心，发生了严重的故障，这个错误是一个错误的路线的有通讯移动，吧一连串的亚马逊EBS通讯量发送到了一个新的镜像，这种反常现象造成了美国亚马逊在东部地区的服务大规模中断，更可怕的是这个错误持续了四天未修复。很多企业因此迅速陷入了困境之中，造成了严重的损失。