SRE中的SLA/SLO/SLI

Posted 2023-04-19

SLA通俗理解

SLA 表征服务方与客户间的服务等级协议，定义服务方需保证的服务质量以及不达标情况下的服务补偿，在SRE领域，SLA 细分为 SLI、SLO 与 SLA：

• SLI，服务质量指标，服务的某项质量的一个具体的量化指标，如时延、吞吐量、错误率等。
• SLO，服务质量目标，服务的某项 SLI 的具体目标值，或者目标范围，如 99% 访问延迟 < 500ms。
• SLA，服务质量协议，描述在服务不达 SLO 情况下的后果，可简单理解为 “SLA = SLO + 后果（惩罚）”。

由于SLA是交付给客户的协议，因此 SLA 中的 SLO 是需要可直观被用户感知的，直接影响用户体验的，这是 SLA 隐含的应有之义。

 

因此，计算 SLA 主要在于定义服务不同维度的 SLI，根据不同 SLI 设计合理 SLO，并经时间段采集、计算汇总得出每个 SLO 不达标时间，进而计算服务所有 SLO 总的不可用时间，利用总时间与所有 SLO 不可用时间差值与比值，得出服务最终的 SLO。

SLO 计算模型

对于大多数服务而言，表述服务可用性最直接的方式可能就是服务可用时间。在这种体系下，常说的99.9%，99.99%，99.999%的可用性都是时间维度的统计，可以理解为：在规定的条件和规定的时间内，完成规定任务的概率。基于时间的可用性有如下表述形式：

可用性 = 系统正常运行时间 / 统计周期内的总时间

 

同时为了避免选择过大的时间窗口会平滑可用性计算，无法准确表现某个时间段服务的状态，因此将时间窗口缩小到秒级，定义在每个小时间片内的成功率要求，如果达标则认为该时间片可用，那么可用性又可以有如下表述形式：

可用性 = 系统达标时间 / 统计周期内的总时间

 

时间窗口越小越精确，这其实是一个积分运算，窗口越小越能准确表现总体趋势，但也需权衡数据分析性能与准确性，常用时间窗口1min

看一个示例：

 

SLO1 = 1 - T2/(T1+T2+T3+T4)
 
SLO2 = 1 - T3/(T1+T2+T3+T4)

 

根据每个指标的 SLO 结果聚合出服务的总体 SLO：

SLO = 1 - (T2+T3)/(T1+T2+T3+T4)

 

 

开放服务 SLA 建设

问题定义

1. 如何定义开放服务的 SLI、SLO，是否能基本表征服务质量？
2. 采集对应 SLO 所需元数据并计算
3. SLO 不达标时，快速定位原因，并驱动服务质量提升

 

服务SLI

衡量服务有多个维度：性能（响应时间）、可用性（成功率）、自定义业务指标（任务队列排队数）等，每个维度又有多个指标，针对开放服务需挑选直接与用户使用相关的指标、下游对服务的依赖能力等。

服务重点关注性能和可用性，结合集团内部其他衡量案例，采用 可用率（失败率）和响应时间作为SLI。

可用率

可用率不是成功率，有很多请求失败是客户端传参失效、登录态超时导致，HttpCode 以 4xx 标识。可用率可用公式

available = count(2XX) / (count(2XX) + count(5XX) - count(noise))

 

额外说明：

计入开放服务 SLO 的特殊情况：

• 网关等待服务响应超时（10s）会返回给客户端 503，这是 网关层做的安全管控，可理解为：服务性能问题、网络故障、服务故障等，这部分会记入开放服务 SLO
• 开放接口转发规则配置出错导致503，后期网关可在开放接口发布流程上做强管控尽可能避免此类问题发生
• 请求body过大（超过521KB）的拦截、大响应（超过2M）拦截

计入网关 SLO 的特殊情况：

• 网关认证中心错误，如超时、服务不可用

不计入 SLO 的特殊情况：

• 网关与服务长连接超时问题导致返回503，网关调用HTTP服务失败，这种情况一般是业务的HTTP长连接空闲配置与网关不一致导致, 网关为60秒空闲自动关闭连接，如果业务方服务的空闲时间小于60秒就会导致这个问题，原理参考：https://segmentfault.com/a/1190000021704869
• 限流（理论上是网关的保护逻辑，不应计算在可用率内），包括主动限流 + 被动限流，每个开放接口默认500QPS，超过即限流；提供业务侧主动限流，定向防刷

 

因此需消除已上噪音才能相对准确反应开放服务可用率。

响应时间

响应时间很大程度上代表服务性能，但由于不同服务不同接口的业务特点，如果强制划定所有接口 RT 需小于一定值则有失公允，因此基于分位数计算历史一个月服务的总体数据，eg: TP<90> < 275ms，近一个月百分之90的请求的 RT 在 275ms内，利用该值放缩至每个小时间片，时间片内每个接口 rt < 275 则符合要求，否则不满足。随着服务的分位数 TP<90> 的不断迭代，进而影响每个小时间片内的达标率，促使服务性能优化。 

响应时间采用如下策略：

1. 服务大盘使用历史 TP<90> 分位数作为标杆值，计算 SLO
2. 重点接口使用约定指标，限定计算

 

最后

基于服务每个月的 SLA，可总体了解服务的性能及稳定性。同时基于不满足 SLO 的时间片，通过 sls 关联分析以及网关日志回溯，找到影响指标的接口，每周生成报表推送给对应服务负责人进行整改。

开放服务 SLO 每周产出开放服务报表，把服务可靠性从经验模型向量化模型转移，对用户对服务方有明朗的价值。提供对应质量数据，同时针对一些指标的不足在保证最优 ROI 下去解决导致质量下降的根因，进而优化服务。

 

附件：

草拟网关服务的 SLA：

网关服务等级协议

本服务等级协议（Service Level Agreement，简称 “SLA”）规定了网关向客户提供的 API 网关的服务可用性等级指标及赔偿方案。

20xx年xx月xx日起生效。

1. 定义

服务周期：服务可用性按服务周期统计，一个服务周期为一个自然月，如客户使用不满一个月则以当月使用累计使用时间作为一个服务周期。

有效请求：网关接收到的所有请求，视为有效请求。

失败请求：由于网关原因造成的 API 调用失败，则视为失败请求但不包括以下情况的调用失败：

(1)因用户配置问题导致的 API 调用失败；

(2)客户的应用程序受到黑客攻击或者主动流量攻击而导致被网关限制的请求。

(3)因用户登录态失效导致的 API 调用失败；

当出现网关故障无法通过获得失败请求数时，将通过计算前7个自然日用户每分钟请求数的平均值，用该平均值乘以故障时间，从而计算出该情况下的失败请求数。

每15秒错误率：以15秒为单位按照如下方式计算错误率：

每15秒错误率=每15秒失败请求数/每15秒有效总请求数x100%

月度服务费用：客户在一个自然月中就API网关服务所支付的服务费用总额。以代金券结算不计入月服务费用。

2. 服务可用性

2.1 服务可用性计算方式

网关的服务可用性按服务周期统计，通过计算服务周期内每15秒错误率的平均值，从而计算得出服务可用性，即：

服务可用性=（1-服务周期内Σ每15秒错误率/服务周期内15秒总个数）x1

（注：服务周期内15秒总个数=4 x 60 x 24 x 该服务周期的天数）

2.2 服务可以用性承诺

对于网关，承诺一个服务周期内的服务可用性见下表：

服务类型	服务可用性
网关代理服务	不低于99.90%

如网关未达到上述可用性承诺，客户可以根据本协议第3条约定获得赔偿。赔偿范围不包括以下原因所导致的服务不可用：

（1）预先通知用户后进行系统维护所引起的，包括割接、维修、升级和模拟故障演练；

（2）用户的应用程序或数据信息受到黑客攻击而引起的；

（3）用户维护不当或保密不当致使数据、口令、密码等丢失或泄漏所引起的；

（4）不可抗力以及意外事件引起的；

 

3. 赔偿方案

暂无

 

 

 

优维DevOps系列沙龙全回顾：DevOps+SRE落地实践+DevOps最后一棒

5月6日，优维科技和数人云联合主办的DevOps&SRE系列活动《DevOps&SRE 超越传统运维之道》在深圳顺利举行。

优维科技CEO王津银、数人云CEO王璞、腾讯SNG运维负责人梁定安分别分享了《DevOps与传统的融合落地实践及案例分享》《SRE在传统企业中的落地实践》《DevOps最后一棒，有效构建海量运营的持续反馈能力》，为大家带来了一场异彩纷呈的技术盛宴。

△场面爆满

除了DevOps、SRE相关的经验，还有具体落地的案例分享，会后大家都反馈收获满满，期待我们的下一次系列活动。在这里先做个小预告：DevOps&SRE系列活动北京站，将于6月10号与大家见面！

优维科技作为DevOps理念的践行者，除了我们的平台以外，还希望通过技术分享的方式让更多企业因DevOps理念受益，真正的为运维行业带来一些改变。

以下为现场回顾

DevOps与传统的融合落地实践及案例分享

△优维科技CEO王津银

演讲内容：主要分为以下三个部分，第一个是devops全局的理解以及DevOps与ITIL的对比融合，第二个是devops落地经验14则，第三个是德邦物流的案例分析。

DevOps落地经验14则

第一则：理念与价值先行，到底什么是理念什么是价值？

第二则：顶层设计与全局规划

第三则：Start Small，从小做起

第四则：构建IT元数据平台，驱动IT平台间整合。过去传动的平台为什么没有很好的应用起来，依然面向研发者管理、整个的交付过程，没有进入到IT运营，这里怎么样构建一个元数据平台。

第五则：痛苦的事情优先解决，这一点来源于持续交付的原则。

第六则：工具也是一种文化，人过分的强调驱动文化因素的时候，比如说把devops必须要把领导的思维改变，这一点非常的困难，能不能从实际的地方做起，比如说工具和工程师的文化推行，这里面讲的工具也是一种的文化。强调它的文化作用。

第七则：组织二元性，加强落地力。

第八则：价值拉动，而非事务驱动。更多是面向客户的价值。

第九则：平台+插件化=服务能力产品化，和组织一致。

第十则：自动化别人，先自动化自己，先把自己的能力自动化再插件化到上层平台去。

第十一则：持续交付是DevOps落地的最佳实践

第十二则： IT运营管理驱动Ops能力建设

第十三则：构建面向应用的最强管理驱动力。

第十四则：构建指标，驱动DevOps落地

以上是王津银关于DevOps实践的一些具体经验分享，随后结合物流行业案例进行进一步讲解。

演讲实录敬请期待我们的后续文章

SRE在传统企业中的落地实践

△数人云CEO王璞

演讲内容：Google的SRE是DevOps思想在运维方面的具体实践。本次介绍了SRE理念、传统运维模式与SRE的区别、SRE落地实践的关键点以及具体的落地实践案例分析。

SRE落地的关键点：

1）建立体系化平台；平台和工具实现自动化、自助化；平台和工具落地各项规章管理制度。

2）容量规划与容量管理

3）保障SLO并最大化迭代速度

4）建立有效监控，谷歌内部对监控尤其是对报警及其的严格的，每一个报警出来必须有明确的动作。三种有效的输出：告警、工单、日志。

以上王璞所提到SRE落地实践的关键点，都是在谷歌得到了很好的落地，同样在其他企业也能进行借鉴参考。

演讲实录敬请期待我们的后续文章

DevOps最后一棒，有效构建海量运营的持续反馈能力

△腾讯SNG负责人梁定安

演讲内容：以腾讯运维团队打造的业务监控和指标度量体系为背景，解读大规模技术运营场景下，实现业务质量持续反馈的方法和技巧。

对于运维团队而言，持续反馈意味着什么？要做好监控、告警和运营，大梁认为这3点是缺一不可的。其中运营很重要，通过运营可以把一些我们想做好，但是需要其他团队或角色协同我们完成的事情，落实下去，推进执行好，这点很DevOps。

持续反馈于运维的理解

1）监控（覆盖率、状态反馈、指标度量）

2）告警（时效性、准确性、触及率）

3）运营（RCA、事件管理、报表／考核）

本次演讲大梁重点要跟大家分享的另一内容，在腾讯做海量监控数据分析的技巧：

1）溯源（多维分析、级联分析）

2）根因（递进收敛、ROOT）

3）优选（DLP、舆情分析）

感谢各位讲师的精心筹备，感谢各位到场嘉宾的大力支持，优维科技将带着DevOps管理专家的使命，分享最新的技术理念、DevOps实践经验。希望更多的企业能因DevOps而受益。

演讲实录敬请期待我们的后续文章