W23-一种可以准确描述客户影响的稳定性指标

背景

为什么想到了稳定性指标这个话题是因为最近发生的几件事情叠加在一起促成了这样一段思考。其一是我在准备愚公的容灾工作;其二是可用性提升是今年团队的O2,我需要辅助忠泽去做一些规划;其三是Jerry前段时间推荐的一门和数据思维相关的课程,给了我不少启发。

一些基础概念

我们经常会讲服务要高可用、高可靠、高稳定,从广义上看,会理解为有一个类似成功率的指标去衡量就够了。但从狭义上看,可用性、可靠性、稳定性这三个概念并不等价。

Availability,可用性。指在某个考察时间,系统能够正常运行的时间占比。描述的是能不能用。

Reliability,可靠性。指系统在给定的时间间隔和给定条件下,系统可以无故障持续运行的概率。描述的是对不对。

Stability,稳定性。指软件在一个运行周期内、在一定的压力条件下,在持续操作时间内出错的概率,性能劣化趋势等。对于前端来讲,运行时是非中心化的,离散在各个终端的。所以,稳定性描述的是,在不同机型和网络条件下,软件好不好用。

它们之间的关系可以这样理解,可靠性差一定程度上是会影响可用性,但反过来不一定成立。可用是可靠的前提,稳定是可靠的进一步提升。

接下来简单介绍下期望这个概念。这个部分来自前边提到的数据思维课,里边有一个用期望解释墨菲定律的例子,是一个很好的应用。

期望的定义是,对可能出现的结果以概率为权做加权平均。期望值完全是由概率分布决定。在大数定律下,次数足够多后会达到我们预设的期望值。由此可见,期望是一个事前预测值。需要注意的是,我们常讲的平均值是一个事后的统计值。在英文中它们也各有所代,期望值是Mean,平均值是Average。

现有的可用性指标计算方案

软件交付规格中的SLA就是一组期望值。

行业内有一个对可用性的通用定义,Availability = MTTF / (MTTF + MTTR)。

MTTF,即Mean Time To Failure。平均失效前时间,系统平均能够正常运行多长时间,才发生一次故障。MTTF越长,系统越可靠。

MTTR,即Mean Time To Repair。平均修复时间,是指可修复系统的平均修复时间,就是从出现故障到修复完成的这段时间。MTTR越短,系统可维护性越好。

公司内对可用性做了更为具体的定义。详细定义了修复时间,时间是通过故障损失数据转化为时间来计算的。

计算公式为:Availability = ( 525600 - sum( min {1440 * loss, ( t2 - t1 ) })) / 525600。

525600代表525600分钟/年。1440代表1440分钟/天。loss代表日订单损失占比,如果是非交易类业务,也可以选择浏览量损失,或者增加的客诉量。t2-t1代表故障时长。

X指标的计算方案

我尝试找到一个指标,可以更为准确地描述对客户的影响。因为还没有想到很好的名字,就姑且叫它X指标吧。

如果我们把对客户影响的期望值定义为M(Mean),把客户影响发生的概率定义为P(Probability),把客户影响的程度定义为D(Degree),那么应该有M = P * D。为了方便阅读,这里以交易类业务为例进行说明。在交易类业务中,P = 故障时长 / 全年时间,D = 损失单量 / 全年单量。

那么X指标的计算方式可以如下:

( 1 - sqrt ( (损失单量 / 全年单量) * (故障时长 / 全年时间) ) * 100%

如何将这个指标落到生产当中,还需要一些纯熟的思考。

最后更新于