衡量技术的最关键指标，稳定性

来啦，请坐。

我是老杨，这是我的《数字化研发管理》书籍的前奏，我带你稍微见识下其魅力。

如果你有强化管理能力，量化技术产出，提升技术效能，打造技术团队等需求，那么这套课程会为你揭开技术管理的神秘面纱，可以让“妈妈再也不用担心你的工作了”。

这是《数字化技术管理的方法和实践》第八讲，衡量技术的最关键指标——稳定性。

一句话解释下：对于技术做的好还是坏，技术水平强还是弱，最基础最关键的指标就是稳定性。所谓稳定性就是系统能够稳定提供服务的能力，一般是SLA，用几个9的可用性或故障的个数来衡量。本篇中用故障个数来衡量，其实故障个数能够和几个9的可用性进行一个简单换算，此处先卖个关子，后面会讲到这个换算关系。

好，那下面详细讲解下技术最基础最关键的指标——系统稳定性，即系统可用性，只有系统是可用的才能谈好用、爱用。可以说稳定性就是技术的基本面，必须要不遗余力的去提升。那具体是在哪些方面进行提升呢？

根据上一篇的逻辑层次，稳定性划分为三个层次：技术基础层、技术平台层、业务服务层，本篇聚焦在技术平台层、业务平台层和服务层。提升稳定性的层次清楚了，那在稳定性的生命周期内怎么量化呢？本篇用故障个数来衡量，单纯的讲故障个数是不科学的，比如1个影响全部用户的故障和10个影响1%用户的故障，孰轻孰重？有鉴于此，本篇所指的故障个数，是分等级的故障的个数，即不同级别的故障个数不超过几个。

细心的同学会问：“那怎么定义故障等级呢？”

非常好的问题，这个就是由上一篇的业务等级顺下来的，定义故障等级的最关键维度就是业务等级，再加上影响用户，影响时间等维度，每家公司对故障等级的定义有所不同，我附上我的一个示例供大家参考，如图1，其中最核心的就是故障等级和判断标准，本示例判断标准中的影响用户和影响业务是OR的关系，影响时间是AND的关系。

图1 故障等级标准

好，故障等级标准有了，那么故障个数标准——稳定性标准也可以定出来了，我继续展示我的示例如图3，以S1的为例解释下：S1的故障一年不超过3个，换算一下就是说：S1级的业务一年内尽量控制在9小时以内不可用，相当于S1级的业务承诺4个9的可用性（4个9的可用性是指一年内8.76个小时不可用）。

图2 故障个数标准

那故障等级标准和故障个数标准都清楚了，怎么去提升系统稳定性呢？我又又又梳理了一张二维表如图3。

图3 提升稳定性

其中稳定性分为两个层次：

1.尽量避免故障发生。

2.故障发生了尽量降低故障影响。

每一个层次又有两种手段去进行保障：

1.技术手段：1）集群、分布式、异地多活、灾备等，避免单点，保证系统的水平和垂直扩展等；2）安全性考虑，防攻击等；3）持续集成、自动化测试、代码/架构优化等，保证质量；4）监控告警，及时发现问题处理问题；5）限流熔断降级，降低影响；6）各层资源隔离，避免互相影响。

2.管理手段：1）做好容量规划，严格管控生产环境发布和压测；2）定期巡检、演练，提前发现问题；3）制定应急预案，积累故障处理流程；4）7✖24小时值班；5）大促期间进行充分故障等。

至此稳定性的事已经讲述完成了，下面的章节会讲解性能和个数这两个指标，欢迎持续关注。

谢啦，下次见。