SRE: Google运维解密经典读后感有感
《SRE: Google运维解密》是一本由【美】Betsy Beyer（贝特西 拜尔）等著作，电子工业出版社出版的平装图书，本书定价：CNY 108.00，页数：480，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《SRE: Google运维解密》读后感(一)：《SRE Google 运维解密》读书笔记
第12章，有效的故障排查手段
- 有效展开故障排查的两个条件
- 通用故障排查流程中的关注点
- 故障排查过程中的常见陷阱
- 金句：当所有的可能都存在的时候，我们应该优先考虑最简单的解释
- 金句：我们要记住，相关性不等于因果关系
第13章，紧急事件响应
第14章，紧急事故管理
第15章，事后总结：从失败中学习
第16章，跟踪故障
第17章，测试可靠性
《SRE: Google运维解密》读后感(二)：《SRE Google 运维解密》读书笔记
第12章，有效的故障排查手段
- 有效展开故障排查的两个条件
- 通用故障排查流程中的关注点
- 故障排查过程中的常见陷阱
- 金句：当所有的可能都存在的时候，我们应该优先考虑最简单的解释
- 金句：我们要记住，相关性不等于因果关系
第13章，紧急事件响应
第14章，紧急事故管理
第15章，事后总结：从失败中学习
第16章，跟踪故障
第17章，测试可靠性
《SRE: Google运维解密》读后感(三)：SRE: Google运维解密
大型软件系统生命周期的绝大部分都处于“使用”阶段，而非“设计”或“实现”阶段。那么为什么我们却总是认为软件工程应该首要关注设计和实现呢？在《SRE：Google运维解密》中，Google SRE的关键成员解释了他们是如何对软件进行生命周期的整体性关注的，以及为什么这样做能够帮助Google成功地构建、部署、监控和运维世界上现存最大的软件系统。通过阅读《SRE：Google运维解密》，读者可以学习到Google工程师在提高系统部署规模、改进可靠性和资源利用效率方面的指导思想与具体实践——这些都是可以立即直接应用的宝贵经验。
任何一个想要创建、扩展大规模集成系统的人都应该阅读《SRE：Google运维解密》。《SRE：Google运维解密》针对如何构建一个可长期维护的系统提供了非常宝贵的实践经验。
《SRE: Google运维解密》读后感(四)：满满干货，运维必读，五星推荐
应该有一种职业是专注于整个软件系统的生命周期管理。对于Google，就是SRE。
内容很不错，作为Google长期运维经验的总结，满满干货，运维必读，五星推荐。
从一个运维工程师的角度来看，书中的各种内容都是羡慕嫉妒恨。
花了两个月的时间，终于看到结语了，感觉自己终于松了一口气，这么厚的一本书终于看完了。当然是带着复杂的心情——远超于我们水平的Google分享出它的运维经验，甚是惊喜；书中介绍到他们的运维人员为企业或是世界所作出的贡献，十分羡慕；在阅读过程中，处处感受到我们和他们的差距，五味杂陈；当看到某些地方我们原本可以采用更好的方式时，只能叹息。
对我们来说，运维，依旧有很长的一条路要走。虽然国内的企业，在运维方面，发展也是相当迅速的，尤其是互联网公司。但还是期盼着什么时候，国内的运维也能达到世界级领先的水平，带领运维界进行下一次变革。
《SRE: Google运维解密》读后感(五)：机器的反省心智
如果说跟人打交道靠的是情商，那么跟机器打好交道，尤其是做好人和机器之间的协调者的话，就必须纯熟的应用好机器的语言，也就是软件了。
Google运维的秘密就是对软件进行生命周期的整体性关注。
RE是站点可靠性工程的简称，仍属于DEVOPS的范畴，是开发运维一体的一种方法。与传统的对“网络进行管理“的方法不同的是，SRE是让编写软件的程序员来“管理网络”，即由“机器被动的接受管理”转变到“机器在程序员的帮助下进行自我管理”。
书中有很多google运维专家实战的干货，有些可能受技术条件的限制，并不能马上实施。但重要的是从中领悟到人机协作的精髓。
人与机器的关系是什么？
并不是人要征服机器，而是要实现机器的“区域自治”。机器的特点是执行力超强，但是缺乏“反省”心智。SRE就是通过编程的方式，为机器注入反省心智，自动的进行“行为纠偏”（性能优化）。
《SRE: Google运维解密》读后感(六)：【商汤科技】招聘运维开发工程师，
【商汤科技】招聘运维开发工程师，有兴趣的朋友私戳or投简历，谢谢大家
https://www.lagou.com/jobs/6063439.html
https://www.lagou.com/jobs/6074363.html
职位描述：岗位职责：
1、负责视觉技术平台的运维系统设计与搭建
2、参与平台的基础架构设计
3、视觉技术平台的日常运维工作
任职要求：
1、计算机相关专业本科及以上学历，2年以上运维开发工作经验
2、熟悉Kubernetes, Docker, Kafka, Zookeeper, Mysql, Cassandra, Elasticsearch等开源组件的架构及实现
3、熟练使用脚本语言Python/Shell进行编程工作
4、熟悉主流自动化配置工具，如 Terraform、Ansible、Saltstack、Chef 等
5、理解持续集成/部署，至少熟悉一种 CI/CD 工具，Gitlab CI、Jenkins 等
6、熟悉典型互联网架构、微服务维护实践，和常见的分布式系统架构
7、熟悉 Linux 操作系统原理、TCP/IP 以及常用RPC协议
《SRE: Google运维解密》读后感(七)：SRE Google运维解密 -- 读书笔记
第一部分 概览
第1章 介绍
1. DevOps分离的团队模型存在的问题 1.1 直接成本：Ops成本与系统 负载线性相关 1.2 间接成本：Dev/Ops沟通协调 1.2.1 运维团队：运维流程 1.2.2 开发团队：补丁、开关、插件等各种形式要求快速上线绕过运维团队的流程2. DevOps还是SER 2.1 DevOps是SRE的普适版 2.2 SRE是DevOps在Google的具体实践
3. SRE方法论 3.1主要的职责： a. 可用性改进 b.延迟优化 c.效率优化 d.变更管理 e.监控管理 f.紧急事务处理 g.容量规划与管理
4. 主要矛盾 迭代创新的速度与产品稳定程度之间的矛盾
第2章 Google生产环境， SRE视角
1. 典型的Google数据中心的拓扑结构 a. Rack b. Row c. Cluster d. Datacenter e. Campus
2.管理物理服务器的系统管理软件 2.1 Borg分布式集群操作系统 （类Apache Mesos） 2.2 Borg下一代Kubernetes
3. 存储 a. D服务 b. Colossus（GFS改进版） c. Bigtable d. Spanner e. Blobstore
4. 网络 a. 带宽控制器（BwE） b. OpenFlow协议的软件定义网络（SDN） c. 全球负载均衡系统 （GSLB） i. 物理位置进行负载均衡DNS请求 ii. 在用户服务层面进行负责均衡 iii. 在远程调用(RPC）层面进行负载均衡
5. 监控与警报系统 5.1 以下几种方式使用监控系统 a. 对真实问题进行报警 b. 对比服务更新前后状态变化 ，是否更快？ c. 检查资源使用量随时间的变化情况
6. 软件基础设施 6.1 stubby(gRPC) 6.2 Protocol Buffer
《SRE: Google运维解密》读后感(八)：SRE 平台支撑研发必读
之前没有看过，不过想法一致。也算不同现实经历总结得出大同小异经验。
1 dev ops 严格分离在某些场景下并不合理
2 Keep It Simple Stupid / Dont Repeat Youself 老生常谈但无处不在，而经验不足的工程师可能无法领悟，要经历许多不必要或本来可以避免的故障灾难才明白
3 以前在学堂翻看老一辈 hacker 的书总絮絮叨叨讲 KISS DRY 时候心里嘀咕，为啥这么基本素养要啰里啰嗦写得写书传授？ 工作多年发现大多数人都在野蛮生长到基本素养都不具备
《SRE: Google运维解密》读后感(九)：来自 Google，给人肉运维们传福音了
本书开门见山地，指出了传统运维与开发团队分离模式 存在的矛盾。
第一个矛盾是， 系统复杂增长与落后的运维生产力的矛盾。
造成的后果就是，随着用户量的增加或系统复杂度的增加导致运维工作的增加，运维人员的增加，以致于运维人员天天拿着消防水管救火的状态。
第二个矛盾是，运维与开发者之间的供需矛盾。
开发者想要快速迭代，想要时时更新和发布新版本。
但是，系统的风险百分之七十是系统变更产生的。所以，运维想压制开发，尽量不让开发上线。
以致于产生了各种复杂的审核流程，各种互相甩锅的现象出现。
这两种矛盾不断积蓄，最终产生崩盘。
最终 Google 的 工程师们看不下去了，决定给运维工程师们传福音了。
Google Sre 就是利用软件工程的理念，构建 自动化的运维。本书既包含了一套方法论，又有 践行理念的经验。看完可得道升天也。借用 本司 技术大拿开叔的一句话，“这是我这几年来看过的最好的一本书了”
接下来，我会摘录一些理念。以供借鉴。
运维需要有一半的时间在研发想象一下，假如有个运维朱大哥一天到晚的工作都是救火，那么久而久之会产生倦怠，脾气也会变得暴躁， 随着团队的增长，运维工作越来越多。不仅自己累，别人也不满意。这样运维的系统如果能正常工作，那都是巧合。并且，充满了随处可见的临时脚本，像狗屎一样堆在路中央，随便踩到一个，不是摔跤就是系统宕机。
这样的系统就像是要用人血去灌溉的吃人机。企业的成本也会上升。
但假如，他每天花一半时间想象如何提升，如何自动化，那么将带来很大的杠杆率。从原来的 拉牛耕作到人工智能运作的挖掘机。不仅 bug少，而且还稳定。那么老板给他的年终奖肯定不会少，同事们也自然敬重和爱戴他们的猪哥哥。
没有 百分百稳定的系统，我们也没必要百分百稳定。当然，这不符合社会主义核心价值观。 但，我们的确需要承认这一点。
从用户到服务器，需要经过若干个中间系统，这些中间系统产生的错误率和噪声都会高于 百分之零点零几。
我们所做的都必须经过 风险和成本的权衡。
错误预算这个很有意思， 研发部门想每天上线。 运维部门说，好啊，现在一个季度给你一个可以停止服务时间的配额。
假如 研发部门 水平高，上线稳定，那么上线次数自然可以很多。
假如研发水平不咋的，一上就挂，那么配额自然用光。上线次数自然减少。
这个制度，可以很好的解决了开发与运维的宿怨。 不可谓不机智！
更多，
由于我还没看完，暂时只能说这么多了。
总的来说，是本开卷有益的书。
《SRE: Google运维解密》读后感(十)：《SRE》读后感
原文来自：http://blog.csdn.net/xindoo/article/details/52723114
《SRE》这本书英文版已面世半年后，中文版终于面世。从4月、5月的时候，我就一直在尝试看英文版，由于自己英文水平有限，阅读进度和深度实在有限，看到中文版，对很多章节的内容才算是有了较深入的理解，一句话评价此书，这是一本运维转型的指导性书。
看过原版，再对照中文版，从内容上，并不比原版少什么，所以各位读者不必担心内容相对原版是否缺失，如果各位英语不好、但又想了解Google的SRE，放心大胆的买中文版吧，因为译者也是Google的前SRE，翻译的不能说原汁原味，但也八九不离十。
我自己本身也在国内某大厂做运维，我们也面临着传统运维向devops的转型，接下来我就结合自己实际工作的经历，谈谈我对这本说的理解。
这本书基本上可以分成几个大部分。
* SRE的诞生
* Google内部软硬件环境
* SRE和Dev的协作
* SRE自己是如何做事的
RE是为了解决op和dev相互之间的矛盾和割裂的问题，用一些工程和规范来让op和dev之间有个平衡，并且最优化系统的发展。书中举出大量dev和sre系统的方法和规范，比如错误预算、部分运维工作交还dev、SRE协助dev团队健康发展等……
从我自己的经验来看，其实作为一个op，一天到晚有一堆乱七八糟的事，曾经因为这些事，搞的我情绪都不太好。不同于国内一些公司，google考虑到了这些，制定了一系列的标准来平衡SRE工作上的问题，比如最多50%运维工作、完善的轮值机制、完善的SRE培训体系……，前两天还看过google的《重新定义公司》，从他们内部各种福利政策来看，google是一个非常人性化的公司。
运维工作中，有些是管理层需要做的事，但也有些内容能让你自己提升自己运维的效率。这么多年，SRE总结出了一套完善的方法论，比如和Dev团队的协作沟通，SRE在风险管理、on-call、故障排查、问题处理、故障后总结……，google都总结出了想当好的经验。
书中也介绍了google的一些软硬件环境，比如数据中心、网络、borg、Chubby（zookeeper）、监控系统、负载均衡、cron等。书中介绍了一些这类软硬件设计的思路，可以给那些想自己设计软硬件系统的公司一些方向。
gt; We want our systems that are automatic, not just automated.
gt;
上面这句话是英文版原文，如何理解这句话？我们想让要系统是自治的，而不仅仅是自动的。这是一个设计系统先进的理念，想想我们往常是怎么设计系统的，是不是专注于解决一个问题，流程在这里卡了，需要人为干预，甚至是再做一个新的系统来解决某些问题。
举个例子，一个应用有数十台服务器，服务器会宕机，然后需要把服务器下线，再扩容一台。然后就会有一个监控系统发现问题，再弄个服务器下线的系统，自动化扩容的系统，然后都需要手工提单。这个时候，有人嫌提单麻烦，又写了个自动调其他三个系统解决问题的系统。就因为服务不是自治的，而我们一味强调自动化，导致系统越来越复杂，越来越难以自动化。其实我举的这个例子，google的borg已经很好的解决了，我认为borg基本上就是一个自治的系统。
总结一把，我觉得这本书并不是直接告诉你应该怎么做，因为不同的公司在不同的阶段关注的重点是不一样的，做的事也不可能和google相同，盲从某些方法论可能会得到相反的结果，所以我的建议是把这本书当成一种方向性的指导。
2017年7月29日补充：在我即将离开运维这个岗位之即，说下我的体会，目前国内许多大公司都鼓吹运维向devops（也就是sre）转型，其实大多数人都在转型过程中被干掉了，我觉得其实是因为运维缺乏研发能力。SRE骨子里是研发，而不是运维，就像这本书里说的，SRE其实是研发团队构建运维团队的产物。