SLO 从方法论到实践：Part1 建立有效的 SLO¶
近年来，组织越来越多地采用服务水平目标 (SLO) 作为其站点可靠性工程 (SRE) 实践的基本部分。Google 开创了围绕 SLO 的最佳实践—— Google SRE 书籍很好地介绍了这一概念。从本质上讲，SLO 植根于服务可靠性和用户幸福度齐头并进的理念。设定具体且可衡量的可靠性目标有助于组织在产品开发和运营工作之间取得适当的平衡，最终带来积极的最终用户体验。
我们从三个part来学习了解SLO:
SLO 从方法论到实践: Part3 使用观测云管理SLO的最佳实践
关键术语¶
在继续之前，让我们首先分解一些将在整个系列中使用的关键术语：
- 服务水平指标 (SLI) 是用于衡量提供给最终用户的服务水平的指标（例如，可用性、延迟、吞吐量）。
- 服务水平目标 (SLO)是目标服务级别，由 SLI 衡量。它们通常表示为一段时间内的百分比。
- 服务水平协议 (SLA)是合同协议，概述了最终用户可以从服务提供商处获得的服务水平。如果这些承诺没有兑现，供应商可能会面临重大后果，这些后果通常是财务性质的（例如，服务信用、订阅延期）。
- 错误预算是服务在不符合 SLO 之前可接受的不可靠性水平。简而言之，它们是 100% 可靠性和 SLO 目标之间的差异。您可以将错误预算视为财务预算——但在这种情况下，开发人员将预算用于构建新功能、重新设计系统架构或任何其他产品开发工作。
服务水平目标对谁很重要？¶
为了让整个组织的主要利益相关者采用 SLO，您需要他们就实际可实现的可靠性目标达成一致，考虑到业务的优先级和他们希望开展的项目。在本节中，我们将仔细研究最终用户、开发人员和运营工程师关心的内容，以及我们在设置 SLO 时应如何考虑他们的目标和优先级。
终端用户¶
无论是何种产品，最终用户都对他们获得的服务质量抱有期望。他们希望应用程序可以在任何给定时间访问、快速加载并返回正确的数据。虽然您可以使用支持票或事件页面来衡量您的客户的不满意程度，但您不应仅仅依赖它们来做出产品决策，因为它们并不能全面捕捉您的最终用户体验。例如，解决所有故障单并不一定意味着您达到了最终用户期望的服务水平。
实际上，始终实现 100% 的可靠性是不可能的。SLO 帮助您在产品创新（这将帮助您为最终用户提供更大价值，但冒着破坏事物的风险）和可靠性（这将使这些用户满意）之间找到正确的平衡点。您的错误预算决定了在您的最终用户可能遇到服务质量下降之前，开发工作所能承受的不可靠性程度。
开发人员和运营工程师¶
传统上，开发人员和运维工程师之间的分歧源于他们对立的目标和职责：开发人员旨在为其服务添加更多功能，而运维工程师则负责维护这些服务的稳定性。SLO 不仅可以推动积极的业务成果，还可以促进文化转变，让开发和运营团队对其应用程序的可靠性形成一种共同的责任感。
有了 SLO 及其伴随的错误预算，团队就能够客观地决定优先考虑哪些项目或计划。只要有剩余的错误预算，开发人员就可以发布新功能以提高产品的整体质量，而运维工程师可以更专注于长期可靠性项目，例如数据库维护和流程自动化。但是，当错误预算开始耗尽时，开发人员将需要放慢或冻结功能工作，并与运维团队密切合作，在违反任何 SLA 或 SLO 之前重新稳定系统。简而言之，错误预算是一种可量化的方法，用于调整开发人员和运维工程师的工作和目标。
从 SLI 到 SLO¶
现在我们已经定义了一些与 SLO 相关的关键概念，是时候开始考虑如何制作它们了。深入了解您的用户如何体验您的产品——以及哪些用户旅程最重要——是创建有用 SLO 的第一步，也是最重要的一步。以下是您应该考虑的几个问题：
- 您的用户如何与您的应用程序交互？
- 他们通过应用程序的旅程是什么？
- 这些旅程与您基础设施的哪些部分进行交互？
- 他们对您的系统有什么期望，他们希望完成什么？
在本系列中，假设您在电子商务企业工作，并考虑此类企业将如何设置 SLO。您需要弄清楚您的客户如何与网站互动——以及他们从第一次进入网站到退出的路径。在基本层面上，您的客户需要能够登录、搜索商品、查看单个商品的详细信息、将商品添加到购物车以及结帐。像这样的关键用户旅程与用户体验直接相关，因此设置 SLO 很重要。
完成此练习后，您可以继续选择指标或 SLI，以量化您在这些关键用户旅程中提供的服务水平。
选择好的 SLI¶
随着您的基础架构变得越来越复杂，为每个数据库、消息队列和负载均衡器设置外部 SLO 变得越来越麻烦。相反，我们建议将您的系统组件组织成几个主要类别（例如，响应/请求、存储、数据管道），并在每个类别中指定 SLI。
当您开始选择 SLI 时，请记住一句简短但重要的说法：“所有 SLI 都是指标，但并非所有指标都是好的 SLI。” 这意味着虽然您可能要跟踪成百上千个指标，但您应该关注最重要的指标：最能捕捉用户体验的指标。
您可以使用下表（来自Google 的 SRE 书籍）作为参考。
现在，想象一下您的购物者卡在结账页面上，等待缓慢的支付端点返回响应。他们等待的时间越长，他们就越有可能对您的业务产生负面印象。除了声誉受损之外，客户放弃购物车可能会产生昂贵的后果。事实上，一些最大和最成功的组织发现，每一秒的延迟都与收入的显着减少相关。从这个例子中，我们可以看到响应延迟是在线零售商跟踪的一个特别重要的 SLI，以确保他们的客户能够快速完成关键业务交易。
将此与几乎肯定永远不会成为良好 SLI 的指标进行对比：CPU 利用率。即使您的服务器正在经历 CPU 使用率的激增——并且您的基础架构团队更频繁地收到这种高使用率的告警——您的最终用户可能仍然能够无缝地结账。这里的要点是，无论一个指标对您的内部团队有多重要，如果它的价值不直接影响用户满意度，那么它作为 SLI 就没有用处。
一旦您确定了好的 SLI，您就需要使用来自您的监控系统的数据来衡量它们。同样，我们建议从最接近用户的组件中提取数据。例如，您可以使用支付 API 来接受和授权信用卡交易，作为结账服务的一部分。虽然许多其他内部组件可能构成此服务（例如，服务器、后台作业处理器），但它们通常从用户的视图中抽象出来。由于 SLI 用于量化您的最终用户体验，因此仅从支付端点收集数据就足够了，因为它向用户公开了功能。
将 SLI 转换为 SLO¶
最后，您需要为 SLI 设置目标值（或值范围）以将其转换为 SLO。您应该说明您的最佳和最坏情况标准是什么——以及该条件应在多长时间内保持有效。例如，SLO 跟踪请求延迟可能是“在 30 天内，99% 的身份验证服务请求的延迟将小于 250 毫秒。”
当您开始创建 SLO 时，您应该记住以下几点。
现实点 无论将 SLO 设置为 100% 有多么诱人，在实践中基本上不可能实现。如果不考虑错误预算，您的开发团队可能会在尝试新功能时过于谨慎，这会抑制您产品的增长。典型的行业标准是将 SLO 目标设置为多个 9（例如，99.9% 被称为“三个 9”，99.95% 被称为“三个半九”）。
作为一般经验法则，您的 SLO 应该比您在 SLA 中详细说明的内容更严格。谨慎行事总是更好，以确保您满足您的 SLA，而不是始终如一地交付不足。
做实验 完善 SLO 没有硬性规定。每个组织的 SLO 将根据产品的性质、管理它们的团队的优先级以及最终用户的期望而有所不同。请记住，您始终可以继续优化目标，直到找到最佳值。例如，如果您的团队持续大幅超越目标，您可能希望收紧这些值或通过加大对产品开发的投资来利用未使用的错误预算。但是，如果您的团队一直未能实现其目标，那么将它们降低到更容易实现的水平或投入更多时间来稳定产品可能是明智之举。
不要把它复杂化 最后但并非最不重要的一点是，在定义 SLO 目标时，抵制设置过多 SLO 或使 SLI 聚合过于复杂的诱惑。与其为构成关键旅程的每个集群、主机或组件设置单独的 SLI，不如尝试以有意义的方式将它们聚合为单个 SLI。通常，您应该将 SLO 和 SLI 限制为仅对您的最终用户体验至关重要的 SLO 和 SLI。这有助于消除噪音，让您可以专注于真正重要的事情。
现在您知道您的 SLO¶
在这篇博文中，我们探讨了如何选择正确的 SLI 并将其转换为定义明确的 SLO 可以让您的组织走上成功之路。通过使用 SLI 来衡量您为用户提供的服务水平——并根据实际 SLO 跟踪您的性能——您将能够更好地做出决策以提高功能速度和系统可靠性。我们已将本指南总结为一个简单的清单，您可以在开始创建 SLO 和加入更多团队成员时参考该清单。