在开始您的 SRE 之旅时,解读所有首字母缩略词似乎令人生畏。什么是 SLO 与 SLA? SLI 和 SLO 有什么区别?在这篇博文中,我们将介绍 SLI、SLO 和 SLA 的含义以及它们如何为您的可靠性目标做出贡献。

SLI、SLO、SLA有什么区别?

以下是每个术语的定义以及简要说明。定义根据Google SRE 手册。

SLI:“对所提供的服务水平的某些方面进行仔细定义的定量测量。”

SLI 是一种定量测量,通常通过您的 APM 平台提供。传统上,这些指的是延迟或可用性,它们被定义为响应时间,包括队列/等待时间,以毫秒为单位。 SLI 的集合或复合 SLI 是一组归属于更大 SLO 的 SLI。这些指标是数字用户旅程中的点,有助于提升客户体验和满意度。

当开发人员设置 SLI 来衡量他们的服务时,他们分两个阶段进行:

1. 将直接影响客户的 SLI。

2. 直接影响某些服务的健康和可用性或延迟和性能的 SLI。设置 SLI 后,您将进入您的 SLO,这是针对您的 SLI 的目标。

SLO:“由 SLI 衡量的服务水平的目标值或值范围。因此,SLO 的自然结构是 SLI ≤ 目标,或下限 ≤ SLI ≤ 上限。”

服务水平目标成为公司使用的通用语言,允许团队设置护栏和激励措施,以推动高水平的服务可靠性。

今天,许多公司都以一种不断反应的模式运作。他们对 NPS 分数、流失或事件做出反应。这是对时间和资源的昂贵且不可持续的使用,更不用说对客户满意度和业务造成潜在的不可挽回的损害了。 SLO 为您提供了客观语言和衡量标准,说明如何优先考虑可靠性工作以实现主动服务健康。

![替代文本](https://dev-to-uploads.s3.amazonaws.com/i/cougd0kks1q1rz2g5q89.png

SLA:“与您的用户签订的明确或隐含的合同,其中包括满足(或错过)他们所包含的 SLO 的后果。”

服务级别协议是由业务而不是工程师、SRE 或操作人员设定的。当 SLO 发生任何事情时,SLA 就会启动;它们是您的 SLO 失败时采取的行动,通常会导致财务或合同后果。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--7JESXS5W--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/i/s2lxminb6cumq3d4tagi.png)

这些术语如何帮助提高可靠性:一个案例研究

想象一下,一个组织正在寻求提高可靠性。该公司最近开始调查代价高昂的 SLA 违规行为,并想知道为什么它的可靠性受到影响。该组织几乎每个月都会违反其可用性 SLA。随着它通过 SLA 吸引更多客户,如果不满足其性能保证,这些费用可能会增加。

这个虚构的组织也在处理低 NPS 分数。团队意识到了这个问题,但 NPS 分数对于已经开始流失的客户来说是一个滞后指标。团队开会讨论需要做什么。第一步是分解公司的 SLI。

识别对用户重要的 SLI

团队知道它需要检查可用性并为其设置 SLO,因此它开始查看用户旅程。 QA 团队已经完成了一些文档,因此团队参考了那里概述的用户旅程,并用他们自己的旅程来扩充此文档。

该团队确定了最受投诉的关键点。团队成员还研究黑盒监控,这是一种有助于从用户角度识别问题的策略。通过黑盒监控,团队充当服务的外部用户,无法访问内部监控工具。这使团队成员可以专注于与用户幸福感直接相关的几个指标。

在查看了用户的旅程后,团队确定费用功能上每个选项卡的单独加载页面不会单独加载缓慢,但是当有人需要浏览 2 个或更多页面时,它变得乏味。因此,团队还决定为负载均衡器的响应时间创建一个 SLO。

建立相应的SLO

在团队确定其 SLI 之后,就该设置 SLO。团队正在查看网站的可用性(常见的抱怨),以及费用页面上的延迟问题。虽然团队计划稍后添加更多 SLO,但这两个将充当豚鼠。

对于延迟问题,团队为所有页面设置了一个 SLO,以在 1 秒内加载。这种更快的加载时间意味着用户不会因为滚动多个页面而感到恼火。然后,团队转到可用性 SLO。

根据流量水平、客户使用情况、NPS 分数,该团队确定其客户可能对 99.5% 的可用性感到满意。另一方面,前几个月的数据表明,当正常运行时间大于 99.9% 时,客户满意度和使用率似乎并没有增加。这意味着此时没有理由针对高于 99.5% 的正常运行时间指标进行优化。

有了 SLO,团队将需要通过创建错误预算策略来解决如果未达到这些目标该怎么办。该政策将详细说明:

• 给定时间段内系统可接受的故障级别(错误预算)

• 错误预算耗尽时服务升级策略的警报和待命程序

• 在超出错误预算的一定时间后停止功能开发并专注于可靠性的协议。

一旦每个人都同意,SLO 就会启动。团队仔细观察并在每月的错误预算会议上重申。几个月后,团队有足够的信心添加更多的 SLO。

就 SLA 达成一致

SLA 是一个外部指标,因此与 SLO 的目标不同。 SLA 是与用户达成的业务协议,规定了一定程度的可用性。工程团队知道 SLA,但没有设置它们。相反,团队设置 SLO 比 SLA 更严格,给自己一个缓冲。

例如,团队 99.5% 的可用性 SLO 意味着该服务每月只能停机 3.65 小时。但是,组织与用户签署的 SLA 规定它必须保持 99% 的可用性。这意味着该服务每月可以减少 7.31 小时。团队每月有 3.66 小时的缓冲时间。现在,团队可以使用护栏来开发新功能以提高可靠性。组织将受益于更快乐的用户,团队有信心在保持可靠的同时进行创新。

当一起使用时,SLI、SLO 和 SLA 是强大的工具,可让您为用户提供最好的服务。虽然正确获取这些指标可能很棘手,但修订、迭代和无责的文化将帮助您实现可靠性目标。

如果您喜欢这篇文章,请查看以下资源:

• 网络研讨会:实施服务水平目标

• 什么是服务水平目标?经验教训

• SLI 如何帮助您了解用户的需求