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

Johnny21 等级 313 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
运维监控系统——Zabbix简介
前言对于运维人员来说,监控是非常重要的,因为如果想要保证线上业务整体能够稳定运行,那么我们则需要实时关注与其相关的各项指标是否正常,而一个业务系统的背后,往往存在着很多的服务器、网络设备等硬件资源,如果我们想要能够更加方便的、集中的监
运维安全-信息安全
本文转自 ,如有侵权,请联系删除。
深度剖析什么是 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)
数据库运维做些什么?
一. 数据库生命周期 结合软件生命周期、项目的开展,数据库的生命周期大致可分为这么几个阶段。 (https://imghelloworld.osscnbeijing.aliyuncs.com/8552b8c2942bb8ce23
DevOps简介
DevOps 是一个完整的面向IT运维的工作流,以 IT 自动化以及持续集成(CI)、持续部署(CD)为基础,来优化程式开发、测试、系统运维等所有环节。DevOps的概念DevOps一词的来自于Development和Operations的组合,突出重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
DevOps概述
DevOps概述DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营(运维)、质量保障(测试)(QA)部门之间的沟通、协作与整合。随着业务复杂化和人员的增加,开发人员和运维人员逐渐演化成两个独立的部门,他们工作地点分离,工具链不同,业务目标也有差异,这使
基于k8s的DevOps实践之路
原标题:基于k8s的DevOps实践之路很多快速发展的公司都面临着一个巨大挑战:在需求不断动态横向扩容的同时继续保持系统的高可用性。如何有效解决这一问题,Kubernetes(k8s)应运而生。k8s以运行可扩展工作负载而闻名,它可以根据资源使用情况调整工作负载。白山科技云分发团队基于多年的DevOps实践经验,在白山会运维日第三期与Thoughtworks
如何基于K8s构建下一代DevOps平台?
如何基于K8s构建下一代DevOps平台?发布时间: 20082715:41阿里妹导读:OAM是阿里巴巴与微软联合推出的开放应用模型,旨在解耦应用研发、应用运维与基础设施人员在应用生命周期中各自的关注点,明晰责任与界限,聚焦自身业务,同时又依然能紧密协作。当前云原生DevOps体系现状如何?面临哪些挑战?如何通过
SRE和DevOps值得关注的十大开源项目
构建可扩展且高度可靠的软件系统是每个SRE的最终目标。在SRE/DevOps领域中,有大量出色的开源项目,每个项目都有新颖而激动人心的解决方案。在本文中,我们将会介绍一些在监视,部署和维护领域最受欢迎的开源项目。 1\. Cloudprober可以主动跟踪和监视应用程序,并帮助你提前发现故障。它使用“活动(active)”监视模型来检查你的组件是否按预
运维大佬嘲笑我,这个你都不知道?
大家好,我是阿沐,一个喜欢分享技术而且爱好写散文的程序员。今天来给大家介绍一下info命令查看redis具体的详细信息讲解!起因是:前几年我在老家郑州实习面试(那个时候还没有毕业)的时候遇到面试官提问;面试官来于百度总部的工程师6年java开发经验+3年多的PHP开发经验,我在他的面前基本就是弟弟中的弟弟,虽然勉强通过入职了,但是却被运维无情地嘲笑,就因为组