上周四，由于亚马逊网页服务器出现故障，包括基于位置的社交网站FoureSquare，问题和解答服务商Quora;新闻共享网站Reddit以及为网络出版商提供游戏工具的BigDoor瘫痪。
尽管北京时间4月25日，在亚马逊最新的公告中，我们看到了“‘Majority' of Cloud Problems Resolved”——大多数受到影响的数据库已经得到了恢复，但是对于牵涉其中的用户来说，这实在是非常漫长的煎熬。我们能从此次事件中获得哪些教训呢？
教训一：将应用分布在不同区也不能避免遭受宕机之苦
对于愿意多付一点钱的云客户，亚马逊提供了一项很有诱惑力的提议——将应用分布到多个可用区上，可获得一项几近保证的服务：不会遭受宕机之苦。
目前，不少公司正将他们的计算基础设施外包给数据中心，以避免琐事并降低运营成本。目前，包括辉瑞和Netflix在内的数千家企业都是亚马逊云的客户。
“在分开的可用区上运行实例，可放置你的应用程序在单个位置上出现故障。”亚马逊在推广其弹性计算云服务——EC2时如此说道。
只在一个可用区上创建应用的客户更容易遭受服务中断的故障。但是，多个可用区同时停止运行时将会怎样？我们已经看到了结果：一次服务器宕机令多家网站无法访问。
教训二：不要理所当然地相信云服务供应商的保证
令人吃惊的是，亚马逊云服务中断将近4天却没有违反亚马逊EC2服务的服务等级协议（简称SLA）。亚马逊FAQ问答解释说，“它确保在365天的服务期内一个区域拥有99.95%的服务利用率。”由于亚马逊出现故障的是EBS和RDS服务，而不是EC2服务，因此，从法律上讲，它并没有违反服务等级协议。这当然不能安抚受影响用户的心，也不能成为他们该受影响的理由。这一点的确应该引起我们的深思。
IDC的分析师Matthew Eastwood指出，该事件实际上是再一次敲响了云计算技术乃至整个产业的警钟，它将迫使云计算行业重新考虑这项远程控制技术所面临的问题。
目前来看，许多受到影响的用户都准备支付额外的费用将他们的数据保存到多个可用区（Availability Zone）。亚马逊建议用户这样做实际上是为了确保在服务中断的情况下能够及时恢复用户的数据。根据亚马逊FAQ问答，每个可用区“都是独立运行的，其基础架构在物理上都是截然分开的，这样的工程设计是为了确保数据的可靠性，即使一个可用区的发电机和冷却设备等出现故障，也不至于影响到其他可用区的服务。而且，由于这些可用区在物理上是截然分开的，因此，即使是像火灾、龙卷风或洪水这样的极端自然灾害也只能影响到一个可用区。”不幸的是，人们到最后才发现亚马逊说的这一切只是技术规范，并没有成为合同保障。亚马逊可能需要花费一番功夫才能修复它被此次事件损坏的名声。
教训三：准备多套方案应对云服务供应商可能的故障？
正如技术出版公司O'Reilly的乔治-瑞斯（George Reese）所说：“如果你存储在亚马逊云中的系统失败，这不是亚马逊的错。这要么是你命里该有此一劫，要么是你的系统设计不符合亚马逊的云计算模型。”因此，用户很有必要准备多套方案，应对云服务供应商可能会出现的故障。
但是，多套方案似乎只是一厢情愿而已，Gartner分析师Drue Reeves指出，客户应与提供多个地点的多家提供商签订协议，从而可以在单个销售商发生故障时能够幸免于难。
这种方式现实吗？Reeves给出了否定的回答，只是对于大多数客户是如此。云计算应简化应用的部署和管理。创建一个可工作于多家销售商平台上的应用需要大量的额外投入。
“无法在多家云提供商上构建应用的原因在于，缺少标准和互操作性。”Reeves说道：“如果你是应用创建者，你需要增加存储或计算容量，这些容量的分配、收费和使用，对于每个提供商都是不同的。这不是做不到，而是非常非常困难。”
据说了解，在亚马逊服务中断事件中，有几家公司幸免于难。例如，Twilio公司的服务就没有关闭。该公司没有详细说明它在北维吉尼亚可用区的业务受到了怎样的影响，但是它的联合创始人兼首席技术运营官埃文-库克（Evan Cooke）在博客中描述了其基础架构的设计原则。这些原则包括将资源分解到各个独立的存储池中，支持超时连接和重试等待。
另外一个没有被关闭的站点是NetFlix，它的所有基础架构都在亚马逊云中运行。但是，目前也不清楚它的业务在该事件中受到影响的程度。
教训四：增强恢复能力需要加大投入
鲍勃-沃菲尔德（Bob Warfield）描述了此前一家公司使用Amazon.com基础架构的方法，该方法能让这家公司“在一个可用区的服务中断时，能用另一个可用区的数据在20分钟内恢复服务，而且只会造成不超过五分钟的数据丢失。”他继续说道，你选择的你准备支持的中断服务的时长，决定了你必须承受的成本。“聪明的用户和PaaS（平台即服务）供应商会多准备几个选择，因为首先你不论如何必须在亚马逊S3服务器上做个备份，其次还需要选择几个替代的站点。你所要考虑的只是这些替代站点的服务能否够热情，价格是否优惠。”
此外，用户还需要向云服务供应商问一些必要的问题，以确保你所依靠的云服务不会让你遇到类似的服务中断问题（或者即使遇到了，你也能理解它，并愿意以较低廉的成本承担相应的后果）。鲍勃-沃菲尔德特意提到了NetFlix公司的做法，该公司为了测试其恢复能力，通常会随机地破坏其资源和服务。
“这可能是你需要向你的PaaS（平台即服务）和云服务供应商提出的第二个问题——’你们有没有通过破坏生产基础架构的方法来测试你们应对故障的能力？”当然你会乐意看到他们进行测试，而不仅仅是听他们口头上说说。
教训五：选择云计算服务商透明度非常重要，缺乏透明度是亚马逊的致命弱点
几位受到影响的用户抱怨，在服务中断期间，亚马逊并没有及时公布最新的信息。BigDoor公司首席执行官基思-史密斯（Keith Smith）写道：“如果亚马逊能开诚布公地说明他们目前正面临的问题，那么我们就能更快地恢复我们的系统。”GoodData公司的罗马-斯坦克（Roman Stanek）呼吁亚马逊拆除保密的墙：
“我们无法从一些支离破碎的信息中得知究竟该如何组织我们的系统，从而提高它的性能、灵活性以及最重要的灾难恢复能力……在云计算基础架构中，IaaS（基础设施即服务）、（PaaS平台即服务）、SaaS（软件即服务）和客户之间不应该竖着一堵妨碍相互沟通的墙壁。”
在未来几周，亚马逊将要遇到的挑战是：它必须向用户证明它的恢复工作已经准备就绪。如果亚马逊不能够做到这一点，而其他云服务供应商却比它做的更好，那么它将会逐渐开始失去它目前在IaaS（基础设施即服务）供应方面的统治地位。
教训六：所谓的无坚不摧都是鬼话
在去年12月‘匿名’组织弄垮网站的尝试失败后，亚马逊著名的大型服务器据说是不可能崩溃的。云计算被宣传为安全可靠的工具，但是这次中断似乎动摇了客户对云计算服务的信心。
实事上，用户的担心并非不无道理，根据CSDN之前的一项对国内云计算应用的调查显示，超过60%的用户认为，云计算的架构缺陷是他们不得不考虑的问题（P.S. 云计算：省钱次要 基础架构性能提升是关键）。
尽管如此，对于大多数用户来说，无论他们遭受到了多么严重的影响，他们都会赞颂亚马逊，称其帮助他们用较少的成本和精力运营着一个强大的基础架构。许多人在批评亚马逊之前都会首先感谢亚马逊帮助他们做到的事情。例如，BigDoor公司的首席执行官凯斯-史密斯（Keith Smith）就说：“亚马逊网络服务（AWS）让我们迅速建立起了复杂的系统，而且非常节约成本。在任何给定的时间内，我们都有12个数据库服务器，45个应用程序服务器，6个静态服务器和6个分析服务器处于待命状态和正在工作。当流量或处理要求增加时，我们的系统就会自动增加工作服务器的数量；当流量减少时，我们的系统就会自动减少工作服务器的数量，从而节约成本。”
对一些从亚马逊EC2平台上得到了好处的用户而言，他们认为云计算模式仍然是安全的。Rackspace公司的首席战略官卢穆尔曼表示，亚马逊数据中心服务中断事故对云计算行业造成的影响相当于一次航空事故，目前航空旅行仍被视为比汽车行驶更安全的交通方式。数据中心依旧比那些拥有自己IT基础设施的个别公司更安全。关键的是，业界应该从亚马逊服务中断事故中汲取教训。