第一章

主要介绍了SRE的由来，我感觉主要是为了解决传统开发部门和运维部门之间的矛盾，两个部门沟通协助成本高，开发和运维的目标在书中描述可以理解成互相矛盾的存在，开发想更快的发布版本，而运维则是版本发布完，为了不发生故障和可靠性，就抱着能不动环境就不动环境的心思，最好不升级版本。其实可以理解，在商业公司中，开发和运维部门都存在利益冲突，如果领导层不能统一他们的目标，降低沟通和协助成本，两个部门就是矛盾体，对公司的发展很不利，特别是在大公司而言，大家都怕担责任而不主动去推动项目的进度。但对小公司而言，一是人比较少，好管理，二是部门沟通没那么多死规则，比如发个版本必须要做各种测试，提交各种报告后，才给你走部署流程。
所以Google为了避免这两种部门的矛盾，提高研发的效率和运维的服务质量，提出了SRE，SRE团队有两类人组成，一种是一般的开发，另一种是即懂开发，也懂运维的人。由这两种人轮流轮值，但前提是必须保证工作精力分配50%以上在研发上，剩余精力通过开发减少重复运维工作。可以理解成就是打破了开发和运维部门的壁垒，由两个部门的人合并，统一目标战略，即提高了研发的效率，也保证了服务的质量。如果对DevOps有了解的，可以人为DevOps是SRE核心理念的普适版。

第二章

主要介绍Google的生产环境介绍，我觉得Google之所以能践行SRE的理念，得益于Borg管理系统。如果有了解过kubernetes的，就很好理解，把硬件服务器和应用两方面的运维切分开来，让运维更加关注应用本身，更关注应用的可靠性上面，部署应用不需要关注底层硬件服务器、负载均衡和故障迁移等，一般只需要提供需要多少CPU和内存资源的清单即可。如果应用要上kubernetes，则需要打包镜像，并发布镜像，镜像的制作和发布和则属于运维范畴，但一般开发都要学会，而要学会这些，必须要懂得系统是如何运作的（网络通信、存储方式等），可以说kubernetes让开发和运维的工作配合更加密切了，而传统的物理服务器运维工作交给平台层或者硬件团队去维护。