> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2022-nian/w23-yi-zhong-ke-yi-zhun-que-miao-shu-ke-hu-ying-xiang-de-wen-ding-xing-zhi-biao.md).

# 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%

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