我们从根本上认为，风险是累积而来的。当你执行了多个有风险的行动，或者进行了许多有风险的变更时，终究会到达一点，这时风险会变成现实，系统将出现问题。我们在 AKF Partnersl的做法是教会我们的客户管理系统中的紧急风险和整体风险。所谓紧急风险，就是一个变更或者一次发布中的一组变更带来的风险。整体风险来自于经年累月对系统执行有风险的行动累积起来的风险。无论哪种类型的风险，都会给系统带来危机。我们将讨论如何管理这两种类型的风险，以确保你对在某个时间点应该允许在系统中做什么以及

我们从根本上认为，风险是累积而来的。当你执行了多个有风险的行动，或者进行了许多有风险的变更时，终究会到达一点，这时风险会变成现实，系统将出现问题。我们在 AKF Partnersl的做法是教会我们的客户管理系统中的紧急风险和整体风险。所谓紧急风险，就是一个变更或者一次发布中的一组变更带来的风险。整体风险来自于经年累月对系统执行有风险的行动累积起来的风险。无论哪种类型的风险，都会给系统带来危机。我们将讨论如何管理这两种类型的风险，以确保你对在某个时间点应该允许在系统中做什么以及不应该做什么能够做出正确的决策。



通过监控对系统计划的变更(如发布)所做的风险评估，可以管理紧急风险。你也许想预先对能够并发执行的行动的风险大小设立一定的限制，或者想对一天的某个特定时间段或有一定客户量的时间段所允许的风险大小设立一定限制。例如，你可以决定任何风险评分大于50(通过FMEA法计算得出)的行动，都必须通过补救措施把风险降低到50以下，或者拆分成两个单独的行动。或者，你可能要求在午夜之前，只能对系统执行风险评分低于25的行动，任何高于这个评分的行动，都要在午夜之后执行。即使这里讨论的只是一个行动的紧急风险，但这种风险也是具有累积性的，因为一个行动的风险中包含的具有风险的项目越多，发生问题的可能性就越大，而由于被改变的东西太多，发现问题或者判断根本原因的难度也就越大。

作为一个思想实验，不妨考虑两种发布版本，一种只发布一个功能，该功能识别出的故障模式有两种，另一种要发布50个功能，每个功能识别出的故障模式有两种或多种。首先，由于出故障的机会多，所以后者更可能发生问题。打个比喻，同时抛50个硬币。虽然每个硬币头像朝上的可能性是独立的，但在整体结果中，你很可能至少有一个是头像朝上的。其次，因为有50个功能，那么变更彼此互相影响或者以预料之外的方式改变同一个组件、类或方法的可能性就很高。因此，无论从累积的出故障机会还是从累积的负面交互的可能性来看，这都会增加发生问题的可能性。如果儆了这些发布后，出现了问题，假设所有功能的复杂性和规模差别不是很大，那么当发布的版本中只有一个功能时，确定问题的起因会比版本中包含50个问题要容易得多。

要管理紧急风险，列出所有的规则和可接受的风险水平。这样做清楚明确。此外，你还应该确定一个例外策略，对于这些规则以外的情况，必须由软件开发团队的VP和运营团队的VP批准，或者由CTO批准。

以及每个变更相应带来的风险大小。就像我们在讨论紧急风险时提到的，联合的行动会造成负作 对于管理整体风险，有两个因素可能引发问题。第一个因素是系统中已经发生的变更的总量，用。发布的版本越多，拆分数据库的操作越多，或者配置的变更越多，那么某个行动引发问题的可能性就越大，或者它们之间的相互作用引发问题的可能性就越大。如果开发团队是在只有一个数据库的开发环境中进行开发的，在发布这个数据库之前的两天，才把它拆分成主数据库和只读副本，那么除非做了无数的协调和补救工作，否则下一次发布很可能会出问题。
 
在分析整体风险时，要考虑的第二个因素是人的因素。随着人们执行的行动的风险越来越高，他们能够容忍风险的水平也会提高。当我们需要适应新环境时，这种自我调节功能很有用，但当要控制系统风险时，它则会让我们误入歧途。如果你的附近已经出现剑齿虎了，而你仍然不得不每天离开自己的洞穴去打猎，那么适应生活中这一新风险的能力对你存活下来至关重要。否则的话，你就只能整天待着自己的洞穴中，忍饥挨饿。但在生产环境中推送越来越多的变更，只是因为你还没有遭殃，你就觉得自己是所向无敌的，这样只会造成严重的问题。

特定时间段中建议APP开发的风险大小，风险的评分是通过FMEA方法计算出来的。如果你用的不是FMEA法，可能需要调整一下风险水平这一列的值，使它对你有意义，例如你可以用<5个绿色或3个黄色的行动来代替<150分。和紧急风险管理流程一样，你需要考虑异议和反对意见。你应该预先规划好，设立一个升级流程。一个思路是，对于任何风险水平，执行主管可以额外增加50分，VP可以增加100分，CTO可以增加250分，但不能累计。无论你决定采用哪种方式建立这套规则，最重要的是，它要对你的组织是有意义的，而且它已经被记录在文档中，你的组织会严格遵守这套规则。