指导思想：服务质量目标

前言

本文是 《SRE：Google 运维解密》一书中第 4 章的读书笔记。

强烈推荐阅读《SRE：Google 运维解密》

服务质量目标

书中的「服务质量」一词在原作中对应的是「Service Level」。一般情况下我们可以将其简单理解为「系统的性能」。

服务质量目标即 Service Level Objectives ，缩写为 SLO 。

包括 SLO 在内，书中一共定义了三个术语：

• SLI ：服务质量指标（Indicator）
• SLO ：服务质量目标（Objective）
• SLA ：服务质量协议（Agreement）

1、指标

SLI 指的是服务的某项服务质量的一个具体量化指标。

尽管每个系统提供的服务各不相同，但通常都会有一些通用的 SLI ，例如请求延迟（处理请求所消耗的时间）、吞吐量（每秒请求数量）、可用性（服务可用时间的百分比）和错误率（请求处理失败的百分比）等。

在实际的实践过程中，第一步应该根据用户对系统的真实需求，把真正有用的、具有代表性的指标定义为 SLI 。

SLI 的指标定义过多会影响对真正重要的指标的关注，过少会导致重要的系统行为被忽略

第二步，则是利用监控系统将所需要的指标数据采集起来。

最后一步，为了简化和使数据更可用，经常需要对指标进行汇总统计。

一般来说，在统计方面我们应该倾向于分析一组数据的百分比分布，而不是其算术平均值。对于大部分指标而言，应该以分布，而不是平均值来定义。

拿一组数据举例，针对某个服务的请求延迟 SLI ，有些请求可能很快（10ms），但有些却非常的慢（10s），如果简单分析其平均请求延迟，就可能会掩盖长尾延迟和其中的变化。

这就好比我和马云的平均财富高于全世界 99% 的人，但是胡润富豪榜上却没有我

而如果利用百分比分布情况来分析，就可以很快发现一些问题所在。

某系统的 50%、85%、95%、99% 的请求延迟，注意这里的 Y 轴是指数级分布的

只要将某一时刻所有的请求延迟按从小到大排列，假设有 100 个请求，50% 即中位数值，也就是排位为 50 的值，如果其对应的响应时间为 50ms ，则说明当前时刻有半数的请求可以在 50ms 完成。最后将所有时刻的变化联合起来就可以得到这幅图。

当然中位数值是不够精确的，所以会继续使用 85% 、95%、99% 甚至 99.9% 来进行分析。

越高百分位（例如 99% 和 99.9%），就越能体现指标的最差情况，而 50% 则一般用来体现普遍情况。

继续分析该图，可以看出竟然还有 100%-95%=5% 的请求的响应时间是大于 1s 的，这和中位数值的 50ms 相差了 20 倍！这个数据意味着系统还有很大的优化空间。

图中的响应时间的分布非常分散，特别是最上面的那条线，这意味着用户受到长尾请求延迟的影响很明显，说明我们的系统可能由于负载过高已经出现了请求排队的问题。

基于这些分析，我们就可以快速发现出问题并针对其优化了。

另外，对于一些常见的 SLI ，我们应该为其标准化，构建一套可以重用的 SLI 模板，避免每次都要重新评估。

之后，任何一个符合标准定义模板的服务就可以不需要再次自己定义 SLI 了，例如：

• 汇总间隔：每 1 分钟汇总一次
• 汇总范围：集群中的全部任务
• 度量频率：每 10 秒一次
• 包含哪些请求：从黑盒监控任务发来的 HTTP GET 请求
• 数据如何获取：通过监控系统获取服务器端信息得到
• 数据访问延迟：从收到请求到最后一个字节被发出

2、目标

SLO 指的是服务的某个 SLI 的目标值或目标范围。可以定义为 SLI ≤ 目标值，或 范围下限 ≤ SLI ≤ 范围上限 。例如，定义一个 SLO ，要求 99% 的请求会在 10ms 内完成 。

有目标才有执行的动力

在实际的实践过程中，应该从用户真正所关心的方面入手，可以先想出想要的目标，然后再反向推导出目标对应的具体的指标。

另外，要求 SLO 能够被 100% 满足是不正确的，也是不现实的，过于强调这个只会降低创新和部署的速度，甚至额外增加一些成本过高、过于保守的方案。

对于这个问题，可以使用错误预算（Error Budget）方案，其实就是指对达不到 SLO 的容忍度，可以以天或周等单位计量对 SLO 达标程度进行监控，这样就可以在重大问题发生之前得到预警。

因此错误预算本质上也是一个 SLO ，是用来保证达到其它 SLO 的 SLO 。其对应的 SLI 可以是：达不到 SLO 的现象的发生频率。

对于目标的选择方面，就不是一个纯粹的技术问题了，还需涉及到产品和业务层面的决策。SLI 和 SLO 的选择都应该直接反映该决策。

从可行性和风险性方面来考虑目标的选择的话，书中给了我们一些建议：

• 不要仅以目前的状态为基础选择目标
• 保持简单
• 避免绝对值
• SLO 越少越好
• 不要追求完美

一个好的 SLO 除了对开发团队来说是有效的、可行的激励机制；在控制手段上，对决策系统运维时也非常有用，我们可以知道是否（或者何时）需要执行某种操作（服务器扩容等）了；并且还可以通过公布 SLO 来建立用户对服务质量的预期，用来应对那些没有根据的抱怨——“服务太慢了”。

3、协议

SLI 是构成 SLO 的基础，而 SLO 又构成了 SLA 的基础。

SLA 指的是服务与用户之间的一个明确的，或者不明确的协议，描述了在达到或没达到 SLO 之后的后果。这些后果可以是财务方面（退款或罚款），也可以是其它类型的。

例如腾讯云制定的 CVM 实例的 SLA 的赔偿方案：

起草这样的一份 SLA 需要业务部门和法务部门选择合适的后果条款。SRE 在这个过程中的主要作用是帮助这些部门理解 SLA 的 SLO 达标的概率和困难程度。

当然，最好在对用户宣传方面保持保守，别画大饼。

总结

不管是对外服务，还是内部 API ，我们都需要制定一个针对用户的服务质量目标，并且努力去达到这个质量目标。在这个过程中，我们就需要利用一些主观判断并结合过去经验以及对服务的理解来定义一些 SLI 、SLO 、SLA 。