前言
之前的文章 - 如何配置 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 表达式如下：
好的事件 / 所有的事件 * 100% ERLANG-REPL |
典型的一个 SLI 就是：HTTP 请求的延迟
其表达式如下：
响应时间小于 5s 的 http 请求 / 所有的请求 * 100% ERLANG-REPL |
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 APACHE |
还是拿之前的举例：
95% 的目标就是 5% 的错误预算；
一个月的错误预算就是：
1 |
5% * 30d * 24h * 60min = 2160 min APACHE |
七步成诗 - 创建有效 SLO 的最佳实践
SLO 已经超出了基本的监控指标范畴；它们是站点可靠性工程师 （SRE） 和 DevOps 平台团队的强大指导工具，可帮助指导每个组织的 CI/CD 和生产流程中的改进。
但是，创建有效的 SLO 可能很困难。根据 Dynatrace 的 2022 年 SRE 状况报告，99% 的 SRE 表示，他们在定义和创建 SLO 时会遇到挑战。识别和实施有效的 SLO 需要深思熟虑和结构化的方法才能取得成功。以下是为您的平台和服务实施正确 SLO 的建议步骤。
- 站在同一阵线上
- 确定影响 SLA 的关键服务并确定其优先级
- 确定内部利益相关者并与不同的团队保持一致
- 确定要用作 SLI 的关键指标
- 确定关键 SLO
- 定义错误预算
- 确保主动 SLO 监控和告警
第一步：站在同一阵线上
服务级别协议 （SLA） 是供应商与其客户之间的合同财务协议。这些协议定义了客户和最终用户期望的服务级别，使它们成为了解 IT 如何确保实现总体业务目标的绝佳起点。违反 SLA 会导致经济处罚，影响收入，并损害公司的声誉。因此，调整 SLO 以满足客户需求至关重要。
📝Notes
服务定义：服务是指一个平台的任何特征 / 功能，提供给外部各方。
例如：
对于前端，不同的 User Action 算是不同的服务；
对于后端，不同的 HTTP 请求 可能指向不同服务。
在相关合同和 SLA 的维度下，SRE 和 DevOps 需要就使用的术语和定义达成一致。
这样可以消除所有的噪音，通过简单的术语，可以快速 确定重点.
SRE 或 DevOps 以及开发、运营、项目管理、销售，确定满足 SLA 要求所需的服务，尤其是客户经常与之交互的服务，或者如果发生故障，可能会导致最严重问题的服务。
第二步：识别你的客户群
接下来，你需要确定：
- 你的平台为哪些或哪些客户提供服务？
- 他们如何与你的平台直接互动？
客户可以是人，也可以是依赖你平台的其他平台。
例如，不同的平台服务可能会面向不同的用户：
- 互联网用户
- 系统管理员
- 呼叫中心客户
- 线下客户
- 临时客户
- 合作商
- …
第三步：通过客户群识别服务
平台的所有需求， 最终会具象化为平台提供的服务
而不同的服务会面向不同的客户。
这是非常重要的一步， 需要一些实践 / 公开交流来定义服务。 这里有个小技巧：通过架构图可以更方便地进行识别。
举例来说：
- 对于互联网用户， 登录（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 的关键步骤是：
- 谁是我的 客户群?
- 我的 服务 有哪些？
- 这些服务的关键指标 (SLI) 是哪几个？
- SLO 是什么？
最后的最后，监控.
监控是确保您满足 SLA 和业务目标的持续过程。除了在发生 SLO 违规时接收警报之外，更好、更主动的方法是在错误预算 (error budget), 燃尽率 (burn rate) 出现得比正常情况快时接收警报。此方法允许您在潜在问题导致问题之前解决它们。无论哪种方式，警报都应路由 (route) 到正确的团队或个人，以加快对问题进行分类并减少 MTTR。
