如何管理风险？

我们从根本上认为风险是累积的。当您执行多个风险操作或进行许多风险更改时，您最终将达到风险成为现实并且系统将出现问题的程度。我们在AKF Partnersl的方法是在我们的客户管理系统中教授紧急风险和整体风险。所谓的紧急风险是发布变更或一系列变更的风险。总体风险来自多年来在系统上执行风险行为的累积风险。无论何种风险，都会给系统带来危机。我们将讨论如何管理这两种风险，以确保您可以在某个时间点在系统中执行某些操作

我们从根本上认为风险是累积的。当您执行多个风险操作或进行许多风险更改时，您最终将达到风险成为现实并且系统将出现问题的程度。我们在AKFPartnersl的方法是在我们的客户管理系统中教授紧急风险和整体风险。所谓的紧急风险是发布变更或一系列变更的风险。总体风险来自多年来在系统上执行风险行为的累积风险。无论何种风险，都会给系统带来危机。我们将讨论如何管理这两种类型的风险，以确保您能够就某个时间点应该允许的系统以及不应该执行的操作做出正确的决策。通过监控系统计划变更（如发布）的风险评估来管理紧急风险。您可能希望对可以同时执行的操作的风险设置一定的限制，或者您可能希望设置一天特定时间段或一定时间段内允许的风险金额限制客户例如，您可以确定风险评分大于50的任何操作（通过FMEA方法计算）必须通过修复将风险降低到50以下或分成两个单独的操作。或者，您可能要求系统仅在午夜之前执行风险评分低于25的操作，并且高于此评级的任何操作将在午夜之后执行。虽然这里的讨论只是一个紧急的行动风险，但这种风险是累积的，因为行动风险中包含的风险较高的项目，出现问题的可能性越大，并且由于变化太多，更难找到问题或确定根本原因。作为一个思想实验，考虑两个发布版本，一个是仅发布一个功能，该功能识别两种故障模式，另一个必须释放50个功能，每个功能识别两种故障模式。或者各种各样。首先，由于失败的可能性更大，后者更容易出现问题。 做一个比喻，同时投掷50个硬币。虽然每个硬币化身面朝上的概率是独立的，但在整体结果中，你可能至少有一个化身面朝上。其次，因为有50个函数，所以更改很可能会相互影响或以意外的方式更改相同的组件，类或方法。因此，无论累积失败的可能性或累积的负面相互作用的可能性，都会增加出现问题的可能性。如果您在这些版本之后遇到问题，假设所有功能的复杂性和规模并没有太大差异，那么当发布版本中只有一个功能时，确定问题的原因要比确定问题的50个问题更容易。版。许多。要管理紧急风险，请列出所有规则和可接受的风险级别。这很清楚明确。此外，您还应确定必须由软件开发团队的副总裁和运营团队的副总裁或CTO批准的例外策略。以及与每次变化相关的风险量。正如我们在讨论紧急风险时提到的那样，联合行动可能会对管理整体风险产生负面影响，而且有两个因素会导致问题。第一个因素是系统中发生的更改总量。您发布的版本越多，拆分数据库所需的操作就越多，或者您对配置所做的更改越多，操作引发问题的可能性就越大，或者它们之间的交互发生的可能性就越大。会引起问题。如果开发团队在只有一个数据库的开发环境中进行开发，那么除非有无数的协调和修复任务，否则它将在数据库发布前两天拆分为主数据库和只读副本。下一个版本可能会出错。分析总体风险时要考虑的第二个因素是人为因素。随着人们的行为风险越来越大，他们可以容忍的风险水平将会提高。当我们需要适应新环境时，这种自我调节功能非常有用，但是当涉及控制系统性风险时，它可能会让我们误入歧途。 如果你附近有一只剑齿虎，你仍然需要每天离开你的洞穴去捕猎，那么适应生活中这种新风险的能力对你的生存至关重要。否则，你只能整天待在自己的洞穴中并且饿死。但是，在生产环境中推动越来越多的变化只是因为你没有遭受过，你觉得你是无敌的，这只会造成严重的问题。建议在特定时间段内开发APP的风险，风险评分通过FMEA方法计算。如果您未使用FMEA方法，则可能需要调整风险级别列的值以使其对您有意义。例如，您可以使用＆lt; 5绿色或3个黄色操作而不是<150点。与紧急风险管理流程一样，您需要考虑异议和异议。您应该提前计划并设置升级过程。一个想法是，对于任何级别的风险，执行人员可以额外增加50点，副总裁可以增加100点，而CTO可以增加250点，但不会累积。无论您决定构建此规则的哪种方式，最重要的是它对您的组织有意义，并且已记录在案，并且您的组织将严格遵守该规则。