我在博客文章《以RAID分析作为架构驱动力》中介绍了RAID分析方法。这个方法将风险作为其中的一个重要驱动力，指导我们进行架构设计，避免陷入未知的陷阱。
无独有偶，Simon Brown在其著作Software Architecture for Developers中专门列出一个章节来阐释风险。他认为：
识别风险是恰如其分的预先设计的一个关键的部分，简而言之，风险就是未来可能发生的坏事，比如所选技术无法满足供应商的承诺。
Software Architecture for Developers中译本
George Fairbanks在其著作Just Enough Software Architecture中更是将风险看做架构设计的核心，提出“风险驱动设计”的方法论。我作为本书的译者之一，深刻地理解了这一方法，并在诸多项目中尝试实践。
古语云：为将者，未虑胜先虑败，故可百战不殆矣。这种“未虑胜先虑败”的思维实则就是我们时常提及的风险思维。由于软件架构是整个系统中最重要也是最不容易改变的部分（另一层意思就是改变成本太高），若不能正确地预见风险，并给出应对之道，一旦风险成为事实上的问题，就可能导致整个系统架构要推到重来，又或者付出即为沉重的重构成本。
George Fairbanks在Just Enough Software Architecture书中给出一个风险驱动设计的案例，介绍了Rackspace日志处理系统的演化，分别从本地日志文件演化到中央数据库，进而演化到基于HDFS的索引簇方案。这种演化固然说明了在当时当刻做出的所谓“恰如其分”的架构，但从另外一个层面来看，也可以视为风险意识不够，没有充分考虑到日志分析系统的可伸缩性，从而带来两次高成本的架构重构（甚至可以认为是重写）。
与RAID分析方法相似，Simon Brown在Software Architecture for Developers书中提出了一种帮助团队识别风险并排定优先级的协作手段——风险风暴。步骤如下：
- 首先在白板上绘制系统最高层的架构图（可以参考书中给出的C4模型）；
- 团队成员（架构师、开发者、项目经理、业务分析师）在架构图前，各自写下他们能够识别的风险，一个风险用一张便利贴，并量化该风险；
- 将各自的便利贴贴在架构图上，邻近风险被识别的区域；
- 对风险设定优先级。
C4模型
识别风险并评估其优先级并非最终的目的。风险可以提前给我们以警示，之所以采用风险风暴的形式，是希望通过团队成员的群策群力尽可能让隐藏的风险暴露出来，从而为架构设计提供重要的参考。
于是乎，识别风险大多数时候又与技术决策以及技术选型相关，这才是真正考验架构师技术能力、敏锐性、知识广度与深度，以及设计经验的关卡。这是一个很大的话题，我希望能结合广泛的案例来深度探讨这部分内容。这里揭过不提，算是一个不礼貌的收尾。
网友评论