风险管理的风险

文摘   2024-12-18 08:03   四川  

想象一下,我们已经计划好周末去野餐。但天气预报说有5%的降雨概率,我们可以选择租帐篷,甚至重新安排野餐时间,但是考虑到这么低的降雨概率以及带来的不便似乎并不值得。风险很小,但为了降低风险所付出的代价远远超过了其潜在影响。

再考虑另一个场景,我们正在组织一个线上活动。使用Teams视频会议平台有很大的概率会出现故障,但我可以通过切换到另一个视频会议平台轻松解决这个问题。在这种情况下,发生的可能性较高,但影响很容易被降低。

尽管这些例子看起来很明显,但我们经常会看到团队在评估风险时没有同时考虑发生概率和影响这两个因素。

失效模式与效应分析FMEA

几年前我接触到了失效模式与效应分析(FMEA)。对它的解释非常详细,在概念上我发现非常有效。最原始的形式中,它着眼于“失效模式”(即事情可能出错的方式)和“效应分析”(出错的后果)。该分析包括严重性(影响)和发生频率(连同根本原因、解决措施等)。根据我的经验,在FMEA中,严重性和发生频率的评分(加上对解决方法的一些猜测)是看待风险的一种非常平衡的方法。

Failure Mode and Effect Analysis (FMEA) 是一种系统化的、前瞻性的分析方法,用于识别潜在的故障模式(即产品或过程中可能出错的方式),评估这些故障对系统的潜在影响,以及确定如何最好地预防或减轻这些故障的影响。FMEA 的目的是提高产品的可靠性、安全性和质量,并减少开发和生产成本。

不确定性

道格拉斯·哈伯德(《How to Measure Anything》作者)还写了另一本非常不错的书——《The Failure of Risk Management》,这本书更深入地探讨了这个主题,并提供了一些有趣的见解。

哈伯德指出,“风险 = 概率 × 影响”的公式过于简单——这种方法是一个有用的起点,但它忽略了现实世界中风险评估的关键点。哈伯德谈到了如何在评估风险时评估不确定性的价值。例如,可以估计某个地区发生地震的概率,但其确切的时间、强度和次发影响(如海啸)仍然具有不确定性。哈伯德建议使用蒙特卡洛模拟方法来评估不确定性如何影响整体风险——但我发现仅仅承认不确定性就是一个巨大的进步。

举个例子

假设你的团队即将发布一个软件应用程序的重大更新,更新内容包括主要的架构更改和新功能。

如果这里出现了一个bug,可能会导致大面积的中断或数据丢失,甚至声誉损失。但这并不意味着你不应该发布新软件。你还必须考虑引入重大缺陷的可能性。如果你已经做了大量的测试,并且提前进行了良好的测试,那么出现重大缺陷的可能性就会小得多。

上述情景可能是大多数团队的标准操作流程,但它没有考虑不确定性。哈伯德认为,在评估风险时,还需要考虑系统中的所有无法控制的因素。如果我们的新软件依赖于新的第三方软件或服务,我们需要在评估风险时考虑这些因素。如果我们使用的来自第三方服务小组件经常变更并且出过问题,就应该对这次发布更加谨慎。

简而言之,风险是一个系统。你不能只看风险的任何一个单一因素就能准确地了解真正可能发生的问题。

风险是一个系统

风险管理并不是要避免每一个可能的问题——而是要纵观全局通过综合考虑概率、影响和不确定性,你可以更明智地决定在哪里投入时间和资源。像FMEA这样的框架以及哈伯德这样的思想家提醒我们,风险不是一维的,它是一个动态的、相互关联的系统,并且需要深思熟虑的分析

以后当你面临一个有风险的决策时,希望请三思而行。不要只对最显著的影响点做出反应。而是要考虑整个系统,接受未知,并专注于真正重要的风险。这不是要完全消除风险——而是要管理好风险,以便有信心地前进。


往期系列文章

阿里微服务质量保障系列:异步通信模式以及测试分析

阿里微服务质量保障系列:微服务知多少

阿里微服务质量保障系列:研发流程知多少

阿里微服务质量保障系列:研发环境知多少

阿里微服务质量保障系列:阿里变更三板斧

阿里微服务质量保障系列:故障演练

阿里微服务质量保障系列:研发模式&发布策略

阿里微服务质量保障系列:性能监控

阿里微服务质量保障系列:性能监控最佳实践

阿里微服务质量保障系列:基于全链路的测试分析实践

阿里微服务质量保障系列 服务虚拟化技术

软件质量保障
所寫即所思|一个阿里质量人对测试技术的思考。
 最新文章