我们知道，如今的网购、娱乐、物联网等，给我们生活带了诸多便利，这其中很大一部分原因是互联网提供的服务是高可用的，能够随时随地满足你诉求，那么究竟什么是高可用？

什么是高可用？

试想下，你中午需要做饭，想在某平台购买食材，发现该平台不能下单，无法满足你的诉求。我们能说该平台是高可用的吗，显然不能。高可用是面对故障时，服务能够自愈或能够尽最大努力提供有损服务。

那是什么原因导致系统出现故障的呢？其实，可能只是一个小的、随意的原因引起系统的故障，比如：

• 库存不足；
• 新增第三方支付，引起的故障；
• 服务变更，版本兼容引起的故障；
• 触发某安全策略意外拦截，导致无法下单；
• https证书过期导致；
• 优惠券服务导致下单服务出现故障；
• 库存校验失败，引起故障；
• 某依赖云厂商出现硬件故障导致；
• 光纤被挖了；
• ……

对于能够引起系统故障的因素我们称之为影响高可用因素，这块我在下文会讲。

高可用从架构设计角度，可以理解是面向风险设计，也就是指面对风险时，能够提供高可用性的能力，从可靠性角度，可以理解是通过设计减少系统不能提供服务的时间。们在进行系统架构设计时，要考虑拓展性、安全性等等，其中，高可用也是必须要考虑的因素。

如何度量系统可用性？

上面的例子，我们能够大体地认识并了解高可用，所有的系统，必然是一步步地提升系统可用性的，不能一蹴而成，因此我们也要能够知道如何去度量高可用，管理学大师彼得.德鲁克曾说过：“如果你不能度量它，你就无法改进它 ”。

对于高可用的度量，一般从“可用性”和“可靠性”两个维度来描述：

• 可用性：在单位时间内，系统可提供服务的持续时间；
• 可靠性：根据系统平均失效时间来衡量。平均失效时间越短可靠性越高。

首先我们来看可用性。一般我们会用几个9来描述可用性（几个9也通常用来标识服务的SLA，即服务等级协议）。

可用性的计算公式： 可用性=系统无故障运行时间/(系统无故障运行时间+系统故障维护时间)

举个例子：某图书管理平台计划投入运行10天，计划运行时间为每天早8点至晚6点（每天运行10小时），第2天上午9点发生一次故障，故障恢复用了1小时；第5天下午又发生一次故障，故障恢复用了4个小时；第9天上午发生一次故障，故障恢复用了1小时，那么图书管理平台的可用性是多少呢？

• 系统故障恢复时间：一共用了1+4+1=6个小时
• 系统无故障运行时间：7*10+9+6+9=94个小时
• 图书管理平台的可用性：94/(94+6)=94%

通过上述案例能够看到，图书管理平台系统的可用性是94%，才一个9，对于很多平台，系统的可用性要求在三个9以上，要求更为严格的是4个9以上或者5个9。

以年为单位，倒推下，不同要求下对于故障的可容忍时间：

• 1个9：(1-90%)*365=36.5天

• 2个9：(1-99%)*365=3.65天

• 3个9：(1-99.9%)*365*24=8.76小时

• 4个9：(1-99.99%)*365*24=0.876小时=52.6分钟

• 5个9：(1-99.999%)*365*24*60=5.26分钟

所以，当你的系统可用性不满足三个9的时候，你就要注意了，考虑系统的可用性是不是要提高，换句话说一年内有三天多的时间系统是不可用的，无法正常提供服务，带来的损失也是不可估量的，因此，很多平台对系统的可用性要求在三个以上。

说完了可用性，我们再来说一下可靠性。在业界，一般谈到可靠性，必然离不开MTTR平均修复时间、MTBF平均无故障时间、MTTF平均失效时间这三个指标，在前面也讲到过平均失效时间越短可靠性越高。

• MTTR平均修复时间，它的计算方式是：MTTR=维护时间总和/维护次数之和，比如计算图书管理平台的MTTR：6/3=2个小时。MTTR反应出对线上响应和问题修复的效率，MTTR的数值越小，对故障的修复效率越高。
• MTBF平均无故障时间，它的计算方式是：MTBF=总运行时间/总失败次数，比如计算图书管理平台的MTBF：94/3≈31个小时。MTBF反应出系统的可用性，系统的可用性越高，平均无故障时间越长。
• MTTF平均失效时间，它的计算方式是：MTTF= 服务副本数的总运行时间/副本数，我们还是来计算图书管理平台的MTTF：图书管理平台是单机部署，所以只有一个副本，故MTTF：94/1=94个小时。MTTF反应出系统的故障间隔周期，该数值越低，说明系统故障的频率越频繁。

知道了什么是可用性和可靠性，那对于一个稳定性系统来说，哪一点更重要呢？

其实，系统的首要目标是先降低故障的次数，频率要低，从而提高可靠性；同时在故障出现后，要提高故障的恢复时间，速度要快，从而提高业务的可用性。

我们举个例子来说明二者的区别。如果系统在每小时崩溃1ms，那么它的可用性就超过99.9999%，但是它还是高度不可靠，因为它只能无故障运行1小时。与之类似，如果一个系统从来不崩溃，但是每年要停机两星期，那么它是可靠的，但是可用性只有96%。

还有个问题：为什么大家经常讲提升系统可用性（稳定性），而不经常提到可靠性呢？我认为可用性包含可靠性，理由是假设系统不可靠，那么面临的问题可能是业务Bug或者导致系统出错等情况，这些是不允许的，如果存在这些漏洞是无法上线的，所以大家经常讲可用性。

业界也有很多典型的案例，可以从中了解到对于有足够影响力的平台，一旦出现故障导致不可用，那也将影响着我们的生活，供我们参考和学习：

• 2020年国庆前一天，受“2020年最难打车日”的需求影响，滴滴平台和嘀嗒平台相继出现宕机故障；

• 2018年亚马逊prime day：亚马逊会员日故障（顾客无法将商品添加到购物车结账），导致公司损失高达9900万美元。

• 2015年由于中国工商银行部分地区因计算机系统升级，造成柜面和电子渠道业务办理缓慢，甚至不能受理业务

• 2012年12306铁路订票网站因机房空调系统故障，导致暂停互联网售票、退票、改签业务。

构建高可用系统，面临哪些难题？

不过，打造高可用系统，这个话题还是相对来说比较虚。高可用构建不是一个点，而是所有点组合的一个结果。不像技术案例具体可实现，高可用更抽象，需要有足够的技术视野，需要能够观测并提前做好布局。即便如此，在构建稳定性时，还是会遇到很多难题。

• 难题一：业务变化之快

对于一个业务来说，不同阶段业务目标是不同的，对系统的要求也是如此：业务初期的要求迭代效率，业务中期的要求是业务起量，业务长期的要求是高可用（稳定性）。需要注意的是，面对业务的快速发展及不确定性，想要提升系统稳定性，需要贴合业务的节奏，对于影响稳定性高严重性、高可能性的风险进行风险管控处理。

例如：我们针对某个核心关键流程进行优化、容错、解耦设计，这个改动可能涉及系统层面从上到下的多处修改，包括数据结构调整、业务逻辑改造、数据交互方式等等，可能上线一段时间，因业务变化，该业务废弃，那么前期所做的一切都是无用功。

面对业务的快速，我们对服务的优化和改造，一定要有远瞻性，可以提前做好稳定性建设布局：

• 基础设施建设，比如：日志、监控、告警、分布式配置中心；
• 通用性业务组件建设，比如：分布式锁、限流、熔断器；
• 洞察业务趋势，做好技术储备。

• 难题二：构建范围之广

稳定性建设需要从全局视角总览，建设范围广，工作量大，其中包括研发、测试、运维、DBA等多个角色，流程规范，变更管理，涉及架构设计、数据库、缓存、消息队列等。

例如：我们可能针对某个核心关键流程进行优化、容错、解耦设计，这个改动可能涉及系统层面从上到下的多处修改，包括数据结构调整、业务逻辑改造、数据交互方式等，涉及诸多方面，很可能有遗漏或bug，导致严重的事故，需要有逐一确认某个细节及强有力的测试才可以。

在构建范围上，可以考虑从以下几个维度入手：

• 业务上，要面向异常情况考虑，比如：页面加载失败、要友好提示；
• 技术方案上，要面向失败设计，比如：数据一致性、强依赖失败；
• 核心关键流程上，要标准化，比如：上线审批流程、技术方案评审必须由架构师确认；
• 工具上，要尽可能自动化、避免人为操作，比如：部署系统。

• 难题三：实施成本之高

稳定性建设是需要投入一定的成本，带来的收益也是隐形的，不像业务目标那么明显。一般情况下，业务上不会给技术做稳定性建设的，除非是业务已取得一定的收益，业务模型已形成闭环，此刻业务为了走的更远，打稳地基，允许投入一定的成本做稳定性建设。

不过技术债，还是要尽早还，因为坐在前期的成本要小很多。比如，服务依赖不合理，前期调整比后期调整的成本就要小的多。

影响稳定性因素有哪些？

在前面我们举了个买菜的例子，能够看到影响稳定性的因素有很多，比如网络通信、证书协议出了问题，或者配置信息有误等，为了便于我们理解和记忆，我这里对影响稳定性的因素进行抽象的总结，分为：人为因素、自然因素两大类。

以下为我简单总结的思维脑图，供参考：

系统的一砖一瓦都是我们自己搭建起来的，对于系统的稳定性，人为因素占比还是比较大的，相信大家都是深入感触，下面拿几个因素简要说明下：

• 研发流程方面

很多公司的稳定性都是通过流程规范来保障的，人总是不可靠的，当然不是说人不靠谱，原因是人为的操作过程中，可能出现丢三落四的情况，故尽可能把所有流程都流程化、标准化、自动化，减少人为的过多的干预。

例如：变更管理流程，涉及很多环节开发、测试、预发、灰度、小流程、全量，DB结构变更等等，很多公司都有相应的系统，而这个系统实际上是将变更管理所有要做的点做了自动化，避免了人直接操作，通过系统来避免出错，从而保障稳定性。

题外话：在很多公司，对于线上数据出现不一致的情况，那么该如何修复数据，怎么操作呢？

第一种做法：通过数据库客户端直接修改。

第二种做法：先将修复的数据备份，通过SQL语句直接修改。

第三种做法：通过shell或者python脚本，编写sql，通过执行脚本修复。

对于这种三种方法，你觉得那种比较合适呢？

• 代码方面

代码问题和研发人员水平有很大关系，例如对某段逻辑处理错误、参数校验合法性、异常逻辑处理、是否死循环、第三方依赖库是否正确使用等等。

关于代码问题，可以通过第三方工具进行代码检测，提前发现一些问题。工具可以帮助检测的内容如下：不遵循代码标准、潜在的缺陷、糟糕的复杂度分布、重复、注释不足或者过多、缺乏单元测试、糟糕的设计等，避免这些问题带到生成环境。

例如：非法数据输入，像入参的校验，我们是否做到参数非空、长度、数值类型、范围等多个维度的校验。

• 配置方面

很多研发工程师对配置参数了解的很少，大多数沿用默认的，像数据库连接池、消息队列重试次数、超时时间，中间件（Kafka、Redis）配置参数，对参数配置是否合理完全不感知。

当然我不是反对用默认的参数配置，而是说你要提前了解每个参数配置决定什么，对应起到什么作用，面对不同的业务场景配置合理的参数。

例如：超时参数配置，对于用TO-C服务、TO-B服务（业务后台）可能某些接口超时参数是不一样的，可能对TO-C比较短，业务最快响应，对TO-B可能面对某些大数据库查询，超时时间也是不一样的，需要根据业务场景及接口区分开合理配置。

再例如：重试次数配置，重试次数1和3的区别很大，因为是每个请求连接可能可能会流量放大1倍或3倍，试想下，重试参数配置很简单，带来的效果是完全不一样的，针对不同的场景对重试次数合理配置，或不配置用户侧重试，其实是对服务的一种保护机制。

小结

今天我们的学习，能够让你知道什么是高可用，理解度量可用性的方法；学完这篇文章，你还可以尝试着评估你负责的业务系统可用性。同时我们也分析了构建高可用系统面临的现实问题，以及分析现实场景中存在着影响高可用的因素。