七步成诗 - 快速创建有效 SLO

本文最后更新于：2023年5月6日 上午

前言

之前的文章 - 如何配置 SLO - 东风微鸣技术博客 (ewhisper.cn) 介绍了一些常用的各类 SLO, 但是在实际制定 SLO 过程中，并不一定适合实际业务需求。本次介绍 SLO 的最佳实践 - 如何 7 步创建有效的 SLO.

SLI SLO 定义

在之前的文章 - SLA、SLO、SLI 定义 -「译文」使用 Prometheus 和 Grafana 实现 SLO - 东风微鸣技术博客 (ewhisper.cn) 中，我们已经介绍过 SLI SLO SLA 的定义。这里再次简单提一下。

SLI

SLI: Service Level Indicator, 即 服务水平 指标, 这是了解服务健康状况的一个关键指标，也是设置 SLO 的基石。

典型的 SLI 表达式如下：

1
好的事件 / 所有的事件 * 100%

典型的一个 SLI 就是：HTTP 请求的延迟

其表达式如下：

1
响应时间小于 5s 的 http 请求 / 所有的请求 * 100%

SLO

SLO: Service Level Object, 即 服务水平 目标, 是我们针对 SLI 设定的一个目标。而往往 SLO 是与时间窗口紧密相关的。

典型的 SLO 如下：

  • 目标 99.9%
  • 低于该目标，😡
  • 大于等于该目标，😎

典型的一个 SLO 示例：95% 的请求的响应时间都≤5s

Error Budget （错误预算）

目的是：

利用错误预算进行开发和创新
允许更好的进行合作，因为一个共同的目标

  • 用完错误预算之后，就主要强制执行（即阻止部署）
  • 保持在错误预算内，那么就可以激励创新和更高风险的部署

定义是：
1 - 可用性目标。SRE 和 Devs 在错误预算内工作。

比如：SLO 是 99.5%, 那么 错误预算就是 1-99.5% 就是 0.5%

那么一个月的错误预算就是：

1
0.5% * 30d * 24h * 60min = 216 min

还是拿之前的举例：

95% 的目标就是 5% 的错误预算；

一个月的错误预算就是：

1
5% * 30d * 24h * 60min = 2160 min

七步成诗 - 创建有效 SLO 的最佳实践

SLO 已经超出了基本的监控指标范畴；它们是站点可靠性工程师 （SRE） 和 DevOps 平台团队的强大指导工具，可帮助指导每个组织的 CI/CD 和生产流程中的改进。

但是，创建有效的 SLO 可能很困难。根据 Dynatrace 的 2022 年 SRE 状况报告，99% 的 SRE 表示，他们在定义和创建 SLO 时会遇到挑战。识别和实施有效的 SLO 需要深思熟虑和结构化的方法才能取得成功。以下是为您的平台和服务实施正确 SLO 的建议步骤。

  1. 站在同一阵线上
  2. 确定影响 SLA 的关键服务并确定其优先级
  3. 确定内部利益相关者并与不同的团队保持一致
  4. 确定要用作 SLI 的关键指标
  5. 确定关键 SLO
  6. 定义错误预算
  7. 确保主动 SLO 监控和告警

第一步：站在同一阵线上

服务级别协议 （SLA） 是供应商与其客户之间的合同财务协议。这些协议定义了客户和最终用户期望的服务级别，使它们成为了解 IT 如何确保实现总体业务目标的绝佳起点。违反 SLA 会导致经济处罚，影响收入，并损害公司的声誉。因此，调整 SLO 以满足客户需求至关重要。

📝Notes

服务定义：服务是指一个平台的任何特征 / 功能，提供给外部各方。
例如：
对于前端，不同的 User Action 算是不同的服务；
对于后端，不同的 HTTP 请求 可能指向不同服务。

在相关合同和 SLA 的维度下，SRE 和 DevOps 需要就使用的术语和定义达成一致。
这样可以消除所有的噪音，通过简单的术语，可以快速 确定重点.

SRE 或 DevOps 以及开发、运营、项目管理、销售，确定满足 SLA 要求所需的服务，尤其是客户经常与之交互的服务，或者如果发生故障，可能会导致最严重问题的服务。

第二步：识别你的客户群

接下来，你需要确定：

  • 你的平台为哪些或哪些客户提供服务？
  • 他们如何与你的平台直接互动？

客户可以是人，也可以是依赖你平台的其他平台。

例如，不同的平台服务可能会面向不同的用户：

  1. 互联网用户
  2. 系统管理员
  3. 呼叫中心客户
  4. 线下客户
  5. 临时客户
  6. 合作商
  7. …

第三步：通过客户群识别服务

平台的所有需求， 最终会具象化为平台提供的服务

而不同的服务会面向不同的客户。

这是非常重要的一步， 需要一些实践 / 公开交流来定义服务。 这里有个小技巧：通过架构图可以更方便地进行识别。

举例来说：

  • 对于互联网用户， 登录（Login） 是重要的服务

第四步：确定服务的优先级

为每个客户群挑选最重要的前 2-3 项服务， 如：对于 互联网 客户群，就是 ** 登录（Login）和 结账（checkout）** 服务，这有助于将重点放在关键服务上。

排序的标准是根据对客户和对财务影响。例如，用于购买产品的“结帐 (checkout)”服务的优先级高于用于比较产品的“比较服务”。

第五步：细分客户目标

客户对服务的目标包括：

  • 可用性要求
  • 性能要求
  • 服务的活动量
  • 服务的正确性

这里推荐使用行业标准的框架，需要与您的 SRE 和运营团队合作，了解您的可观察性平台提供哪些关键指标以及需要跟踪哪些指标。有许多类型的 SLI 可供选择，例如 Google 的 四个黄金信号，RED 指标（速率 Rate，错误 Error，持久性 Duration）或 USE 指标（利用率 Usage，饱和度 Saturation，错误 Error）。

还是继续之前的举例，对于：

  • 互联网客户群
    • 登录服务
      • 客户期望：随时都可以登录
      • 客户期望：每分钟并发可达到上百次
      • 客户期望：登录很快
      • 客户期望：登录成功无报错

第六步：选择具体指标（SLI）

还是继续之前的例子，需要通过多次的会议、访谈、对话，选择其中的前 2-3 个重要目标，并将其细化：

  • 用户群：互联网客户群
    • 服务：登录服务
      • 客户期望：登录成功无报错
        • 具体指标：错误率
      • 客户期望：登录很快
        • 具体指标： 响应时间（持续时间或延迟）
      • 客户期望：随时都可以登录
      • 客户期望：每分钟并发可达到上百次

第七步：建立 SLO

确定关键服务和 SLI 后，即可创建 SLO。确保每个目标都可以通过为特定时间范围（例如：小时，周，月）设置的现实的，可实现的阈值来衡量。SLO 的不切实际的高门槛将面临不断的违规行为。相反，容易实现的低 SLO 阈值使得很难知道何时发生服务中断。SLO 必须 有意义并推动业务成果 ，而不仅仅是作为要达到的目标而存在。确定阈值的一个好方法是查看服务执行方式的 历史趋势。

这是最后一步， SLO 需要是你可以监测的东西，并且应该是具体的。
有这么几个关键词：

  • 可用性（目标）
  • 时间范围
  • 具体条件（SLI）

还是继续之前的例子：

  • 用户群：互联网客户群
    • 服务：登录服务
      • 客户期望：登录成功无报错
        • SLI：错误率
          • SLO：过去 5min 错误率 < 1%
      • 客户期望：登录很快
        • SLI： 响应时间（持续时间或延迟）
          • SLO: 过去 1 个月 95% 的响应时间 ≤ 5s
      • 客户期望：随时都可以登录
      • 客户期望：每分钟并发可达到上百次

总结

总结一下，创建有效 SLO 的关键步骤是：

  1. 谁是我的 客户群?
  2. 我的 服务 有哪些？
  3. 这些服务的关键指标 (SLI) 是哪几个？
  4. SLO 是什么？

最后的最后，监控.

监控是确保您满足 SLA 和业务目标的持续过程。除了在发生 SLO 违规时接收警报之外，更好、更主动的方法是在错误预算 (error budget), 燃尽率 (burn rate) 出现得比正常情况快时接收警报。此方法允许您在潜在问题导致问题之前解决它们。无论哪种方式，警报都应路由 (route) 到正确的团队或个人，以加快对问题进行分类并减少 MTTR。

📚️参考文档