【51CTO专稿】 上周Amazon网络服务停机事件一出，各大社交网站及博客平台上的议论之声此起彼伏，人们纷纷对此抛出自己或客观或主观的评价。有些议论者认为公共云服务的停机状况应该上升到法律诉讼高度；另一些效力于其它云供应商的议论者则喜欢把这次事件当成AWS存在缺陷的有力证明。此外，还有一种声音认为Amazon遇到的问题为用户敲响了警钟，今后我们应该在SLA处罚条款中将停机作为关注重点，并以谈判的方式为业务流程提供停电保护。
显然，这些反应或者是有心者蓄意归纳出的偏见、或者是议论者结合自身情况给出的建议，都没能从此次事故出总结到正确的教训。重要的是，议论者多数是在毫无顾忌地大放厥词，根本没有提供真正有用的意见或建议，更谈不上拿出一套能够替代传统方案、真正为新时代IT事务服务的风险缓解策略。
首先我们要弄清楚“风险”这个词到底是什么意思。根据维基百科的解释，风险就是“未来出现损失的机率与程度”。换句话来说，我们应该通过评估问题出现的频率与可能造成的损失来正确看待风险。当然，作为技术专家，我们还需要估算到底要投入多少人力、物力与财力才能缓解甚至最大程度避免风险。花1美元的投入、避免1000美元的损失是笔聪明账，但花1000美元只为了保护自己免受1美元的损失则绝对是种愚蠢的念头。
Amazon服务中断告诉我们，故障也是可以选择的
目前用户们所面临的问题在于，此次停机带来的损失是不是大到足以让人彻底对AWS失去信心（或者说风险太大），转而寻求其它方案的帮助。我们不能否认，在AWS平台上运行的应用程序数不胜数，其中很多甚至与几百万甚至几十亿美元的巨额交易息息相关，所以每位企业客户首先要做的就是弄清楚这个问题的答案。
在此次停机事故中，Amazon公司曾公开向用户们发出通知，称这只是一次有计划的维护活动，但过程中遭遇到了内部配置文件更新失败与程序内存泄漏等问题。结果证明，Amazon公司引以为傲的弹性块存储（简称EBS）服务可用性相当差劲。
有趣的是，上次AWS遭遇的重大停机故障同时是由EBS问题所引发，尽管两次事故的产生原因不尽相同——上一回是人为因素所导致。在这两次事故中，都是因为员工没能正确配置EBS资源而衍生出的意外情况令作为后备机制的EBS无法为继。
更有趣的是，AWS声称用户没必要对停机事故表现得太过惊讶。Amazon公司的头号设计原则就是：任何产品都会有出问题的一天，只有把故障作为设计中的一部分，才能最大程度避免事故的发生。
很多人都对停机表现出极大愤慨，认为服务供应商应该为此承担责任，毕竟100%（或者至少是99.999%）可用性是业界良心的份内之职。然而Amazon公司的态度非常明确——他们不会为此负责。在他们看来，如果用户对于自己的业务可用性如此重视，就应该选择那些愿意为服务可靠性提供严格承诺的供应商。换言之，用户需要通过所谓“企业级”硬件及软件作为依托，以此换取固若金汤的意外状况应对能力。
无论SLA条款如何规定，“完美”的设备都不可能真正存在
尽管议论之声四起，但我得说：这些流言所谈到的解决方案早已过时，既不合理也很难持续。
首先，人们假设企业级设备的介入能够降低停机风险。但事实上任何一种设备都有可能在紧要关头出现纰漏。把提高可用性的希望寄托在简单地采用“完美”设备的观念上，其结果只能是被残酷的现实打击得鼻青脸肿。
资源失效是铁一般的现实，首要方案在于如何让用户保护自己免受硬件故障的影响，这才是解决问题的关键。我认为，在谈判桌上锱铢必较的策略与通过严惩提振士气的做法并没什么不同。这么做只会让SLA条件的制定方获得一定程度的心理满足感，但对实际效果并不会带来任何改善。
许多云服务供应商都针对此次AWS停机故障提出了这样或那样的解决方案，但在我看来这只是再一次证明了他们的无能与愚蠢。说实话，如果遇上这类情况，那帮供应商的硬件同样支持不住。在这里我奉劝有心棒打落水狗的从业者们，Amazon的失利只能证明一点：骄兵必败。
其次，高强度的变更控制流程事实上根本无法降低资源失效的风险。这是因为但凡涉及人机交互的工作总会带来潜在的失误可能，而失误正是引发故障的根源。而且值得注意的是，AWS这两次重大停机都跟硬件故障没啥关系，而完全是人为因素所酿成的恶果——由于设计人员在开发之初并没有将这类情况考虑在内，因此人为失误一旦出现就将一发而不可收拾。就连那些ITIL（即信息技术基础构架库）管理经验极为丰富的企业也很难彻底根除人为故障。
最后，大家提出的的解决方案缺乏前瞻性。每家运营良好的公司都必然会经历IT基础设施规划的规模化扩展；仅仅在业务流程中考虑刚性资源需求、缺乏前瞻性眼光及对故障的认识只会令企业在发展的道路上举步维艰甚至陷入困境。可以说没有任何一家IT企业（或者云服务供应商）能够负担得起这种级别的人力（或者企业级设备）。
冗余设施与失效备援在很长一段时间内仍是最佳选择
资源失效状况的最佳解决方案其实早已非常成熟，这就是冗余设施与失效备援这一黄金组合。如果企业业务只需一台服务器，咱们就设置两台；如果其中一台出现故障，管理人员可以马上将应用程序切换到第二台当中。过去可能很多企业承担不了如此沉重的经济负担，但随着时间的推移，如今软件与硬件成本都已经大幅降低，要为少数真正的关键任务应用配备冗余方案其实并不困难。
云计算的出现堪称照世之明灯，它以轻松的方式与低廉的成本一举搞定了冗余资源这个大问题。许多用户都会在设计应用程序时纳入弹性理念，借以应对自有资源失效并保护业务系统的可用性。其实历史的选择往往才是正确的选择，面对一众叫嚣着使用传统解决方案的议论者，云计算已经在客观上成为企业级设备发生故障时最好的后备机制。
真正令人不安的情况在于，只有极少数停机事件中掺杂了人为因素，绝大多数故障完全是由服务失败所引发。换句话来说，出问题的并不是某个应用所涉及的资源，而是一类服务之下所包含的大量应用程序。
在普通用户眼中，Amazon遭遇此次重创的原因可能是没有制定良好的运营流程、或者不舍得花钱雇佣技术高超的员工。很多人认为如果云服务供应商能够做好这两点，此类停机事故根本不会发生。
这种态度显然不够科学，即使大家的期望成为现实，各种小麻烦仍然会在阴暗的角落里酝酿滋生。云计算是一套新的计算模式——它自动化程度极高、易于扩展且功能丰富，整个行业在这位计算新宠的运营及管理方面都在摸着石头过河。而在摸索的过程中，失误自然是不可避免的。我所说的失误绝不只是简单的错误，它代表着特殊条件所引发的基础设施内部的意外状况。虽然云服务供应商已经竭尽所能、严防死守，但故障在很长一段时间内仍然会持续出现。
最终，一切归于“风险”
这些或罕见或多发的服务停机到底该如何解决？根据AWS的建议，服务供应商应当采取地理区域更广阔、部署更合理的冗余资源方案。在AWS看来，这将有效保护业务环境免受大规模突发情况的干扰。想法不错，但问题只有一个：广域冗余方案太过复杂也太过昂贵，相对于简单的资源冗余措施，很少有哪家企业有能力实现这种几乎没有直接回报的烧钱规划。
这就回到了我们在文章开头提到的风险话题。请记住，风险评估的基本定义在于衡量故障发生的可能性以及由此带来的损失。作为管理者，大家必须以理性的眼光评价这类发生频率不高但后果严重的资源失效事件，同时考虑新方案的设计及运营成本。从某种意义上说，这是一道精心设计加运营与意外事故之间的成本计算题。
计算设计及运营成本当然并不困难，但很多人都无法正确估量应用程序失效所带来的实际损失。但对于AWS来说，随着越来越多关键性业务应用进入其统辖范畴，在缺乏对风险的准确预期时就轻易推出抗灾措施显然太过草率。
综上所述，我们应该看到停机可能性并非无法估量，但合理的解决方案同样难以设计。就连电信运营商这样的成熟企业同样无法做到完美无瘕，所以大家不妨以平和的心态面对云服务供应商在停机事件中应该承担的责任。或者说回我们自己，每个人在做出决定时都很难准确认识到可能伴随而来的连带风险。而对于那些在停机事故之后一味指责供应商、要求完美服务，自己却毫无可行方案的家伙，我对此深感遗憾。时至今日，云计算仍是个危险的游戏，玩与不玩取决于我们自己。正视问题、认识风险，这才是最好的处理态度。
原文标题：The Amazon Outage in Perspective: Failure Is Inevitable, So Manage Risk
