管理系统中风险是系统可用性和可扩展性的关键-InfoQ



 写点什么

孙子说：是故智者之虑，必杂于利害。

虽然我们经常提到风险管理，但还没有阐述我们对风险的观点，以及如何进行风险管理。本文大致涵盖了在任何的技术或业务决策过程中如何确定和管理风险。风险管理是提高和保持可用性及可扩展性的最基本和最重要的方面。

风险管理的重要性

商业在本质上是一种冒险的尝试。举一些风险的例子，比如业务经营模式不成立或者过时，产品成本太高或者产品不再受客户的青睐。在经营中，你必须能够识别和平衡风险与相关的回报。比如，推出一个新版本，显然会有风险，但也应该有回报。

大多数组织监控风险并聚焦在降低风险事故发生的概率。在产品开发生命周期中引入更多的测试是降低风险的典型方法。这种方法的问题是，测试只能减少错误或者降低错误出现的概率，但是毕竟这还是有限的非零数量。而且需要在长时间里持续测试，比如尽管卫星软件已经研发完成，但是仍然不能确保代码没有缺陷。1999 年 9 月 23 日，美国航空航天局失去了价值 1.25 亿美元的绕火星轨道飞行的卫星，原因是有一个关键的航天器计算，洛克希德·马丁公司的工程团队使用英制的测量单位，而 NASA 团队则使用标准的公制测量单位。为什么在测试中没有发现这种不一致的问题呢？正如质量专家所熟知的，答案是：即使是中度复杂程度的系统，要想确保软件无缺陷，在数学上也是不可能的。

在 AKF，我们倾向于把风险看成是一个多元化的产品，如图所示。我们将风险分为事件发生的概率，以及如果该事件发生会产生什么样的影响。事件的概率部分是由在版本发布中所涉及的变更量和每一个变更所涉及的测试量而所决定的。变更的量越大，事件发生的几率就越高。测试做得越多，事故发生的概率就越低。降低事故概率的主要措施应该包括较小的版本和更有效的测试。

相比之下，事故的影响包括影响范围（按客户的百分比计算的用户影响或交易的百分比）和持续时间。如图 16-1 所示，架构决定如故障隔离和 X、Y 和 Z 轴分割（所有这些都会在第三部分中讨论），将有助于降低影响范围。有效的监控以及问题和事故管理将有助于缩短持续时间。我们曾经在第一部分涉及这些领域。

如果从本质上看企业都是有风险的，那么那些成功企业的风险管理难道就是做得好吗？我们认为，这些公司要么是风险管理很有效，要么是迄今为止非常幸运。我们都知道，运气迟早会耗尽的。

如果只是因为幸运，那么你现在应该开始担心了。人们可能争辩说，风险遵循马尔可夫特性，这意味着未来的状态是由现在的状态决定的，与过去的状态无关。我们认为，在某种程度上风险是一个累积的过程，也许是呈指数衰减但仍然是不断增加的。今天的一个危险事件，可能会导致未来的失败，不是直接相关（例如，今天的变更是未来某个事故产生的原因）就是间接相关（例如，组织对风险容忍度的增加会导致未来更大风险的行为）。无论是哪种方式，行动都可能会带来近期和长期的后果。

有些人可以自然地感知和管理风险。这些人可能经过多年的技术工作累积了这方面的经验和技能。也可能有一种与生俱来的感知风险的能力。虽然有这样的人很好，但是这样一个人仍然是一个单点故障。因此，我们需要培养组织里其他的人更好地测量和管理风险。

因为风险管理对可扩展性非常重要，我们需要了解风险管理过程的组成和步骤。试图准确地确定风险的方法有很多，有些比较准确，有些涉及的面比较广。重要的是为你的组织选择合适的方法，这意味着要平衡严密性和精确性。在对风险进行评估后，必须对急性风险和整体风险积极管理。急性风险是与特定行为相关联的风险，例如在服务器上更改配置。整体风险是由于在过去数天、数周甚至数月内发生的所有行动在系统中所累积的风险。

测量风险

管理风险的第一步是要准确地确定某一具体行动所涉及的风险有多大，保持必要的准确性。在这里为什么我们要使用“必要”而不是“可能”这个词？你可以更准确地测量风险，但基于目前产品或组织的当前状态这可能是不必要的。例如，对一个产品做 beta 测试，因为客户预期会有一些小故障，可能决定没有必要进行复杂的风险评估，粗略的分析就够了。有许多不同的方法来分析和评估风险。在工具箱中的测量方法越多，就越有可能在最合适的时间、对最合适的活动、用最合适的方法来测试风险。在这里，我们将涵盖三种确定风险的方法。对于每种方法，我们将讨论其优点、缺点和精度。

第一种方法是直觉法。当相信自己可以感知风险时，人们经常使用这种方法，同时赋予风险管理者做出重要决定的权力。正如我们之前提到的，有些人天生就有这种能力，在组织中有这样的人肯定是很好的。然而，有两个非常重要的问题需要提醒你。首先，这个人是否真的有能力在潜意识层面理解风险，或者你只是希望他能做到？换句话说，你是否查证了这个人的准确性？如果没有的话，在你认为这仅仅就是个猜测之前，你应该去查证。如果有人声称可以“感知”风险的水平，让他或她把预测写在白板上。这是为了好玩。其次，注意我们事先警告的关于故障的单点。你需要在组织中多几个人来了解如何评估风险。理想情况下，每个人都熟悉风险的重要性，并掌握现有的评估和管理方法。

薄切片（Thin Slicing）是心理学和哲学中的一个术语，用来描述只根据“薄切片”或狭窄的经验窗口在事件中发现模式的能力。作者马尔科姆·格拉德威尔，在《无思维的思维力量》（The Power of Thinking Without Thinking）一书中，认为这种即时决策的过程与经过精心策划、深思熟虑的决策过程往往一样好、甚至更好。

课堂上的研究已经表明，专家可以从教师的简单举止中，区分出有偏见的教师和公正的教师。此外，法院的研究也表明，法官在审判中的只言片语可以让专家们预测法官对审判的期望。

格拉德威尔声称专家经常做出快速决策，这往往比经过大量分析的决策更好。有时过多的信息会干扰判断的准确性，导致俗话说的“分析瘫痪”。这种在非常有限的信息基础上做出决策的能力似乎很理想，格拉德威尔还指出，专家的薄片决策能力可能受个人的喜好、偏见和成见的影响。

风险评估方法的核心优势在于非常快速。一个真正的专家，如果能从根本上理解某些任务所固有的风险，可以在几秒钟内做出决定。正如我们所讨论的那样，直觉方法的缺点包括这个人可能没有这个能力，因为几次巧合的成功，被误以为他可以。另一个缺点是，这种方法很少可以复制。人们往往在行业内工作了许多年，积累和磨炼了不少经验，这可不是在一小时的课堂能就完成讲授的东西。这种方法的另外一个缺点是，很多的决定取决于一个人一时的冲动，而不是一个团队或小组集思广益得出的结论。该方法的准确性是高度可变的，这取决于人、行动和其他因素。本周一个人的风险可能会评估得很好，但下星期可能会彻底地失败。因此，如果时间是至关重要的，风险是在最坏的情况下和有一个久经考验的专家，你可以谨慎使用这种方法。

测量风险的第二种方法是交通灯法。在这种方法中，通过将行动分解成最小的组件，并用绿色、黄色或红色来标明其风险等级。最小的组件可能是应用版本发布中的一个功能或维护列表中的一个配置变化。粒度取决于几个因素，由团队进行这些评估，包括可用时间和演练的次数。下一步我们确定行动的整体或集体风险。为每种颜色分配一个风险值，计算每种颜色的数目，用不同颜色的数目乘以响应的风险值。然后，将计算得到的风险总值除以动作总数。风险评估的结果是最接近得分的颜色。图 16-2 个描述了三个功能组件的风险等级，它提供了一个对整体系统版本发布的累积风险的评估。

对微观层次组件很熟悉的人应该去评估风险值，并为每个微观组件标定颜色。标定颜色应根据完成每个组件的任务难度，需要的工作量，组件之间的关联关系等来分配。图中展示了一些最常见的属性及其相关的危险因素，可由工程师或其他专家衡量在某个特定功能或颗粒项目的风险。

交通灯方法的显著优点是，它使风险评估开始变得有条不紊，这意味着它有可重复性，能够记录而且训练。重复性意味着我们可以根据评估结果来学习和提高。许多人可以进行风险评估，所以你不再依赖于单一个体。再次，因为许多人可以进行评估，可以以组为单位对做出的决策进行讨论，他们可以确定某个人的论点是否有优点。这种方法的缺点是，它是过程中的一个额外步骤，比直觉猜想法需要更多的时间。另一个缺点是，它依赖于每个专家来选择属性，并用这个属性去评估每个组件的风险。由于专家之间存在着这种可能的变数，这种风险评估的准确性属于中等水平。如果专家非常熟悉而且清楚地了解特定领域风险属性的构成，那么交通灯方法的结果可以相当准确。如果他们在评估的时候，对需要重点检查哪些属性没有清楚的理解和认识，风险水平的评估结果可能会差一些。我们会在下一个风险评估方法的讨论中看到这一点，新方法可以解决这种潜在的变动性，使评估的结果更加准确。

评估特定行动风险的第三种方法是故障模式及影响分析法（Failure mode andeffects analysis，FMEA）。这种方法最初是从 20 世纪 40 年代末的军队中开始使用的。从那时起，它被广泛应用于包括汽车、制造业、航空航天和软件开发等许多行业。进行评估的方法类似于交通灯方法，系统被分解成最小的组成部分进行风险评估。对于应用版本发布，这些组成部分可能是功能、任务或模块。然后为每个组成部分确定一个或多个可能的故障模式。每个故障模式都有相应的效果，描述如果故障发生时的影响情况。

例如，注册功能的故障有几种情况，无法把新用户的信息适当地储存到数据库，为新用户分配错误的权限或其他的几种情况。其影响将是用户无法注册或能看到没有经过授权的数据。每个故障的现象可以依据下述三个因素来打分：故障的可能性、严重性和可检测性。我们选择使用 1、3 和 9 作为打分的范围，这让我们非常保守，同时可以把高风险因素和中低风险因素区分开来。故障的可能性基本上是这个特定故障真实发生的概率。故障的严重性是指如果故障发生，对客户和业务产生的总体影响。这种影响可以用金钱损失、声誉损失或任何与业务有关的其他因素来测量。故障的可检测能力指的是如果故障发生你是否能够注意到。正如你所能想象的，一个有灾难性后果并极有可能发生的故障实际上却无法检测，那将是最坏的结果。

对单项失效模式和效果打分后，将这些分数相乘得到总的风险评分，即可能性得分×严重性得分×检测能力得分。这个分数显示了一个特定组件在整体行为中的整体风险。

FMEA 过程的下一步是确定可以执行或落实到位的缓解步骤，以降低特定因素的风险。例如，如果一个功能组件的可检测能力有非常高的风险分数，这意味着如果事件发生，那将很难发出通知。因此该团队可能会决定提前准备一些查询，在产品或服务发布后，每小时检查一次数据库，检测是否有故障发生的迹象，如丢失数据或数据错误。此缓解措施对该组件的风险因素有降低的作用，同时应该说明风险可以降低到什么程度。

在表中，有两个人力资源管理系统（HRM）的应用实例：公司客户的新注册流程和改用新的信用卡处理器。这些功能有几种故障模式。让我们来看看信用卡的支付功能，重点放在信用卡账单错误的故障模式，它的影响是支付时被收取过多或者过少的费用。在我们的例子中，工程师可能会将这个故障的风险设成 1 分，或者是不太可能发生。也许这个功能经过了深入全面的代码审查和质量保证测试，因为它处理的是信用卡，所以风险度较低。工程师觉得这种故障会带来灾难性的影响，所以故障的严重性自评为 9 分。这似乎是合理的，因为错误的信用卡账单会引发客户的愤怒、昂贵的退款、潜在的退回许可证费用。工程师认为故障检测难度将是中等，因此故障可检测能力自评为 3 分。此故障模式的总风险评分为 1×9×3＝27。已经确定了该功能集的补救行动，在 beta 测试中推出的新支付处理应用仅限于某些客户使用。因为客户的影响将是有限的，这样将减少故障的严重性。采取这种补救措施后，因为故障严重性降低，风险将降低到 3 分，修订后的风险评分仅为 9 分，大大好于以前。

FMEA 风险评估过程很有条理性，这使风险评估能够长期得以记录、培训、评估和改善。另一个优点是精度。特别是随着时间的推移，团队在识别故障和准确地评估风险方面可以做得更好，这种方法是最准确的风险确定方式。FMEA 方法的缺点是它需要时间和思考。投入到分析中的时间和精力越多，结果就会越好、越准确。这种方法与测试驱动开发非常相似，而且互补。在研发前进行 FMEA 会提高设计和错误的处理水平。

我们将在下一节讨论，风险测量的分数，特别是那些利用 FMEA 方法得到的，可以在系统任意时间间隔或任一应用版本发布中管理风险的数量。风险评估的下一步是要有人或团队可以对评估的精度进行评价，对决策提出质疑。这也是采用如 FMEA 这样系统化方法的好处：人人都可以通过培训学会使用，因此可以互查以确保用最高的质量标准进行评估。评估过程的最后一步是在行动后重新评估，看你和专家们在确定合适的故障模式和评估因素时的准确率。如果不可能发现的问题出现了，请专家调查详细的情况并提供潜在的情况不能被提前发现的原因，警告其他专家注意这种类型的故障。

风险评估步骤

如果你正在计划使用任何有条理的方法来进行风险评估，下面是适当的风险评估步骤。这些步骤适用于交通灯方法或 FMEA 方法：

确定合适的粒度级别来评估风险。
选择一个可以复制的方法。
对将进行风险评估的人进行培训。
安排事后评审每一个评估，或者集体回顾所有的评估。
选择一个合适的评分表（例如，1、3、9），并考虑好需要如何保守。
完成代码发布或系统维护后，对故障类型、可能性、严重性及可检测性进行审查。

无论使用的是交通灯方法、FMEA 或其他风险评估方法，一定要遵循这些步骤，确保可用于全面风险管理的风险评估的成功。

管理风险

从根本上说，我们相信风险是可以累积的。没有缓解的风险越大，出现重大问题的可能性就越大。我们教导客户管理系统的急性和整体风险。急性风险是个别变更或应用版本发布中组合变更所带来的风险。整体风险水平代表着在系统中小时、天、周所累积的风险。无论急性或整体风险，都可能会导致危机情况的发生。

急性风险管理通过监控系统变更，如应用版本发布，来进行风险评估。你可能要提前设置一些限制以控制任何并发行动带来的风险，比如允许系统在某天的某个特定时段或某些客户范围使用系统。例如，你可以决定任何通过 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 世界里，可扩展性是这种风险–回报结构的一个部分。在系统的可扩展性方面必须冒险，否则系统会过度建设，而无法交付使企业成功的产品。通过主动的风险管理，提高系统的可用性和可扩展性。

虽然评估风险有很多不同的方法，本文对其中三个方法进行了分析。第一种方法是直觉法。不幸的是，虽然有些人天生擅长识别风险，但许多人被认为有这样的能力，实际上却没有。

第二种是交通灯法，把组件的风险评估为低风险（绿色）、中等风险（黄色）和高风险（红色）。所有组件的组合通过发布、变更或维护形成整体风险水平。

第三种方法是我们推荐的故障模式及影响分析法。在这种方法中，专家通过识别每个组成部分或者功能可能的故障模式，以及这种故障将导致的直接影响，完成风险评估。例如，信用卡支付功能可能会失败，这种失败的表现是向客户收取太多或太少的金额。根据失败发生的可能性、严重性和发生故障后的检测能力对这些故障模式和影响打分。这些分数相乘后得到总的风险值。利用该评分，专家们将推荐相应的补救措施减少一个或多个危险因素，从而降低整体的风险。

风险评估完成后，我们必须进行管理。这一步可以分解为管理急性风险和管理整体风险。急性风险针对单一行动，如应用版本发布或者维护等等，而整体风险针对一段时间，如小时、天或周发生的变更所带来的风险。对于急性风险和整体风险，我们建议采用规则，预定义每个行动或者每个时间段可以容忍的风险量。此外，准备好应付那些持反对意见的人，应预先建立一个投诉升级的路径，以避免第一次危机在没有想清楚，没有来自各方合适输入的情况下，陷入混乱。

与大多数的过程一样，风险评估和风险管理最重要的方面是在特定的时间与组织匹配。随着组织的成长和成熟，可能需要修改或增加这些过程。如果要使风险管理更有效，就必须使用它。若要使用，该过程就必须与团队配合良好。

关键点

管理系统中风险的数量是确保系统可用性和可扩展性的关键。
风险是可以累积的，尽管随着时间的推移会发生一定程度的退化。
为达到最佳效果，应该使用可重复和可测量的风险评估方法。
风险评估和其他过程一样，可以随着时间的推移不断提高。
各种不同的风险评估方法都有各自的优点和缺点。
各种风险评估方法的准确性有很大的不同。
风险管理既解决急性风险也解决整体风险。
急性风险管理涉及单一的变更，例如应用版本发布或维护。
全面风险管理聚焦在任何时间点观察和管理系统中的风险总水平。
如果要确保风险管理过程有效，我们必须使用和遵循这个过程。
确保过程有效的最佳方法是确保它与组织有良好的匹配度。