202236:杀鸡也要用牛刀--《SRE：Google运维解密》的历史知识

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）。相比于很多教授和学者都看不上站点的开发，可这是最传统的工程，随着用户规模的增大，完全成为了一个专业，而不是看不上眼的能耐，我们的一流高校还是很缺乏这类计算机基础工程与科学的研究人才，实在是令人唏嘘。