谷歌SRE理论读书札记:SLI、SLO与SLA

Johnny21 等级 937 0 0

趁着这被人扫地出门,无地可去的日子,多学习学习别人的理论知识。
书籍名 《Site Reliability Engineering》网络运维工程,编者Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy

第二部分 规则(Principles)

第四章 Service Level Objects

如果你不知道哪些行为对服务有关键影响(无论积极还是消极),那么你就不可能正确地去管理好这个应用。那么为了衡量行为的程度,我们的服务需要一些指标,如果有人调用我们的服务,那他们也应该熟悉这些指标。
这里我的理解是,比如别人调用我的接口去操作一台网络设备,执行了某个命令。这就是一个行为,但是我们对于这个行为,应该有一些具体的数字进行描述

谷歌SRE在这里定义了三个名词,分别是:
SLIs、SLOs、SLAs,这里SL是 srvice level,服务级别,而I O A分别是 indicator、object与agreement
这些名词和指标建模、选择、分析息息相关。(这里的指标,就是metric,就是我们现在监控系统所采集的对象),SRE中有个原则是“简单”,所以在监控系统中选择要关注哪些指标是非常重要的,我们既需要这些指标能比较全面、客观地反馈服务的状况,又必须尽可能压缩监控指标的数目(特别接触了对几千台物理设备的监控系统后,我深有体会,每多一个指标,在生产环境是需要multiply几千的)
SLI就是服务状况体现最直观的数字,比如:
request latency 请求延迟(提一嘴,latency这个常见指标,很多时候是从服务端测获取到的,其实不见得能反应服务的真实延迟状况)
error rate 错误率(SRE说,别只统计成功的request数)
system throughput(这个有点意思,按照字面意思,是系统生产力。如果目前系统在服务1000个人,能说系统的生产力很高吗?或许但不一定,因为很可能虽然在服务1000个人,创建了2000个连接,但却没做什么事情。而如果从反馈数据的带宽,是否比前面的连接数更能说明系统的“生产力”呢?)
当然还有一种SLI对于SRE很重要,那就是 n个9 的服务可用性

SLO
SLO是一组值的范围,这个值就是由SLI定义的服务级别数值。自然的SLO定义就是,某SLI在正常情况下需要小于某值或者处于某个大小值之间。
选择一个合适的SLO并不是一件容易的事情,当然你并不需要一开始就设定好这个范围,比如说QPS,这个指标取决于你的用户,而你是无法预先做出判断的。(比如运维平台上线了某个服务,你可能预测这服务最后每天的使用量能达到100次,但实际并没人用,因为可能用户都不知道有这么一项功能)
确定一个SLO,和服务怎样运行也有关系(how service to perform)

SLA
服务级别的协议,可能是明确的协议,也可能是不明确的(implicit,比如约定俗成的、没有纸面协定)
这种协定可能是,如果服务失效、或者达不到预期的效果,该怎样做。一般是赔偿、退款,当然也有其他形式。一般来说,SRE是不参与SLA的制定,因为SLA更靠近商务层面或者产品设计层面。
比如谷歌搜素这项服务,并没有暴露给用户的SLI,但是却有和全世界都签订协议,也就是SLA。(你注册谷歌账号时,一大堆的文字)

SLI实践

了解你的用户关心什么

你不需要把监控系统中每个metric都视为SLI,选择尽可能少的SLI,但这些SLI却能说明服务是否健康。这些SLI应该:
用户侧系统(user-facing serving systems):可用性(a)延迟(latency)服务生产力(throughput)。换句话说:服务能响应用户的请求吗?响应要耗时多久?我们能处理多少请求?(个人心得:很多时候,我们喜欢在监控系统的dashboard上把agent获取到的数据全都摆上去,看起来很高大上,但却连服务“能”处理多少请求都无法了解,这里能处理多少请求从另外一个角度讲就是服务的饱和度)
存储系统(storage systems):延迟,可用性和持久性。换句话说:成功写数据需要多久?是否能正确获取到想要的数据?当我们需要这个数据时它是否还在那儿(这应该指的是缓存)
大数据系统(big data systems):对于数据处理管道(data processing pipeline),就需要去关注生产力与端对端的延迟(end-to-end latency)换句话说:有多少数据被处理?从获取数据到处理完成耗时多少?
对于所有系统,还需要关注正确度(correctness):服务返回的是否是正确的数据?正确度是关注服务健康的重要的SLI

收集indicators

我们绝大多数情况都是从服务侧收集的,比如使用borgmon或prometheus,但是我们也应该关注用户侧的指标收集。

聚合

本文转自 https://www.jianshu.com/p/a9e0cd4c55b4,如有侵权,请联系删除。

收藏
评论区

相关推荐

头条研发-SRE运维研发实习生视频面试(一, 二面)
(about:blank%E4%B8%80%E9%9D%A230min "一面 (30min)")一面 (30min) 江湖规矩自我介绍, 很罕见的没有用算法题起手, 直接就问很具体的问题, 点个赞 <3 (htt
SLI、SLO和SLA,这次终于搞明白了
前言 SLO和SLA是大家常见的两个名词:服务等级目标和服务等级协议。 云计算时代,各大云服务提供商都发布有自己服务的SLA条款,比如Amazon的EC2和S3服务都有相应的SLA条款。这些大公司的SLA看上去如此的高达上,一般是怎么定义出来的呢?本文就尝试从技术角度解剖一下SLA的制定过程。 说SLA不能不提SLO,这个是众所周知的,但是还有一
《Google SRE》读后感
注:从我的知乎搬移过来,方便管理,link:《Google SRE》读后感(https://link.jianshu.com/?thttps://zhuanlan.zhihu.com/p/22912741?group_id815131133242134528) (https://imghelloworld.osscnbeijing.a
我们离Google SRE还有多远?
经过几年的挣扎和讨论(确切说应该是3年),老板在钉钉群以通告的方式正式告别伴随我们多年的职业Title PE,改名为SRE。(后续以A SRE区别Google SRE) (https://imghelloworld.osscnbeijing.aliyuncs.com/188fb7b287badee91332a9f90c3af347.p
深度剖析什么是 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)
SRE和DevOps值得关注的十大开源项目
构建可扩展且高度可靠的软件系统是每个SRE的最终目标。在SRE/DevOps领域中,有大量出色的开源项目,每个项目都有新颖而激动人心的解决方案。在本文中,我们将会介绍一些在监视,部署和维护领域最受欢迎的开源项目。 1\. Cloudprober可以主动跟踪和监视应用程序,并帮助你提前发现故障。它使用“活动(active)”监视模型来检查你的组件是否按预
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
Google SRE之后的CRE,一起来看看吧
![](https://oscimg.oschina.net/oscnet/5bf875465af5c15f36554f995a073bc2998.jpg) 去年10月份,也就是2016年10月份,Google Cloud Platform Blog上更新了一篇文章,Google宣布了一个新的专业岗位,CRE,Customer Reliabilit
Serverless解决方案,与传统和容器化应用的不同之处
![](https://oscimg.oschina.net/oscnet/53406a59-99f1-41b4-9763-436be0d502bf.gif) 无服务架构(Serverless)和DevOps、SRE、微服务、容器等一样,是最近两年比较新兴的概念,数人云之前给大家分享过[《Serverless用这5大优势,挽救了后来7亿用户的I
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)的追求,对于业务系统的掌控度的要求越来越高,主要体现在: * 对于第三方依赖的监控,实时/准实时了解第三方的健康状况/服务品质,降低第三方依赖对于自身系统的扰动(服务降级、故障转移) *