该知识点也会分成三个篇章来介绍：高可用性的度量、高可用系统设计思路、高可用系统运维。

高可用（High availability,HA）是你在系统设计时候常用到的一个词，它指的是系统具备无故障运行的能力。

我们在很多开源组件文档中看到的HA方案就是提升组件的高可用，让系统免于宕机无法服务的方案。

比如，你知道 Hadoop 1.0 中的 NameNode 是单点的，一旦法身故障整个集群就是不可用的；而在 Hadoop2 中提出的 NameNode HA 方案就是同时启动两个 NameNode，一个处于 Active 状态，另一个处于 Standby 状态，两者共享存储，一旦 Active NameNode 发生故障，则可以将 standby node 节点切换为 Active 状态继续提供服务，这样就提升了Hadoop的持续无故障运行能力，也就提升了它的高可用。

通常来讲，一个高并发大流量的系统，系统出现故障比系统性能低更损伤用户体验。一个日活过百万的系统，一分钟的故障可能影响到上千用户。而且随着系统日活的增加，一分钟故障可能影响的用户数也会增加，系统对可用性的要求也会更高。所以今天就如何提高系统的高可用性 提供一些思路 。

可用性的度量

可用性是一个抽象的概念，你需要知道如何来度量它，与之相关的概念是：MTBF 和 MTTR。

MTBF（Mean Time Between Failure）平均故障间隔的意思，代表两次故障的间隔时间，也就是系统正常运转的平均时间。这个时间越长代表系统稳定性越高。

MTTR（Mean Time To Repair）故障的平均修复时间，也可以理解为平均故障时间，这个值越小，对用户影响越小。

可用性与 MTBF 和 MTTR 的值息息相关，我们可以用下面的公式表示它们之间的关系：

Availability = MTBF / (MTBF + MTTR)

这个公式的结果是一个比例，而这个比例代表系统的可用性。一般来说我们会用几个九，来衡量系统的可用性。

通过这张图可以看到，一个九 两个九的可用性很容易达到的，只要么有蓝翔技校的叉车搞破坏，基本可以通过人肉运维的方式实现。

三个九之后，系统的故障时间锐减到 8个小时，四个九之后年故障时间锐减到52分钟。在这个级别的可用下，你可能需要建立完善的运维体系、故障处理流程、业务变更流程。你可能还需要在系统设计上有更多考虑。比如，在开发中你要考虑，如果发生故障，是否可以不需要人工介入就能自动恢复。当然了，在工具建设方面你也要多加考虑，以便出现故障能快速定位原因，让系统迅速恢复。

到达五个九之后，故障就不能靠人力恢复了。想象一下，从故障发生到你接收报警再到你打开电脑，早就十分钟过去了。这个级别的可用性是考验的你的系统容灾和自动恢复能力了，让机器来处理故障才会让你的可用性提升一个档次。

一般来说，我们核心业务系统的可用性要达到四个九，非核心业务系统最多容忍到三个九，在实际工作中，你可能听到过类似的说法，只是不同级别不同业务系统对系统的可用性要求不同。

目前，你已经对系统的可用性评估指标有了一定程度的了解，接下来的一章节我们就看下高可用的系统设计需要考虑哪些因素。