上周，又一AWS服务的失效冲击了几大网站及其服务。如何才能避免瘫痪？仅为伸缩进行架构还不够，还需为灾备进行架构。

根据AWS服务健康仪表板，Amazon东区（北弗吉尼亚区）AZ的一组云服务——EC2、EMR、RDS和弹性Beanstalk失效，时间大约从六月29日下午7：25起，至六月30日下午3时止。该失效影响了许多公司及其服务和网站，其中有Netflix、Instagram、Pinterest和Herokua。据Amazon报道，罪魁祸首是“由横扫北弗吉尼亚地区的大面积电暴引起的”电力事件，上周五晚间一场暴风雨袭击了美国东部地区，导致13人丧生，三百万人口被停电。

除了电力设施的波动之外，一次巨大的电压脉冲袭击了两大计算中心，迫使它们切换到发电机供电模式，但是其中一个数据中心的发电机未成功运行，导致了相应数据中心在耗尽UPS之后停电。电力很快就得到恢复，但是将服务恢复至所有功能完好却需要长得多的时间。Inmar的架构副总裁Mike Kavis解释了需要这么长时间的原因：“事实上，虽然Amazon的备份电源切换进来，但是并非所有的计算资源得到成功灾备。其结果是有一组虚拟服务被踢下线，直到AWS恢复它们为止。用户（译注：AWS的用户）对于这一情况的应对措施决定了其应用是瘫痪还是保持弹性。许多网站瘫痪了。”

考虑到这类事件对于理解如何避免瘫痪的重要性。这次AWS的电力事故之后，Kavis在其博文中说，他的公司自2009年起经历过5次AWS失效，但是他们的服务从未宕机过。原因是他们使用了多个Zone和Region。

Amazon的每个Region的SLA可达到99.95%。在同一区域里从未发生过多个Zone同时失败，也从未出现过多个Region同时失败的情况。本质上，他们提供了计算资源的100%正常运行时间（uptime）。只不过这取决于我们如何架构系统以利用Zone和Region的优势……

我们假设平台中的每个服务器和服务都可能在某个时间点失败，所以设计出多条通路，使之能在多个Zone的冗余计算资源上继续处理交易。换言之，我们假定区域内的Zone可能会失效，所以将平台设计得不依赖于单个Zone。

但是，多个Zone也不够，Kavis说：

在这些失效中，我注意到一个模式，即AWS的RDS服务（将数据库管理过程自动化的服务）似乎在每次Amzon出现问题时都会失效……

事实上，我们手动管理我们的MySQL数据库才是我们在这些失效中保持弹性的主要原因之一。如果我们依赖于RDS，我们也不会那么幸运。这是否意味着AWS客户不该使用RDS呢？不，我们仍然用它实现一些无需极端SLA的功能并提供与各销售点系统的实时连接。

Kavis提到，上次AWS失效所袭击的一些公司有着“目前看到的最吸引人、最先进的高可用环境的架构”。但是，他们为了伸缩性牺牲了正常运行时间（uptime）：

无SLA要求的免费社交媒体网站就可能会把更多的时间花在支持上百万并发用户的伸缩性上，同时会面临一至两个小时宕机的风险。对于他们而言，把精力花在处理突发访问量比关注不太容易发生的AWS失效更有价值。毕竟没有人会因为无法向Facebook传照片而死掉。

其结论是：若要实现永远可用，就要为灾备进行架构，而不仅仅为伸缩性架构。正如Kavis所言，“我们需要理解的是，弗吉尼亚地区的许多公司自建的数据中心也瘫痪了，而且仍然处于瘫痪中。发生了电力故障。云端和本地的数据中心都瘫痪了。最终一切都瘫痪了。正常运行时间（uptime）的秘密在于你如何在设计时考虑这些失效。”

查看英文原文：Avoiding Downtime When Cloud Services Fail