SLA通俗理解
SLA 表征服务方与客户间的服务等级协议，定义服务方需保证的服务质量以及不达标情况下的服务补偿，在SRE领域，SLA 细分为 SLI、SLO 与 SLA：
- SLI，服务质量指标，服务的某项质量的一个具体的量化指标，如时延、吞吐量、错误率等。
- SLO，服务质量目标，服务的某项 SLI 的具体目标值，或者目标范围，如 99% 访问延迟 < 500ms。
- SLA，服务质量协议，描述在服务不达 SLO 情况下的后果，可简单理解为 “SLA = SLO + 后果（惩罚）”。
由于SLA是交付给客户的协议，因此 SLA 中的 SLO 是需要可直观被用户感知的，直接影响用户体验的，这是 SLA 隐含的应有之义。
文章来源：https://www.toymoban.com/news/detail-418440.html
因此，计算 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 建设
问题定义
- 如何定义开放服务的 SLI、SLO，是否能基本表征服务质量？
- 采集对应 SLO 所需元数据并计算
- 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> 的不断迭代，进而影响每个小时间片内的达标率，促使服务性能优化。
响应时间采用如下策略：
- 服务大盘使用历史 TP<90> 分位数作为标杆值，计算 SLO
- 重点接口使用约定指标，限定计算
最后
基于服务每个月的 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. 赔偿方案
暂无
文章来源地址https://www.toymoban.com/news/detail-418440.html
到了这里，关于SRE中的SLA/SLO/SLI的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
