运维稳定性问题的关键–可用性

复盘更多的是基于事后的总结与提升。那么我们如何发现、测量稳定性问题呢？那么我们就需要请出今天的主角了——可用性。

可用性作为评价业务稳定性的一个重要指标，它可以通过数据量化、建立基线的方式来发现业务中存在的周期性问题，并由此更有针对性的进行服务质量改进。

那么，什么是可用性呢？可用性是指在一个指定的时间间隔内，对于一个功能个体来讲，总的可用时间所占的比例。换句话说，是指在指定的时间段内，系统能够正常运行的概率或占比。对于我们现在的互联网业务来说大部分都属于「实时」、「在线」，即Real-Time Online System，实时在线系统。对于我们的大部分业务说上面所指的指定时间段，应该就是7*24小时。

可用性的结果经常使用小数点或者百分比表示。我们通常使用一个被称为几个九的度量，对应小数点后连续9的个数。比如，“五个九”就是指该系统在指定时间段内有0.99999（或者99.999%）的可用性。

比如，某系统在一个指定的时间段内，如1天，即24小时。同时我们的监测粒度是分钟，即1440分钟。在我们监控的1440分钟内，系统正常运行了1430分钟。那么在这个指定的时间段内，该系统的可用性即为1430/1440≈0.99306（99.306%）。也就是我们常说的2个9。

那么，99.306%这个值就代表该系统处于正常可用的Availability状态占比，那么1-99.306%得到的0.694%这个值就代表该系统处理异常不可用的Unavailability状态占比。简单的罗列为公式，即为：

业务在线总时长 ＝ 业务的正常可用时长 + 业务的异常不可用时长

更进一步，可用性就是指：

可用性＝业务的正常可用时长 / 业务在线总时长

理解了什么是可用性，接下来我们讲一下如何建立可用性。建立可用性的方法有很多，常见的方法有几种：

拨测法即是按照各业务的应用、功能、模块进行周期性测试其运行状态是否正常的一种方法。

举例：我们业务有一个名为A的模块，那么就周期性的（比如，每5分钟一次）对这个模块使用模拟用户行为的方法对其运行状态进行抽样检查。如果该模块运行正常，就记为Availability，如果为非正常，就记为Unavailability。累加至一个时间周期内（比如，1天）Availability状态的占比即是这个模块的可用性。

那么，如何判断业务或模块是否正常呢？我们以一个web类型的业务为例，我们可以检查该服务下的主页、分类页或内容页的关键内容。一般来说，我们可以匹配指定页面Head、Body、bottom的指定字段或关键字。如果可以匹配到指定的一个或一组字段或关键字，那么即为正常，反之为异常。我们可以通过脚本、Nagios、Zabbix等工具来实现对业务的周期性拨测。

这种方法的优、缺点都很明显。优点是这种方法实施难度较低且可以与通过模拟用户行为的方式来测量，也业务实际情况可以比较吻合。但通过这种周期性抽样的方法，存在抽样样本不足或偏差的问题。比如每5分钟拨测一次，如果故障出现和修复都在这5分钟内完成，那么拨测法就很难去捕获到这种错误。

日志分析法即是通过各业务的应用、功能、模块日志进行分析得到可用性的一种方法。

举例：我们业务有一个名为A的模块，那么就周期性的（比如，每小时一次）对这个模块上1个小时日志进行分析。从日志层面区分出正常请求在占比，即是这个模块在过去1个小时的可用性。还是以web类型的业务为例，我们可以从日志中将2XX、5XX状态分别进行统计、分析，可以理解2XX即是Availability，5XX即是Unavailability。（3XX与4XX可以按照实际的业务情况再考虑是否参与分析）

这种方法上很明显的解决了拨测法抽样样本不足或偏差的问题，但也存在与实际业务影响指数可能会存在较大差别的情况。比如，我们在过去1个小时的错误都发生在1分钟内，剩余的59分钟业务都是正常的。很显然这样得出来的可用性和实际业务情况是有一定偏差的。那么怎么解决这种偏差呢？日志分析阈值法就应运而生了。

日志分析阈值法是在日志分析法的基础上添加了状态阈值判断的一种可用性计划方法。

举例：我们业务有一个名为A的模块，我们通过日志分析法得到，这个模块每分钟正常情况下的请求数约为10W次，那么我们可以设置一个阈值为10次。这10次的意思就是指，我们容许在1分钟内发生万分之一以内的错误。如果1分钟内发生的错误在10次以内，我们就认为在过去1分钟的状态为正常，就标记为Availability。如果1分钟内发生的错误超过10次，那么我们就认为在过去1分钟的状态为异常，就标记为Unavailability。最后再统计Availability状态的占比即是这个模块的可用性。当然这个阈值需要根据业务的实际情况进行调整。

这种方法上就很好的解决了拨测法抽样样本偏差与日志分析法差生实际业务影响脱节的不足，达到很好的一种平衡。

还有一个问题，如果一个业务由A、B、C三个模块构成，那么怎样通过模块的可用性，怎么算出业务的可用性呢？简单的方法就是通过最三个模块可用性的平均值即可。但这存在与业务目标相悖的问题。那么我们可以通过与业务目标对齐，进行加权平均的方法。比如A模块对业务来说更加关键，那么我们在计算可用性时就给出A模块更多的权重；C模块是业务的旁路系统，那么就可以在计算时降低对C模块的权重。以此类推，我们得出的可用性就可以尽可能的贴近业务及其目标了。

我们还可以通过利用像基调、博睿这种第三方的测试平台的节点，对业务进行更加广泛的拨测，以提高采集样本的精度，减少其偏差。当然其结果也受限于第三方平台及链路间的稳定性的影响
对于有客户端的业务，我们可以通过在客户端关键路径上进行打点，然后将用户的打点日志集中至服务端后再进行集中分析。这种方法虽然可以反应出最真实的用户状态，但也存在实施成本相对 较高、日志上传延迟等问题。

计算可用性的方法有远不至上面写的几种，并且并有哪一种方法可以解决所有的问题和痛点。从成本、收益、时间等角度选择一种或多种最合适自己业务或团队的方法，用于持续改进业务的服务质量才是王道。