SLO从方法论到可观测性实践

近年来，组织越来越多地采用服务水平目标 (SLO) 作为其站点可靠性工程 (SRE) 实践的基本部分。Google 开创了围绕 SLO 的最佳实践—— Google SRE 书籍很好地介绍了这一概念。从本质上讲，SLO 植根于服务可靠性和用户幸福度齐头并进的理念。设定具体且可衡量的可靠性目标有助于组织在产品开发和运营工作之间取得适当的平衡，最终带来积极的最终用户体验。

我们从三个部分来学习了解 SLO:

第一部分：建立有效的 SLO

第二部分：SLO 工具选型

第三部分：使用观测云管理SLO的最佳实践

第一部分：建立有效的 SLO

关键术语

在继续之前，让我们首先分解一些将在整个系列中使用的关键术语：

服务水平指标 (SLI) 是用于衡量提供给最终用户的服务水平的指标（例如，可用性、延迟、吞吐量）。
服务水平目标 (SLO) 是目标服务级别，由 SLI 衡量。它们通常表示为一段时间内的百分比。
服务水平协议 (SLA) 是合同协议，概述了最终用户可以从服务提供商处获得的服务水平。如果这些承诺没有兑现，供应商可能会面临重大后果，这些后果通常是财务性质的（例如，服务信用、订阅延期）。
错误预算是服务在不符合 SLO 之前可接受的不可靠性水平。简而言之，它们是 100% 可靠性和 SLO 目标之间的差异。您可以将错误预算视为财务预算——但在这种情况下，开发人员将预算用于构建新功能、重新设计系统架构或任何其他产品开发工作。

服务水平目标对谁很重要？

为了让整个组织的主要利益相关者采用 SLO，您需要他们就实际可实现的可靠性目标达成一致，考虑到业务的优先级和他们希望开展的项目。在本节中，我们将仔细研究最终用户、开发人员和运营工程师关心的内容，以及我们在设置 SLO 时应如何考虑他们的目标和优先级。

终端用户

无论是何种产品，最终用户都对他们获得的服务质量抱有期望。他们希望应用程序可以在任何给定时间访问、快速加载并返回正确的数据。虽然您可以使用支持票或事件页面来衡量您的客户的不满意程度，但您不应仅仅依赖它们来做出产品决策，因为它们并不能全面捕捉您的最终用户体验。例如，解决所有故障单并不一定意味着您达到了最终用户期望的服务水平。

实际上，始终实现 100% 的可靠性是不可能的。SLO 帮助您在产品创新（这将帮助您为最终用户提供更大价值，但冒着破坏事物的风险）和可靠性（这将使这些用户满意）之间找到正确的平衡点。您的错误预算决定了在您的最终用户可能遇到服务质量下降之前，开发工作所能承受的不可靠性程度。

开发人员和运营工程师

传统上，开发人员和运维工程师之间的分歧源于他们对立的目标和职责：开发人员旨在为其服务添加更多功能，而运维工程师则负责维护这些服务的稳定性。SLO 不仅可以推动积极的业务成果，还可以促进文化转变，让开发和运营团队对其应用程序的可靠性形成一种共同的责任感。

有了 SLO 及其伴随的错误预算，团队就能够客观地决定优先考虑哪些项目或计划。只要有剩余的错误预算，开发人员就可以发布新功能以提高产品的整体质量，而运维工程师可以更专注于长期可靠性项目，例如数据库维护和流程自动化。但是，当错误预算开始耗尽时，开发人员将需要放慢或冻结功能工作，并与运维团队密切合作，在违反任何 SLA 或 SLO 之前重新稳定系统。简而言之，错误预算是一种可量化的方法，用于调整开发人员和运维工程师的工作和目标。

从 SLI 到 SLO

现在我们已经定义了一些与 SLO 相关的关键概念，是时候开始考虑如何制作它们了。深入了解您的用户如何体验您的产品——以及哪些用户旅程最重要——是创建有用 SLO 的第一步，也是最重要的一步。以下是您应该考虑的几个问题：

[x] 您的用户如何与您的应用程序交互？
[x] 他们通过应用程序的旅程是什么？
[x] 这些旅程与您基础设施的哪些部分进行交互？
[x] 他们对您的系统有什么期望，他们希望完成什么？

在本系列中，假设您在电子商务企业工作，并考虑此类企业将如何设置 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 和加入更多团队成员时参考该清单。

第二部分：SLO 工具选型

服务水平目标或 SLO 是站点可靠性工程工具包的关键部分。SLO 提供了一个框架，用于围绕应用程序性能定义明确的目标，最终帮助团队提供一致的客户体验、平衡功能开发与平台稳定性，并改善与内部和外部用户的沟通。

SLO 和 SLI

正如我们在第 1 部分中看到的，SLO 为您的 SLI 设置了精确的目标，这些目标是反映服务运行状况和性能的指标。通过在观测云中管理您的 SLO，您可以无缝访问监控数据——包括来自 APM 的跟踪指标、自定义指标、合成数据和从日志生成的指标——以用作 SLI。例如，如果您想确保快速处理典型的用户请求，您可以使用来自 APM 的服务的中位延迟作为 SLI。然后，您可以将 SLO 定义为“在任何日历月 99% 的时间里，所有用户请求的中位延迟（按每分钟计算）将小于 250 毫秒。”
为了准确跟踪实际性能与您设定的目标的比较情况，您需要一种方法来不仅监控实时性能（例如，每 60 秒计算一次中位延迟并将其与 250 毫秒阈值进行比较），而且还需要测量在更长的时间跨度内违反该阈值的频率（以确保每个日历月都达到 99% 的目标）。观测云跟踪您的 SLI 并可视化它们与您建立的 SLO 相关的状态，因此您可以立即看到在给定时间段内实际性能与您的目标的比较情况。

工具选择

对于SLI指标，数据主要源于三大件：Metrics、Logs、Traces
Metrics：指标，主要是收集系统及应用程序指标，这些指标对我们的服务有很大的影响，比如CPU突然暴增100%带来的后果是应用处理能力极具下降，对用户表现就是卡顿现象严重。

Traces: 链路，基于有向无环图构建的软件各个模块直接的调用关系，服务调用链路情况，通过链路信息，我们能够快速的定位哪些服务、哪些语句对客户有很大的影响，比如数据库慢查询。

Logs: 日志，系统/应用输出的时间相关的记录，通常由系统/软件开发人员输出，方便定位系统的错误和状态。将日志中有关联性的数据提取为Tag或Field，Tag方便进行聚合和分组，Field方便基于计算和聚合。

常用工具

Metrics
promethues、OpenTelemetry...
Traces
skyworking、OpenTelemetry、jaeger、Sleuth、Zipkin...
Logs
ELK 、filebeat、flume...

太多的免费开源工具且每个体系都是有特定的 Console 和语法，这些工具对您来说都有着高额的学习成本以及昂贵的维护成本，分散的系统和用户体系不得不让您在多个平台间不断来回切换，恰恰SLI需要这样一个能够集中各系统组件的平台聚合，通过一个平台能够接入多方工具并统一语法，能够有效的降低学习成本。观测云是最好的选择，观测云为您提供了一站式解决方案，目前已经接入了 200+ 开源工具组件。当然您也可以组建团队来构建这样一个平台，但并不建议您这么做。

在一处管理您的所有 SLO

如果您的组织致力于跨多个产品和团队的各种 SLO，在一个地方可视化所有 SLO 的状态可以帮助您设置优先级并解决问题。观测云的服务级别目标视图允许您查看所有 SLO 的状态，以及每个SLO 的剩余错误预算。

根据指标和监视器创建 SLO

在 SLO 列表视图中，您可以通过单击新建 SLO按钮。观测云中的 SLO 可以基于现有的监视器（例如，将 p90 延迟与目标阈值进行比较的监视器）或根据指标计算的实时状态。基于指标的 SLO 可用于监控满足特定定义的指标百分比，例如来自负载均衡器的非 5xx 响应数除以响应总数。

一目了然地查看您的 SLO 和错误预算

单击 SLO 或者打开事件会打开一个侧面板，其中显示 SLO 的详细信息，例如其状态、目标值和剩余错误预算。观测云自动生成一个错误预算对于每个 SLO，这表示在违反 SLO 之前您可以承受的不可靠性程度。这有助于快速了解您是否正在实现目标，以及您的开发速度是否适合您既定的性能和稳定性目标。观测云会根据您指定的 SLO 目标和时间窗口自动计算错误预算。例如，7 天期间 99% 的 SLO 目标将为您提供大约三个半小时的错误预算，该期间的性能不合标准。

可视化 SLO 状态

要在上下文中跟踪 SLO 的状态以及有关相关服务或基础架构组件的详细数据，您可以将 SLO 小部件添加到您的观测云仪表板。然后，您可以在内部或外部共享您的仪表板，将您的 SLO 的实时状态传达给依赖您的服务的任何人。

您还可以通过常见的 SLO 基准（例如上周、上月、本周至今或本月至今）可视化违反该阈值的频率。如果您将过去 30 天的目标设置为 99%，并将警告目标设置为 99.5%，则您的 SLO 状态在高于 99.5% 时显示为绿色，低于 99.5% 时显示为黄色，下降时显示为红色低于 99%。

展示并共享您的服务状态

观测云使在您已经监控应用程序、基础设施、用户体验等的同一个地方监控和管理您的 SLO 变得简单。也许同样重要的是，观测云使您能够向依赖于满足这些 SLO 的任何利益相关者或用户提供透明度。如果您还没有使用观测云来监控您的服务的运行状况和性能，您可以从这里开始免费试用帐户。

第三部分：使用观测云管理 SLO 的最佳实践

决定好 SLO 工具选型后，现在我们来看看 SLO 在观测云的最佳实践。

协作和沟通对于成功实施服务水平目标至关重要。开发和运营团队需要根据既定的服务可靠性目标评估他们的工作的影响，以改善他们的最终用户体验。观测云使您组织中的每个人都能在一个地方跟踪、管理和监控所有 SLO 和错误预算的状态，从而简化了跨团队协作。团队可以在仪表板上将他们的 SLO 与相关服务和基础设施组件一起可视化，并与依赖它们的任何利益相关者共享这些 SLO 的实时状态。

为每个用例选择最佳 SLO

在观测云中，可以创建多种监视器，您可以使用一个或多个监视器来计算其 SLI。SLI 被定义为您的服务表现出良好行为的时间比例（由处于非警报状态的底层监视器跟踪）。

观测云监视器

阈值检测

突变检测

区间检测

水位检测

日志检测

基础设施对象检测

应用性能指标检测

用户访问指标检测

安全巡检异常检测

可用性数据检测

网络数据检测

您可以创建不同种类的监视器来满足各自SLO的需求。

您可以创建一个基于用户访问指标检测的监视器创建 SLO，它使用您在观测云中的指标来计算其 SLI。SLI 被定义为有效请求总数中的良好请求数。

如果您希望跟踪对支付端点的请求的延迟，创建一个应用性能指标检测监视器的 SLO 来跟踪基于时间的数据可能更合适：端点表现出良好行为（即，响应速度足够快）的时间百分比以满足您的 SLO 目标）。要创建此 SLO，您可以选择一个观测云阈值监视器，该监视器在对支付端点的请求延迟超过特定阈值时触发。

这个 SLO 可以口头表述为“在 99% 的时间里，请求的处理速度应该在 30 天的时间窗口内快

另一方面，如果您希望跟踪您的支付端点是否成功处理请求，您可以定义一个基于应用性能指标监视器指标的 SLO，应用性能指标检测主要是基于APM 的跟踪指标来跟踪请求到达端点的频率以及它们何时成功，该 SLO 使用基于计数的数据（即，与有效事件总数相比，良好事件的数量事件）为其 SLI。解决此问题的一种方法是将具有非 2xx 状态代码的 HTTP 响应的数量（我们将其视为异常事件的数量）。

如果您的应用部署在 Docker 上，您希望应用环境能够提供良好的服务，即一个安全容器的 SLO ，也可以从模板中创建一个 Docker监视器，并在设置 SLO 时，指定对应的监视器。

使用 SLO 增强您的仪表板

您可能已经在使用仪表板来可视化来自您的基础设施和应用程序的关键性能指标。您可以通过添加SLO 摘要小部件来增强这些仪表板，以跟踪您的 SLO 随时间的状态。为了获得有关 SLO 状态的更多上下文，我们还建议添加与基于指标的 SLO 相对应的 SLI 图表，并显示构成基于监视器的 SLO的监视器的状态。

使用观测云 SLO 确保服务可靠性

通过这篇文章，我们研究了一些有用的技巧，它们将帮助您从观测云中的服务级别目标中获得最大价值。SLO 与您的基础设施指标、分布式跟踪、日志、综合测试和网络数据一起，帮助您确保提供最佳的最终用户体验。观测云的内置协作功能不仅可以轻松定义 SLO，还可以轻松地与组织内外的利益相关者分享见解。

查看我们的文档，开始定义和管理您的 SLO。如果您还没有使用观测云，您可以立即开始免费试用。