架构中的控制风险

风险，在架构活动的上下文里，指的是有可能带来损失的不确定事件。一般说风险足够大，是指不确定性事件发生的概率和一旦发生之后带来的损失同时都很大。

架构师要面对互联网企业在不确定性的商业环境、日常工作缺乏流程、团队成员高强度工作节奏和日常反射式研发所带来的混乱和质量问题。所以在架构活动的全生命周期里，架构师都需要持续收集、发现、评估和控制风险，把风险控制在可以接受的范围内。

具体怎么做呢？有三个关键动作：逐渐形成量化认知，可以冒险，但不能不说。

第一个关键动作是逐渐形成量化认知。发现和评估风险是个极其耗时间的过程。在互联网企业，不仅每天都有新风险，而且现有的风险还在不断变化。要是把风险评估作为一次性的前置环节，不仅会占用大量宝贵时间，也不能有效控制风险。

所以成本更低的做法是搭车制。意思就是架构师要在架构活动中持续预留一部分的带宽，比如 5% 的精力。任何时候都先关注已知的最大风险，然后随着时间的推移，不断对这些风险形成更深刻的认知。而这些更深刻的认知，最终也将转化成一个能够准确量化的风险控制成本和企业的预期损失。

第二个关键动作，可以冒险。在架构活动中，如果我们发现了一个风险，也对损失有了一定的预估，并准备好了预案以响应不确定性事件。这个时候，就可以“冒一次有准备之险”。

为什么要这么做呢？如果企业能接受预估的损失，如果风险预案的成本与预估损失差别不大。那么当我们选择忽视这个不确定性事件的话，既可以省下宝贵的研发资源，投入到更紧急的需求中去。还能让我们获得宝贵的时间资源，有机会以更快的速度去做业务迭代。

第三个关键动作是不能不说。架构师的权责，还没有大到可以代替公司去决定风险政策的地步，所以必须向上及时传递重大风险和冒险行为，而不是直接采取冒险行为。

一旦决定采取逐渐形成量化认知的策略，那么就要准确感知即将到来的风险变化。大多数时候风险是连续的，但是监管政策的大幅调整、公司上市、经济环境的变化、黑天鹅事件等等，都会让风险产生大幅变化。一旦风险升级，你就可以试图控制风险，寻找有效的控制手段和响应预案。并对效果做一定程度的验证，提升团队对风险变化的响应能力。

如果没有找到有效的控制手段，而风险又很大，那么最好的办法就是及时向决策者、赞助人汇报，告知风险。同时也要向合作方传递风险预警。