亚马逊云服务故障引发了人们对云计算的疑虑。 那麽我们能从中吸取哪些教训呢？ 1. 认真阅读云服务提供商的服务水平协议 令人叫绝的是近乎四天的故障并没有违反亚马逊的EC2服务水平协议（SLA），FAQ部分写 着「在一个区域内一年以内保证99.95%的可用性」。而这次发生故障的是EBS和RDS服务， 而不是EC2，所有故障都发生在单独区域，从法律角度讲该协议没有问题。 这一点值得思 考。 2. 别认为服务商的保障可以做到万无一失 很多受影响用户向亚马逊支付额外费用把自己的服务托管在多个可用区（Availability Zone）。亚马逊实际上也推荐这种做法。亚马逊称每个可用区都独立运转，有独立的基础 设施，非常可靠。一个可用区的发电机或冷却系统出现问题不会影响其它数据中心。此外 ，这些区域之间有物理隔绝，即便遇到火灾、龙卷风、洪水等自然灾害也只会影响一个可 用区。不幸的是这只是一种技术指标，并没有包括在合同条款。亚马逊消除此次事件的负 面影响还需要一段时间。 做到事後诸葛亮不难，但亚马逊面对这种故障时的脆弱或许本可以通过深入的尽职演练加 以避免。正如亚马逊竞争对手Joyent的首席科学家 Jason Hoffman 所言：「这次不是速 度变慢，不是云计算失败，也不是成长的烦恼，这是亚马逊的基础框架决策导致的可预见 後果。」 3. 大部分顾客仍会原谅亚马逊的失败 不管所受影响多麽严重，人们一直在赞美亚马逊，因为亚马逊帮助他们用低廉的成本和少 量的投入运营者强大的基础设施。很多人在批评的同时也会给予褒奖，比如BigDoor表示 ：「AWS帮助我们以极低的成本快速升级一个负责的系统。在任何时候我们都有运转良好 的12台数据库服务器，45台应用服务器，6台静态服务器和6台分析服务器。如果流量或处 理能力超了我们的系统会自动升级，如果不需要就会自动降级，从而节省费用。」 4. 除了云服务提供商的恢复能力之外，还有很多补救措施 正如来自O'Reilly的 George Reese 指出，如果你的系统在本周的亚马逊云服务故障中挂 彩的话，那不是亚马逊的错误。或者你把这种故障看作是可接受的风险，或者你没能按照 亚马逊云计算模式进行设计。查看亚马逊顾客使用的技术、避免故障非常有用。 Twilio和NetFlix在此次故障中安然无恙，前者是因为根据亚马逊的技术规范进行了出色 的设计，後者虽然把所有的基础设施都托管在亚马逊云服务中，但通过使用多个数据中心 的服务来确保服务的可靠性。 5. 增加额外的恢复能力需要更高成本 聪明的用户和Paas服务商应该准备多套方案。无论如何你都应该备份到亚马逊S3存储服务 上，这样一旦出现问题，你可以从S3中恢复。 6. 权衡好利弊关系可以帮助你提出问题 在选择一家云服务之前要提出一些问题，从而判断该服务是否靠谱。 比如你可以问这样的问题：你们会通过关闭某些基础设施来检测你们的自动备份能力吗？ 当然，你最好能亲眼看到类似测试。 7. 缺乏透明性是亚马逊的「软肋」 很多受到影响的顾客都抱怨在故障期间亚马逊没有提供足够的有用信息。BigDoor CEO Keith Smith 说「如果亚马逊能预料到他们目前遭遇的故障的话，我们就可以很快恢复我 们的系统了」。GoodData 的 Roman Stanek 则呼吁亚马逊推倒神秘的围墙： 我们的开发运营人员不知道如何管理系统的性能、可扩展性、以及最重要的应急恢复能力 。「合理的」服务水平协议和「99.999%承诺」之间的区别就是临时抱佛脚和完全符合我 们各自运营流程之间的区别……在云设施中，IaaS，PaaS，SaaS和顾客之间不应该有沟通 围墙。 亚马逊在未来几周内的挑战就是如何提供用户所需信息，增强自己的恢复能力。如果亚马 逊无法满足这种需求，而且其它公司做得更好的话，它或许会渐渐失去今天在Iaas领域的 统治地位。 http://b99.in/fkx1h 成长的烦恼：亚马逊云服务故障引发云计算担忧 云服务好比是一个风筝，风太大时风筝就会断线。 http://www.36kr.com/kite-in-the-cloud/ --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 114.33.12.223