亚马逊Web服务:耗尽客户信任

就像一种常规事件,位于美国东部的亚马逊Web服务于星期一又经历了一次宕机。此次宕机导致弹性块存储和关系数据库服务出现了问题,也导致一些很有分量的客户退出,包括流行的网站Flipboard、Foursquare和Pinterest。因此,亚马逊的失败再一次引人注目,这样的事情已经导致其声誉受影响,由此扩展开来,一些企业观察者认为普遍而言公有云信誉不可靠。

但是在这个案例中,其他产业观察者表示看起来好像是缺少可靠性原则,实际上和一些亚马逊客户做出的选择有关。

引入冗余来避免宕机是保护像周一这样的宕机中的业务资产的唯一方法,但是这是根据个别案例基础做出的决定,亚马逊合作伙伴SolutionSet副总裁Kent Langley表示,他们已经有很多客户收到了这次事件的影响。“这要求灾难恢复的实现一机业务连续性计划和实施,这些通常都被忽略或者被认为是过于昂贵,而且还有不能接受的风险成本,”他说,“只有非常少的客户会希望维护其业务的多区域部署。”

公平的说,对于此次事件也许存在很好的理由。毕竟,不能将责任归咎于Pinterest或者检查出来Foursquare本身简直太危险了;在一种精益、平均的Web业务模型中来构建昂贵的企业风格冗余当然不值得。

就拿Yipit为例来说,这是一家Web公司,过滤来自像Groupon这样的网站的日常交易。该公司的主数据库在最近这次宕机中受到影响,周一晚上完成了恢复备份。这也是该公司没有将其数据库跨多个有效区域架构的直接结果,根据该公司负责运维的开发者Andrew Gross所述。

“过去很少宕机,我们没有受到影响,而且我们知道几乎躲开了危机,因为在这一点上,我们觉得不值得去花费额外的工程经理去尝试和获取那些可能避免损失的事情,”Gross表示,“我们就把它当做一种生活一样接受并处理了就好了。”

对于像Foursquare和Pinterest这样的企业,在冗余中区分新功能可能更有利可图,根据Damian Bramanis所言,他是Sentinus咨询服务总监,这是一家澳洲的云计算咨询公司。“如果这是一种有意的选择也没什么奇怪的,”他说。

但是事实是一些基于Web的业务并没有重点考虑冗余的方式,并不是意味着充足的冗余不能在需要的地方构建。在单一的有效区域构建实际的关键应用也没有任何借口,尤其是在美国东部,过去五年中这是亚马逊失败时间的“震中”。

“质量、可靠性和安全在企业和云服务提供商之间具有连带责任,”Bramanis表示,“亚马逊对于构建最佳实践、可靠性、失败冗错服务已经给出了选择,在于企业去做哪种选择。”

“从这一点上讲,我觉得有点人性的问题在里面了,”在谈到亚马逊持续宕机的单一可用区域失败时,Tier1 Research分析师Carl Brooks表示。“大多数人知道如何消费责任,”Brooks。“有些人却不是。” (译者:张培颖)