第二篇：稳定性之如何有条不紊地应对风险？

上一节，我们讲到人为和自然因素会给系统带来不同程度的风险，进而影响系统稳定性，这一节，我们来说一下，要如何有条不紊地去应对这些风险。

首先要知道的是，所有的系统都会存在风险，它是所有系统中不可避免的一部分，无论是系统集成还是软件开发，风险都会一直存在的，不能全部消除。我们能够做的是检查并评估风险范围、严重性及可能性、风险接受程度，依据这些去优化风险，总体的目标是确保可能出现的风险均是可接受的，不可接受的风险要全部被优化掉。

那么如何得知哪些风险是业务侧可接受的、不可接受的呢？这部分需要我们能够对业务有足够的认识，了解业务系统哪些是核心功能、非核心功能，而不能单独从技术视角来评估，技术永远是为业务服务的，不要自嗨。

首先我们来通过一个案列，如何从业务和技术双层视角来评估风险。

如何从业务和技术双层视角来分析风险

下面这张图是某在线教育平台的架构（当然是简易版），首先讲下该平台核心价值：用户选择（购买）适合的课程套餐，可在该平台完成学习，以提升自我。

前奏大体就是这样，你觉得该平台最核心的业务价值是什么？为了便于理解，我以A和B代表两个核心价值。

A：核心价值用户可以随时选择适合的课程套餐。

B：用户可以随时在平台完成课程学习。

对于上述核心价值 A 和 B，出现故障都是不可接受的，如果用户无法下单，那么则影响企业的损失，如果用户无法在该平台进行课程学习，那么则用户的核心权益无法保证，最终带来的影响，还是对企业的损失。

知道了该平台的核心价值之后，我们需要开始梳理整条链路，确保该链路是稳定、可靠的，才能保证上层目标。这条链路上出现任何风险都是不可接受的，换句话说严重性高。

文章中，我们以A的链路为例来说明，如下：

这么长的链路，如何保证每个链路都是稳定、可靠的呢？这离不开我们架构的设计和落地，使这些环节面对故障时，服务能够自愈或能够尽最大努力提供有损服务，当然我们本章节不是讲述如何设计，而想要结合业务，发现影响稳定性因素的可能性。

注意：并不是所有的风险对我们都有威胁的，我们优化的大概率可能发生的因素，并且出现故障时不可接受的（严重性高）。

业务分析：

登录这块业务出现故障的可能性小，理由是业务相对来说比较简单，不太可能发生变更。

商品这块业务出现故障的可能性大，理由是为了更好的售卖课程套餐，频繁组合调配SKU，业务的频繁变更，技术侧也会随之发生调整，服务端故障十有八九都是由变更引起的。

订单这块业务出现故障的可能性大，理由是订单模式可能发生多变，如普通下单、拼团、加价购等等。

支付这块业务出现故障的可能性小，理由是支付业务单一，多个支付渠道（微信、支付宝）。

课程这块业务出现故障的可能性小，理由是根据下单购买的课程，给用户分配就是了。

至此，我们就识别出了这个系统核心价值一的链路中存在的各类风险，这些风险可以用我们熟悉的四象限图来归类。

对于可能性大、严重性高的风险因素，我们需要重点关注，一旦出现故障那将带来的损失将是我们无法接受的，在实际项目中，无论是业务还是架构设计，都可能存在诸多潜在的隐患，我们不要丢了西瓜，捡了芝麻，要搞清楚哪些才是真正的威胁。

现在我们已经会识别并归类风险，在实际的场景中，我们面对的可能是微服务架构、分布式架构，面对的场景要复杂的多，风险可以说是无处不在，我们该怎么办呢？

如何管理风险？

首先想的是风险管理，是通过某种形式记录存档，以标准化的格式、可对其进行审计和追踪，方便对风险进行识别、分析和应对。识别、分析在前面也有讲到过，接下来要讲的是如何描述风险。

描述风险的记录形式有很多种，比如word、excel 、wiki等，对此，只要我们内部团队认可且使用方便即可。不过，对风险的描述要尽可能概全，比如要包含：风险描述、风险预案、风险严重性、影响范围等等。

之前我也见过很多bad case，对于风险描述不够详细或者缺乏关键信息，这样会导致：

风险处理不彻底，或者处理风险的同时引进新的风险；

无法对后续的风险审计、追踪提供有价值的信息；

无法以史为镜，原因是风险描述信息缺乏有价值的信息；

……

因此，我认为良好的风险描述，至少要包括以下内容：

简要讲述下每列信息的含义：

风险编号（ID)：这个是风险的唯一标识，它可以是任意类型的，通常选择唯一的整数标识，这是最简单的方式，满足需要即可。

风险名称：这个是对风险概述，需要对风险起一个契合的名称，该名称尽可能简短，便于查看，可以通过风险名称知道该风险的一系列信息。

风险描述：该风险的描述，是风险的概述，简要的描述的风险内容。

归属人：该风险的归属人，标识该风险的责任人，便于了解该风险当前的责任人，通过该责任人可以了解该风险的情况，包括风险解决方案，状态等等。

风险类型：该风险的归类，比如：稳定性、扩展性等。

发生条件（临界条件）：风险发生的情况，当出现什么情况时可能会触发该风险，我们需要知道该风险的发生条件，才能应对针对性的解决方案。

后果（带来的影响）：风险发生之后带来的影响是什么，例如用户体验、稳定性、数据丢失、资金方面的影响。

优先级：针对该风险发生的可能性及发生之后带来的后果对该风险定级，确保该风险能够及时消灭掉。

状态：该风险的当前状态，该值可以是“修复中”、“已解决”、“待处理”等。

标识日期：该风险描述的时间点，可以是发现该风险的时间点。

ETA（预计解决时间）：表示该风险的预计解决时间点。

解决方案：表示对风险的解决方案，可以短、中、长期。

预案：当该风险提前发生时，有哪些应对的动作，这些动作是风险应对的方法。

备注：可以是对该风险的任意描述、对该风险的特殊描述。

我们以A为例，举个风险描述的例子，为了视觉方便，将表格颠倒了下：

风险编号（ID）	123456
风险名称	商品列表模块-SKU慢查询
风险描述	高并发情况下，商品列表无缓存列表要查询多个SKU、直接对数据库查询
归属人	张三
风险类型	稳定性
发生条件（临界条件）	晚高峰期20点时一旦QPS超过100，则响应速度明显下降一旦QPS超过200，则数据库超负荷、瘫痪
后果（带来的影响）	无法满足A的要求
优先级	高
状态	处理中
标识日期	2020.12.1，12点左右
ETA（预计解决时间）	2020.12.2
解决方案	短期方案：数据库索引优化、提升并发处理能力短期方案：重新预估临界阈值，对该接口QPS限流长期方案：优化商品列表架构、引入缓存
预案	2020.12.1，20点前要对该接口QPS限流完成，阈值：150
备注	短期方案将2020.12.2完成、长期方案预计2021.3.3

通过上面的表格，可以清晰看到风险概述、紧急程度、处理方案等等，良好的风险描述，一方面便于风险管理，另一方面有助于以史为镜，对于后续提升团队实力都是很有帮助的。接下来我们说说面对风险，有何处理原则可参考？

如何对应对风险

对于A的风险描述中，我们能够看到长期解决方案是通过引入缓存，减轻对数据库查询压力，目的是将数据库的风险转移到缓存，通过引入缓存提升响应速度和吞吐量，这种方式被称之为“风险转移”，在PMBOK2012 版提到4种应对风险原则分别是：规避、转移、减轻、接受，下面我们详细讲下。

第一，规避。通过改变项目计划，以排除风险或条件，或者保护项目目标，使其不受影响，面对某些风险，在初期通过分析找出发生风险事件的原因，消除这些原因来避免一些特定的风险事件发生。这么说可能有点抽象，我们举个例子，在实际项目中，可能的风险：

技术方案未满足业务要求。原因分析：表象是为满足业务要求，其本质原因是对需求理解不透或者存在边界未搞清楚。

技术方案存在偏差。原因分析：表象原因是技术方案存在漏洞，其本质原因可能是对业务理解不够透彻导致技术方案存在偏差，或用人的能力未跟上等问题。

你会发现，这些风险完全可以在发生风险事件之前，找出原因，提前把问题消灭掉。比如：

组织相关负责人对该业务串讲，并梳理整个业务流程。

对技术方案Review，要求更高级别的人员参与，确保技术方案能够满足当前需求且合理。

第二，转移。将风险的后果连同应对的责任转移到第三方身上，其实是将责任推给另一方，而并非将其排除。

为什么需要转移风险？原因有两点：

处理风险的成本要高于收益；

某些风险，不受我们控制比如：企业内部跨团队合作，对于依赖某兄弟团队的服务，我们是无法控制的。

比如：当前很多中小公司的服务都使用云厂商，将公司的服务部署在云上，对于中小公司选择云厂商无疑是比较优的选择，第一是云厂商提供高可用的基础服务，依赖云厂商比较有优势的技术，提供高可用的基础服务，将这种劣势和可能存在风险转移给云厂商。

在团队合作的过程中，双方责任和职责要明确并划分清楚，其实某种意义上也是一种风险转移，双方各自履行好自己的责任和职责。

第三，减轻。通过降低风险因素发生严重性，在风险发生前采取行动，减少风险发生后所带来的影响或损失降到最低，这样比事后亡羊补牢要有效。

比如，某项目组的研发工程师对所需开发技术不熟，要边输入边输出，中间过程可能要踩很多坑。可以采用熟悉的技术来减轻项目在成本或进度方面的影响，也可以事先进行培训来减轻对项目的影响。

第四，接受。是对风险分析之后，对于风险发生后的严重性，表示是能够承受的。采取此项技术表明项目团队已经决定不为处置某项风险而改变项目计划，或者表明他们无法找到任何其他应对良策，还有种情况是处理风险的成本要大于收益，这种也是可接受的。

比如，一般情况下我们提供服务是冗余的，那么这种情况对某台服务宕机或者故障时，这种故障可接受，再或者是对于风险的发生，我们已经有预案了，并且风险的严重性也是可接受的。

应对风险，要持之以恒

上面案例A风险的描述中，还要考虑它的长期方案是否落地、落地后是否带来新的风险？如若长期方案未落地，那么商品列表模块，可能还存在着风险，等等。故面对风险，我们要持之以恒。

对风险持续地监控、跟踪，避免拔出萝卜带出泥，防止优化过的风险再次出现在我们的系统中。因此，我们需要持续监督风险的变化情况，并确定随着某些风险的消失而带来新的风险。

为此我们需要做两个层面的工作：

跟踪风险的变化情况，包括在项目生命周期内，风险产生的条件和导致的后果，衡量风险的可能性与严重性，并针对此制定优化方案。

对风险池中的风险变化情况及时调整风险优化方案，并对已发生的风险及产生的遗留风险和新增风险，及时采取适当的应对措施。

已发生过和已解决的风险也应及时从风险监控列表调整出去。

最有效的风险监控工具之一就是Top 10的风险列表，Top 10是按照严重性、可能性排序，也就是这是最需要优化的，对此要密切监视，每次检查之后，形成行的Top 10，总之要确保Top 10是定期变更的，而非一成不变的。

小结

相信到这里，你对风险的评估及处理有更深的认识，风险是持续存在的及变化的，我们能够做的就是降低风险发生的可能性和严重性，将风险带来的影响或损失，降到最低。

面对风险想要彻底消灭是不可能，风险可能是多个因素组成的，而非单一形成，消灭旧的风险，可能引出新的风险，面对这种情况，我们唯有前期，架构设计时能够提前识别风险，从而应对风险，且看我们下一章如何借风险之力驱动架构演进。

关于稳定性建设之道大纲速览

目录：关于【稳定性建设之道】大纲速览_jackl-CSDN博客从理论、方法、实践多维度阐述稳定性、从全局视野出发、由内到外、从组织到文化，从风险识别到风险预防、从面向失败到主动失败多个阶段，多维度去描述如何打造一个高可用的系统。https://blog.csdn.net/liu_dudu/article/details/122333724