《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的根本职责与主要关注重点近十年内基本保持不变的结论，个人觉得还是太保守了。