暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / 深入理解SLO和SLI：指标、目标与协议

深入理解SLO和SLI：指标、目标与协议

IT那活儿 2025-08-19
633
点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
一

指标、目标与协议

今天来聊一下SLO（Service Level Objective，服务级别目标），它是衡量服务性能和可靠性的重要指标之一。SLO定义了服务在特定时间段内的期望性能水平，通常以百分比形式表示，并且是用户和服务提供方共同认可的目标。它与SLA（服务级别协议）和SLI（服务级别指标）密切相关。
1.1 服务级别指标（SLI）
SLI 是服务级别指标，用于测量服务等级的关键指标。
大多数服务将请求延迟（返回请求响应所需的时间）视为关键的 SLI。其他常见的 SLI 包括错误率（通常表示为收到的所有请求的一部分）和系统吞吐量（通常以每秒请求数来衡量）。测量结果通常是聚合的，即，在测量窗口中收集原始数据，然后将其转换为比率、平均值或百分位数。
对 SRE 来说，另一种重要的 SLI 是可用性，或者服务可用的时间比例。业界普遍表示高可用性可用性值以可用性百分比中“9”的数量表示，而当前发布的 Google Compute Engine 可用性目标是“三个半 9”——99.95% 的可用性。
1.2 服务级别目标（SLO）
SLO 是服务级别目标，是围绕 SLI 构建的目标，表示在特定时间段内的目标达成率。
1.3 服务级别协议（SLA）
SLA 是服务级别协议，指提供服务的企业与客户就 SLO 交付所达成的协议，以保障服务可用性。
1.4 误差预算（Error Budget）
根据 SLO 的目标百分比（100% - 目标百分比）得出的允许的不可靠性量，剩余误差预算以百分比形式显示，并使用以下公式计算：
二

SLO指标选择

2.1 选择 SLI 指标的两大原则
  • 原则一
    选择能够标识一个主体是否稳定的指标，如果不是这个主体本身的指标，或者不能标识主体稳定性的，就要排除在外。
  • 原则二
    针对有用户界面的业务系统，优先选择与用户体验强相关或用户可以明显感知的指标。
2.2 快速识别 SLI 指标的方法
VALET 是 5 个单词的首字母，分别是Volume、Availability、Latency、Error 和 Ticket。这 5 个单词就是我们选择 SLI 指标的 5 个维度。
1）Volume- 容量
Volume（容量）是指服务承诺的最大容量是多少。比如，一个应用集群的 QPS、TPS、会话数以及连接数等等，如果日常设定一个目标，就是日常的容量 SLO，对双 11 这样的大促设定一个目标，就是大促 SLO。对于数据平台，要看它的吞吐能力，比如每小时能处理的记录数或任务数。
2）Availablity- 可用性
Availablity（可用性）代表服务是否正常。比如请求调用的非 5xx 状态码成功率，就可以归于可用性。对于数据平台，任务的执行成功情况，这个也可以根据不同的任务执行状态码来归类。
3）Latency- 时延
Latency（时延）是说响应时间，时延直接影响到了用户的真实体验。
对于时延，一般不会直接做所有请求时延的平均，因为有时候平均值是符合正常值的，所以这里会引入百分位数来衡量请求时延，以类似“90% 请求的时延 <= 80ms，或者 95% 请求的时延 <=120ms ”这样的方式来设定时延 SLO。
如果采用平均响应时间来计算，可能出现业务逻辑执行失败时间很短，或者是1ms执行完成但是出现404的状态，从可用性角度来说这种请求是执行失败的，但是如果统计平均响应时间他就会拉低整个响应时间。
当然也会出现某几次请求因为不同原因导致延时比较高，但是大多数请求延时较低，这样延时高的这几次请求就会被平均掉，单纯从平均值来看就没有异常，但是实际来说用户体验非常差。所以我们采用数据计数法是比较合理的。
因为不排除很多请求从业务逻辑层面是不成功的，这时业务逻辑的处理时长就会非常短（可能 10ms），或者出现 404 这样的状态码（可能就 1ms）。从可用性来讲，这些请求也算成功，但是这样的请求会拉低整个均值。
4）Errors- 错误率
错误率的指标主要是针对HTTP状态码来进行统计，除去我们日常使用比较多的5xx之外，还需要将4xx的一起统计，站在业务和用户体验角度，4xx太多也是对用户有很对影响的。
当然这里也可以自定义一些状态码，来定义那些状态对业务是有问题的或者是影响用户体验的。自定义的状态码不需要是系统错误，任何对用户体验和业务有影响的都可以定义。
5）Tickets- 人工介入
是否需要人工介入？
如果一项工作或任务需要人工介入，那说明一定是低效或有问题的。举一个我们常见的场景：
  • 数据任务跑失败了，但是无法自动恢复，这时就要人工介入恢复；或者超时了，也需要人工介入，来中断任务、重启拉起来跑等等。
Tickets 的 SLO 可以想象成它的中文含义：门票。一个周期内，门票数量是固定的，比如每月 20 张，每次人工介入，就消耗一张，如果消耗完了，还需要人工介入，那就是不达标了。
Google 提供的，基于 VALET 设计出来的 SLO 的 Dashboard 样例：
三

SLO计算

计算逻辑是通过配置良好时间数和总事件来区分良好事件和失败事件。使用良好事件的总和除以一段时间内事件总数的总和来计算SLI。可以将所有的指标都配置SLO，包括从 APM 调用链生成的指标、RUM 事件、指标采集的和日志生成的自定义指标。
设置时间窗口和目标百分比，时间窗口支持设置7天、30天、90天，目标百分比最多允许小数点后三位：
3.1 相关指标定义
  • <前缀>_sli_good_events（良好事件数）
    根据SLI指标配置的良好事件数的计算公式得出最终的值。
  • <前缀>_sli_total_events（总事件数）
    根据SLI指标配置中的总事件数的计算公式得出最终的值。
  • <前缀>_sli_current_rate（当前百分比）
  • <前缀>_sli_error_budget_rate（错误预算）【不生成指标】
  • <前缀>_sli_error_budget_left（剩余错误预算）
  • <前缀>_sli_burn_rate（燃烧率）
  • <前缀>_sli_error_budget_time （错误预算时间）

3.2 SLO度量周期
下面是Google定义的标准：
  • 汇总间隔
    每一分钟汇总一次。
  • 汇总范围
    集群中的全部任务。
  • 度量频率
    每10秒一次。
  • 包含哪些请求
    从黑盒监控任务发来的 HTTP GET请求。
  • 数据如何获取
    通过监控系统获取服务器端信息得到。
  • 数据访问延迟
    从收到请求到最后一个字节被发出。
但是我们在真实实践过程中可能达不到10s一次的指标采集，所以我们一般的SLO计算周期都以指标的采集周期去灵活判断，将指标度量周期在5分钟以下的以5分钟为周期去计算SLO，大于5分钟小于10分钟的以10分钟为周期计算SLO。按照这样的规则在生产中可以达到准实时计算SLO。
四

SLO燃烧率

燃烧率是Google 创造的一个无单位值，表示相对于 SLO 的目标长度，是指错误预算的消耗速度，它帮助我们了解错误预算是否在预期时间内被消耗完。对于给定的SLO周期（如30天），我们需要考虑该周期内允许的错误时间。
当设定了99.9%的SLO，30d窗口的错误预算，基准错误率：0.1%，这个时候的燃烧率就是默认的1；当错误率达到1%，燃烧率为10，他是咋计算出来的呢，就是：
SLO周期内允许的错误时间：
假设SLO目标是99.9%，这意味着在一个30天的周期内，允许的错误预算时间为：
换算为分钟：
五

SLO展示

5.1 SLO示例图
5.2 SLO状态更正
状态更正允许您从 SLO 状态和错误预算计算中排除特定时间段，也就是设置维护周期：
  • 防止预期的停机时间（例如计划维护）耗尽您的错误预算；
  • 忽略非工作时间，在这些时间里，你不需要遵守你的 SLO；
  • 确保部署导致的临时问题不会对 SLO 产生负面影响。

END


本文作者：邸仁杰(上海新炬中北团队）

本文来源：“IT那活儿”公众号

百分比可用性sli时间计算
文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论