管理系统中风险是系统可用性和可扩展性的关键(3)

简介: 管理系统中风险是系统可用性和可扩展性的关键(3)


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


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


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


image.png


image.png


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


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


风险评估步骤



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


1. 确定合适的粒度级别来评估风险。

2. 选择一个可以复制的方法。

3. 对将进行风险评估的人进行培训。

4. 安排事后评审每一个评估,或者集体回顾所有的评估。

5. 选择一个合适的评分表(例如,1、3、9),并考虑好需要如何保守。

6. 完成代码发布或系统维护后,对故障类型、可能性、严重性及可检测性进行审查。


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

 





相关文章
|
3月前
|
缓存 运维 监控
|
3月前
|
缓存 监控 负载均衡
系统健康长期“三高”:实现高性能、高可用性和高稳定性的关键要素
大家想必都知道在人类健康领域,我们常常警惕“三高”带来的风险,三高是一个不健康的意思,而在数字化世界中,恰恰相反,系统的高性能、高可用性和高稳定性代表着系统的健康和卓越运行,是一个健康的概念。作为开发者怎么能让我们开发的系统保证长期“三高”,那么本文就来简单讨论一下如何让系统长期维持理想的“三高”标准,以及“三高”在实际业务场景中的真实性,并探索一下在技术负责人角色中使用“三高”来评价系统开发工作的可行性等内容,欢迎大家在评论区留言交流。
77 1
系统健康长期“三高”:实现高性能、高可用性和高稳定性的关键要素
|
7月前
|
消息中间件 监控 Java
系统稳定性保障设计总结和思考
系统稳定性保障设计总结和思考
355 0
|
7月前
|
运维 监控 容灾
建设强大系统:提升高可用、可靠性和稳定性的秘诀
建设强大系统:提升高可用、可靠性和稳定性的秘诀
|
11月前
【架构质量】可靠性系列#1:可靠性与韧性
【架构质量】可靠性系列#1:可靠性与韧性
|
12月前
|
敏捷开发 设计模式 测试技术
如何从容应对复杂性(1)
如何从容应对复杂性
101 0
|
12月前
|
设计模式 安全 前端开发
如何从容应对复杂性(2)
如何从容应对复杂性
|
JSON 缓存 监控
系统的稳定性建设
 静儿来面试新美大这个部门的时候,HR跟我说我们是最核心的部门,没有之一。我以为这是句夸张的招人用的玩笑。结果来了发现,额,这句话是很公正客观的。现在上上下下组成了一支牛人团队,请来了其他部门很多资深高手进行封闭开发,确保我们系统的稳定性。   选择一份工作,必然要考虑的是:我们是做基础设施的,还是做平台的,还是做核心链路的。业务方面讲究领域驱动,各个领域目标也不同。   基础设施最重要的指标是稳定性、性能、扩展性。平台讲究多业务,通用性,人效。所谓人效就是我这个平台有些自动化的东西不能满足需求,需要靠手工来完成,这样开发人员的人效就低。如果一个平台需要输入的东西很多,而且还需要多步骤审核
|
设计模式 敏捷开发 安全
如何从容应对复杂性
软件的复杂性,是一个很泛的概念。但是一直都是开发过程中的一个难题,本文旨在探讨如何去从容应对复杂性
281 0
如何从容应对复杂性