服务级别目标 (SLO) 是针对特定服务议定的一段时间内的性能目标。SLO 规定了服务的预期状态，帮助利益相关者管理特定服务的运行状况，并优化兼顾创新和可靠性的决策。1
SLO 是使用服务级别指标 (SLI) 来衡量的，SLI 是服务某些方面的定量指标。SLO 是服务提供商和客户之间更广泛协议的一部分，该协议称为服务级别协议 (SLA)，其中概述了客户可以从提供商处获得的服务级别，并规定了如果未能达到目标将受到的处罚。
为了确保服务级别与业务需求和客户需求保持一致，站点可靠性工程 (SRE) 团队、开发运维、IT 和其他相关团队必须了解每个应用程序的关键用户旅程：即支持最终用户获得预期结果的交互。
内部支持对于成功的 SLO（因此也是 SLA）至关重要，多个利益相关者应参与确定 SLO，包括产品经理、开发运维和问题管理团队以及基础设施工程师。外部客户通过焦点小组、研究、客户投诉和社交媒体来参与讨论。
SLO 的关键逻辑是服务可靠性会提升用户满意度，从而带来更大的商机。建立可衡量的可靠性目标有助于组织在愉悦高效的用户体验与合理成本之间取得平衡：超出所需或预期的服务级别不会超出 IT 预算。
SLO 是必要的，因为它们以具体、可衡量的客观术语定义了服务质量 (QoS) 和可靠性目标。它们的目的不是确定最佳性能水平，而是确定可能达到和最不可接受的性能标准的范围。1
O'Reilly Media 的 97 Things Every Cloud Engineer Should Know（每个工程师都应该知道的 97 件事）（ibm.com 外部链接）很好地总结了 SLO 的目标：“如何为管理层提供一种简单的方法，让他们立即了解可靠性、创新速度和成本之间的权衡？SLO 就是答案。SLO 制定了明确的可靠性准则，在云成本、变更速度和外部风险之间取得平衡。”
这本电子书旨在破除有关可观测性的误解，并展示其在数字世界中的作用。
注册获取实施 FinOps 的指南
SLO 是跟踪和评估服务性能所涉及的几个相互关联的术语之一：
SLI 是对服务的某些方面的量化指标。SLI 提供真实的数字（系统性能的量尺），例如错误率、批量吞吐量或请求延迟。通常，测量结果将被汇总并以比率、平均值或百分位数的形式呈现。
SLO 是为了遵守服务级别协议 (SLA) 而必须满足的那些衡量标准（例如，确保响应时间保持在 200 毫秒以下）的目标值。这些值通常以一段时间内的百分比表示。
SLA 是供应商与客户之间的合同，由各个 SLO 组成，保证一定级别的服务活动、功能或流程。其中还规定了协议未得到满足时的处罚。
错误预算是 SLO 的一个方面，定义了在合同中断之前可接受的故障量。错误预算允许纳入实际不可避免的服务计划内或计划外停机时间。通过内置停机时间，开发团队将能够针对新开发、操作以及更新或修复已安装的软件做出明智的决策。
可靠性和响应能力通常以“趋于 100% 的若干 9 的百分比形式”来衡量：90%、99%、99.9% 等。例如，CPU 可用性的目标可能呈现如下：
可靠性级别 | 允许的不可靠窗口时间 | ||
|
|
| |
每年 | 每季度 | 每 30 天 | |
90% | 36.5 天 | 9 天 | 3 天 |
95% | 18.25 天 | 4.5 天 | 1.5 天 |
99% | 3.65 天 | 21.6 小时 | 7.2 小时 |
99.5% | 1.83 天 | 10.8 小时 | 3.6 小时 |
99.9% | 8.76 小时 | 2.16 小时 | 43.2 分钟 |
99.95% | 4.38 小时 | 1.08 小时 | 21.6 分钟 |
99.99% | 52.6 分钟 | 12.96 分钟 | 4.32 分钟 |
99.999% | 5.26 分钟 | 1.30 分钟 | 26.9 秒 |
|
|
| |
小数点后的位数每多一位，通常涉及更高的成本和复杂性。客户（内部和外部）可能需要一定程度的响应能力，之后将无法再检测到差异。设定 SLO 既是科学，也是艺术，需要在统计完美和成本效益、现实目标之间取得平衡。
开发团队可能希望推出新功能，而运营团队则希望确保稳定性和质量，以可控的方式引入变更。由于企业向内部和外部客户提供产品或服务，因此从客户的角度衡量任何服务水平非常重要。
SLO 有助于各组织围绕可靠性开展合作。最终，利益相关者应为客户商定一个可衡量的 SLO，以实现速度和服务质量之间的有效平衡。
从基本层面上讲，服务级别目标很重要，因为它们可确保服务可靠性并满足服务级别协议的要求。如果能满足 SLA 要求，将会让客户满意，这对业务也有好处。
SLO 不仅对外部客户有价值，还能为内部客户提供宝贵的洞察。SLO 可帮助各个团队衡量服务和应用程序的性能，并确定对它们进行改进的方法。除了其他优点外，SLO 还可以帮助各组织：
SLO 和 SLI 提供针对服务和应用程序的性能的洞察分析，并为团队提供有关停机时间和其他潜在问题的准确度量标准。这些信息对开发运维、IT 和其他团队在更新现有产品和发布新功能时寻求创新与可靠性之间的平衡非常有用。
经过深思熟虑的 SLO 可以根据客户体验来衡量微服务的运行状况，为产品性能和用户体验提供宝贵的洞察。
SLO 的确立和跟踪有助于整个组织的团队团结在一起，了解服务和相关预期。经过深思熟虑的 SLO 有助于培养一种沟通文化，在这种文化中，所有利益相关者都会权衡所属单位对服务的期望，并了解他们在确保满足 SLA 方面的作用。
此外，使用 SLO 创建报告并实现自动化可以帮助团队每个成员更快地回答有关事件的问题。SLO 对于开发运维、基础设施和 SRE 团队来说很重要，还可以帮助改变公司的几乎每个方面。通过可观测性收集的数据可以转换为可访问、上下文相关且可行性信息。这些洞察为团队提供了做出及时、经济高效的决策所需的可见性。
SLO 为开发运维团队提供了预见能力，能够在问题发生之前识别潜在问题。这种预见能力可防止出现不可接受的停机时间或其他可能对最终用户造成负面影响或使公司蒙受损失的事件。
SLA 通常使用每月停机时间或可用性百分比来计算费用。停机时间是系统未能执行其主要功能的时间段。例如，通信故障可能导致网络停机。行业的可用性标准仍然很高，停机时间成本也在不断增加。除了财务影响外，未达成 SLO 还会导致客户不满。
许多组织都是按照被动事件管理流程进行运营。但是，如果等待事件发生，则需要更长的时间来缓解和解决系统内的问题，从而增加平均修复时间 (MTTR)1。妥善确立的 SLO 有助于提高可观测性，支持各组织更主动地进行事件管理。
不相关的警报不仅会增加运营成本，还会导致高倦怠率，因为工程师需要浪费时间并降低工作效率来应对不存在的警报。警报方面最大的挑战之一就是，在过多和过少的警报之间找到适当的平衡。
相关警报是指在性能下降可能导致无法实现可靠性目标时通知工程师的警报，即基于症状的警报。例如，当一项服务在过去一小时的响应延迟可能导致延迟 SLO 在一周内不合规时，将是一个真正的问题。
如果问商界人士，他们的系统正常运行时间目标应该是多少，许多人可能会说他们愿意尝试 100%。这是非常雄心勃勃的目标，但也非常昂贵，并且可能会在做其他事情之前先耗尽大部分 IT 预算。SLO 的设计目的不是为了炫耀，而是为了发现并满足客户的期望，这样，就可以让客户满意并成为回头客。可靠性是一种手段，而不是目的。
仅仅因为可以衡量性能指标并不意味着它对客户的满意度或利润很重要。划分优先级。重点关注那些最能表明积极客户体验的指标。
在服务级别管理基础（ibm.com 外部链接）中，Rick Sturm 和 Wayne Morris 提出了这份设置切合实际的 SLO 的清单：
SLO 应该：
· 可实现
· 可重复
· 可衡量
· 可理解
· 有意义
· 可控制
· 价格实惠
- 相互接受
请注意，他们的清单以“可实现”开头。追求远大的目标非常昂贵，并且可能会提供比客户预期更多的正常运行时间。以下是一些重要的最佳实践，可以帮助企业实现 SLO 目标：
定义支持 SLA 或业务目标的 SLO。20 个 SLO 真的是 5 个 SLO 四倍吗？或者，这只会给 IT 团队增加更多工作量并使客户感到困惑，而没有任何有意义的好处？不要觉得必须对所有可以测量的东西进行评分。
设定切合实际的 SLO 目标，而不是过度承诺然后交付不足，这可能会造成代价高昂的处罚，甚至可能导致企业失去客户。对内部利益相关者和客户实事求是，使每个人都能做出明智的决定。从长远来看，不切实际的高 SLO 目标只会花费更多。
通过事先就现实期望达成一致，可以避免内部团队之间以及与客户之间出现混乱和冲突。
手动指标收集表可能会减慢修复速度，而且可能不支持根本原因分析。收集相关 SLI 以自动评估 SLO，并在违反 SLO之前 构建自动警报。包括员工需要的上下文以及依赖关系，以便在问题变得严重之前加以解决。
IBM Instana 通过提供一个解决方案来实现可观测性的普及化，开发运维、SRE、平台、ITOps 和开发领域的任何人都可以使用该解决方案在所需的环境中获取所需的数据。该平台专为云原生而构建，但与技术无关，能够在移动、Web、应用程序和基础设施的逻辑和物理依赖关系环境中，支持以 1 秒的粒度自动且连续地提供高保真数据并进行端到端跟踪。
利用 IBM® Turbonomic 混合云成本优化平台，能够持续实时地自动执行关键操作，从而主动为堆栈每一层的应用程序提供最有效的计算、存储和网络资源。
脚注
1“服务级别目标”，IBM，2023 年 9 月 6 日。