《SRE：Google运维解密》读后有感

最早接触到《SRE：Google运维解密》是在三年前，当时由于自身原因并未细细的阅读，对于书中的部分知识也是浅尝辄止，可能是因为当时爬的坑，摔的跤太少，对其并没有太深刻的理解，慢慢的就对其淡忘了许多。

近期技术委员会重提了这本书，我又细细的看了一遍，发现过去的三年我们竟然也是大差不差的在向其努力，但是就是缺乏一个体系化的思维，所以大家都有一种东一榔头西一棒槌的感觉，感觉做了些什么又感觉没做什么。

本书总共分为四部分：概览、指导思想、具体实践、管理。书中对于SRE做了如下的定义“SRE职业专注于整个软件系统的生命周期管理。从其设计一直到部署，历经不断改进，最后顺利退役，这样一种职业必须具备非常广泛的技能，但是和其他职业的专注点都不同。首先SRE是工程师，其次SRE 的关注焦点在于可靠性”。这一部分我谈谈我个人的理解，从书中的定义结合我个人的经验，SRE对于人员的要求的水平其实是非常高的，这种工作并不是一个平常的SaaS层开发可以胜任的岗位，它要求人员必须具备SaaS/PaaS/IaaS三层的经验，要有架构设计、软件开发、运营维护的知识，对于稳定性有自己的理解，如果一个系统上线之后，用户不能稳定的使用，那么就没有存在的意义，而SRE人员所要做的事情就是，用尽自己的所学，尽可能的让整个系统运行的更加可靠，更有效的利用资源，但是并不是说SRE人员要追求100%的稳定可靠，因为追求100%可靠，收益和付出比太低了。

书中从拥抱风险、服务质量目标、减少琐事、监控、发布、自动化、简单化提出了一系列的指导思想。个人认为其中最精华的部分就是提出了监控系统的4个黄金指标：延迟、流量、错误和饱和度。“延迟指的就是服务处理某个请求所需要的时间，流量指的是系统中的某个高层次的指标针对系统负载需求所进行的度量，错误指的是请求失败的速率，饱和度是指目前最为受限的某种资源的某个具体指标的度量”。此处谈谈我个人的理解，延迟这个概念比较好理解，但是需要注意一点的是将错误回复的延迟和正常回复的延迟区分开来，如果不区分开来，延迟低这个指标并没有什么实际的意义。关于流量这块说的比较拗口，其实可以做如下理解：如果是WEB那么就是每秒HTTP的请求数量，如果是文件服务器那就是网络I/O速率，针对数据库那么就是每秒读取操作数量。而错误这个指标重点需要注意的是隐式失败，比如说大家对于HTTP请求返回500的错误这种失败在监控的时候是肯定没有放过的，但是对于比如说HTTP请求返回为200但是错误包含在内部的这种隐式失败，关注度就不高了，但是往往真正的业务错误就是在这种隐式失败中蕴藏。要想监控到这种指标，就需要监控分析的程序对于程序的返回值做针对性的适配开发，以适配业务自身的状态码，其实在此处就引申出了，在一个公司内部统一状态返回码的重要性，更上一层就是标准化接口返回值格式，当此处统一之后，那么针对性的适配开发就变成了公司内部的一个公有的能力，避免了重复造轮子的尴尬。关于最后提出的饱和度的概念，首先就是需要得到一个系统的流量峰值，就拿单个WEB服务来说，需要首先通过各种手段获取到它处理请求的峰值，然后拿上面的流量比上这个峰值，来得到这个服务的峰值；此处其实不仅仅是单个服务的视角，更拔高一层就是系统的视角，抽出系统的核心服务，核心组件，计算饱和度，可以得到目前整个系统的饱和度，这个指标对于监控一段时间系统的正常运行有非常重要的意义。

书中第三部部分介绍到具体实践，个人觉得最关键的部分就是服务的可靠度层级模型：自底向上分别是：监控、应急事件处理、事后总结/问题根源分析、测试发布、容量规划、软件开发、产品设计。掌握了服务的可靠度层级模型就相当于有了稳定性保障的检查清单，当接手一个系统的时候，问一下自己：系统的监控是否覆盖了，是否遵循了四个黄金指标的要求？针对系统出现的问题，有没有应急事件处理流程，有没有应急预案？如果是个旧系统，有没有历史的故障记录与事后总结和问题根源分析？如果是个新系统有没有纳管接入公司内部的故障管理系统（业务连续性管理平台）？系统有没有标准化的测试发布流程？有没有针对性的增加稳定性相关的测试，保证软件在发布到生产环境中不会出现某些共性的通用性的问题？比如说：边界值导致的业务逻辑错误等共性问题？有没有针对系统做过容量规划，负载均衡体制能不能正确的使用服务这些容量？软件开发和产品设计中有没有遵循标准化的流程和框架？当我们进行体系化的思考的后，我们就会有新的收获，并且在解决方案上更加的完善。

书中第四部分主要介绍如何迅速培养SRE加入on-call,处理中断性任务，SRE与其他团队的沟通和协作，以及SRE参与模式的演进历程。这部分主要介绍管理方面的知识，但是我个人觉得其中很重要的一点就是关于三种参与模型的描述；简单PRR模型，早期参与模型，框架和SRE平台。框架和SRE平台这种模式，提供了很多的益处，比如说：显著的降低运维开销，因为它支持代码结构、依赖关系、测试、编码样式指南等的强合规性测试，内置服务部署、监控和自动化，设计中自带的通用性支持，这种在框架中把基于生产最佳实践的代码模式进行标准化封装，让SRE在管理时降低了认知的负担，同时仍然可以保持服务的质量，每一个标准框架都为问题所在的领域或者问题相关的基础设市以来提供了一个完整的解决方案。

这本书并不是停留在理论上的夸夸其谈，而是可以很容易被其他SRE团队重用的，本书出版于2016，至今已经有6个年头了，再回头看这本书的时候，我惊讶的发现，书中的理论和解决方案至今都适用，关于SRE的根本职责与主要关注重点近十年内基本保持不变的结论，个人觉得还是太保守了。

《SRE：Google运维解密》读后有感相关推荐

新生语不惊人死不休 —— 《无限恐怖》读后有感
开篇声明,我博客中"小心情"这一系列,全都是日记啊随笔啊什么乱七八糟的.如果一不小心点进来了,不妨直接关掉.我自己曾经写过一段时间的日记,常常翻看,毫无疑问我的文笔是很差的,而且心 ...
DayDayUp：2019.12.30吴晓波2020年终秀演讲《预见2020：来海边，拾起信心》读后有感
DayDayUp:2019.12.30吴晓波2020年终秀演讲<预见2020:来海边,拾起信心>读后有感导读:2019年,过的好不好?有人豪情万丈,有人强颜欢笑. 互联网平台带来了方便快 ...
大道至简读后有感
大道至简读后有感今天的读后感是在读完第二章之后写的,这一章的标题乍一看很有意思,题为是懒人造就了方法,其实细细一品,很是有道理.这章也分为四节,分别是"是懒人造就了方法", ...
读后有感 - UI设计师必知：线框图、原型和视觉稿
读后有感 - UI设计师必知:线框图.原型和视觉稿太阳火神的美丽人生 (http://blog.csdn.net/opengl_es) 本文遵循"署名-非商业用途-保持一致"创作 ...
读后有感 - 残忍但诚实的忠告：您没钱，就不要掺和这事了
读后有感 - 残忍但诚实的忠告:您没钱,就不要掺和这事了太阳火神的美丽人生 (http://blog.csdn.net/opengl_es) 本文遵循"署名-非商业用途-保持一致" ...
复旦大学《数学分析》教学大纲，读后有感
该<分析>大纲读后,犹如时间倒转,回到19世纪的马克思撰写<数学手稿>时代,-- 但是,时光不能倒流.进入20世纪,数学公理化时代终于到来了.1930年,哥德尔紧致性定理:19 ...
读后有感！吴军博士的新书《见识》
<见识>脱胎于吴军在得到APP的专栏<硅谷来信>,在内容上进行了重新补充.调整.整体来说,语言比较平实,内容深度见仁见智,不过增长点见识还是可以的. 接下来给大家提炼下< ...
《it创业疯魔史》读后有感
这本书是一周的时间看完的,当小说看,每天睡前都看. 和看小说不同的,是看这本书的时候,不是因为困放下书,是因为思考.返回头看自己的笔记,才发现每次中断的原来都是有共鸣的地方. 真心觉得这本书不应该叫& ...
EOS白皮书读后有感
特性参数信息来源备注产块速度 0.5秒/块 consensus-algorithm-bft-dpos 会出现空白块,即在预定时间没生成出对应的块产块原理多人协作顺序产块 \ The sel ...
有人负责，才有质量：写给在集市中迷失的一代（读后有感）
读了这篇文章以后,确实引发了我很多的思考,也对我接下来的学习有了很大的帮助. 简单概括为以下几点: 1．许多人虽作为一名IT人士,但他们的基本功不扎实,仍有欠缺,也缺乏规范化开发软件的过程. 作者说, ...

《SRE：Google运维解密》读后有感

《SRE：Google运维解密》读后有感相关推荐

最新文章

热门文章