最近对DevOps比较感兴趣，饶有兴致的在京东上看了看推荐和评价，发现很多人对O'reilly的这本《SRE：Google运维解密》评价很高 。不过，O'reilly出版社出版的计算机类书籍，质量还是靠谱的，于是找了一本来看，对我的启发也是蛮大的。
软件质量是管理能力的延续--《SRE：Google运维解密》一个全球数一数二的IT科技公司，除了对外发布的产品稳定性强，自己内部使用的辅助软件也是卓越不凡，这就不难解释现在开源世界的一些主流框架都是那么几家公司的产品了。看着这些顶级大师写的文章，自己当然是佩服不已，毕竟自己真没有这样的能力，但可以朝着大师的方向去努力嘛。
全本书都是关于技术和管理的经验，然而我的感觉就是：
软件质量是管理能力的延续。
这话是什么意思呢？就是大公司之所以为大公司，它的管理一定是高效而有力的。我曾经也在电信行业的多家公司从业，书中谈到的很多经验针对的就是我当年工作的痛点啊。
比如在谷歌，运维人员并没有低人一等，而是用上了自己开发的能力保障巨大规模系统的运行，并且遇到问题还能自己定位，然后和研发一起完成。在我的老东家，作为研发的我，时常会接到运维同事的工单，一开始我还算客气，后来便开始烦躁，然而人家真的不懂，得靠你研发去排查和反馈。在我现在的岗位上，运维只能做最简单的启动程序或关闭程序，有时候连启动和关闭都得请厂家过来，更不用说接管程序的代码，从程序运行中提供更多的服务和扩展了。
杀鸡就要用牛刀Google是当今现有的为数不多的，愿意投入精英力量钻研本质问题的公司，而且这些精英很多都有工学博士学位。工具永远只是解决方案中的一个小小组件，用来链接日益庞杂的软件、人和海量的数据。书中没有万能药，没有什么东西能解决一切问题，但是这恰恰是本书的宗旨：相比最后的软件结果、架构设计而言，真实的设计过程、作者本身的思考经历更有价值。实现细节永远只是短暂存在的，但是文档化的设计过程却是无价之宝。SRE，站点可靠性工程师，用软件工程理念和自动化工具定义了这个行业，这就是我对Google充满敬仰的原因之一，虽然Google的有些理念我也是不认同的。
书中讲到：
SRE（Site Reliability Engineering）和传统的IT运维有很大区别，SRE真正实现了DevOps：
首先，SRE深度参与开发阶段的工作，对应用程序的设计实现方式、依赖库、运行时的资源消耗都有严格的规约；其次，SRE工程师本身也要做不少编程工作，来实现各种工具用以自动解决问题和故障，换句话说，SRE强调的是对问题和故障的自动处理，而非人工干预；再者，按照SRE的约定，开发人员自行负责程序上线部署更新，毕竟开发人员对自己开发的程序更熟悉，易于处理程序上线过程中遇到的问题。总之，作为Google的DevOps实践，SRE非常注重开发和运维职能的结合，极大地加快了业务应用迭代周期，提升了IT对业务的支撑能力。
以往的系统开发和采购，甲方往往会受到技术认知的壁垒，把软件架构、软件质量和未来的扩展性都交给厂家，这无异于与虎谋皮。当我14天不在广州却无端被广州赋了黄码，直接同步到贵州的时候，我猛然发现十多年前算法老师说的“软件写不好是要害人的”，有了更深的理解。以前的程序多用于内部业务的支撑和交互，是一个辅助工具，当然很多时候上头的程序出了问题会第一时间赖上我们的网络以及硬件。有一回，整好是我在负责这个工作的时候，多用了几个命令去追踪信息的时候，才发现问题不在我们这，当我有理有据的反馈之后，基本上再也没收到类似的问题了。
软件工程有的时候和养孩子类似：虽然生育的过程是痛苦和困难的，但是养育孩子成人的过程才是真正需要花费绝大部分精力的地方。但是，传统软件工程专业花费了很多精力讨论软件的开发过程，而不是其后的维护过程。有统计显示，一个软件系统的40%～90% 的花销其实是花在开发建设完成之后不断维护过程中的。
行业内流行的一个说法是：一个系统如果已经开发完成，部署在生产环境上，那么它就是 “稳定的”，就不需要那么多工程师花费精力去优化、维护。Google认为这个说法是错误的。从这个视角出发，书中认为如果软件工程职业主要专注于设计和构建软件系统，那么应该有另外一种职业专注于整个软件系统的生命周期管理。从其设计一直到部署，历经不断改进，最后顺利退役。这样一种职业必须具备非常广泛的技能，但是和其他职业的专注点都不同，Google 将这个职位称为站点可靠性工程师（SRE）。相比于很多教授和学者都看不上站点的开发，可这是最传统的工程，随着用户规模的增大，完全成为了一个专业，而不是看不上眼的能耐，我们的一流高校还是很缺乏这类计算机基础工程与科学的研究人才，实在是令人唏嘘。
前路异常艰辛或许是专业的缘故，我对软件工程情有独钟，毕竟如果仅有技术而没有工程的能力，大概率是做不好一个项目的。过程模式就是软件工程中的一个大分支，过程模式讲的是软件生命流程（lifecycle）中，应该如何去做需求、研发、上线、运维以及宣告一个软件的死亡。随着互联网的崛起，并为我们提供了许多公共服务，那传统行业的软件生态必然也被倒逼升级，软件系统也面临着针对用户日益增长的业务工作需要和系统的不平衡不充分的发展之间的矛盾，尤其是当下一个系统按照流程走最快也要三年才能落地的约束下，我们真的需要探索一条新的路子。
这是一条异常艰难的路子，但是如果我们这些科班出身的专业人士不去努力探索一把，那我们对得起这十几二十年的修行吗？运维某个程度也是研发，对于新的系统，运维必须能啃下来，然后针对某些需求还能做调整尽量适应业务处室的需求，这才是我们要的，而尽量规避因为没有立项、没有经费而无法支撑业务处室需求的无奈。一个项目建立可信度很慢，但是失去它却非常快。反观Google SRE部门的工程师的特点：
对重复性、手工性的操作有天然的排斥感。有足够的技术能力快速开发出软件系统以替代手工操作。SRE团队和产品研发部门在学术和工作背景上非常相似，所以他们可以算是内部系统的研发人员。从本质上来说，SRE 就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。这些SRE倾向于通过设计、构建自动化工具来取代人工操作，它的成功的关键在于对工程的关注。如果没有持续的、工程化的解决方案，运维的压力就会不断增加，团队也就需要更多的人来完成工作。传统的Ops团队的大小基本与所服务的产品负载呈线性同步增长。如果一个产品非常成功，用户流量越来越大，就需要更多的团队成员来重复进行同样的事情。为了避免这一点，负责运维这个服务的团队必须有足够的时间编程，否则他们就会被运维工作所淹没。
结语我在想，短期内自己无法招募培养这样的一个团队，能做的就只能是通过自己有限的力量，整合资源，提供写程序以及工程实践的能力，看是否能把现有的团队提升成DevOps的实施团队。
倘若成功，这算是我个人计算机生涯的一次里程碑，我终于在软件工程这领域找到属于自己的立足之地了；倘若不成功，那也算我在自己的领域的一种求索，路漫漫其修远兮。
