管理风险
从根本上说，我们相信风险是可以累积的。没有缓解的风险越大，出现重大问题的可能性就越大。我们教导客户管理系统的急性和整体风险。急性风险是个别变更或应用版本发布中组合变更所带来的风险。整体风险水平代表着在系统中小时、天、周所累积的风险。无论急性或整体风险，都可能会导致危机情况的发生。
急性风险管理通过监控系统变更，如应用版本发布，来进行风险评估。你可能要提前设置一些限制以控制任何并发行动带来的风险，比如允许系统在某天的某个特定时段或某些客户范围使用系统。例如，你可以决定任何通过FMEA方法计算的风险值大于50的相关单独行动，必须采取补救措施把风险值降低，或者把这一变更分裂成2个单独的行动。或者在午夜前，你可能只允许风险值在25以下的行动在系统上发生，任何风险值高于25的行动必须在午夜之后发生。即使这个讨论是针对单一行动的急性风险，风险具有累积性，变更事项越多，累积的风险越多，出问题的可能性就越大、越难检测，出现问题后找出根源也越难。
想象应用版本发布中有一个功能，其中包含两个故障模式，与有50个功能的应用版本发布相比较，每个功能中有两个或更多的故障模式。首先，在后一种情况下，由于机会很多，所以出现问题的可能性很大。作为一个模拟，考虑在同一时间抛50个硬币。虽然每个硬币人头朝下的概率是独立的，总的结果中很可能至少有一次出现人头朝上。其次，如果有50个功能，那么变更之间相互影响或代码以意想不到的方式动到相同的组件、类或方法的可能性更高。因此，无论是从机会累积的角度来看，还是从负面相互作用概率累积的角度看，50个功能与一个功能相比，出现问题的可能性都大大地增加。假设所有功能的复杂度和规模比例相同，两个故障模式的应用版本发布后，即使出现问题，也远比50个功能的发布更加容易确定根源。
为管理急性风险，我们建议做个图表，其中列出所有的规则和相应的可以接受的风险水平。这种方式对每个风险级别的行动都是明确的。你也应该建立一个例外的政策，例如，这些规则之外的东西必须经工程部副总裁、运营副总裁或首席技术官单独批准。
管理整体风险应该考虑两个因素。第一个是系统发生变更的累积数量以及与这些变更相关的风险量的相应增加。正如我们在急性风险中讨论的，组合的行动可能会产生不必要的相互作用。应用版本发布越多、数据库分割越多或配置变更越多，越有可能导致问题的发生，或越可能因为相互作用而产生问题。如果开发团队一直在开发环境中的一个数据库上工作，在应用版本发布前两天，数据库被分割成读写主机和只读主机，这很有可能导致在下一个版本发布时出现问题，除非已经有大量的协调和补救工作完成。
在整体风险分析中应考虑的第二个因素是人为因素。随着人们从事越来越多高风险的活动，风险承受能力也逐渐上升。当需要适应新环境的时候，这种人为的条件可以很好地发挥作用，但涉及控制系统中的风险时，它可能会使我们迷失方向。如果一只剑齿虎已经搬到你的附近，适应生活中新风险的能力是生存下去的关键，你每天还是要离开洞穴出去打猎，否则只能整天待在山洞里挨饿。相反，因为你还没有被吃掉，自我感觉不错，这会导致严重的问题。
我们建议为了管理系统中的整体风险，可以采用如下表所示的一组规则。此表列出了特定时间段按照FMEA所确定的风险量。如果你使用的是FMEA以外的方法，就需要用某些规则和分数范围来调整风险水平列。例如，不用“低于150点”，而用“少于5绿色或3黄色行动”。在急性风险管理过程中，你需要考虑异议和否决。你应该提前计划，并建立一个升级过程。一种做法可能是总监对任何风险水平有额外的50点，VP可以给100点，首席技术官可以给250点，但这些增加并不累积。不管你用什么方式建立这套规则，最重要的是它对你的组织有意义，并且可以记录并严格遵守。作为另一个例子，假设一个功能发布需要一个主要的数据库升级。FMEA的综合得分是200点，超过了应用版本发布的最大风险值（表16-3中150点）。首席技术官可以批准额外的风险，或要求数据库升级与代码发布分开。
结论
在本文中，我们专注于风险。我们从探索风险管理的目的开始，讨论风险管理的构成以及它与可扩展性之间的关系。由此得出结论，风险普遍存在于所有的企业，特别是初创公司。在商业世界里，要取得成功就必须冒些风险。在SaaS世界里，可扩展性是这种风险–回报结构的一个部分。在系统的可扩展性方面必须冒险，否则系统会过度建设，而无法交付使企业成功的产品。通过主动的风险管理，提高系统的可用性和可扩展性。
虽然评估风险有很多不同的方法，本文对其中三个方法进行了分析。第一种方法是直觉法。不幸的是，虽然有些人天生擅长识别风险，但许多人被认为有这样的能力，实际上却没有。
第二种是交通灯法，把组件的风险评估为低风险（绿色）、中等风险（黄色）和高风险（红色）。所有组件的组合通过发布、变更或维护形成整体风险水平。
第三种方法是我们推荐的故障模式及影响分析法。在这种方法中，专家通过识别每个组成部分或者功能可能的故障模式，以及这种故障将导致的直接影响，完成风险评估。例如，信用卡支付功能可能会失败，这种失败的表现是向客户收取太多或太少的金额。根据失败发生的可能性、严重性和发生故障后的检测能力对这些故障模式和影响打分。这些分数相乘后得到总的风险值。利用该评分，专家们将推荐相应的补救措施减少一个或多个危险因素，从而降低整体的风险。
风险评估完成后，我们必须进行管理。这一步可以分解为管理急性风险和管理整体风险。急性风险针对单一行动，如应用版本发布或者维护等等，而整体风险针对一段时间，如小时、天或周发生的变更所带来的风险。对于急性风险和整体风险，我们建议采用规则，预定义每个行动或者每个时间段可以容忍的风险量。此外，准备好应付那些持反对意见的人，应预先建立一个投诉升级的路径，以避免第一次危机在没有想清楚，没有来自各方合适输入的情况下，陷入混乱。
与大多数的过程一样，风险评估和风险管理最重要的方面是在特定的时间与组织匹配。随着组织的成长和成熟，可能需要修改或增加这些过程。如果要使风险管理更有效，就必须使用它。若要使用，该过程就必须与团队配合良好。
关键点
□管理系统中风险的数量是确保系统可用性和可扩展性的关键。
□风险是可以累积的，尽管随着时间的推移会发生一定程度的退化。
□为达到最佳效果，应该使用可重复和可测量的风险评估方法。
□风险评估和其他过程一样，可以随着时间的推移不断提高。
□各种不同的风险评估方法都有各自的优点和缺点。
□各种风险评估方法的准确性有很大的不同。
□风险管理既解决急性风险也解决整体风险。
□急性风险管理涉及单一的变更，例如应用版本发布或维护。
□全面风险管理聚焦在任何时间点观察和管理系统中的风险总水平。
□如果要确保风险管理过程有效，我们必须使用和遵循这个过程。
□确保过程有效的最佳方法是确保它与组织有良好的匹配度。
