人永远不够用——在复旦大学分享SRE团队组织和管理

从10月底到12月初， 数人云与复旦大学合作开授了面向复旦大学软件工程学院软件工程硕士的《信息系统工程概论（SRE：大规模应用运维实践）》系列选修课程，今天小数为大家带来此次选修课上有关SRE团队建设的精彩分享。

源于Google的SRE有助于解决传统运维模式上的问题，SRE是在运维模式上的全新探索，也是DevOps思想在运维方面的真正实践。SRE代表了一套先进的、完整的运维体系，作为Google最早提出，又经由Google发展完善的一个崭新概念，SRE已成为一个涵盖运维理念、思路、组织架构、和具体实践的完整体系。

SRE团队的建设和管理是SRE体系中重要的部分，今天我们来介绍一下SRE团队组织和管理，其中包括SRE工程师的特点，SRE的团队组织和工作原则，SRE的内部沟通机制，SRE的新人培训，SRE团队学习演练和总结。

SRE是这样一种人

SRE（Site Reliability Engineer）即站点可靠性工程师，是一种和传统系统管理员以及普通软件工程师有所区别的新型职业类型。从这张表里我们可以看到这三类人群从工作内容、关注点、技能特长和思维特征都不尽相同。

关于程序员、系统管理员、SRE在关注事项上的区别我们可以用一个例子来说明。比如图上这是一个标准的三层结构网站，对于这样一个结构的网站，程序员的着眼点是如何处理前端HTTP的request和生成response，如何构建数据库表的结构，通过API来访问数据库以及如何优化SQL语句来提高查询的效率。

系统管理员则关注的是如何承载业务压力，规划容量和保证日常运维工作的顺利开展。这包括服务器和网络的配置是什么，如何配置和对接监控和收集日志，该使用哪种版本的中间件和数据库，防火墙和iptable的设置等等。

而一个SRE人员关注的是什么呢？重点是如何在系统地灵活性和可靠性之间找到一个平衡。比如Web服务器的负载均衡策略是什么；数据库的高可用该选择什么样的方案；如果数据库未来需要扩容，当前方案是否支持；是否要跨地域多中心地部署，相应的流量引导和数据同步问题如何解决，评估系统变化对于可靠性和可扩展性的影响等等。

所以，综上所述可以归纳出SRE应该是这样的人。他们关注问题发生的根本原因，更够通过现象看本质，能够将复杂的问题切分成很多部分，这就是我们常说的决策树。再针对这些拆分的部分提出假设，并进行测试。不断深入不同的分支，直到找到根本的原因。他们能够根据大量信息进行归纳和抽象，以便进行深入的调查。基于现有数据和经验进行判断，拒绝主观的臆断。他们不拘泥于现成的“最佳方案”而是根据实际情况追求各方诉求的动态平衡。不但解决眼前出现的问题，还会预见未来的风险和扩展可能性，从而设计出有长远目标的实施方案。最后他们不默守陈规，勇于拥抱变化，不断打破旧的经验，重复造轮。

SRE的团队组织和工作原则

下面我们来介绍一下Google的团队组织和工作原则。Google在团队组建的时候秉承的是多样化原则。团队组织成员如果过于专业化虽然能够提高成熟度，但是只有多样化才能不断解决新的问题。Google SRE团队中有着包括“技术负责人”（TL）、“SRE经理”（SRM）和“项目经理”（PM/TPM/PGM）等多种角色。

很多时候组织内部是一个动态的环境，各种角色之间可以动态地协商切换责任。一般来说，越动态的团队成员的个人能力越强，每个人都要能写代码，每个人都要具备通用的工程能力。但是动态的团队不得不面临在沟通上需要花费更多时间的问题，因此这就要求团队持续进行沟通用以平衡多样化带来的弊端。

虽然团队的角色是多样化的，但是每一项工作内容要求专业化，明确区分系统性和值班化的工作，每个阶段都必须要有一个单一的目标，确保专注做好每件事情。

SRE的内部沟通机制

Google SRE一般是通过生产会议（production meeting）来进行内部的有效沟通。会议组织者一般由相关的SRE进行轮值，项目经理、所有SRE、开发团队代表、商务等任何和项目相关的成员都会被邀请参加会议。一般这个会议一周一次，一次一个小时左右。会议的议程包括变更预告、SLO review、故障的事后总结、警报紧急评估等相关议题。

SRE的新人培训

如何培养一个合格的SRE，Google也积累了一些内容和方法。这张图内包含了SRE团队可以采用的几个培训新员工的最佳实践，同时保证老员工不会落伍。从下面描述的很多个工具中，我们可以从中选择最适合团队的几个来使用。

这张图中包含两个轴 :

• X 轴代表了工作类型的范围，从抽象的，一直到具体的工作；

• Y 轴代表了时间，从上至下，新加入的SRE通常对系统和服务知识了解很少。

阅读之前故障的事后总结对他们很有帮助。新的SRE也可以试图从基本元素出发反向工程整个系统，因为他们本来对系统也没有任何了解。当学员对系统有一定程度的了解，并且已经进行了一些实际操作时，SRE就可以参与见习on-call值班了，同时可以修订文档中不完善或者过时的部分。

阅读上述图表的一些建议 :

• 正式参加on-call值班是SRE新员工的一个重要里程碑，在这之后，学习过程将基本靠自己主导，是未定义的——所以SRE参与on-call值班之后的培训计划都是用虚线标注的；

• 三角形的“项目工作”意味着新项目刚开始都很小，随着时间推移复杂程度逐渐增大，所需投入也在增加，很有可能在参与on-call值班之后还会继续；

• 这里的某些活动是抽象性的，还有些是被动性的。其他的一些活动，则是非常具体和非常具有主动性的，还有一些活动则是混合型的，这样的安排是为了满足不同学习方式的人，让他们都能找到合适自己的活动；

• 为了使培训效果最优，培训课程应该节奏合理：有些可以立即开始，有些则应该在SRE正式参见on-call之前开始，而其他的则应该是持续性的，同时要求SRE老员工也参与的，在SRE正式参加on-call之前，应该处于持续不断的学习过程中。

SRE的团队学习演练

故障处理分角色演习

当面对一个经验各异、能力各异的SRE团队时，如何能够将所有人紧密结合在一起启发他们互相学习是一个挑战。同时，如何将SRE文化——不断解决问题的文化——传授给新员工，同时保证老员工始终能跟上不断变化的环境和服务发展也是一个挑战。Google的SRE团队通过一个老传统——“故障处理分角色演习”来解决这些问题。这个活动同时也被称为“不幸之轮”（Wheel of misfortune）或者“走木板”（Walk the plank）等。这个活动能很好地帮助全体成员每周共同学习并且富有趣味。具体过程很简单，和桌上RPG游戏类似：“主持人”（GM）选择两个团队成员成为主on-call和副on-call;

这些SRE与GM同时坐在房间的最前面。主持人宣布某个警报发生了，这个on-call团队就需要进行调查和现场处理该报警。

GM事先准备一个故障场景，这个场景可能是某个以前发生过的故障，新成员可能没有经历过，老成员可能已经忘记了。或者该场景是某个新功能或者马上上线的功能的假想故障场景，这样参与的所有人都不知道如何处理。

在接下来的30~60分钟内，主on-call和副on-call要试着寻找问题的根源所在。GM会随着问题的展开而提供更多的信息，例如可能会告知大家某个监控图表的走势等。如果该问题需要向其他团队寻求帮助，GM会假扮成其他团队成员回答问题。

当灾难演习RPG运转成功时，每个人都会从中学到一点东西：可能是一个新工具、新技巧，或者解决问题的另外一个角度，或者（对新员工来说）对成功解决某个问题的认可。也许这项练习可以鼓励团队成员面对下周的挑战，甚至成为接下来某一周的GM。

总结

我们已经讲过构建一个合理的错误预算是非常重要的，极端的可靠性会带来成本的大幅提升，这也包括SRE团队的人力成本。因此对SLO要有一个量化的评估，以确保和人力水平相匹配。要从根源上解决问题就是要减少琐事，将重复性工作自动化，消除运维负载，否则人永远不够用。