前言

可用性是公有云对外服务的基础，​表示系统正常运行的时间​，因此下文所有可靠性相关的概念都与时间相关（注意与可靠性不一样，可靠性表示系统输出正确的结果）。没有可用性就没法对外正常服务，因为你可用性都保障不了，那客户怎么用，客户必然会放弃产品，因此可用性是那个绝对的1，其他都是补充补强的0。这里简单介绍下可用性建设的的一些概念和思想。

什么是可用性？

下面是百科上的解释。

1，The degree to which a system, subsystem or equipment is in a specified operable and committable state at the start of a mission,
when the mission is called for at an unknown, i.e. a random, time.
2，The probability that an item will operate satisfactorily at a given point in time when used under stated conditions in an ideal support environment.

简言之，在理想的环境和规定的条件下，系统，子系统或设备在执行的时间点能正常运行的概率，比如20%，50%，90%。那问题来了，什么是高可用性（High availability）？

百科有对高可用性（High availability）也有正式的定义；

High availability (HA) is a characteristic of a system that aims to ensure an agreed level of operational performance, usually uptime, for a higher than normal period.

总之，​高可用性是系统一个特征，目的在于确保系统在正常时间段内，达到能高于商定的运行性能水平​。没有说多大的可用性才是高可用性，这个就是客户和云厂商共同商定的SLA了。​不过顾名思义，高可用性就是很高的可用性啦，由于故障不可避免，越接近100%可用性越高，一般3个9以上才可以叫做高可用，也就是99.9%以上​。像Google Cloud对外承认的最低SLA（Service Level Agreement）为99.95%，一般公有云公司也差不多如此，更高的可用性需要更高的成本，这就需要考虑软件开发的价值回归的问题了，需不需用这么高的成本去实现这么高的可用性？当然这就是另一个话题了。

为啥要重视可用性？

Everything in the tech industry is driven with a very hardcore eye for profit and very little interest in anything else？

科技行业的一切，核心都是利润，而不是其他任何事情。很有道理，难道不是吗？技术价值性本文还是喜欢从客户角度上考虑问题，下图思路出自一个竞品云公司的技术大佬。

因果流程
1，客户使用公有云产品。
2，公有云产品低可用性。
3，客户无法用我们的公有云产品创造价值。
4，公有云产品没有达到商定的SLA，产品方需要补偿客户。
5，公有云产品总是影响客户创造价值，客户拒绝再使用我们的产品。
6，直接或者间接​影响产品赚钱​。

可用性咋计算的？

上文说明了可用性的相关概念，也同时说明了可用性主要和时间相关，业内的主要计算方式是通过两个工业指标MTTR和MTBF。

​MTTR​(Mean Time To Repair/Recovery) ： 平均修复时间，系统出错到修复花费的时间，也可以理解为​平均下线时间​（average downtime）。
​MTBF​(Mean Time Between Failures) ：平均失效间隔时间，隔多久时间发生一次故障，也可以理解为​平均在线时间​（average uptime）。

MTTR和MTBF概述图如下所示：

MTTR

指标计算公式如下。

MTTR=总的修复时间/总的维护次数，等于平均的修复时间，也就是这个时间段内不可用（downtime）在维护中。因此也可以用下面的公式表示MTTR：

MTBF

指标计算公式如下。

MTBF=总的正常运行时间/总的故障次数，等于平均失效间隔时间，也就是这段时间间隔内服务是稳定在线（uptime）运行的。因此也可以用下面的公式表示MTBF：

Availability

MTTR impacts availability, MTBF measures availability and reliability。通过上述对MTTR和MTBF的描述，可以知道​MTTR影响可用性，MTBF保障可用性和可靠性​。可用性Availability公式推导思路图如下。

​Availability=MTBF/(MTBF+MTTR)​；通过上图的推导是不是很清晰了。那我们要增加可用性，主要是往以下两个方向走。
1，​增加MTBF​，也就是增加平均上线时间（average uptime），增加两次事故的间隔，业内的主要方法有冗余和保护两种思路。
2，​减少MTTR​，也就是减少平均下线时间（average downtime），减少事故的影响时间，范围，次数，通过上文的MTTR定义图也可以提供如下方法。
2.1）​监控和告警要及时和准确​，这样才能快速定位发现问题，定位问题。快速感知减少故障通知时间和诊断时间。
2.2）​SRE自动化平台要强​，甚至有条件的话可以接入AIOps，都没有的话至少要有一个运维手册，这些能大大减少修复时间。
2.3）故障修复完成后要能快速上线测试和验证流程，测试完成后也要能快速恢复到可用状态，比如有​一个灰度发布流程​。

SLA

SLA（Service Level Agreement）服务质量协议。

A service-level agreement (SLA) is an agreement between a service provider and a customer.
Particular aspects of the service – quality, availability, responsibilities – are agreed between the service provider and the service user

简言之，SLA是服务提供方和使用方达成的服务对质量，可用性，责任的一种协议。而可用性是可以在给定时间内计算出来的，比如年，季度，月，周，日。通过上述的计算公式，百科给出了如下99线可用性表格。​一般云厂商会给出99.95%3个9的保证，一年的不可用时间为4.38h​。

提高可用性的因素

lim Availability->1

上文可知，可用性只能尽可能接近100%的99线，也就是9的个数越多可用性越高，比如金融，医疗，航空等行业9的个数就越高。那问题来了为什么只能是接近100%，而不是等于100%呢。​黑天鹅事件表明那些不可预测的不寻常事件可能会导致系统出现极大的问题，且墨菲定理表明Anything that can go wrong will go wrong。如果一件错误可能出现，那么在未来的某个时候一定会出现。黑天鹅事件和墨菲定理两者结合，故障不可避免​。那又有那些常见的故障？

故障不可能避免，下面按事故率排名。
1，运维：人为误操作，线上操作频繁，无监控或者错误监控等。
2，硬件：硬盘，网卡，电源，交换机等。
3，编码：开发编码问题在特定的业务场景下奔溃。比如OOM，服务依赖过大等。
4，性能：fullGC，陡增流量，CPU过高，IO过高，内存不够。
5，网络：网络是不可靠的。网络波动拥堵等。
6，安全：黑客攻击，DDOS，SQL注入，XSS攻击等。
7：管理：人员分工不明确，发布流程混乱等。

措施

通过上文的铺垫我们大概能了解可用性的定义，可用性的价值，以及可用性计算方式和影响因素，还有故障的来源，那我们现在来了解下业内如何提高可用性。关于提高可用性的方法，也没有权威的统一规划的数学论文，资料千篇一律老生常谈了，大家都懂。不过严谨上来说上文已说明如果要提高可用性，主要从增加MTBF，减少MTTR两个大方向入手。大体的核心策略是冗余、保护，监控。本文通过整理资料主要从软件开发的生命周期来说明不同软件开发节点提高可用性的方法。下图是软件开发生命周期节点与提高可用性因素关系。

一些说明
1，从软件开发的生命周期看，大体分为产品设计，技术设计，代码开发，测试，线上运维五个点，在每一个软件开发的节点都要对提高可用性有一定的考虑。
2，在提高可用性的方法上，通过对上文中故障的常见联系，重点关注几个方法是：产品设计中的容量预估，服务分级，错误预算。技术设计中的可熔断、可降级、可限流、隔离、负载均衡、无状态设计、高可用架构、有状态服务的数据备份和故障转移。代码开发中的模块解耦。线上运维的监控告警、SRE平台的自动化管理、灰度发布。

重点提高可用性项

产品设计中的可用性提高

容量预估：具体问题具体分析，确定系统需要抗多大的量多少的并发非常重要，影响到后续的开发基本以及部署和运维的成本，也影响到后续服务在运行中的稳定性。

​服务分级​：提高可用性是需要成本的，不需要将所有的服务都做到3个9以上的可用性，比如内部的管理平台系统。而有些服务的可用性则要求很高，比如核心的主业务流程服务，以及底层的数据存储服务，因此需要梳理出一个系统中各个服务的级别，方便在可用性上针对性的开发和运维。
​错误预算​：《SRE Google运维解密》说明版本迭代是导致可用性的最大因素，但是产品又要保证不断的功能发布，所以想要有一个错误预算。在​1-(错误预算+可能的故障比率)=SLA（99.9...%）的框架下既能保证商定的SLA可用性，也能保证服务的功能快速迭代​。产品开发和运维不冲突。

技术设计的可用性提高

​可熔断、可降级、可限流​：可熔断保证上有服务调用者的可用性，可限流保证下游服务提供者的可用性，不被服务调用者的亲戚数打垮。可降级则保证服务的最低限度的服务能力，而不至于可用性直接归0。
​隔离​：隔离是物理上的，是在代码解耦逻辑隔离的基础上的，尽可能减少服务的爆炸范围，避免一个服务导致全盘奔溃。比如有进程隔离，机房隔离，读写隔离，线程池隔离，环境隔离，租户隔离等等。
负载均衡：冗余策略的直接方法，避免单点故障。
无状态设计：服务应该是尽量无状态的，只有主要才方便做到可弹性和动态的负载均衡，运维也可以到处部署。
高可用架构：有状态的服务要看是否满足CAP和BASE思想，基础知识可以看下本栏写的这篇《分布式一致性学习》。
有状态服务的数据备份和故障转移：及满足高可用架构下要做到数据的备份和故障转移。

代码开发的可用性提高

​模块解耦​：解耦是逻辑上的隔离，做到​高内聚、低耦合​，避免牵一发而动全身。按软件开发原则，有无依赖或弱依赖，无循环依赖原则等，开闭原则，接口隔离原则，单一职责原则等。

线上运维的可用性提高

​监控告警​：​没有人想维护一个没有监控的系统，除非你想蒙着眼睛狂奔​。在减少MTTR的关键因素中就要准确监控和及时告警。
​SRE平台的自动化管理​：《​SRE Google运维解密》说人是不完美的机器​，自动化运维操作是减少故障的最好方法。
​灰度发布​：翻译《SRE Google运维解密》的孙宇聪大佬说过，​影响服务MTBF的三大因素：发布，发布，还是发布​。灰度发布是上线的最后一道安全防护机制。

总结

1，上述的文档已经给了提高可用性的一个模型，通过按这个模型来套当前服务在公有云的可用性有多少。
2，可用性是公有云对外服务的基础，​表示系统正常运行的时间​。
3，MTTR影响可用性，MTBF保障可用性和可靠性；Availability=MTBF/(MTBF+MTTR)；提高可用性，主要从增加MTBF，减少MTTR两个大方向入手。
4，提高可用性不是一个框架，直接引入就可以接近问题，也不是一个人，一个组能包办的，它是一套完整的体系方法，想要上下游所有人都参与才行，不仅仅包括产品，测试，开发和运维，想要按照增加MTBF和减少MTTR的思路去不断优化和改进才行。
5，监控和告警是可用性的基础，没有可监控和告警的系统就像一批蒙着眼睛的奔腾野马。
6，人是不完美的机器，要尽量完善SRE管理平台，实现​更高的自动化​。比如说灰度发布平台。在工程团队里面有进攻和防守两种角色，进攻角色负责开发新产品和增加功能，防守角色负责维护产品。​一味地进攻只会遍体鳞伤，我们应该多多考虑防守​。
7，《SRE Google运维解密》说虽然生育孩子的过程是艰苦和困难的，但是养育孩子成人的过程才是真正需要花费大量时间和精力的地方。​开发人员应该投入更多的工作在SRE的工作上​，没有比开发更懂自己的业务模块，在SRE上做更多的自动化功能是能大大减少人为操作失误的可能性。大大提高可用性。
8，影响MTBF的主要因素是版本迭代，如果一个流量稳定的服务，不去操作他是基本上不可能出问题的，大部分问题出在版本发布上，但是产品必须要保证快速功能迭代，因此在考虑可用性的时候，​要有一个错误预算​。
9，墨菲定理：Anything that can go wrong will go wrong。​海因里希《工业事故预防：科学方法》三角1：29：300定律。So，可能的问题即使很小，我们也要尽快解决​。