可用性的本质
不可用和可用性是什么？
软件系统是开发给用户使用的。所以，软件系统的可用性是由用户决定的。对一个没有用户使用的软件系统，谈论它的可用性是没有意义的。
由此，我们推导出“软件的不可用”的定义：用户能感知到的不可用才叫不可用。
那么，计划内停机是否算不可用？如果用户认为该计划停机，我们通常认为计划内停机不算不可用。
不可用的反面，即可用。软件系统维持可用的状态的能力，我们称之为可用性。这也就是可用性的本质。
在行业里，可用性的计算有两种方式：
- 基于时间的可用性计算
- 基于工作单元成功率的可用性计算
我们接下来详细讨论这两种方式。
方式一：基于时间的可用性计算
计算公式为：可用性 = 系统正常运行的时间 / （系统正常运行时间 + 停机时间）
这个停机时间通常指的是意外停机时间。
这种方式下，可用性指标更像篮球比赛中计分牌上的分数。我们想要更多的分数，但是它本身又无法告诉我们该如何得到它。
行业上的文章大多也是写这种方式。
方式二：基于工作单元（units of work）成功率的可用性计算
这是《Google SRE》的另一种可用性计算方式：可用性=成功请求数 / 总的请求数。即请求成功率。但是，考虑到并不是所有的服务都是有请求的，比如定时任务型的服务。
所以，我们将公式改成：可用性 = 成功的工作单元数 / （成功工作单元数 + 失败工作单元数）。
在这种计算方式下，每个服务的owner都必须主动的去思考如何衡量自己负责的服务的可用性。
我们也注意到，这种可用性的计算可能带来的好处是：开发人员会被迫去思考服务的成功定义。在某些产品能力不足的团队，开发人员会倒推产品给出更明确的“成功”定义。
选择何种可用性计算方式？
可用性计算方式的考虑维度
选择何种方式，我们从以下两个维度考虑：
- 对实际工作是否有指导意义：能否真的指导我们如何提高可用性。
- 是否准确：能否准确到某个内部服务的可用性。
通过案例学习如何选择可用性计算方式
通过案例，可以让我们更容易看清可用性计算的本质。
我们先看两个案例。
案例1：凌晨3点，只有3个用户正在访问我们的服务。而我们正在发布一个内部服务A，导致这3个用户的多个请求返回失败。这时，我们应该如何计算可用性？
如果基于时间的方式，计划内停机时间是不算在不可用时间范围内的。但是，用于用户来说，凌晨3点时，我们的服务就是不可用的。
所以，在这个案例中，基于时间的方式对于实际工作（用户认为的可用性）没有指导意义。也无法准确到具体哪个服务不可用。
而选择基于工作单元成功率的方式是更合理的。
案例2：当DNS出现问题时，用户根本无法请求到我们的服务 www.example.com/login（简称login服务）和www.example.com/push（简称push服务）。这时，我们应该如何计算可用性呢？
在这个案例中，用户都无法访问到我们的服务，我们又该如何能计算出工作单元成功率呢？所以，此时它即可实际工作指导意义，又不准确。所以，基于工作单元成功率的计算是不合适的。
而假设login服务和push服务是存在拨测监控的，我们即可准确得知两个服务是真实不可用。
最后结论
通过两个案例，我们可以得到，单靠一种方式是无法准确计算出用户眼中的可用性的。所以，在实际工作中，我们需要同时使用两种方式。
附：
反脆弱与可用性之间的关系
反脆弱和可用性都可表达一个软件系统维持可用状态的能力。但是侧重点不一样。反脆弱更侧重表达对不可用状态的主动出击。而可用性更侧重在陈述一个事实。
