《SRE》读后感  

  

                        xindoo    评论    SRE            5    2016-10-02 10:57:41                                                  原文来自：[  /xindoo/article/details/52723114]xindoo/article/details/52723114[/url]
《SRE》这本书英文版已面世半年后，中文版终于面世。从4月、5月的时候，我就一直在尝试看英文版，由于自己英文水平有限，阅读进度和深度实在有限，看到中文版，对很多章节的内容才算是有了较深入的理解，一句话评价此书，这是一本运维转型的指导性书。

看过原版，再对照中文版，从内容上，并不比原版少什么，所以各位读者不必担心内容相对原版是否缺失，如果各位英语不好、但又想了解Google的SRE，放心大胆的买中文版吧，因为译者也是Google的前SRE，翻译的不能说原汁原味，但也八九不离十。  

我自己本身也在国内某大厂做运维，我们也面临着传统运维向devops的转型，接下来我就结合自己实际工作的经历，谈谈我对这本说的理解。   

这本书基本上可以分成几个大部分。

* SRE的诞生  
* Google内部软硬件环境  
* SRE和Dev的协作
* SRE自己是如何做事的  


SRE是为了解决op和dev相互之间的矛盾和割裂的问题，用一些工程和规范来让op和dev之间有个平衡，并且最优化系统的发展。书中举出大量dev和sre系统的方法和规范，比如错误预算、部分运维工作交还dev、SRE协助dev团队健康发展等……   

从我自己的经验来看，其实作为一个op，一天到晚有一堆乱七八糟的事，曾经因为这些事，搞的我情绪都不太好。不同于国内一些公司，google考虑到了这些，制定了一系列的标准来平衡SRE工作上的问题，比如最多50%运维工作、完善的轮值机制、完善的SRE培训体系……，前两天还看过google的《重新定义公司》，从他们内部各种福利政策来看，google是一个非常人性化的公司。  

运维工作中，有些是管理层需要做的事，但也有些内容能让你自己提升自己运维的效率。这么多年，SRE总结出了一套完善的方法论，比如和Dev团队的协作沟通，SRE在风险管理、on-call、故障排查、问题处理、故障后总结……，google都总结出了想当好的经验。  

书中也介绍了google的一些软硬件环境，比如数据中心、网络、borg、Ch y（zookeeper）、监控系统、负载均衡、cron等。书中介绍了一些这类软硬件设计的思路，可以给那些想自己设计软硬件系统的公司一些方向。
> We want our systems that are automatic, not just automated.
>

上面这句话是英文版原文，如何理解这句话?我们想让要系统是自治的，而不仅仅是自动的。这是一个设计系统先进的理念，想想我们往常是怎么设计系统的，是不是专注于解决一个问题，流程在这里卡了，需要人为干预，甚至是再做一个新的系统来解决某些问题。  

举个例子，一个应用有数十台服务器，服务器会宕机，然后需要把服务器下线，再扩容一台。然后就会有一个监控系统发现问题，再弄个服务器下线的系统，自动化扩容的系统，然后都需要手工提单。这个时候，有人嫌提单麻烦，又写了个自动调其他三个系统解决问题的系统。就因为服务不是自治的，而我们一味强调自动化，导致系统越来越复杂，越来越难以自动化。其实我举的这个例子，google的borg已经很好的解决了，我认为borg基本上就是一个自治的系统。   

总结一把，我觉得这本书并不是直接告诉你应该怎么做，因为不同的公司在不同的阶段关注的重点是不一样的，做的事也不可能和google相同，盲从某些方法论可能会得到相反的结果，所以我的建议是把这本书当成一种方向性的指导。

2017年7月29日补充：在我即将离开运维这个岗位之即，说下我的体会，目前国内许多大公司都鼓吹运维向devops（也就是sre）转型，其实大多数人都在转型过程中被干掉了，我觉得其实是因为运维缺乏研发能力。SRE骨子里是研发，而不是运维，就像这本书里说的，SRE其实是研发团队构建运维团队的产物。

有人回复了楼主：

还是不建议做运维，说下我们运维团队的变化，15年我实习的时候团队有30多人，我16年写这篇书评的时候团队拆分后运维还有将近20人，19年初团队彻底解散。。。再说下转行难不难的问题，我算是18年中真正从运维转到java开发，但在此之前我自己就有大量的编码练习，而且还刷脸去旁边的开发团队过渡了半年的时间蹭了个项目经验。我能从运维转开发是有大量的前期准备和很多机遇在里面的，并不是所有人都能走我这条路的，所以我还是觉得直接运维转开发门槛还是很高的。    但是所有事情都得辩证去看，运维的经历也不是说完全不好，运维的经历让我学到了好多普通开发不懂的知识，就比如我现在很多命令行工具玩的贼溜，关键时刻节省大量时间；再比如比较虚的有对架构的理解、对流程的把控也是超过普通开发。运维也算是让我修炼了一些内功，学起其他的东西也比较快。注意：这一切都得建立在你有学习的主动性上，我觉得很少有leader能在运维方向上给你指明未来的发展道路(可能他们自己也不知道)，也很少有人会愿意这么做。

《SRE》读后感  

  

                        xindoo    评论    SRE            5    2016-10-02 10:57:41                                                  原文来自：[  /xindoo/article/details/52723114]xindoo/article/details/52723114[/url]
《SRE》这本书英文版已面世半年后，中文版终于面世。从4月、5月的时候，我就一直在尝试看英文版，由于自己英文水平有限，阅读进度和深度实在有限，看到中文版，对很多章节的内容才算是有了较深入的理解，一句话评价此书，这是一本运维转型的指导性书。

看过原版，再对照中文版，从内容上，并不比原版少什么，所以各位读者不必担心内容相对原版是否缺失，如果各位英语不好、但又想了解Google的SRE，放心大胆的买中文版吧，因为译者也是Google的前SRE，翻译的不能说原汁原味，但也八九不离十。  

我自己本身也在国内某大厂做运维，我们也面临着传统运维向devops的转型，接下来我就结合自己实际工作的经历，谈谈我对这本说的理解。   

这本书基本上可以分成几个大部分。

* SRE的诞生  
* Google内部软硬件环境  
* SRE和Dev的协作
* SRE自己是如何做事的  


SRE是为了解决op和dev相互之间的矛盾和割裂的问题，用一些工程和规范来让op和dev之间有个平衡，并且最优化系统的发展。书中举出大量dev和sre系统的方法和规范，比如错误预算、部分运维工作交还dev、SRE协助dev团队健康发展等……   

从我自己的经验来看，其实作为一个op，一天到晚有一堆乱七八糟的事，曾经因为这些事，搞的我情绪都不太好。不同于国内一些公司，google考虑到了这些，制定了一系列的标准来平衡SRE工作上的问题，比如最多50%运维工作、完善的轮值机制、完善的SRE培训体系……，前两天还看过google的《重新定义公司》，从他们内部各种福利政策来看，google是一个非常人性化的公司。  

运维工作中，有些是管理层需要做的事，但也有些内容能让你自己提升自己运维的效率。这么多年，SRE总结出了一套完善的方法论，比如和Dev团队的协作沟通，SRE在风险管理、on-call、故障排查、问题处理、故障后总结……，google都总结出了想当好的经验。  

书中也介绍了google的一些软硬件环境，比如数据中心、网络、borg、Ch y（zookeeper）、监控系统、负载均衡、cron等。书中介绍了一些这类软硬件设计的思路，可以给那些想自己设计软硬件系统的公司一些方向。
> We want our systems that are automatic, not just automated.
>

上面这句话是英文版原文，如何理解这句话?我们想让要系统是自治的，而不仅仅是自动的。这是一个设计系统先进的理念，想想我们往常是怎么设计系统的，是不是专注于解决一个问题，流程在这里卡了，需要人为干预，甚至是再做一个新的系统来解决某些问题。  

举个例子，一个应用有数十台服务器，服务器会宕机，然后需要把服务器下线，再扩容一台。然后就会有一个监控系统发现问题，再弄个服务器下线的系统，自动化扩容的系统，然后都需要手工提单。这个时候，有人嫌提单麻烦，又写了个自动调其他三个系统解决问题的系统。就因为服务不是自治的，而我们一味强调自动化，导致系统越来越复杂，越来越难以自动化。其实我举的这个例子，google的borg已经很好的解决了，我认为borg基本上就是一个自治的系统。   

总结一把，我觉得这本书并不是直接告诉你应该怎么做，因为不同的公司在不同的阶段关注的重点是不一样的，做的事也不可能和google相同，盲从某些方法论可能会得到相反的结果，所以我的建议是把这本书当成一种方向性的指导。

2017年7月29日补充：在我即将离开运维这个岗位之即，说下我的体会，目前国内许多大公司都鼓吹运维向devops（也就是sre）转型，其实大多数人都在转型过程中被干掉了，我觉得其实是因为运维缺乏研发能力。SRE骨子里是研发，而不是运维，就像这本书里说的，SRE其实是研发团队构建运维团队的产物。

有人回复了楼主：

还是不建议做运维，说下我们运维团队的变化，15年我实习的时候团队有30多人，我16年写这篇书评的时候团队拆分后运维还有将近20人，19年初团队彻底解散。。。再说下转行难不难的问题，我算是18年中真正从运维转到java开发，但在此之前我自己就有大量的编码练习，而且还刷脸去旁边的开发团队过渡了半年的时间蹭了个项目经验。我能从运维转开发是有大量的前期准备和很多机遇在里面的，并不是所有人都能走我这条路的，所以我还是觉得直接运维转开发门槛还是很高的。    但是所有事情都得辩证去看，运维的经历也不是说完全不好，运维的经历让我学到了好多普通开发不懂的知识，就比如我现在很多命令行工具玩的贼溜，关键时刻节省大量时间；再比如比较虚的有对架构的理解、对流程的把控也是超过普通开发。运维也算是让我修炼了一些内功，学起其他的东西也比较快。注意：这一切都得建立在你有学习的主动性上，我觉得很少有leader能在运维方向上给你指明未来的发展道路(可能他们自己也不知道)，也很少有人会愿意这么做。