高可用：系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一

我们在评估一个系统的可用性和可靠性时，一般都会说四个9，五个9之类的（四个9指的是 99.99%，五个9就是 99.999%）。这些一般都是说系统的SLA(Service Level Agreement) 具体是几个「9」，以此，来表示该系统一年中具体宕机的时间。

Service Level Agreement，服务等级协议。SLA 是服务商和用户之间的协定，规定了服务的性能和可用性。根据这种可量化的协定，双方可以更详细地制定细则，比如没有到达一定的可用性时的赔偿方案。

SLA 并不是一个固定的数值，“四个九”“五个九”只是代表系统可以保持稳定的时间。SLA 会因为成功数与请求数的不同而变化，可能是 95%，也可能是 80%，这需要我们去计算。

如果你要计算某个接口的 SLA 情况，就可以指定一段时间区间，然后依据以下的公式来计算：

总计成功数 / 总计请求数 = 百分比(%)

那总计成功数是怎么得来的呢？比如 HTTP 请求，状态码 200 就可以算是成功，此时成功数就可以 +1；dubbo 不出现异常时成功数就可以 +1。当然，这也不是一定的，根据公司内部的 HTTP 响应状态码等内容也可以更细粒度地规定，如果将相应结果中 json 的 code 值 1 定为成功，则满足条件是成功数也可以 +1。

如果我们需要保证这个服务 1 年的 SLA 是“五个九”。那么 1 年就是时间单位，由此我们可以算出服务不可用的时间：

1 年 = 365 天 = 8760 小时 

三个九 = 8760 * (1 - 99.9%) = 8.76 小时 

四个九 = 8760 * (1 - 99.99%) = 0.876 小时 = 0.876 * 60 = 52.6 分钟 

五个九 = 8760 * (1 - 99.999%) = 0.0876 小时 = 0.0876 * 60 = 5.26 分钟

1 年内，该服务不可用的时间为 5.26 分钟。

由此可见，想要保证越多的“九”，就要保证服务稳定，缩短服务错误的时间，因此，它对系统稳定有重要的意义，“九”也成了公认的标准。

1. 可用性

系统可用性是通过将系统建模为串联和并联的组件来计算的。以下规则用于确定系统是串联的还是并联的：

• 如果组件的失效导致组合变得不可操作，则认为这两个部件是串联操作的
• 如果组件的故障导致另一部件接管故障部件的操作，则认为这两部件并行操作。

1.1. 串行的可用性

如上图所示，两个组件 X 和 Y，如果有一个出问题导致整个组合都不可用，就认为 X 和 Y 这两个组件是串联的。只有组件 X 和组件 Y 同时可用时，整个组合才可用。由此可见，组合的可用性是这两部分的乘积，公式如下：

从上面的等式我们看出，串联系统中，整体组合的可用性，总是低于单个组件的可用性。

对于上面 X 和 Y 两个串联组件，可用性如下：

从上面的表中，我们看到，即使使用了非常高可用性的组件Y，但组合系统仍然受组件 X 的影响，会降低好多，和「木桶原理」一致，都受最短板的影响。

1.2. 并行的可用性

如上图所示，如果两个组件都失败时，整个系统会失败的话，这两个组件会被认为是并行的。任一组件可用时，整个系统都是可用的。整体可用性是 1- （两个组件都不可用），公式如下：

从上面我们能看出，两个组件并行的系统，整体可用性要任一单独的组件可用性高。如上图假设是组件X的两个部分，可用性如下：

我们看到，即使一个可用性低的组件X，组合后的系统可用性也很高。

2. 可用性计算

2.1. 了解系统

第一步，我们先准备一个系统的详细框图。该系统由输入传感器组成，该传感器接收信号并将其转换为适合信号处理器的数据流。输出会送到两个冗余的信号处理器。源信号处理器用于输入，备用信号处理器忽略来自输入换能器的数据。备用处理器监控主信号处理器的健康状态。两个信号处理器的输出被组合并发送到输出转换器。再次，有源信号处理器驱动数据线。待机使数据线保持不变。输出传感器将信号输出到外部。

2.2. 系统可靠性

第二步是准备系统的可靠性模型。在这个阶段，我们决定系统的并行和串行连接。我们的示例系统的完整可靠性模型如下：

这里要注意的几个要点是：

• 信号处理器的硬件和软件已经被建模为两个不同的实体。软件和硬件是串联的，因为如果硬件或软件不工作，信号处理器就不能工作。
• 两个信号处理器（软件+硬件）结合在一起，形成信号处理复合体。在信号处理复合体中，两个信号处理复合体被并行放置，因为当信号处理器之一失效时，系统可以工作。
• 输入传感器、信号处理复合体和输出传感器被串联放置，因为三个部件中的任何一个的失效都将导致系统的完全失效。

2.3. 计算单个组件的可用性

第三步包括计算单个组件的可用性。MTBF（Mean time between failure 故障之间的平均时间）和MTTR（Mean time to repair 修复的平均时间）值针对每个组件进行估计。对于硬件组件，MTBF信息可以从硬件制造商的数据表中获得。如果硬件是在内部开发的，则硬件组将为板提供MTBF信息。对硬件的MTTR估计基于操作员对系统的监视程度。这里我们估计大约2小时的硬件MTTR。

• MTBF（Mean Time Between Failure）是平均故障间隔的意思，代表两次故障的间隔时间，也就是系统正常运转的平均时间。这个时间越长，系统稳定性越高。
• MTTR（Mean Time To Repair）表示故障的平均恢复时间，也可以理解为平均故障时间。这个值越小，故障对于用户的影响越小。

一旦已知MTBF和MTTR，就可以使用以下公式来计算组件的可用性：

评估软件的MTBF 这个活儿还是比较费劲的。软件MTBF实际上是软件重新启动的时间。中间的间隔可以用系统的缺陷率来估计。在这里，我们估计MTBF大约是4000小时。MTTR是重新启动失败处理器的时间。我们的处理器支持自动重启，所以我们估计软件MTTR大约5分钟。请注意，5分钟似乎是在更高的一面。但MTTR应包括以下内容：

• 由于信号处理器软件崩溃而中止的活动中浪费的时间
• 检测信号处理器故障的时间
• 失败的处理器重新启动并返回服务时所花费的时间

从上面表格我们看到：

• 即使硬件MTBF更高，软件的可用性也更高。主要原因是软件的MTTR要低得多。换句话说，软件确实经常失败，但是恢复很快，因此对系统可用性的影响较小。
• 输入和输出传感器具有相当高的可用性，因此即使在没有冗余组件的情况下也能够实现相当高的可用性。

2.4. 计算系统可用性

最后一步是计算整个系统的可用性。这些计算是基于串行和并行可用性计算公式。

4. 影响SLA的因素

• 服务自身因Bug挂掉或无法正常工作；
• 服务因机器物理故障导致无法正常工作，比如磁盘坏块、内存颗粒坏了、主板故障等；
• 服务器物理机因机房断网、断电、空调损坏无法降温等原因导致机房故障；
• 地震、洪水、台风等灾害导致机房损坏；
• 服务依赖的组件故障导致无法正常工作；
• 被黑客攻击导致无法正常工作；
• 并发量超过系统承载能力，导致系统崩溃、数据错乱。

以上各种原因都可能影响 SLA，只是概率不同而已。有的概率很低，对总的 SLA 影响较小。不过，有一个基本原则：下层系统的 SLA 在设计上通常需要高于上层系统的 SLA，只有下层系统的 SLA 足够高，上层系统的 SLA 才更容易得到保障。

5. 参考资料

《分布式链路追踪实战 》

https://mp.weixin.qq.com/s/kEOgeIwInDRir8oixHhirA