什么是服务级别目标 (SLO)？

SLO 是通过服务级别指标 (SLI) 来衡量的，SLI 是服务某些方面的定量指标。SLO 是服务提供商与客户之间更广泛协议——服务等级协议 (SLA) 的一部分。这类协议会明确客户可从服务提供商处获得的服务水平，并规定未达成目标时的惩罚措施。

为确保服务水平与业务需求及客户期望保持一致，站点可靠性工程 (SRE) 团队、开发运维 (DevOps) 团队、IT 团队及其他相关团队必须了解每个应用程序的关键用户旅程。这些旅程由一系列交互构成，助力终端用户达成其期望的结果。

内部支持对于成功的 SLO（因此也是 SLA）至关重要，多个利益相关者应参与确定 SLO，包括产品经理、开发运维和问题管理团队以及基础设施工程师。外部客户通过焦点小组、研究、客户投诉和社交媒体来参与讨论。

SLO 的关键逻辑是服务可靠性会提升用户满意度，从而带来更大的商机。建立可衡量的可靠性目标有助于组织在愉悦高效的用户体验与合理成本之间取得平衡：超出所需或预期的服务级别不会超出 IT 预算。

SLO 是必要的，因为它们以具体、可衡量的客观术语定义了服务质量 (QoS) 和可靠性目标。它们的目的不是确定最佳性能水平，而是确定可能达到和最不可接受的性能标准的范围。¹

O'Reilly Media 的 97 Things Every Cloud Engineer Should Know（每个工程师都应该知道的 97 件事）很好地总结了 SLO 的目标：“如何为管理层提供一种简单的方法，让他们立即了解可靠性、创新速度和成本之间的权衡？SLO 就是答案。SLO 制定了明确的可靠性准则，在云成本、变更速度和外部风险之间取得平衡。”

SLO 是跟踪和评估服务性能所涉及的几个相互关联的术语之一：

SLI 是对服务的某些方面的量化指标。SLI 提供真实的数字（系统性能的量尺），例如错误率、批量吞吐量或请求延迟。通常，测量结果将被汇总并以比率、平均值或百分位数的形式呈现。

SLO 是为了遵守服务级别协议 (SLA) 而必须满足的那些衡量标准（例如，确保响应时间保持在 200 毫秒以下）的目标值。这些值以一段时间内的百分比表示。

SLA 是供应商与客户之间的合同，由各个 SLO 组成，保证一定级别的服务活动、功能或流程。其中还规定了协议未得到满足时的处罚。

错误预算是 SLO 的一个方面，定义了在合同中断之前可接受的故障量。错误预算允许纳入实际不可避免的服务计划内或计划外停机时间。通过内置停机时间，开发团队将能够针对新开发、操作以及更新或修复已安装的软件做出明智的决策。

可靠性和响应能力通常以“趋于 100% 的若干 9 的百分比形式”来衡量：90%、99%、99.9% 等。例如，CPU 可用性的目标可呈现如下：

小数点后的位数每多一位，通常涉及更高的成本和复杂性。客户（内部和外部）可能需要一定程度的响应能力，之后将无法再检测到差异。设定 SLO 既是科学，也是艺术，需要在统计完美和成本效益、现实目标之间取得平衡。

开发团队可能希望推出新功能，而运营团队则希望确保稳定性和质量，以可控的方式引入变更。由于企业向内部和外部客户提供产品或服务，因此从客户的角度衡量任何服务水平非常重要。

SLO 有助于各组织围绕可靠性开展合作。最终，利益相关者应为客户商定一个可衡量的 SLO，以实现速度和服务质量之间的有效平衡。

从基本层面上讲，服务等级目标很重要，因为它们可确保服务可靠性并满足服务级别协议的要求。如果能满足 SLA 要求，将会让客户满意，这对业务也有好处。

SLO 不仅对外部客户有价值，还能为内部客户提供宝贵的洞察。SLO 可帮助各个团队衡量服务和应用程序的性能，并确定对它们进行改进的方法。除了其他优点外，SLO 还可以帮助各组织：

可靠性问题会让企业蒙受损失。对 SLO 进行妥当设置后，将能够看到并发现可观测性方面的差距。SLO 设置可能是集中来自企业中使用的多个监控工具的洞察的唯一位置。更好的可观测性有助于企业提供更好的产品、减少客户流失并提高运营效率。

SLO 和 SLI 提供针对服务和应用程序的性能的洞察分析，并为团队提供有关停机时间和其他潜在问题的准确度量标准。

这些信息对开发运维、IT 和其他团队在更新现有产品和发布新功能时寻求创新与可靠性之间的平衡非常有用。

经过深思熟虑的 SLO 可以根据客户体验来衡量微服务的运行状况，为产品性能和用户体验提供宝贵的洞察。

SLO 的确立和跟踪有助于整个组织的团队团结在一起，了解服务和相关预期。经过深思熟虑的 SLO 有助于培养一种沟通文化，在这种文化中，所有利益相关者都会权衡所属单位对服务的期望，并了解他们在确保满足 SLA 方面的作用。

此外，使用 SLO 创建报告并实现自动化可以帮助团队每个成员更快地回答有关事件的问题。SLO 对于开发运维、基础设施和 SRE 团队来说很重要，还可以帮助改变公司的几乎每个方面。通过可观测性收集的数据可以转换为可访问、上下文相关且可行性信息。这些洞察为团队提供了做出及时、经济高效的决策所需的可见性。

有了明确阐述的目标，各组织可以转向自动化来监控和测量 SLI。这种方法可以帮助确保实现目标，目的不仅仅是监控，还在于实现端到端流程的完全自动化。

在服务性能实际未达到 SLO 中设定的目标或违反 SLA 之前，自动监控系统可以帮助发现正在发展中的潜在问题。一旦建立了满足 SLO 的流程，就可以实施自动化以确保稳定的性能，例如，使用根据工作负载需求自动分配资源的平台。

SLO 为开发运维团队提供了预见能力，能够在问题发生之前识别潜在问题。这种预见能力可防止出现不可接受的停机时间或其他可能对最终用户造成负面影响或使公司蒙受损失的事件。

SLA 通常使用每月停机时间或可用性百分比来计算费用。停机时间是系统未能执行其主要功能的时间段。例如，通信故障可能导致网络停机。行业的可用性标准仍然很高，停机时间成本也在不断增加。除了财务影响外，未达成 SLO 还会导致客户不满。

许多组织都是按照被动事件管理流程进行运营。但是，如果等待事件发生，则需要更长的时间来缓解和解决系统内的问题，从而增加平均修复时间 (MTTR)¹。妥善确立的 SLO 有助于提高可观测性，支持各组织更主动地进行事件管理。

无关警报不仅会增加运营成本，还会导致工程师倦怠率居高不下——他们需耗费时间应对不存在的警报，既浪费精力又降低工作效率。警报方面最大的挑战之一就是，在过多和过少的警报之间找到适当的平衡。

相关警报会在性能下降可能导致可靠性目标未达标时通知工程师——即基于症状的警报。例如，当一项服务在过去一小时的响应延迟可能导致延迟 SLO 在一周内不合规时，将是一个真正的问题。

如果问商界人士，他们的系统正常运行时间目标应该是多少，许多人可能会说他们愿意尝试 100%。这是非常雄心勃勃的目标，但也非常昂贵，并且可能会在做其他事情之前先耗尽大部分 IT 预算。SLO 的设计目的不是为了炫耀，而是为了发现并满足客户的期望，这样，就可以让客户满意并成为回头客。可靠性是一种手段，而不是目的。

仅仅因为可以衡量性能指标并不意味着它对客户的满意度或利润很重要。划分优先级、重点关注那些最能表明积极客户体验的指标。

在《服务水平管理基础》一书中，Rick Sturm 和 Wayne Morris 提出了制定切合实际的 SLO 的清单：

SLO 应该：

· 可实现

· 可重复

· 可衡量

· 可理解

· 有意义

· 可控制

· 价格实惠

· 相互可接受

他们的清单以“可达到”开始。目标定得过高会推高成本，还可能导致系统可用性超出客户实际需求。以下是一些重要的最佳实践，可以帮助企业实现 SLO 目标：

定义支持 SLA 或业务目标的 SLO。20 个 SLO 真的是 5 个 SLO 四倍吗？或者，这会给 IT 团队增加更多工作量并使客户感到困惑，而没有任何有意义的好处？不要觉得必须对所有可以测量的东西进行评分。

设定切合实际的 SLO 目标，而不是过度承诺然后交付不足，这有可能会造成代价高昂的处罚，甚至可能导致企业失去客户。对内部利益相关者和客户实事求是，使每个人都能做出明智的决定。不切实际的高 SLO 目标最终只会花费更多。

通过事先就现实期望达成一致，可以避免内部团队之间以及与客户之间出现混乱和冲突。

手动指标收集表可能会减慢修复速度，而且可能不支持根本原因分析。收集相关 SLI 以自动评估 SLO，并在违反 SLO 之前构建自动警报。包括员工需要的上下文以及依赖关系，以便在问题变得严重之前加以解决。