测量和管理高可用
我们了解到阻碍高可用的原因，就想如何解决。但先别急，我们先看看怎么测量高可用。
高可用只是一个状态，但我们需要一些可衡量的数据，可以直观看到我们的优化是否有效。要理解可用性发生的变化，必须首先测量出当前的可用性是多少。通过跟踪系统可用及不可用的时间，计算出可用性百分比，可以帮助我们了解一段时间内的可用性程度。通过这个值，我们可以判断出可用性是在提高还是降低。
其实不止是高可用优化，所有的优化都需要做对比才显示出直观效果。比如产品方面有AB测试，产品故意让用户分成AB两部分，使用不同的功能或者交互，然后统计行为数据看哪个结果更佳；还有药物上市之前需要盲测，即病人志愿者被随机分配到实验组和对照组，分别给药和安慰剂，实验期满后，若能观测到实验组的治愈率显著高于对照组那说明药物有效。
定义故障
要计算可用性，首先要定义应用程序怎么为之故障。我以一个企业微信获取accesstoken接口为例
1、响应不可理解
这种响应是无法理解，它是一种以无法理解的形式存在的“垃圾”数据。这可能代表响应的格式错误，或者格式中存在语法错误。
如上面的例子，如果返回的是非json格式，那就认为都是不可解析不可理解的情况。
2、致命错误的响应
这种响应是可以理解的。它表示在处理请求时发生了严重的错误。这通常可能不是因为网络传输的原因，而是服务本身出现了错误。它还可能是由于发送给服务的请求无法被理解而引起的。
如上面的例子，如果http范围非200，或者输入的参数含有一些恶意的非法而导致服务无法理解返回错误，都算致命错误响应。
3、结果跟不匹配
这种响应是可以理解的。它表示操作执行成功，没有严重错误，但是返回的数据无法与预期的结果相匹配。
如上面的例子，我们预期返回code为0，并且有accesstoken，但如果返回其他错误码，即表示不可用。
4、结果超过预期范围
这种响应是可以理解的。它表示操作执行成功，没有严重错误。返回的数据是合理的，并且格式正确，但是数据本身不在预期之内。
如上面的例子，如果返回的expire_in过期值不是一个数字或者不是大于0，则不在预期范围内。
5、没接收到响应
就是api超时。请求已经发出，但是没有接收到服务发回的响应。这可能是由于网络通信故障、服务出现问题，或者服务故障导致的。
6、接收响应很慢
请求已经发出，并且响应也接收到了。响应的内容正确，也在预期范围之内。但是，响应比预期到达时间晚很长时间才接收到。这通常表明服务或者网络压力过大，或者存在其他资源分配不合理的问题。
监控
根据上面对故障的定义，我们就不能对一个应用是否可用，单纯用进程在不在、ip端口通不通来判断，是需要根据具体业务功能挑选关键路径的api，用上述6个维度监控api可用性以保证业务功能可用。
而且，我们应当不断地监控可用性百分比，并定期收集结果。此外，你需要覆盖系统中所有的关键事件点，例如，更改系统配置或者升级的时候，这样可以了解到系统事件和可用性问题之间的关系，也能够帮你确定系统的可用性风险。
分级
接下来，我们必须从可用性的角度出发来理解系统应当如何运行，服务分级是一个可以帮助我们管理系统可用性的工具。服务分级指的是为各个服务打上一些简单的标签，表示该服务对于系统的关键程度。这使得我们能够区分出哪些是至关重要的服务，哪些是很重要但非必需的服务。
一般可以参考分为4级。
1级，系统中最关键的服务。如果某个服务出现故障会导致导致平台大面积系统不可用，影响全量用户。如ESB、服务发现等。
2级，2级服务对于业务非常重要，但是在关键性上不如1级服务。如果2级服务发生故障，会导致用户体验显著受到影响，但是不会让他们完全无法使用系统。如具体某个较多用户的系统。
3级，服务会对用户造成较小的、不容易注意到的，或者很难发现的影响，或者对业务和系统造成有限的影响。如头像服务、搜索服务等。
4级，服务即使失败，也不会对用户体验造成任何严重的影响。如各类系统的后台管理平台，运维平台、报表类平台等。
当为所有服务分配服务级别之后，如何在服务运维时使用它们呢？下面是几种常见的方式。
期望
服务期望的运行时间是什么？它的可靠性如何？它存在多少问题？它允许多长时间出现一次故障？这个「期望」具体来说就是服务等级协议（SLA）。
响应性
应当以多快的速度来响应问题？可以通过哪些途径来解决问题？
依赖
依赖你的服务，以及你所依赖的服务，它们的服务级别分别是多少？它们对你的服务有什么样的影响？
服务等级SLA
服务等级协议（SLA）是一个提供某种级别可靠性和性能的承诺，用来在服务所有者和用户之间创建一个牢固的合约关系。
SLA通常时对外部用户的协议，但其实每个基础服务都应该有SLA，虽然基础服务通常是不会直接为用户提供服务，但基础服务会被多个应用依赖着，所以基础服务的SLA决定着用户应用的SLA是多少。
性能检测
有许多可用来检测服务性能的方法，但具体使用哪种方法，要根据服务的用户和所有人的需求来决定。以下是一些常见的性能检测方法。
调用延迟
这种方法用来测量服务需要多长时间来处理一个请求并返回响应。测量结果通常以微秒或者毫秒计算。服务的消费者必须知道一个请求的处理时间，因为这部分时间会计算在处理请求的总时间内。
流量
这种方法用来测量服务在一段时间内能够处理多少请求。通常按照每秒有多少请求数量来测量，服务的所有者必须知道来自消费方服务的流量，才能知道自己的服务是否能够满足对方的期望。
运行时长
这种方法用来测量服务正常、无故障运行的时间。通常以百分比计算，它可以测量服务在一段时间内（通常以天、月或者年计）的可用性。
错误率
它用来测量服务在一段时间内出现过多少次失败。通常以百分比计算，通过一段时间内失败的请求数除以请求总数得出结果。
数据展现
根据上面所属的检测方法，数据的展现以下几种方式：
限定SLA
通常指期望满足的一个限定值。如果实际的性能好于限定值，则说明满足了SLA。如果实际的性能差于限定值，说明没有满足SLA。限定值本身就是SLA的值。例如，“调用速率必须小于1000请求/秒”表示对服务预期流量的一个限定SLA。如果预期的流量小于指定的限制，则该服务已满足其SLA。
排名SLA
排名SLA适合测量调用延迟等值。通常，服务处理每个请求的时间差异可能会较大，大多数情况下我们并不关心每个请求的处理时间，只要绝大多数请求可以在限定时间内处理就好。常见的TP90、TP80定义就是实际应用例子。
SLA的条件
SLA有时可能以另一种度量方式作为条件来表示。例如，某个服务可以保证一定的延迟，但是必须是在合理时间的前提下。因此，一个SLA可能有如下表示：当流量<250,000请求/秒时，调用延迟TP90<25毫秒。
应当
应当保证尽可能少的SLA数量；
应当确保SLA覆盖了服务的所有关键部分，为所有的主要功能都定义合适的SLA，尤其是在对业务至关重要的地方；
应当只定义那些实际中可以实现监控和报警的SLA；
应当建立一个包含所有SLA和监控的仪表盘界面。
风险管理
高可用是一个终极理想状态，其实并没有结束的概念。识别可用风险的过程都是无穷无尽，随着系统的发展、成本资源的背景变化、技术人员本身的知识面变化、技术的发展变化，可用风险点可能都在变化，只要你去挖就肯定有所发现。
面对这些无限的风险，而技术团队的资源是有限的，所以我们需要主动管理。
风险管理包括确定系统中，风险的位置，确定哪些风险必须消除、哪些风险可以暂时存在，以及如何降低这些留存风险发生的可能性和严重性。
风险管理的概念里面，重点就是可能性和严重性，我们就根据风险的可能性和严重性，定义风险优先级和处理方式。
严重性：如果发生风险，所需付出的代价。
可能性：风险发生的概率。
管理风险就是管理这两者，我们可以降低风险的严重性或者可能性。对于所有已知的风险，不需要双管齐下，但是同时考虑这两者对提高管理风险的能力非常重要。风险的重要程度就是风险发生的严重性与可能性两者之和。如果要成功地管理风险，我们必须同时考虑两者以及它们之间的关系。为了降低风险，你需要至少降低其中之一，或者严重性，或者可能性。
风险评估完可能性和严重性的话，除了少部分特别紧急的风险可以提上日程需要方案解决，对于其他未能马上解决的风险，我们需要先做一些恢复计划、缓和计划。
恢复计划，指的是当风险真正发生时你需要采取的措施。如果已知的风险真的发生了，我们必须处理它的后果。我们可以通过一个恢复计划建立一系列操作，处理和修复风险所造成的影响和问题。
缓和计划，指的是你现在或者即将准备为降低风险严重性或者可能性所采取的措施。缓和计划并不是要消除风险，它只是降低风险的严重性和可能性。
参考：
1、《可伸缩架构（第2版）：云环境下的高可用与风险管理》https://book.douban.com/subject/35178755/