你今日预咗风险未？
每次与项目成员沟通后，应该都会预感项目有风险吧。
大概都会遇到这些问题：进度风险、技术难点、需求变更、资源分配问题等等。
别和我说，基本没啥风险，项目很稳定。真有这样没风险的项目，那就不需要架构师了。毕竟这样的项目肯定会有成熟的“轮子”，直接借鉴就好了。
实际上，没风险的项目很少，需要开发的软件项目总有风险的，因为实际需求都是随时间变化的。
我们日常生活很多事情都是看风险来做决定的，最明显莫过于股票、基金等投资行为，在自己能接受的风险范围内进行决策。这是因为风险可以反映出真实世界的不确定性，而且是一个很好的决策指示器，它能帮助我们看清障碍，做出合理的选择。
因此，风险是可以指导我们进行优秀的架构设计，也就是说我们可以采用风险驱动模型进行架构设计。

风险驱动设计

风险驱动模型就是以风险为中心，根据合乎逻辑的理由进行决策权衡的模型。

采用风险驱动的话，必须要能回答以下这些问题：

• 项目的主要失败风险有哪些？
• 应对失败风险的技术有哪些？
• 何时结束和恢复架构设计？

为了解答以上问题，主要的对策有：

• 识别风险、描述风险
• 选择技术降低风险
• 设定风险阈值，权衡架构设计

下面就将详细讲解以上的问题和对策。

风险

风险是指一个事件产生我们所不希望的后果的可能性。对于已经发生的，应该称之为事故。
以上对风险的定义无法直观衡量，我们借鉴下在工程领域对风险的定义，即：
风险 = 失败的概率 x 失败带来的影响
但定义中失败的概率和影响大部分的时候是难以精确度量的，除非我们能觉察到风险，也就是说只能在已知的条件下去定义风险。因此，风险的定义就变为：
当前已知条件下的风险 = 觉察到的失败的概率 x 觉察到的影响
此定义是让我们接受现实，尽力去降低觉察到风险，使架构设计达到已知的最优。
有了定义，首先我们要识别风险，然后就可以去描述风险，更深入地理解风险。

识别风险

识别风险的方法主要有：

• 确定难以实现的需求。例如，复杂难以理解的业务问题，就需要开需求会议来评估风险。
• 识别不完整或难以理解的质量属性（非功能属性）需求。例如，“保证可靠性”这种不可测试的质量属性，就需要开发质量属性研讨会来识别风险。
• 借鉴典型风险来识别。例如，web项目必须要关注安全性。
• 风险分类排序。以利益相关方需求的优先级和开发者觉察到的难度来进行风险分类排序。

描述风险

根据风险的定义，描述风险至少需要三个部分：条件、后果、优先级。条件是当前风险可能发生的实际情况，后果（觉察到的影响）是由条件引发的将来可能出现的不良状况，优先级（觉察到的失败的概率和影响等来确定）是已知条件下风险的重要程度。
然而，这样的描述方式缺乏项目交叉引用的能力，因此为了标识风险以及便于沟通理解，我们还需要加入四个部分：名称、编号、类型、来源。
我们可以采用表格的形式记录风险。例如，可以用表1作为示例来描述风险。
表1 描述风险

风险名称	风险编号	风险类型	条件	后果	优先级	来源
数据处理风险	R1.1	数据风险	业务系统CPU、磁盘和网络带宽已占有80%，数据处理将消耗大量的时间和资源	可能无法顺利完成任务	高	数据需求D1.1:必须1小时内处理完数据

通过描述理解了风险后，我们可以通过以下方式去降低或消除风险：

• 降低概率。减少业务系统的资源占有。
• 减少影响。优化数据处理的能力，提升资源的利用率。
• 减小风险发生的时间窗口。在业务系统空闲时，进行数据处理。
• 移除条件。增加CPU、磁盘和网络带等资源，或需求来源方沟通，降低质量属性的要求
• 接受现状，等接近不可接受的程度再着手处理。优先级不高，数据处理超时和资源不够用的情况较少出现，等解决完优先级高的风险后或风险优先级上升后再处理。

风险指导架构设计

一旦能清楚地识别和描述所面临的风险，就可以借助风险来指导架构设计，进而运用合适的技术去降低或消除风。
可以把风险理解为架构设计的GPS，它帮助我们进行架构设计的定位，告知我们目前在何地距离要去的目的地还有多远。

技术选择

根据风险选择技术是最敏捷高效的，这样就不会把时间和资源浪费在那些低效的技术上，也不会忽略那些危及项目的风险，主动地推动我们进行最优的技术选型。
借助风险选择技术的方法主要有：

• 分析风险的条件、影响、概率、时间窗口，确定可以解决的部分，进而选择解决问题的技术。
• 借鉴业界成熟解决方案。
• 研究密切相关的技术，寻找解决风险的技术

为了实现架构设计的可重复性，我们还可以总结经验，做出风险指导架构设计的指南。例如：

面临的风险	解决的技术	时间和成本预计
数据处理无法顺利完成	增加硬件资源、引入数据处理框架	硬件资源每年花费XX元，引入XX框架学习成本是x个人天

设定风险阈值

风险的阈值到底是多少？
我们参考下《恰如其分的软件架构》对风险阈值的定义：风险降低到不再是系统中最大风险源的地步。当然这是主观的判断，但只要能保证所设计的架构能克服所面临的失败即可。

如果架构不再是系统中最大的风险源，就可以从主动设计转为被动设计，否则从被动设计转为主动设计。主动设计是指主动设法降低或消除风险。被动设计是指在需求变更、出现未知的性能问题等需要及时纠正的情况。

需要注意的是，架构还可以随时重新变回重大的风险源，这可能是因为现实环境的变化、重大的需求变更、不可控的项目管理风险等等。当这些情况出现时，肯定要切换回主动设计模型。

总结

运用风险驱动设计的方法，可以识别和描述风险，并选择一套架构和设计技术来降低或消除这些风险，还可以根据风险的重要程度和阈值，把握住架构设计的度，进行最高效敏捷的设计。