熬了无数个晚上翻译的《SRE生存指南 –系统中断响应与正常运行时间最大化》终于都出版了。回忆当时翻译的点点滴滴，还记忆犹新，历历在目。
如果没有记错，《SRE生存指南》应该是国内第二本专门讲述SRE的书籍，第一本是《SRE：Google运维解密》。相比于《运维解密》的大部头，《生存指南》稍微轻量级一点，但轻量级不意味着不全面，SRE所涉及的方方面面书中都系统地涵盖到了，让有志于学习SRE的同学可以快速上手，提升SRE的领域知识。而且两本书都是来自于Google的SRE实践的，个人建议是先读《生存指南》，系统掌握SRE的基本领域知识，再深入阅读大部头的《运维解密》，效果会事半功倍。
领域著作的稀缺反映了SRE其实是一个相对较新的领域。但其实SRE所代表的背后的工作与职位其实存在很久了。书中对SRE的定义是 ：“一个专注于熟练地维护一个网站以使其持续发展的领域。”虽然这个定义有进一步优化的空间，但它很好地概括了SRE的主要工作领域，就是系统运维。既然系统运维久已有之，为什么现在又提出SRE的概念呢？
关键的关键就在于SRE最后的E。E是Engineering的意思，即工程化。当一件事物需要用工程化的思维去对待的时候，往往意味着这件事情已经变得非常复杂。那为什么系统运维工作会变复杂呢？显而易见的答案是需要维护的系统变得越来越复杂，行为越来越难以预测。尤其是微服务流行后，现代系统都变成了一个个“Systemof Systems”，系统的涌现行为让人无法预测。按照现在火热的Cynefin认知框架解释，运维是一个横跨Simple，Complicated，Complex甚至是Chaotic的领域。要应对这种不确定的涌现行为，唯有借助工程化思维。工程化思维，意味着要构建一套行之有效的体系，尽可能地弱化这种不确定性的发生，但同时也要保证当不确定性真的发生时，能有有效的处理手段。
《生存指南》中的工程化，实例化成一个叫做 “Mikey金字塔” 的层次结构。这里不做展开，其基本思想概括起来就是四个字：全局优化。从系统生命周期的角度出发，系统运维位于周期的后端，但潜在的问题往往发之与生命周期前端的发布，开发甚至产品设计阶段。所以SRE工程师必须尽早主动介入系统的生命周期，越早越好。这还是可以依据Cynefin认知框架来解释。单从系统运维的视角来看，发生的生产事故可能是Complex甚至是Chaotic，让人对其如何发生摸不着头脑；但从全局视角出发，可能在产品设计阶段一个简单合理的改动就可以消除这个问题（诡异的地方是这中间可能并没有明确的因果关系）。在某个维度难解甚至不可解的问题，思考的角度转换一下，可能就是一个简单问题。问题解决之道往往在问题领域之外，运维的生产问题可在运维之外的阶段得到解决，我想这就是 “Mikey金字塔” 所要带给我们的工程化思维。
最后说一说SRE和DevOps。二者是一体两面，体就是软件系统的开发生命周期。二者更多的是视角不一样，DevOps是站在开发者的角度看系统的开发，是Dev向Ops的融合；SRE是从运维者的角度看系统的开发，是Ops主动向Dev的融合，二者追求的目标是一致的，殊途同归，都是为了打造端到端的高响应力。当然，这里讨论的是狭义的技术上的DevOps，不是囊括敏捷精益管理理论的那个广义DevOps。
最后，附上购书链接，我相信能看到这里的同学都是对SRE有兴趣的，何必按耐自己的欲望呢，赶快购买一本吧。
