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运维解密》，点此链接可在博文视点官网查看此书。 
　　　　　　　　　　　　　　　　　　　　　　

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