写在《SRE 生存指南》出版之际

熬了无数个晚上翻译的《SRE 生存指南 – 系统中断响应与正常运行时间最大化》终于都出版了。回忆当时翻译的点点滴滴，还记忆犹新，历历在目。

如果没有记错，《SRE 生存指南》应该是国内第二本专门讲述 SRE 的书籍，第一本是《SRE：Google 运维解密》。相比于《运维解密》的大部头，《生存指南》稍微轻量级一点，但轻量级不意味着不全面，SRE 所涉及的方方面面书中都系统地涵盖到了，让有志于学习 SRE 的同学可以快速上手，提升 SRE 的领域知识。而且两本书都是来自于 Google 的 SRE 实践的，个人建议是先读《生存指南》，系统掌握 SRE 的基本领域知识，再深入阅读大部头的《运维解密》，效果会事半功倍。

SRE生存指南

领域著作的稀缺反映了 SRE 其实是一个相对较新的领域。但其实 SRE 所代表的背后的工作与职位其实存在很久了。书中对 SRE 的定义是 ：“一个专注于熟练地维护一个网站以使其持续发展的领域。”虽然这个定义有进一步优化的空间，但它很好地概括了 SRE 的主要工作领域，就是系统运维。既然系统运维久已有之，为什么现在又提出 SRE 的概念呢？

关键的关键就在于 SRE 最后的 E。E 是 Engineering 的意思，即工程化。当一件事物需要用工程化的思维去对待的时候，往往意味着这件事情已经变得非常复杂。那为什么系统运维工作会变复杂呢？显而易见的答案是需要维护的系统变得越来越复杂，行为越来越难以预测。尤其是微服务流行后，现代系统都变成了一个个“System of Systems”，系统的涌现行为让人无法预测。按照现在火热的 Cynefin 认知框架解释，运维是一个横跨 Simple，Complicated，Complex 甚至是 Chaotic 的领域。要应对这种不确定的涌现行为，唯有借助工程化思维。工程化思维，意味着要构建一套行之有效的体系，尽可能地弱化这种不确定性的发生，但同时也要保证当不确定性真的发生时，能有有效的处理手段。

《生存指南》中的工程化，实例化成一个叫做“Mikey 金字塔”的层次结构。这里不做展开，其基本思想概括起来就是四个字：全局优化。从系统生命周期的角度出发，系统运维位于周期的后端，但潜在的问题往往发之与生命周期前端的发布，开发甚至产品设计阶段。所以 SRE 工程师必须尽早主动介入系统的生命周期，越早越好。这还是可以依据 Cynefin 认知框架来解释。单从系统运维的视角来看，发生的生产事故可能是 Complex 甚至是 Chaotic，让人对其如何发生摸不着头脑；但从全局视角出发，可能在产品设计阶段一个简单合理的改动就可以消除这个问题（诡异的地方是这中间可能并没有明确的因果关系）。在某个维度难解甚至不可解的问题，思考的角度转换一下，可能就是一个简单问题。问题解决之道往往在问题领域之外，运维的生产问题可在运维之外的阶段得到解决，我想这就是“Mikey 金字塔”所要带给我们的工程化思维。

最后说一说 SRE 和 DevOps。二者是一体两面，体就是软件系统的开发生命周期。二者更多的是视角不一样，DevOps 是站在开发者的角度看系统的开发，是 Dev 向 Ops 的融合；SRE 是从运维者的角度看系统的开发，是 Ops 主动向 Dev 的融合，二者追求的目标是一致的，殊途同归，都是为了打造端到端的高响应力。当然，这里讨论的是狭义的技术上的 DevOps，不是囊括敏捷精益管理理论的那个广义 DevOps。

最后，附上购书链接，我相信能看到这里的同学都是对 SRE 有兴趣的，何不尝试购买一本呢？

https://item.jd.com/12700340.html