SRE之道：创造软件系统来维护系统运行

引言：本文做者Ben Treynor Sloss，Google 运维团队的高级副总裁，SRE 名称的发明者，在这里提供了他对SRE 的定义。 
本文选自《SRE：Google运维解密》。

　　你们都知道， 计算机软件系统离开人一般是没法自主运行的。那么，究竟应该如何去运维一个日趋复杂的大型分布式计算系统呢？雇佣系统管理员（sysadmin）运维复杂的计算机系统，是行业内一直以来的广泛作法。而Google 的解决之道是——SRE。 
　　SRE 团队经过雇佣软件工程师，创造软件系统来维护系统运行以替代传统模型中的人工操做。 
　　SRE 到底是如何在Google 起源的呢？ 其实个人答案很是简单：SRE 就是让软件工程师来设计一个新型运维团队的结果。当我在2003 年加入Google 的时候，个人任务就是领导一个由7 名软件工程师组成的“生产环境维护组”。当时，个人整个职业生涯都专一于软件工程，因此很天然，我按照本身最习惯的工做方式和管理方式来组建了这个团队。 
　　时过境迁，当年的7 人团队已经成长为公司内部1000 余人的SRE 团队，可是SRE 团队的指导理念和工做方式仍是基本保持了我最初的想法。 
　　SRE 方法论中的主要模块，就是SRE 团队的构成。每一个SRE 团队里基本上有两类工程师。 
　　第一类，团队中 50%~60% 是标准的软件工程师，具体来说，就是那些可以正常经过Google 软件工程师招聘流程的人。第二类，其余40%~50% 则是一些基本知足Google软件工程师标准（具有85%~99% 所要求的技能），可是同时具备必定程度的其余技术能力的工程师。 目前来看， UNIX 系统内部细节和1~3 层网络知识是Google 最看重的两类额外的技术能力。 
　　除此以外， 全部的SRE 团队成员都必须很是愿意、也很是相信用软件工程方法能够解决复杂的运维问题。Google 一直密切关注这两类候选人在招聘经过以后在SRE 团队中的表现，可是到目前为止尚未发现他们在工做上和成绩上的显著差别。事实上，因为两类工程师技术背景互补，SRE 团队常常可以寻找到全新的、高效的解决问题的方法。 
按照这个标准来招聘和管理SRE 团队，咱们很快发现SRE 团队成员具备以下特色： 
　　(a) 对重复性、手工性的操做有自然的排斥感。 
　　(b) 有足够的技术能力快速开发出软件系统以替代手工操做。 
　　同时，SRE 团队和产品研发部门在学术和工做背景上很是类似。所以，从本质上来讲，SRE 就是在用软件工程的思惟和方法论完成之前由系统管理员团队手动完成的任务。这些SRE 倾向于经过设计、构建自动化工具来取代人工操做。 
　　SRE 模型成功的关键在于对工程的关注。若是没有持续的、工程化的解决方案，运维的压力就会不断增长，团队也就须要更多的人来完成工做。传统的Ops 团队的大小基本与所服务的产品负载呈线性同步增加。若是一个产品很是成功，用户流量愈来愈大，就须要更多的团队成员来重复进行一样的事情。 
　　为了不这一点，负责运维这个服务的团队必须有足够的时间编程，不然他们就会被运维工做所淹没。所以，Google 为整个SRE 团队所作的全部传统运维工做设立了一个50% 的上限值。传统运维工做包括：工单处理、手工操做等。设立这样一个上限值确保了SRE 团队有足够的时间改进所维护的服务，将其变得更稳定和更易于维护。这个上限值并非目标值。随着时间推移，SRE 团队应该倾向于将基本的运维工做所有消除，全力投入在研发任务上。由于整个系统应该能够自主运行，能够自动修复问题。咱们的终极目标是推进整个系统趋向于无人化运行，而不只仅是自动化某些人工流程。固然，在实际运行中，服务规模的不断扩张和新功能的上线已经让SRE 够忙了！ 
　　Google 的经验法则是，SRE 团队必须将50% 的精力花在真实的开发工做上。那么咱们是如何确保每一个团队都是这样作的呢？首先，咱们必须不断地度量每一个团队的工做时间分配。依靠这个数据，SRE 管理层会对在开发工做上投入时间不够的团队进行调整。一般，管理层会要求该团队将一些常见的运维工做交还给产品研发部门操做，或者从产品研发部门抽调人力参与团队轮值值班工做。此外，还能够中止该SRE 团队的一切新增运维工做。只有管理层主动维护每一个SRE 团队的工做平衡，咱们才能保障他们有足够的时间和精力去进行真正有创造性的、自主的研发工做，同时，这也保障了SRE 团队有足够的运维经验，从而让他们设计出切实解决问题的系统。 
　　咱们发现 Google SRE 模型在运维大规模复杂系统时有不少优点。因为SRE 在调整Google 系统的过程当中经常直接参与开发、修改代码，SRE 文化在公司内部基本表明了一种快速、创新、拥抱变化的文化。实践证实，SRE 团队运行、维护、改进一个复杂系统所须要的成员数量与系统部署规模呈非线性增加。而运维一样的系统，用传统的系统管理员模型维护则须要更多数量的人。最后，SRE 模型不只消除了传统模型中研发团队和运维团队的冲突焦点，反而促进了整个产品部门水平的总体提升。由于SRE 团队和研发团队之间的成员能够自由流动，整个产品部门的人员都有机会学习和参与大规模运维部署活动，从中得到平时难以得到的宝贵知识。普通的开发人员有多少机会能将本身的程序同时跑在100 万个CPU 的分布式系统上呢？ 
　　虽然SRE 模型带来了一些优点，但也存在一些问题。Google 面对的一个持久性的难题就是如何招聘合适的SRE。首先SRE 要和产品研发部门招聘传统的软件开发工程师竞争。 
　　其次，因为SRE 要求同时具有多项技能，市场上具备相关从业背景和经验的人就更少了。因为SRE 模型也比较新，行业内关于如何创建和维护SRE 团队的相关信息并很少。最后，SRE 团队创建以后，因为SRE 模型中为了提升可靠性须要采起一些与常规作法违背的作法，因此须要强有力的管理层支持才能推行下去。例如：因为一个季度内的错误预算耗尽而中止发布新功能的决定，可能须要管理层的支持才能让产品研发部门重视起来。 
　　本文选自《SRE：Google运维解密》，点此连接可在博文视点官网查看此书。 
　　　　　　　　　　　　　　　　　　　　　　

想及时得到更多精彩文章，可在微信中搜索“博文视点”或者扫描下方二维码并关注。