前言
之前的文章- 如何配置 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%
典型的一个 SLI 就是:HTTP 请求的延迟
其表达式如下:
响应时间小于 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%
那么一个月的错误预算就是:
0.5% * 30d * 24h * 60min = 216 min
还是拿之前的举例:
95% 的目标就是 5% 的错误预算;
一个月的错误预算就是:
5% * 30d * 24h * 60min = 2160 min
七步成诗 - 创建有效 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:错误率
- 客户期望:登录很快
- SLI: 响应时间(持续时间或延迟)
- SLO: 过去 1 个月 95%的响应时间 ≤ 5s
- SLI: 响应时间(持续时间或延迟)
客户期望:随时都可以登录客户期望:每分钟并发可达到上百次
- 客户期望:登录成功无报错
- 服务:登录服务
总结
总结一下,创建有效 SLO 的关键步骤是:
- 谁是我的客户群?
- 我的服务有哪些?
- 这些服务的关键指标 (SLI) 是哪几个?
- SLO 是什么?
最后的最后,监控.
监控是确保您满足 SLA 和业务目标的持续过程。除了在发生 SLO 违规时接收警报之外,更好、更主动的方法是在错误预算 (error budget), 燃尽率 (burn rate) 出现得比正常情况快时接收警报。此方法允许您在潜在问题导致问题之前解决它们。无论哪种方式,警报都应路由 (route) 到正确的团队或个人,以加快对问题进行分类并减少 MTTR。