深度剖析什么是 SLI、SLO和SLA?

Johnny21 等级 1360 0 0

前言

SLO和SLA是大家常见的两个名词:服务等级目标和服务等级协议。

云计算时代,各大云服务提供商都发布有自己服务的SLA条款,比如Amazon的EC2和S3服务都有相应的SLA条款。这些大公司的SLA看上去如此的高达上,一般是怎么定义出来的呢?本文就尝试从技术角度解剖一下SLA的制定过程。

说SLA不能不提SLO,这个是众所周知的,但是还有一个概念知道的人就不多了,那就是SLI(Service Level Indicator),定义一个可执行的SLA,好的SLO和SLI是必不可少的。

再有就是SLI/SLO/SLA都是和服务联系在一起的,脱离了服务这三个概念就没有什么意义了。

Service

什么是服务?

简单说就是一切提供给客户的有用功能都可以称为服务。

服务一般会由服务提供者提供,提供这个有用功能的组织被称为服务提供者,通常是人加上软件,软件的运行需要计算资源,为了能对外提供有用的功能软件可能会有对其他软件系统的依赖。

客户是使用服务提供者提供的服务的人或公司。

SLI

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

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

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

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

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

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

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

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

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

3. 如何汇总处理测量的指标?

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

4. 测量指标能否准确描述服务质量?

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

5. 测量指标的可靠度

  • 是否服务提供者和客户都认可
  • 是否可被独立验证,比如三方机构
  • 客户端还是服务器端测量,取样间隔
  • 错误请求是如何计算的

SLO

SLO(服务等级目标)指定了服务所提供功能的一种期望状态。SLO里面应该包含什么呢?所有能够描述服务应该提供什么样功能的信息。

服务提供者用它来指定系统的预期状态;开发人员编写代码来实现;客户依赖于SLO进行商业判断。SLO里没有提到,如果目标达不到会怎么样。

SLO是用SLI来描述的,一般描述为:
比如以下SLO:

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

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

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

如果Service是第一次设置SLO,可以遵循以下原则

  • 测量系统当前状态
    • 设置预期(expectations),而不是保证(guarantees)
    • 初期的SLO不适合作为服务质量的强化工具
  • 改进SLO
    • 设置更低的响应时间、更改的吞吐量等
  • 保持一定的安全缓冲
    • 内部用的SLO要高于对外宣称的SLO
  • 不要超额完成
    • 定期的downtime来使SLO不超额完成

设置SLO时的目标依赖于系统的不同状态(conditions),根据不同状态设置不同的SLO:总SLO = service1.SLO1 weight1 + service2.SLO2 weight2 + …

为什么要有SLO,设置SLO的好处是什么呢?

  • 对于客户而言,是可预期的服务质量,可以简化客户端的系统设计
  • 对于服务提供者而言
    • 可预期的服务质量
    • 更好的取舍成本/收益
    • 更好的风险控制(当资源受限的时候)
    • 故障时更快的反应,采取正确措施

SLO设好了,怎么保证能够达到目标呢?
需要一个控制系统来:

  • 监控/测量SLIs
  • 对比检测到的SLIs值是否达到目标
  • 如果需要,修证目标或者修正系统以满足目标需要
  • 实施目标的修改或者系统的修改

该控制系统需要重复的执行以上动作,以形成一个标准的反馈环路,不断的衡量和改进SLO/服务本身。

我们讨论了目标以及目标是怎么测量的,还讨论了控制机制来达到设置的目标,但是如果因为某些原因,设置的目标达不到该怎么办呢?

也许是因为大量的新增负载;也许是因为底层依赖不能达到标称的SLO而影响上次服务的SLO。这就需要SLA出场了。

SLA

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

SLA用一个简单的公式来描述就是: SLA = SLO + 后果

  • SLO不能满足的一系列动作,可以是部分不能达到
    • 比如:达到响应时间SLO+未达到可用性SLO
  • 对动作的具体实施
    • 需要一个通用的货币来奖励/惩罚,比如:钱

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

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

原文:http://www.cnblogs.com/itcomputer/p/7138655.html

本文转自 https://blog.csdn.net/eurus_5bb67476/article/details/77371654,如有侵权,请联系删除。

收藏
评论区

相关推荐

SLI、SLO和SLA,这次终于搞明白了
前言 SLO和SLA是大家常见的两个名词:服务等级目标和服务等级协议。 云计算时代,各大云服务提供商都发布有自己服务的SLA条款,比如Amazon的EC2和S3服务都有相应的SLA条款。这些大公司的SLA看上去如此的高达上,一般是怎么定义出来的呢?本文就尝试从技术角度解剖一下SLA的制定过程。 说SLA不能不提SLO,这个是众所周知的,但是还有一
深度剖析什么是 SLI、SLO和SLA?
前言SLO和SLA是大家常见的两个名词:服务等级目标和服务等级协议。云计算时代,各大云服务提供商都发布有自己服务的SLA条款,比如Amazon的EC2和S3服务都有相应的SLA条款。这些大公司的SLA看上去如此的高达上,一般是怎么定义出来的呢?本文就尝试从技术角度解剖一下SLA的制定过程。说SLA不能不提SLO,这个是众所周知的,但是还有一个概念知道的人
谷歌SRE理论读书札记:SLI、SLO与SLA
趁着这被人扫地出门,无地可去的日子,多学习学习别人的理论知识。 书籍名 《Site Reliability Engineering》网络运维工程,编者Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy第二部分 规则(Principles)
APM监控
一,基础知识储备 分布式跟踪的目标 一个分布式系统由若干分布式服务构成,每一个请求会经过多个业务系统并留下足迹,但是这些分散的数据对于问题排查,或是流程优化都很有限,要能做到追踪每个请求的完整链路调用,收集链路调用上每个服务的性能数据,计算性能数据和比对性能指标(SLA),甚至能够再反馈到服务治理中,那么这就是分布式跟踪的目标。 分布式跟踪的目的
HADOOP性能优化和运维
集群中任意一个节点都可以被用来提交认任务,虽然通常我们使用master节点提交任务。HADOOP客户端不参与计算和存储,专门用来上传下载文件和提交任务。 性能优化4大块: ![](https://static.oschina.net/uploads/space/2017/0406/111251_QSBe_192561.png) 具体优化如下: 1.选
SLA 4 个 9 ,贝壳高可用架构的质量保障体系
导语 | 贝壳用户需求和用户量的不断增长,对系统的高可用性提出了更高的要求,服务端的质量保证工作该如何开展?本文是对贝壳找房-基础平台中心-质量平台赋能部总监——项旭老师在云+社区沙龙online的分享整理,分享一些关于架构的新思想,希望与大家一同交流。 _[点击视频查看完整直播回放~](https://www.oschina.net/action/GoT
SLA可用性好几个9的阿里云怎么又宕机了?
**官方给出的回应说会按协议尽快赔偿,** **按云服务器 ECS 服务等级协议** **:**[http://terms.aliyun.com/legal-agreement/terms/suit\_bu1\_ali\_cloud/suit\_bu1\_ali\_cloud201802011632\_33742.html?spm=a2c4g.111866
IT设备服务监控的方法论
有方法论提导,在技战术方面才不会偏离目录。 使用服务级别作为关键语,召示着承诺和责任。 https://www.circonus.com/2018/06/comprehensive-container-based-service-monitoring-with-kubernetes-and-istio/ \=======================
Azure Cosmos DB 中 Document API Repository 的实现
_阅读 需要大约  5 分钟。_ **前景:** **Azure Cosmos DB** 由 Microsoft 提供,是**全球分布式多模型数据库**。 通过 Azure Cosmos DB 跨任意数量的 Azure 地理区域弹性且独立地缩放吞吐量和存储。 它通过综合[服务级别协议](https://www.oschina.net/action/Go
Linux 运维是做什么的
![](https://oscimg.oschina.net/oscnet/up-25a98115c12319b11895484bc9dd5ecd170.png) Linux在现在社会发展是非常受欢迎的一个行业,对于从事Linux方面工作的人来说,属于互联网背后的英雄,没有他们的付出,就没有如今的互联网时代。而在Linux从事岗位之中,Linux运维工程师
Linux运维常见面试题之精华收录
Linux运维常见面试题之精华收录 ================= **1、什么是运维?什么是游戏运维?** 1)运维是指大型组织已经建立好的网络软硬件的维护,就是要保证业务的上线与运作的正常, 在他运转的过程中,对他进行维护,他集合了网络、系统、数据库、开发、安全、监控于一身的技术 运维又包括很多种,有DBA运维、网站运维、虚
OpenShift应用发布和运维设计
![](https://oscimg.oschina.net/oscnet/ee3a439e79bf2eb38ec78ec9cc272d4c0c5.gif) ![](https://oscimg.oschina.net/oscnet/672fccee1f9485511b66a673a9facbb5423.jpg) **转载本文需注明出处:微信公众号EAW
SkyWalking6.2.0版本UI参数、告警参数、指标含义中文解释
一、告警规则相关参数 ========== ![](https://img2018.cnblogs.com/blog/285763/201911/285763-20191121191258744-1760167342.png)  二、SkyWalking UI相关参数 CPM:每分钟请求调用的次数 SLA: 服务等级协议(简称:SLA,全称:se
SkyWalking调研与初步实践
APM和调用链跟踪 --------- 随着企业经营规模的扩大,以及对内快速诊断效率和对外SLA(服务品质协议,service-level agreement)的追求,对于业务系统的掌控度的要求越来越高,主要体现在: * 对于第三方依赖的监控,实时/准实时了解第三方的健康状况/服务品质,降低第三方依赖对于自身系统的扰动(服务降级、故障转移) *
初识DevOps
作者:天翼云  研发一部  赵恒 基本概念和延伸的思考DevOps,是Development(开发)和Operations(运维)组成的复合词,一般译为“开发运维一体化”。看到这个概念,首先会产生几个问题:开发是什么,哪些环节是开发?运维是什么,哪些环节是运维?开发人员写好代码在本地调试,环境出问题了自己来调整,这是开发工作还是运维工作?系统故障后,运维人员