主页

索引

模块索引

搜索页面

SLA

• SLA: Service Level Agreement(服务等级协议)

• SLI: Service Level Indicator(服务等级对象)

• SLO: Service Level Objective(服务等级目标)

SLA

SLI 是经过仔细定义的测量指标，它根据不同系统特点确定要测量什么，SLI 的确定是一个非常复杂的过程。

SLI 的确定需要回答以下几个问题:

要测量的指标是什么？
测量时的系统状态？
如何汇总处理测量的指标？
测量指标能否准确描述服务质量？
测量指标的可靠度 (trustworthy)？

常见的测量指标有以下几个方面:

1. 性能
响应时间 (latency)
吞吐量 (throughput)
请求量 (qps)
实效性 (freshness)
2. 可用性
运行时间 (uptime)
故障时间 / 频率
3. 可靠性
质量
准确性 (accuracy)
正确性 (correctness)
完整性 (completeness)
覆盖率 (coverage)
相关性 (relevance)
4. 内部指标
队列长度 (queue length)
内存占用 (RAM usage)
5. 因素人
响应时间 (time to response)
修复时间 (time to fix)
修复率 (fraction fixed)

下面通过一个例子来说明一下：hotmail 的 downtime SLI:

错误率 (error rate) 计算的是服务返回给用户的 error 总数
如果错误率大于 X%，就算是服务 down 了，开始计算 downtime
如果错误率持续超过 Y 分钟，这个 downtime 就会被计算在内
间断性的小于 Y 分钟的 downtime 是不被计算在内的。

测量时的系统状态，在什么情况下测量会严重影响测量的结果:

测量异常 (badly-formed) 请求，还是失败 (fail) 请求还是超时请求 (timeout)
测量时的系统负载（是否最大负载）
测量的发起位置，服务器端还是客户端
测量的时间窗口（仅工作日、还是一周 7 天、是否包括计划内的维护时间段）

如何汇总处理测量的指标:

计算的时间区间是什么：是一个滚动时间窗口，还是简单的按照月份计算
使用平均值还是百分位值，比如：某服务 X 的 ticket 处理响应时间 SLI 的
测量指标：统计所有成功解决请求，从用户创建 ticket 到问题被解决的时间
怎么测量：用 ticket 自带的时间戳，统计所有用户创建的 ticket
什么情况下的测量：只包括工作时间，不包含法定假日
用于 SLI 的数据指标：以一周为滑动窗口，95% 分位的解决时间

测量指标能否准确描述服务质量:

性能：时效性、是否有偏差
准确性：精度、覆盖率、数据稳定性
完整性：数据丢失、无效数据、异常 (outlier) 数据

SLO

SLO (服务等级目标) 指定了服务所提供功能的一种期望状态。SLO 里面应该包含什么呢？所有能够描述服务应该提供什么样功能的信息。 服务提供者用它来指定系统的预期状态；开发人员编写代码来实现；客户依赖于 SLO 进行商业判断。SLO 里没有提到，如果目标达不到会怎么样。

SLO 是用 SLI 来描述的，一般描述为:

如:
每分钟平均 qps > 100k/s
99% 访问延迟 < 500ms
99% 每分钟带宽 > 200MB/s

设置 SLO 时的几个最佳实践:

指定计算的时间窗口
使用一致的时间窗口 (XX 小时滚动窗口、季度滚动窗口)
要有一个免责条款，比如：95% 的时间要能够达到 SLO

SLA

SLA 是一个涉及 2 方的合约，双方必须都要同意并遵守这个合约。当需要对外提供服务时，SLA 是非常重要的一个服务质量信号，需要产品和法务部门的同时介入。

SLA 是一个很好的工具，可以用来帮助合理配置资源。一个有明确 SLA 的服务最理想的运行状态是：增加额外资源来改进系统所带来的收益小于把该资源投给其他服务所带来的收益。

一个简单的例子就是某服务可用性从 99.9% 提高到 99.99% 所需要的资源和带来的收益之比，是决定该服务是否应该提供 4 个 9 的重要依据。

参考

• 深度剖析什么是 SLI、SLO 和 SLA: https://www.cnblogs.com/itcomputer/p/7138655.html

主页

索引

模块索引

搜索页面