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

用户头像
Winfield
关注
发布于: 2020 年 07 月 22 日

熬了无数个晚上翻译的《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

 

发布于: 2020 年 07 月 22 日 阅读数: 17
用户头像

Winfield

关注

还未添加个人签名 2018.05.04 加入

云徙科技专家架构师,曾任ThoughtWorks中国区高级咨询师,汇丰银行技术专家。译作有《SRE生存指南:系统中断响应与正常运行时间最大化》

评论

发布
暂无评论
写在《SRE生存指南》出版之际