更有意义的可用性

最近 Google 发了一篇论文：《更有意义的可用性》。

技术管理圈子里有句玩笑话，「只要选对了指标，就没有搞不垮的团队」。

选择正确的指标来考核研发团队的绩效非常关键。

同时也非常困难。

我在两三年前开始使用发布频率、lead time、MTTR、回滚率等四个指标来考核团队绩效，并且把发布频率当成北极星指标。

这四个指标里，发布频率和 lead time 主要表征效率，而 MTTR 和回滚率则主要表征可用性和质量。

在使用过程中一直有点问题的是 MTTR。

可用性是好指标吗？

一提到可用性大家就会想到那几个 9。

可靠性级别	允许的故障时间（每年）	允许的故障时间（每季度）	允许的故障时间（每 28 天）
90%	36 天 12 小时	9 天	2 天 19 小时 12 分
95%	18 天 6 小时	4 天 12 小时	1 天 9 小时 36 分
99%	3 天 15 小时 35 分	21 小时 36 分	6 小时 43 分 12 秒
99.5%	1 天 19 小时 48 分	10 小时 48 分	3 小时 21 分 36 秒
99.9%	8 小时 45 分 36 秒	2h 9 分 36 秒	40 分 19 秒
99.95%	4 小时 22 分 48 秒	1 小时 4 分 48 秒	20 分 10 秒
99.99%	52 分 33.6 秒	12 分 57.6 秒	4 分 1.9 秒
99.999%	5 分 15.4 秒	1 分 17.8 秒	24.2 秒

在国内技术圈你还经常可以看到或者听到「高可用」这个词。

从畅销书的名字就能看出来「可用」是多么重要。

但实际上，「可用性」只是软件系统的核心设计指标「RAMS」里面的一个：

Reliability
Availability
Maintainability
Safety

甚至在我很喜欢的《Designing Data-Intensive Applications》里，它提到的应用系统主要追求的三个方面就直接没有「可用性」，而是：

Reliability
Scalability
Maintainability

我觉得这里的原因，主要是「可用」更多是用户纬度的一个感受（系统在运行的过程中有多少时间是可以被用户使用的）。它本身是以「可靠性」（系统在出故障的情况十分能够完成工作）和「可维护性」（系统进行定期维护和故障处理十分方便）等其他工程纬度的指标为基础的¹。

按照 Google 那本 SRE 书里面的说法，好的指标应该有三个特性：

Meaningful
Proportional
Actionable

很明显，「可用性」这个指标不太符合第三点：因为你要想让系统更可用，主要是通过提高其他指标表征的工程能力。

但更重要的问题是，「可用性」在「Meaningful」方面也有些问题。

意义不够明确

基于时间计算的问题

考虑可用性很容易想到的首先是基于时间的计算方式：

Availability = Uptime / (Uptime + Downtime)

但是系统怎样算「运行」怎样算「失效」？比如，可以登录添加购物车不能结账算「运行」还是「失效」？

相信每一个奋战过双十一的人都有自己的看法。

所以有了一个看起来更好的计算方式：

Availability = MTTF / (MTTF + MTTR)

北京正常成都打不开算什么？有意的服务降级算哪边？究竟处理什么样的问题算 MTTR？

相信每一个做分布式系统的人都明白，「partial failure」根本避免不了。

而且，系统处于高峰前的不可用和没有流量时不可用，很明显应该有所区分。

为了尝试克服这里面的歧义，一些公司转向了基于次数的计算方式。

基于次数计算的问题

为了克服基于时间计算可用性的问题，最常见的改进是：

Availability = Successful requests / Total requests

这比以时间为基础的指标更加合理，但也存在一些问题:

它主要说明的是高频用户的体验(不同用户的活动水平可以有 3 个数量级的差异)。
它很难对应到最终用户的实际体验。
当用户感知到系统故障时，请求会大量减少，这会带来数据上的巨大偏差。

更有意义的指标

基于时间和基于次数计算都有各自的问题，因此我们实际上没有办法统计类似于下面这样的可用性指标：

每小时最高 10 秒的不良可用性
每季度最高使用时间 6 小时的不良可用性

Google 的做法从概念上来讲不复杂：就是把 uptime 考察对象从系统切换到用户，一个用户的 uptime 可以是另一个用户的 downtime。然后综合所有用户的统计数据，就可以综合基于时间和基于次数计算的优势，得到一个 user uptime：

\[user \ uptime =\frac{ \sum_{u \in users} uptime(u) }{ \sum_{u \in users} uptime(u) + downtime(u) }\]

难点在于，如何获得每个用户的 uptime 和 downtime：

如果是通过探针，那么你很难去对每个用户都做一个不断发送请求的探针。
如果是通过统计用户真实请求，那么你会遇上用户请求稀疏造成数据失效。

Google 在论文里面提出的计算方法是：

After a successful (or failing) operation, assume that the system is up (or down) until the user sees evidence to the contrary.

另外，还有一个概念是「截止期」（cutoff time）：用户平均请求时间间隔的 99 分位。如果一个用户发送了一个请求，然后在截止期内没有再发送请求，则既不计入 uptime 也不计入 downtime，而是计入 inactive time：

这个指标显然是 meaningful 并且 proportional 的，那么它是 actionable 的吗？

可操作性

为了增强指标对操作层面的指导意义，Google 的做法是：

To make availability information actionable, we want to be able to distinguish between outages of different durations (e.g. one user outage of 1000 minutes, vs 1000 outages of 1 minute). In general, the bigger the window you examine availability over, the better the availability figure looks. To address this, windowed user-uptime combines information from all timescales (window sizes) simultaneously. For a given window size w, availability is computed by enumerating all windows of size w, computing the availability of each, and then taking the lowest value. Taken together the results are called the minimal cumulative ratio or MCR.

所以，MCR 是枚举固定大小的时间窗口，计算每个窗口的可用性，然后取最小值来计算的。

我们来看论文里面的例子：