软件开发安全保证措施（常见的软件开发风险和应对措施）
我们在软件开发过程中会遇到不同的变更，代码的更新，新功能的写入，架构的调整，系统的扩容。每天有大量的需求，代码，Bug需要处理，其实我们做的每个对系统产生影响的动作背后都存在风险。那么我们如何评估和管理这些风险呢，任何一位项目的管理者或者领导者都需要了解下面提到的方法论。
对风险进行定义
大家知道在做任何一次变更的时候都存在风险，比如一次新功能模块的发布会影响到几个老的功能模块，那么作为管理者如何评估这个上线的新功能的风险呢。这里介绍几种方法。
第一，直觉，这个说起来有点好笑，其实就是凭借经验丰富的程序员，架构师（老司机）的感觉去评估这次变更存在的风险。这种方式长期存在各个互联网/软件企业之中的，基本都是靠老人来带着大家踩坑。这种方式虽然多见，但是缺点很明显，就是依赖个人能力，而且具有随机性，一旦个人判断失误就真的坑了。
第二，交通灯法。还是刚才新功能的例子，我们可以把新功能影响到的老功能模块列出来，针对每个功能模块受到的影响进行“红，黄，绿”灯评价。绿灯=低风险，黄灯=中风险，红灯=高风险。然后通过团队以及专家评审的方式来判断这次新功能的上线的风险有多大。这个的好处是，减少了人为感知的风险，让风险具体化了，而且引入了团队评审的方式，让结果更加客观。
第三，故障模式及影响分析法（Failure mode and effects analysis, FMEA）。这种方式会把一个功能模块切分成几个组成部分，然后针对每个组成部分的三个维度进行打分。这三个维度分别是：故障发生的可能性，故障发生的严重性，故障检测能力水平。可以针对这三个维度进行打分，分数从1-9分不等，分数越高说明风险越高。通常我们会按照高中低三个级别来划分分值，例如：高风险：9分，中风险：3分，低风险：1分。小伙伴们可以根据自己的团体来具体设置分值不同。举个例子来说，我们有一个登录服务，有可能出现“给用户设置错误权限”的风险。因为这个权限设置都是系统管理员来设置的，那么故障发生的可能性是比较低的，我们给其打分为1分（低风险）。一旦这个权限设置错误会导致，用户看到不属于自己的信息，这个故障发生的严重性是很高的，我们给其打分了9分（高风险）。这个故障我们可以通过后台脚本的方式去针对每个用户的权限进行核对，所以故障检测能力的水平属于中等，就给3分（中风险）。如此这样我们可以把三个维度的分数相乘就是1*9*3=27。如果这个登录功能还包含其他的组件，就以此类推评估每个组件的风险分数然后相加就是这个功能的风险分数了。如果我们希望降低发生故障的风险，就根据这个三个维度采取对应的防范措施。例如：后台定时监测用户权限，如果发现第一时间让用户和权限做隔离，并且通知客户部门给客户做解释，把风险降到最低点。如果这么做了我们就将故障发生的严重性的风险分值将下来了，从原来的9分降到3分，那么总分就是1*3*3=9分。是不是把风险控制到可控的范围内了呢。这里可以根据每个团队设计一个风险的表格把风险都记录下来。
对风险进行管理
如果能够对风险进行定义了，那么风险管理需要主要两类风险，第一类急性风险，第二类整体风险。
急性风险管理，往往针对一个或者多个功能点的变更，整个实施时间不会太长。这里需要针对该变更进行拆解，然后用上面介绍的FMEA进行风险评估，并且对每个组件的风险水平进行设置容忍值。最后形成一个急性风险管理的表格，让实际风险发生的分值必须在风险水平的范围以内。
整体风险管理，这里需要变更的范围比较大，而且持续时间较长，所以未知因素和风险就更加不可控制。这里建议在急性风险管理组件风险水平的基础上加上持续时间的风险评估。会针对每个变更持续时间设置风险水平能够容忍的分数。
但是，在日常的工作中总会有特例，例如有些功能急需变更，有高风险同时也有高收益。这个时候，技术总监，架构师，CTO，业务主管手中也有一些风险水平的分值，这些分值用来调整表格中风险水平的容忍最大值。说白了就是如果关键人物参与风险评测，推动紧急变更上线。
总结：今天我们了解了风险评估的三种方法，并且推荐给大家使用FMEA方法，针对变更拆分，评估，打分，降低单项风险。针对紧急风险管理和整理风险管理提出了一些分析方法。