微信公众号：运维开发故事，作者：夏老师
想知道什么是服务等级目标 (SLO)？在本文中，我们将解释服务级别目标以及它们与 SLA、SLI 和错误预算的关系。
什么是服务等级目标？
服务等级目标 (SLO) 是可靠性目标，由服务等级指标 (SLI) 衡量，有时用作服务等级协议 (SLA) 的保障。SLO 代表客户的幸福感并指导开发团队的速度。
SLO 量化客户对可靠性的期望，并在目标面临风险时开始产品和工程之间关于可靠性目标和行动计划的对话。服务的示例 SLO 是 28 天滚动窗口中 95% 的可用性。
可能会想将目标设置为 100%，但这太好了，令人难以置信。变化带来不稳定，必然导致失败。100% 可靠性不仅是一个不可能实现的目标，而且还意味着无法对生产中的服务进行任何更改。因此，期望完美的可靠性与选择阻止任何新功能接触客户并选择停止市场竞争是一样的。
**设置 SLO 的经验法则是找到客户对服务的可靠性感到满意的点。 **
无休止地提高可靠性目标并不是一个很好的商业决策。我们的目标不是完美，而是让客户满意并获得恰到好处的可靠性。一旦客户对服务感到满意，额外的可靠性几乎没有任何价值。
为什么？因为如果客户对可靠性感到满意，他们会想要新功能而不是更高的可靠性！
如果客户对可靠性感到满意，他们会想要新功能而不是更高的可靠性！
SLO 的目的是什么？
**SLO 的目的是衡量客户满意度，（如果适用）保护公司免受 SLA 违规的影响，并在产品、工程和业务领导之间建立对可靠性的共同理解。 **
客户想要的只是可靠性和创新之间的正确平衡。他们想要功能，并希望能够随时使用这些功能。企业必须创新并发布新功能以推动收入和增长，同时保持可靠性以留住客户。设置 SLO 可以帮助团队讨论并就如何使用数据驱动的方法平衡可靠性和功能速度达成一致。
当服务等级目标由能够在功能速度和可靠性之间进行权衡的人拥有时，服务等级目标最为有效。在小型组织中，CTO 通常担任这一角色，而在大型组织中，理想情况下，该职责应由产品所有者或产品经理承担。
SLA、SLI 和 SLO 之间有什么区别？
这三个术语之间的区别很简单。SLI 是用于定义和衡量 SLO 的指标。SLA 并不适用于每个业务，但是当有 SLA 时，它作为 SLO 的上限。
SLI（服务等级指标）
SLI 用于衡量服务的可靠性。它是根据服务的监控数据构建的可量化指标。选择正确指标的关键是找出客户对服务的期望。此外，不应选择过多的指标，因为这会使注意力从最具指示性的一两个指标上移开。
传统上，SLI 是根据延迟或可用性计算的。但是也有其他的指标。Google SRE 的四个黄金指标：延迟、使用率、错误率和饱和度；USE 方法：利用率、饱和度和错误；RED 方法：**速率、错误和请求延迟。**根据系统不同，也有不同的SLI。
我们将专注于五个指标的收集：
- Rate - 请求率，以请求/秒为单位。例如，在HTTP REST API中, 请求率通常是每秒HTTP请求数；
- Errors - 监控当前系统所有发生的错误请求，衡量当前系统错误发生的速率。
错误率有多少？这里除了 5xx 之外，我们还可以把 4xx 列进来，因为前面我们的服务可用性不错，但是从业务和体验角度，4xx 太多，用户也是不能接受的。有时候还有隐式的失败。比如http 200恢复中包含了错误内容，或者策略导致的失败。比如我们要求超过一秒的请求就返回失败，这样超过一秒的请求都是失败请求。当协议内部的错误码不能表达全部的失败情况时，可以利用其它信息，如内部协议，来跟踪一部分特定故障情况。
-
延迟— 服务请求所需时间。记录用户所有请求所需的时间，重点是要区分成功请求的延迟时间和失败请求的延迟时间。 例如在数据库或者其他关键祸端服务异常触发HTTP 500的情况下，用户也可能会很快得到请求失败的响应内容，如果不加区分计算这些请求的延迟，可能导致计算结果与实际结果产生巨大的差异。除此以外，在微服务中通常提倡“快速失败”，开发人员需要特别注意这些延迟较大的错误，因为这些缓慢的错误会明显影响系统的性能，因此追踪这些错误的延迟也是非常重要的。
-
饱和度——例如CPU的平均运行排队长度，这里主要是针对资源的饱和度。任何资源在某种程度上的饱和都可能导致系统性能的下降。
-
使用率-关注系统资源的使用情况。 这里的资源主要包括但不限于：CPU，内存，网络，磁盘等等。100%的使用率通常是系统性能瓶颈的标志。
但是对于不同类型的系统，SLI 指标是不同的。
- **在面向用户的系统中，SLI 通常强调错误率、延迟和饱和度来计算的。 **
- 数据处理系统或队列等通常强调吞吐量或延迟和请求率。
- 存储系统强调延迟、请求率和使用率。
SLA（服务等级协议）
SLA 是服务提供商与客户之间的法律协议。它包括服务的最低可靠性目标以及不满足该目标的财务后果。后果可能包括部分退款、折扣或额外积分。SLO 是您团队的内部目标，通常不是客户合同的一部分。
SLO 和 SLA 经常被混淆，但它们是两个不同的概念。由于 SLO 是内部目标，因此在违反时不会受到相关的经济处罚。当有 SLA 时，那么对应的 SLO 一般更严格。例如，如果 SLA 定义了 99.5% 的正常运行时间，那么内部目标可以是 99.8%。通过设定更严格的内部目标，SRE 团队有机会采取主动行动，以避免超越 SLA 和违反合同协议。
SLA 与 SLO 不同，由业务开发和法律团队设定。这可能是一个挑战，因为法律和业务开发团队都没有直接参与构建或运行技术。因此，让 IT 和 DevOps 团队一起参与可以增加创建功能性 SLA 的可能性。
如何定义服务的SLO？
为服务定义 SLO 是一个漫长的过程，具体方法因公司而异。我们将在下面讨论两种方法。
以产品为中心的方法
我们将讨论定义服务级别目标的分步方法。关于步骤的顺序没有硬性规定。一些公司首先定义用户旅程并相应地制定 SLO，而其他公司则从指标开始，然后假设用户旅程以改进和完善现有的 SLO。
- 与产品团队一起定义用户旅程
- 确定用户旅程中的关键服务并选择最佳 SLI 类型
- 定义 SLI
- 定义 SLO
- 创建错误预算策略
- 监控和报告 SLO
- 定期重新评估 SLO 并根据需要进行更改
以工程为中心的方法
定义 SLO 的第二种以工程为中心的方法是：
- 定义 SLI
- 定义 SLO
- 基于SLO的监控和报告
许多公司通常从第二种方法开始，并在更广泛采用时遇到困难。错误预算策略至关重要，因为它们使 SLO 具有可操作性。我们还建议团队回到产品并概述关键的用户旅程。
错误预算策略至关重要，因为它们使 SLO 具有可操作性。
谁定义了 SLO？
定义 SLO 是一个由 SRE 团队驱动的协作过程，但它需要来自整个组织的多个利益相关者的投入。
所涉及的主要利益相关者是：
- **产品负责人，从产品经理到业务分析师。产品负责人尝试预测客户需求并将其传达给开发和 SRE 团队。理想情况下，它们有助于定义 SLO 以反映客户需求。 **
- SRE 和运营团队由 DevOps ITSM 和问题管理以及为开发团队奠定基础的基础设施工程师组成。它们有助于确保 SLO 是现实的、可持续的，并且不会导致过度劳累。
- 开发团队由开发软件产品的软件团队组成。如果可靠性工作减慢了发布速度，他们可以谈论 SLO 并协商放松。
- **内部和外部用户以及利益相关者都属于客户的保护伞。他们通过反馈会议、客户投诉、推文和 SLA 为 SLO 定义做出贡献。 **
确定 SLO 后，作者、审阅者（检查技术准确性）和批准者（根据业务考虑进行权衡）将对其进行记录。
为了使服务等级目标适用于组织的各个部分，理想情况下，每个团队都同意 SLO 是用户体验的合理近似值，并将其用作决策的主要驱动力。不满足 SLO 通常会产生有据可查的后果，这些后果将工程工作转向提高可靠性。为了执行后果，运营团队需要执行支持。
归根结底，SLO 会调整激励措施，但仅靠它们是不够的。在一个高度孤立的组织中，达成一致要困难得多。成功的最佳机会是开发人员和 SRE/Ops 团队之间有共同的责任感。开发人员认为他们有责任使服务可靠，SRE/Ops 团队认为有责任帮助开发人员积极发布新功能。
深思熟虑的 SLO 有哪些特征？
良好的服务等级目标必须与公司的特定业务需求保持一致。例如，如果所有客户都在同一个时区，并且朝九晚五工作，那么活动时间之外的可用性对客户来说并不重要。由于客户不会尝试访问该服务，因此如果服务在他们不活跃的时间中断，他们也不会不高兴。
其次，根据谷歌关于有意义的可靠性的论文：
“一个好的服务可用性指标应该是有意义的、成比例的和可操作的。”
- 有意义意味着它捕捉用户体验。
- 成比例意味着指标的任何变化都必须与用户感知可用性的变化成比例。
- 可操作意味着它可以让系统所有者深入了解为什么在特定时间段内可用性较低。
- 现实的意味着可靠的 SLO 必须是现实的。目标不应与迄今为止服务的执行情况相差太远，最好在考虑团队资源限制的情况下做出决定。不要以不切实际的目标为目标，这样会挫败团队。
创建 SLO 有哪些挑战和陷阱？
创建服务级别目标可能非常具有挑战性，尤其是在开始时。
每个人都想要 100% 的可靠性，这是不现实的。这意味着服务的错误预算为零（对失败没有容忍度），这本身就是一个缺点。
常见的陷阱是在早期阶段以过多的 SLO 开始。鉴于大多数系统的复杂性，从小处着手并随着时间的推移进行迭代是最好的做法。你不想让系统变得比它需要的更复杂。只需要测量最关键的服务，理想情况下只有两到六个 SLI。
没有用通俗易懂的语言说明 SLO 是另一个常见的陷阱。由于它主要是内部目标，因此它们通常是为了帮助开发和 SRE/Ops 团队平衡功能开发与可靠性工作。理想情况下，它们应该足够简单，开发和 SRE/Ops 团队中的任何人都可以理解它。
最后，创建 SLO 是一个协作过程，需要所有人（包括领导层、开发团队、SRE/Ops 团队、产品所有者等）的投入和支持。为了使 SLO 发挥作用，所有相关团队和个人都同意这是合理的并可作为决策依据。此外，如果没有管理层的支持，无法执行不满足 SLO 的后果。
SLO 如何与错误预算相关？
服务等级目标用于计算错误预算 - 一种用于平衡创新与可靠性的工具。错误预算定义了服务在不影响客户满意度的情况下可以承受的可接受的不可靠性等级。
只要服务保持在错误预算范围内，开发人员就可以承担更多风险。另一方面，当错误预算开始枯竭时，开发人员可能需要做出更安全的选择。
以下是使用 SLO 计算错误预算的方法：
错误预算 = 1 - 可用性 SLO
例如，如果 SLO 为 97%：
错误预算 = 1- 97% = 3%
如果服务在 4 周内收到 100,000 个请求并且 SLO 为 97%，那么错误预算是 4 周内 1030 个错误。
SLO 监控 - 谁以及如何进行？
监控 SLO 的最佳方式是监控错误预算策略。SRE 团队将监控系统设置为在错误预算的特定百分比被消耗时发送警报。例如，如果在 7 天内消耗了 75%（或 50%）的错误预算，则发送警报。
监控 SLO 主要是 SRE 团队的工作。他们收集 SLI 指标并与其他团队合作来定义 SLO。如果 SLO 处于危险之中，则团队会决定是否需要采取任何行动并找出如何满足 SLO。SRE 团队与开发和产品团队合作，以确保就目标和政策达成一致。
该过程从随着时间的推移监视和测量服务的 SLI 开始。然后将 SLI 与 SLO 进行比较。如果需要采取行动，那么 SRE 团队会确定必须采取哪些步骤来实现目标。如果没有 SLO 和错误预算政策，SRE 团队将无法决定是否以及何时应该采取行动。
SLO 多久评估一次？
使用 SLO 运行服务是一个自适应和迭代过程。在 12 个月的时间里，很多事情都会发生变化。可能没有涵盖新功能，客户期望可能会发生变化，或者公司的风险回报状况可能会发生变化。
每隔几个月重新评估一次 SLO 很重要，因为如果达到了 SLO，但客户仍然不满意并在 Twitter 或 Zendesk 上抱怨，那就不好了。每隔几个月审查和重新评估的 SLO，并每六到十二个月跟进一次类似的审查。
没有关于 SLO 评估的硬性规定。根据产品、预期用途和管理团队，每个组织的 SLO 可能不同。可以考虑所有用户组，例如移动用户、桌面用户和来自不同地理位置的人员，并相应地修改 SLO。
评估和优化目标，直到找到最佳点。例如，如果的团队持续高于 SLO，则：
- 可以收紧 SLO 并提高服务可靠性（也可以将的卓越可靠性作为竞争优势告诉客户）
- 通过投资产品开发或实验来利用未使用的错误预算。
然而，如果团队一直在努力跟上 SLO，那么：
- 可以将它们降低 SLO 到更易于管理的级别。
- 在推出新功能之前投资稳定产品。
SLO 会不断评估，并且都是关于学习、创新和重新开始！
不满足 SLO 的后果是什么？
不满足 SLO 的后果通常包括代码冻结、减慢开发速度以及将更多资源转移到错误修复上。
这里重要的是，产品团队、开发人员和 SRE 都同意不满足 SLO 的后果。SRE 还可以使用错误预算策略在 SLO 面临风险时立即提醒相关领导。例如，如果 SLO 为 95%，那么在 97.5% 时提醒领导者可以帮助他们采取行动并相应地优先考虑可靠性与功能速度。