系统可用性：SRE口中的3个9，4个9...到底是个什么东西？

作为服务端开发的同学，最常听到的一句话是你的接口有几个9？2个9？3个9？到底几个9才算是稳定呢？

今天我们就从系统可用性（Availability）开始，为你讲解开发过程中那些常用的指标名称。

1.系统可用性

1.1-什么是系统可用性

概念：在给定的时间间隔内，计算机系统处在可工作状态的时间比例。

这里重点关注2个名词：

时间间隔：说明系统可用性是在指定的时间范围内进行统计的。
可工作状态：这里引出了一个公式。即【系统可用性 = 系统正常运行时间(排除故障时间) / 系统总运行时间】

1.2-建立"系统可用性"的目的

一方面，系统可用性与SRE的建设目标强相关，SRE的建设目标就是尽量减少系统故障时间，提升系统可用性。

另一方面，系统可用性概念看似简单，但是没有一个固定的计算方式，需要你自己根据自己的系统进行定义。

2.衡量系统可用性的两种方式

目前，业界衡量系统可用性的方式主要有2种：

时间纬度的系统可用性。
请求纬度的系统可用性。

上述两个可用性的计算方式为：

时间纬度的系统可用性：

Availability = 程序正常运行时间 / (程序正常运行时间 + 系统故障时间)

请求纬度的系统可用性：

Availability = 成功请求数量 / 请求总数量

3.时间纬度的系统可用性

基于时间维度的系统可用性，其概念为：从时间纬度，来评估系统的正常运行时间及系统可用性。

时间维度的系统可用性，就是我们经常提起的X个9。

X个9表示以年/月/日等为单位，在指定的时间范围内，系统可以正常使用时间与总时间之比。例如，我们以1年为时间单位，可以得出：

3个9：(1-99.9%)36524=8.76小时，表示该系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。
4个9：(1-99.99%)36524=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
5个9：(1-99.999%)36524*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。

根据如上的定义，我们可以总结出一张表格：

可用性等级	故障时间（以年为单位）	故障时间（以月为单位）	故障时间（以日为单位）
90%	(1-90%)*365天 = 36.5天	(1-90%)30天 24小时 = 72小时	(1-90%)*24小时= 2.4小时
99%	(1-99%)*365天 = 3.65天	(1-99%)30天 24小时 = 7.2小时	(1-99%)24小时 60分钟= 14.4分钟
99.9%	(1-99.9%)365天 24小时= 8.76小时	(1-99.9%)30天 24小时 * 60分钟= 43.8分钟	(1-99.9%)24小时 60分钟= 1.44分钟
99.99%	以此类推	...	...
99.999%	...	...	...

从上面的表格，我们也可以得出一个结论：

系统的99数越高，系统的可用性越高。

4.请求纬度的系统可用性

基于请求纬度的系统可用性定义相对比较简单。

例如，基于1000个请求，那么：

系统可用性90%：表示1000个请求中允许1000 * (1- 90%) = 100个请求出错。
系统可用性99%：表示1000个请求中允许1000 * (1- 99%) = 10个请求出错。
系统可用性99.9%：表示1000个请求中允许1000 * (1- 99.9%) = 1个请求出错。

5.系统可用性目标建立需要考虑的因素

5.1-成本

系统可用性越高，对你的系统要求也越高，那么你付出的成本和代价也会越高。

对于可用性越高的系统，那么对于你服务器的存储、网络、软件等要求也就越高。

而对于一些服务并不需要达到那么高的可用性，因此就可以为这些服务设置较低的可用性目标。

5.2-业务容忍度

系统可用性也需要考虑业务的容忍度。

对于金融行业服务来说，任何一个请求的失败都有可能带来资金的损失，因此对于这类的服务，对于错误的容忍度是比较低的，也就要求系统可用性较高。

对于常用的社交软件而言，例如我们使用的评论区功能/弹幕功能，对于这些应用来说，即使请求一次失败也是可以接受的，下次再请求成功就可以了。因此对于这些业务来说，业务容忍度较高，系统可用性不要求一定要很高。

6.总结