第二十三篇：稳定性之服务SLA

通常我们谈到稳定性，必然能够想到SLA，谈到SLA离不开SLO、SLI这两个，SLI是衡量系统稳定性的指标，SLO是服务等级目标，也是我们设置的稳定性目标，例如3个9、4个9等，那么SLA更多是其实对付费的客户的承诺，多数情况下我们聊的是SLO服务等级目标，通过衡量SLO来判断系统的稳定性。

SLA与可用性

通过上节了解SLA，如何选择合适的SLI指标，也就知道SLO对应的SLI要实现的目标，那么如果通过SLO计算系统的可用性，这涉及到整体系统的可用性两种计算方式，第一种是从故障角度出发，以时长维度对系统进行稳定性评估；第二种是从成功请求占比角度出发，以请求维度对系统进行稳定性评估。通常会选择第二种，也就是根据成功请求的比例来衡量稳定性：

Availability = Successful request / Total request

通常情况下不是看单次请求的成功与否，而是看整体情况，所以我们会把成功请求的占比设定为一个可以接受的目标，也就是我们常说的3个9或4个9这样的可量化的数字。

那么，这个“确定成功请求条件，设定达成占比目标”的过程，其实就是设定稳定性衡量标准的 SLI 和 SLO 的过程。

成功定义计算

成功率计算，通过计算成功次数占比总次数的比例，如一个请求的返回状态码必须非5XX才算成功，也可以，但是在某些情况下并不能满足需求，可以要求延迟不低于80MS，当然还可增加其它条件，作为综合判定，公式表示如下：

• Successful = （状态码非 5XX） & （时延 <= 80MS）

但是这种计算方式存在问题是，对于单次请求的成功与否判定太过严格，很容易出现误判，例如延迟，我们一般会设置取决，如 90% 延时小于等于200MS，用这种计算方式很难体现处理，而且对于状态码的成功率和延时成功率容忍度，通常也不太一样，这种方式不太准确，所以采用第二种方式，下面一起了解下，

SLO方式计算

每个服务的SLO服务等级目标可能均不同，故计算方式也需要更灵活，可随意调整定义，如下列一组SLO服务等级目标：

• 服务A的SLO：99%、计算状态成功率
• 服务B的SLO：90% Latency <= 80ms
• 服务C的SLO：99% Latency <= 200ms

该公式表示：

• Availability = 服务A的SLO & 服务B的SLO & 服务C的SLO

只有当三者均满足时，整个系统的稳定性才算达标，如果一个不满足，则该可用性则不满足，每个服务自身的场景和业务也均不相同，可以将SLO灵活的设置合理性与可用性结合起来。

对于第一种计算方式通常会被利用在第三方提供的服务承诺中，对于这部分用户来说，客户群体非常大，很难面向每一家制定不同的SLO这么细粒度的稳定性目标，每家客户对稳定性需求也不同，无法统一，在这种情况下，第一种计算方式就相对简单。

信任手段

SLO也可用于团队服务之间相互沟通机制，通过SLO对双方达成一种承诺，对于错综复杂的服务中，每个服务的SLA对系统的可用性变得尤其重要，如果依赖的服务未能达到SLA要求，那么其自身的SLA也能难保证，因此SLO的意义在于服务间通信的一种信任，依据该SLA并相信它，才能够有信心设置自身服务的期望值和SLO，SLO也可用划分边界，使各个团队明确职责和责任。例如：服务A依赖服务B，服务B的SLO是响应时长不超100MS，那么服务A依据服务B提供SLO对服务A进行架构设计，满足业务需求并对外声明自身的SLO，一旦服务B的SLO未满足的情况下，势必会影响服务A的SLO。

服务诊断

不论是对外提供产品或者服务声明SLA，本身是下层所有服务提供SLO计算而成，无论系统还是服务其本身都依赖不同服务（数据库、缓存、消息队列）来实现，系统的整个稳定性都依赖底层所有服务的SLO，那么保证每个服务的SLO其本身就是在做稳定性建设；SLO还可用于服务诊断，如果某个服务出现故障或者性能问题，那么首先要排查的是依赖的服务是否SLO是否满足，如果未满足，这首先就是我们要着手的地方，看是否是该SLO未满足的原因等等，如：Mysql慢查询、CPU飙升、延迟、响应耗时等等。

小结

对于稳定性，首先要做的是保证各个服务满足自身的SLA、SLO；SLO通常情况下可以用于团队内部之间沟通信任的手段，也可通过SLO进行故障排查，一旦发现未满足SLO，首先考虑从这里定位和排查，对于每个团队而言要做的就是尽力保证自身对外的承诺即SLO，同时对下游依赖做好兜底容错降级机制，一旦下游未满足SLO，尽可能避免自身的影响，或减少伤害和损失。