世界上最严重的十大云服务宕机事 件.docVIP

云服务是很讨人很喜欢的概念。毕竟，丢弃那些笨重的服务器，只要给自己弄一只大容量的云硬盘就可以了。反正别人会负责维修；你想把数据放在哪里，就可以放在哪里。 当然，现实情况是喜忧参半。一方面，你可以避免维修；但另一方面，你丧失了控制。另外还需要考虑安全问题。但是一旦云服务宕机，那真的是一个活生生的噩梦。 那只要问一问今年4月受到亚马逊网络服务的重大宕机事件影响的随便一家公司。 Nick Franci说：“当时我们完全给搞蒙了；我们绝对是毫无防备。”就在亚马逊出现问题一周前，他的新兴公司Help Scout才开业。 亚马逊云服务 措手不及的并非只有Francis一人。当亚马逊的云服务出现故障时，像Reddit和Foursquare这些大牌公司同样动弹不得。 Lew Moorman是Rackspace的首席战略官，这家云服务提供商也遇到过宕机事件。他说：“人们觉得云计算是一项切实可用、完全可靠的神奇技术。事实上，通过云来购买是另一种购买计算的方式，而计算本身是有缺陷的。如果你想确保那些缺陷不会影响到自己，就必须未雨绸缪。” 为了帮助贵公司在云环境下高枕无忧，我们分享了这些来之不易的经验教训，它们源自互联网经历的十大云服务宕机风暴。 第一大云服务宕机事件：亚马逊网络服务完蛋 可以摆脱繁琐的网络维护工作是在云环境开展业务的一个主要卖点。那有什么缺点吗？当云服务提供商的日常配置变更导致贵公司的业务陷入停顿时，你会有一种孤立无援的感觉。 亚马逊网络服务的许多客户在去年4月就经历了这一幕，当时亚马逊建在北弗吉尼亚州的数据中心遭到了一个故障，最后彻底歇菜了。 这个错误在网络升级升级中开始出现了，当时流量转移到错误的路径上传送后，亚马逊的一组弹性块存储（EBS）卷不断地重新映像，于是它们寻求可用的设备以便对自己进行备份。结果就引发了一连串事件，最终导致该公司在美国东部地区的服务大部分瘫痪。 这个问题持续了大约四天。但是就在许多公司苦苦挣扎的同时，Netflix等其他公司顺利渡过了难关。存活下来的关键是什么呢？那就是在设计系统时要考虑到这些类型的故障。 Netflix的几名工程师在《Netflix从亚马逊网络服务宕机中汲取的经验教训》博文中写道：“我们的架构避免使用EBS作为我们的主数据存储服务，我们实际上依赖的SimpleDB、简单存储服务（S3）和Cassandra服务没有受到这次宕机的影响。”无状态服务和数据的多个冗余热副本分散在多个可用区是避免云服务故障的关键。 是否认为自己非得像Netflix这等规模的公司才能保持安全？那你就错了。Twilio公司专门帮助开发人员把通信功能集成到自己开发的Web应用程序中，它使用亚马逊的弹性计算云（EC2）来托管其基础架构的核心部分——不过亚马逊的宕机事件对于该公司的稳定运行几乎没什么影响。 Twilio的联合创办人兼首席技术官Evan Cooke说：“将业务建立在云环境上的基本前提是，要假定网络会有这样那样的故障和毛病。我们在建立基础架构时就设想主机可能会出现故障，于是我们没有依赖核心架构中的任何一台机器或任何一个组件。” 第二大云服务宕机事件：Sidekick宕机 智能手机让你出门在外时很容易访问自己的数据，但就因为某样东西的名字里面有“智能”（smart），并不意味着它就万无一失。一个典型例子就是：T-Mobile的Sidekick在2009年秋天前后搞砸了。 还记得那次惨败吗？微软旗下的Sidekick遭遇了服务将近一周宕机的尴尬，导致用户们无法访问电子邮件、日历信息及其他个人数据。后来雪上加霜的是，微软承认自己完全丢失了存储在云环境中的数据，自己无力恢复。显然，来自雷德蒙的那群技术精英们之前忘了备份数据。 也许此后技术有所发展，但教训仍然一样：说到关键数据，千万不要想当然地以为别人会自动保护你。确保你了解云服务提供商的灾难恢复系统；如果你自己作了安排，独立备份重要数据，那就更好。 SmartBear旗下AlertSite公司的监控产品副总裁Ken Godskind说：“同样的操作规则甚至适用于云环境。使用云服务的企业千万不要想当然地以为，就因为数据在云环境中，业务连续性规划方面的全部责任可以一股脑儿地扔给提供商了。” 第三大云服务宕机事件：Gmail故障 在所有云服务iv 中，谷歌的Gmail是比较有可能在企业领域危及微软预置型软件的劲敌之一。把需要精心维护的Exchange服务器换成由Postini支持的一种廉价而可靠的电子邮件服务。谁不喜欢呢？ 此后出现了一连串令人恼恨的宕机事件，最近一次是15万个Gmail用户登录进入到帐户，结果却发现里面空空如也：没有电子邮件，没有文件夹，没有什么可以表明他们看到的就是自己的收件箱。值得肯定的是，谷歌定期提供更新版，承诺很快会拿出权宜之计。但对于一些受到影