一文读懂什么是SLI、SLO、SLA

SLA简介

SLA 的由来

在云计算时代，越来越多企业的服务迁移到云上，各大云服务厂商有自己服务发布的SLA，SLA是服务提供商与客户之间定义的正式承诺。

我们使用云服务提供商为我们提供的 APP 或者网站，如果出现购物无法下单、看视频打不开类似的问题，会严重影响用户体验。如果故障持续的时间比较久，那将会流失一大批用户，给业务带来损失。

那么，如何衡量给客户提供的服务质量呢？进而如何衡量系统的稳定性呢？毋庸置疑，需要统一的语言 SLA。

SLA 的定义

服务等级协议（英语：service-level agreement，缩写SLA），是服务提供商与客户之间定义的正式承诺。SLA的概念，对互联网公司来说就是服务可用性的一个保证。

SLA包括两个要素，一个是 SLI，一个是 SLO。

• SLI（服务测量指标，service-level index）：SLI 是经过仔细定义的测量指标，它根据不同系统特点确定要测量什么，SLI的确定是一个非常复杂的过程。SLI确定测量的具体指标，在确定具体指标的时候，需要做到该指标能否准确描述服务质量以及该指标是否可靠。
• SLO (服务等级目标，service-level objective)：指定了服务所提供功能的一种期望状态，包含所有能够描述服务应该提供什么样功能的信息。一般描述为：每分钟平均qps > 100k/s；99% 访问延迟 < 500ms；99% 每分钟带宽 > 200MB/s。

SLA 的维度

SLA 以面向人员的维度区分，可以划分为以下 2 个维度。

• 业务维度：客户对这部分的指标最有体感，直接与用户的体验好坏挂钩。

  • 例如，响应时间，错误率等。有统计数据显示，如果响应时间大于1s，80%的用户就会流失掉；错误率指标，是对功能正确性的保障，如果开始有业务错误，那么客户都无法直接完成期望的操作，流失也是避免不了的。这部分的指标直接影响用户的体验。

• 服务侧维度：描述的是服务端的指标，这部分指标主要是面向开发以及测试人员的，为了在发生问题的时候，可以快速定位问题。

  • 比如，ECS/RDS等的系统指标，包括 CPU/LOAD等。

压测中的 SLA

在进行性能压测设计阶段，有一个重要的环节是确定“性能压测通过标准”。缺少了这个标准，意味着压测可能是没完没了的。谁都不知道什么时候该结束，结果是影响性能压测效果，浪费人力财力。所以需要通过“性能压测通过标准”中一系列量化下来的指标来确定，压测结果是否符合预期，可以停止了。这个"标准"的来源，可能是来自业务方的期望、研发组对系统的性能期望等等，最终整理汇总下来的我们称为压测中的 SLA。这个 SLA与产品对外的 SLA 有紧密联系，但是又存在区别。联系就是，系统对外的 SLA 是压测中的 SLA 的重要来源，而区别就是，压测中的 SLA 可能会涵盖更多更细的指标，而对外的 SLA 并不关心这么多细节。

在压测中，看似一个简单的业务请求，实则后端是复杂的系统架构，比如统一接入层/容器层/存储层，即使容器层，也涉及到了很多不同应用/不同服务，面对纷繁复杂的架构，如何快速判断压测结果是否满足了业务需求？如何快速判断是否达到了系统的水位不能再往上施压了呢？

没有 SLA 的压测

一声号令，开始压测！

好了，A开发看A系统，B开发看B系统，C开发看网络层，D测试看压测结果等。

大家手忙脚乱，这个时候，有人在群里一声喊，我的系统扛不住了，停止吧（当然还有一种风险，是不是这位同学的误判呢）。

好的，这个时候压测停止。

当然这种还是比较好的情况，而有些压测场景，就只有一个测试同学，他怎么分工呢？

一会看看压测结果，一会看看A系统，一会看看B系统，忙得不亦乐乎。

这样压测能否达到效果，当然能。但是这样的状态是最好的一种状态吗？当然不是

有 SLA 的压测

• 开发/测试/业务同学在压测之前，对齐SLA指标，即意味着明确系统需要持续提供的服务能力，以及系统的整体水位，减少后续的沟通流程，大家都以此目标备容。
• 配置好SLA之后，压测的负责人则只需要重点关注是否存在 SLA 告警，如果连续告警则说明系统已经扛不住了，直接停止压测。对于压测的小伙伴来说，省时省力，既不会漏掉一些指标，同时也不会浪费压测时间。

SLI

Service Level Indicator 服务水平指示器，服务水平，简称SLI。对于业务来说是最重要的指标。比如，对于网站来说，一个常见的SLI是请求得到正常响应的百分比。SLI是经过仔细定义的测量指标，它根据不同系统特点确定要测量什么，SLI的确定是一个非常复杂的过程。

SLI的确定需要回答以下几个问题：

• 要测量的指标是什么？

• 测量时的系统状态？

• 如何汇总处理测量的指标？

• 测量指标能否准确描述服务质量？

• 测量指标的可靠度(trustworthy)？

1. 常见的测量指标有以下几个方面：

• 性能

  • 响应时间(latency)

  • 吞吐量(throughput)

  • 请求量(qps)

  • 实效性(freshness)

• 可用性

  • 运行时间(uptime)

  • 故障时间/频率

  • 可靠性

• 质量

  • 准确性(accuracy)

  • 正确性(correctness)

  • 完整性(completeness)

  • 覆盖率(coverage)

  • 相关性(relevance)

• 内部指标

  • 队列长度(queue length)

  • 内存占用(RAM usage)

• 因素人

  • 响应时间(time to response)

  • 修复时间(time to fix)

2. 测量时的系统状态，在什么情况下测量会严重影响测量的结果

• 测量异常(badly-formed)请求，还是失败(fail)请求还是超时请求(timeout)

• 测量时的系统负载（是否最大负载）

• 测量的发起位置，服务器端还是客户端

• 测量的时间窗口（仅工作日、还是一周7天、是否包括计划内的维护时间段）

3. 如何汇总处理测量的指标？

• 计算的时间区间是什么：是一个滚动时间窗口，还是简单的按照月份计算
• 使用平均值还是百分位值，比如：某服务X的ticket处理响应时间SLI的
• 测量指标：统计所有成功解决请求，从用户创建ticket到问题被解决的时间
• 怎么测量：用ticket自带的时间戳，统计所有用户创建的ticket
• 什么情况下的测量：只包括工作时间，不包含法定假日
• 用于SLI的数据指标：以一周为滑动窗口，95%分位的解决时间

4. 测量指标能否准确描述服务质量？

• 性能：时效性、是否有偏差
• 准确性：精度、覆盖率、数据稳定性
• 完整性：数据丢失、无效数据、异常(outlier)数据

5. 测量指标的可靠度

• 是否服务提供者和客户都认可
• 是否可被独立验证，比如三方机构
• 客户端还是服务器端测量，取样间隔
• 错误请求是如何计算的

---

SLO

Service Level Object 服务水平目标，是围绕SLI构建的目标。通常是一个百分比，并与一个时间范围挂钩。比如，月度、季度、年度等。通常用一连串9来度量。如果脱离了时间的度量，SLO的意义就不大了。

• 90%（1个9的正常运行时间）：这意味着10%的停机时间，也就是说在过去的30天里停机了3天。
• 99%（2个9的正常运行时间）：意味着在过去30天中有1%，或者说7.2小时的停机时间。
• 99.9%（3个9的正常运行时间）：意味着0.1%，或者说43.2分钟的停机时间。
• 99.95%（3.5个9的正常运行时间）：意味着0.05%，或者说21.6分钟的停机时间。
• 99.99%（4个9的正常运行时间）：意味着0.01%，或者说4.32分钟的停机时间。
• 99.999%（5个9的正常运行时间）：意味着0.001%，或者说26秒的停机时间。

实例

假如我有一个网站http://raypick_example.com，我对这个网站的监控指标是请求正常响应数，从2023年1月1号上线到今天2023年3月18号，请求数据如下：

1月，总请求数500，错误响应20；
2月，总请求数600，错误响应10；并因为故障宕机10分钟；
3月1号-3月18号，总请求数400，错误响应15；
那么我计算出来的SLI、SLO，SLA是多少呢？

SLI：1 -（20+10+15）/ (500+600+400) = 97%
SLO：1 - ( 10 / 79天 * 24 * 60 ）= 99.991%
SLO：假如我们是给第三方做的网站，并签订了协议SLO达不到99.999%，就赔偿多少钱，那么根据我上面的这个SLO，再根据签订的SLA协议，算出补偿的金额。