SRE

我在Uber创立SRE团队的故事


【编者的话】SRE是指Site Reliability Engineer(网站可靠性工程师)。他是软件工程师和系统管理员的结合,SRE工程师需要掌握很多知识:算法、数据结构、编程能力、网络编程、分布式系统、可扩展架构、故障排除等。Uber在早期意识到SRE的重要性,下面文章是作者回顾Uber初期网站运营的问题,以及搭建SRE的过程。

这是我个人在优步创立SRE组织的故事。如果你想要建议而不是回忆,可以看看《Trunk and Branches Model》和《Productivity in the age of hypergrowth》。

在2014年离开SocialCode后,我花了一个月时间在几家公司面试,试图弄清楚下一步该做什么。我在两条不同的道路上纠结:(1)在一家非常小的初创公司领导工程开发,或者(2)在一家快速增长的公司担任一个小得多的角色,并期望它的增长可以给我创造机会。经过一番考虑,我选择了后者,加入了优步。

我忘记了我在优步的确切面试时间线,但大致是 “周二面试,周三录用,下周一开始上班” (这不是我在优步见过的最快的周转速度!我曾经在星期五下午5:00左右给一个人发了offer,他立刻回复, 并在两天后的星期一开始上班) 。 我被聘用的职位是“DevOps经理”,最初我很紧张, 我不太清楚DevOps是什么意思。在开始工作的前一个周末,我焦急地阅读了《The Phoenix Project 》,试图对我刚刚被雇佣去做的事情进行复盘。

开始的时候,有五个团队在做“基础设施”工作。数据和地图工程团队也归入基础设施组织,但他们非常专注于其他工作,因此为了叙述方便我将省略他们。基础设施团队包括:
  1. 开发工具
  2. 专注于超越PostgreSQL索引对磁盘空间的需求的基础激光设施工程
  3. 丹麦的一个团队,主要专注于部署工具
  4. Techops,负责订购和安装服务器以及网络设备
  5. InfraOps团队,负责其他的所有工作


在一个由200名工程师组成的工程组织中(人数每6个月就会增加一倍), 这些团队加起来大约有20人。

我加入了名单上的最后一支队伍:InfraOps。我们有五个人,负责维护公司的大部分服务器(优步当时没有使用任何云供应商)、请求路由基础设施(主要是HAProxy)、Kafka、大部分数据库、服务供应(“面向服务的架构”中的概念)、一些安全方面的东西(当时只有一个专门的安全工程师,Alex,他比我早几个星期加入)、Puppet、Clusto和各种各样处在组织缓冲区的软件。

开始时,我评估了团队面临的挑战,并将其缩小到几个需要紧急关注的领域:保持网站正常运行(由于负载加速,大多数周五下午都会出现问题,人们的手机在12个小时的值班时间里会因为重复的寻呼而没电);扩展Kafka,准备在优步的万圣节流量高峰之前从我们的第一个数据中心迁移出去(我们已经决定不在我们当前的数据中心购买任何的额外容量,因此这是一个艰难的截止日期),以及支持传入的服务调配请求。在第二周和第三周,我为每项工作都写了一个策略,这让我觉得我们有了一条清晰的前进道路。

就我极其客观且绝不自私的记忆来说,那些计划是最出色的计划。如此好的计划,以至于我的经理后来透露,他最初担心我立即解决他一直在努力解决的问题。当然,人们很快就会明白,那些非常优秀的计划在纸面上效果最好。

我们的第一步是建立一个服务手册: 一个描述我们为其他团队所做工作的YAML文件,以及一个将该文件编译成UI的Python Flask应用程序,该UI在可能的情况下自动执行这些请求,并生成包含完成任务所需信息的结构良好的票据, 包括完成任务的必要信息。我们当时的票据系统Phabricator不支持为不同类型的请求添加必填字段,因此服务指南通过简单地确保每个请求都包含正确的信息而提供了很多价值。更重要的是,服务指南为我们提供了我们一直缺少的东西:关于传入请求的数据。

随着使用数据的积累,我们很快发现,我们的大部分时间要么用于应对关键的生产事故 (这不是我们可以忽视的事情),要么用于供应新服务。

服务供应

在优步的单体架构中工作变得很困难:迁移有风险,部署很慢,调试场景具有挑战性,因为每个部署包括许多团队的提交等等。我们已经做出了废弃使用单体架构的决定,团队正在尽可能快地转移到新的服务中。

服务供应是一个杂乱无章的过程,遵循一个长期的运行手册,并要求在至少三个不同的主机层上顺序部署Puppet更新,此外还要修改Clusto(类似于Hashicorp的Consul,但比它早几年;优步最初的基础设施技术栈大部分是由早期的工程师Jeremy从Digg移植过来的)中许多容易出错的部分。在这些步骤之后,你将不可避免地要开始调试你或者请求新服务的团队的错误之处。总之,你可以很容易地花半天时间来提供一个新的服务,然后再花一周时间与服务所属的团队来回沟通,让最后的部分正常工作。

我们每周都会在服务供应积压方面落后一点,而且我们无法在不占用其他紧急计划的情况下为服务供应工作增加更多的人手。所以我们把重点放在了我们剩下的最好的工具,即自动化。

我们没有很多人专门负责服务供应,所以最初只有我和一名与我同一天加入的工程师Xiaojian兼职做这件事。这还不够,所以我们很快就雇了第二个工程师Woody来全职工作。Woody在服务供应上花费了太多时间,以至于有人在得知Woody是一个人而不是一个Hipchat机器人时感到困惑。

我们的服务手册为我们提供了一个接口来拦截传入的服务供应请求,我们不断扩展工具,直到同事们可以在没有任何团队支持的情况下完全供应服务。当时的一些临时步骤相当笨拙, 我特别记得有一个阶段,我们为每个新服务自动生成了Puppet配置,但是仍然需要请求的工程师实际还是需要合并他们自己的变更。大家都很困惑, 因为申请新功能的时候, 他们要把变化粘贴到我们的Puppet仓库中, 并希望它不会破坏任何东西。

另一个有趣的子挑战是服务发现和路由。我们通过HAProxy进行服务发现,通过在本地主机上连接到服务的静态分配端口,可以路由到当前环境中的服务,然后HAProxy会将该端口路由到在该环境中运行的实例。当Puppet运行时,HAProxy是在每台服务器上单独配置的,通常每台服务器每小时配置一次。(每小时一次的Puppet运行时间为20分钟,所以在无效的Puppet变更开始传播和整个机群崩溃之间大约5分钟的时间。我们擅长在胁迫下暂停推出,但我们也搞坏了很多东西)。要提供新服务,就需要保留一个全局唯一的端口。如果重用一个端口,将不可避免地导致中断。端口最初被记录在某个地方的wiki页面中,尽管许多端口没有被记录在任何地方。为了使服务供应的这一步骤自动化,我们从手动分配转移到了自动分配(后来又摆脱了静态端口分配的恐怖)。这是一个很好的例子,说明我们不得不紧急解除许多早期的选择,以实现整个过程的自动化。

这些问题绝不是原始基础设施设置中“错误选择”的结果。相反,像大多数技术决策一样,这些方法不能在几个数量级的增长中完好无损地生存下来。我们遇到的许多挑战在今天几乎是闻所未闻的,今天解决这些问题的大多数工具在Uber的基础设施刚建立时根本不存在,也没有经过验证。(作为一个后来的例子,优步后来会运行Mesos而不是Kubernetes,因为Kubernetes在那个时候是一个早期项目,在负载方面没有多少使用。)

随着我们逐一解决这些问题,服务供应变得更快,更不容易出错。在18个月内,我们从15项服务扩展到2000多项服务,其中每一项服务都是由这个团队或他们构建的平台提供的。当团队达到顶峰时,大约有四个人在处理这个特殊的问题,绝大多数都是通过这个平台完成的。远离最初的跨团队、长达一周的艰苦工作,服务供应变得足够容易,以至于每个新入职工程师在第一天就可以供应一个新服务。

员工数量

除了自动化方面的工作,我们还加大了招聘力度。我遇到的第一个挑战是团队拒绝了每一个候选人。在我的面试过程中,我最终在白板上用Python做了一个旅行推销员问题,这基本上是面试过程的一部分。没有标准化的问题,没有评估候选人的标准,每个招聘经理的整体结构也各不相同。

今天,我会从推出那些常见的实践开始,但是在我职业生涯的那个阶段,我从未见过或听说过那些最佳实践。因此,我会和我的招聘伙伴坐在一起,复盘为什么每次招聘流程下来都没能发出一份offer。对于我认为可以帮助我们在大量工作中生存下来的候选人,我会去和团队讨论为什么我们需要雇佣他们。最终,他们对和我进行同样的争论感到恼火,并开始同意雇佣一些候选人。

作为一个在加入优步之前雇佣过大概六名工程师的人,这是一次真正的火的洗礼。我在优步的第一年,每周我都要做十次电话筛选和四五次面试。我清楚地记得有一天我在这些玻璃房间里做了三次连续的电话筛选,并努力分辨分我笔记中的候选人。我们做了太多的面试,以至于我们制定了一个流程,当优秀的面试官开始精疲力竭时,我们会主动将他们从面试中轮换出来。

由于缺乏监督或标准化,我们也有过既好笑又可怕的招聘经历。我们拒绝了一个候选人,他的推荐人说服我们六个月后再面试他们,我们又再次拒绝了他。另一个团队没有被吓倒,坚持对候选人进行第三次面试。我联系了那个团队的经理来劝阻他们,但是他们坚持并提出了一个offer。候选人接受了邀请,从优步开始,然后在第一天工作几个小时后,他们接受了Twitter的第二份邀请(很方便,一个街区之外)。最终,他们在优步面试的次数比他们在那里工作的时间还要多。

以这种速度招聘,加上频繁的生产事故,以及频繁的沮丧的合作伙伴团队,毫无疑问是我工作过的最艰难的。这一切都很消耗精力。从好的方面来看,它确实有效。我们雇佣了相当多的人,在一年之内,我们已经从五个人发展到大约四十个人,完全由外部雇佣驱动。

创建SRE

随着我们团队的壮大和自动化程度的提高,我们的计划表明情况会有所改善。但事实并非如此。我们仍然深陷泥潭。我们的方法是可行的,但它的速度还不够快。我们周围的工程组织每六个月增加一倍,并且每几个月就会带来一个新的紧急项目,例如在中国建立两个新的数据中心。

我们还能做些什么来减轻这些工作负担呢?如果增加人力和软件能力还不够,那么我们想到能做的就是减少工作量。太明显了!任何减少工作量的方法都必须满足两个具体要求。首先,我们需要保持我们的能力,为每六个月翻倍的工作负载所带来的不可预测但不可避免的生产问题配备人员。其次,我们必须为其他工程团队提供足够的支持,以便他们能够在关键的, 独立的目标上取得进展。

有一种理论认为,减少工作量的解决方案是迫使你的经理优先考虑你的工作量,但我只看到这种策略在自上而下的组织中奏效。这也是让你从领导者降级为经理的一种可靠方式。我承认我太专注于我们的团队自己克服这一挑战,而没有考虑寻求帮助。最终我们想出了另一种方法:我们能通过改变我们组织的形式来解决这些限制吗?

正是这个问题引发了优步SRE组织的建立。

如果我们能够保护基础设施免受传入的的工作请求影响,我们就有人员来扩展它们,所以我们专注于如何保护团队免受干扰,同时给予请求团队足够的支持来取得进展。该结构是有效的:
  1. 我们的三四个顶级组织合作伙伴将获得SRE的全力支持。合作团队将明确地优先考虑支持他们的SRE工作量。我们根据请求的数量而不是影响来定义“顶级”
  2. 其他人将获得自助服务平台团队的支持。他们会根据加速自动化的原则考虑工作的先后顺序
  3. 其余的基础设施将支持特定领域的可扩展性和操作,例如网络、Kafka。他们通常会优先考虑可伸缩性、可用性和效率。


当我们开始推出这个项目时,我们遇到了一个典型的优步问题: 我们没有任何人来为SRE团队配备人员。然而,没过多久,我们就聘请了优步的第一位SER经理——Rick, 然后招聘工作就开始逐步展开。

当Rick加入时,我对他的入职讲话并不太好,大概是这样的:“你真的很聪明,很有经验。你需要帮助这个合作伙伴团队完成他们的工作,而无需向更广泛的基础架构团队提出任何请求。不需要等待许可,只是去做事。祝你好运!”完全是Rick的功劳,不知何故这成功了。

此后不久,另一名工程师受雇加入Rick,与同一个合作伙伴团队一起工作。然后又雇佣了两名工程师来支持名单上的下一个合作团队。之后的两个人支持了第三个团队,计划开始变得更加形成。我们继续这种模式,添加更多的SRE直接嵌入到顶级合作伙伴团队中,直到我们没有足够大的合作伙伴团队来支持。

合作伙伴团队最终有能力将基础架构要求与他们的工作协调起来,大部分都停止了升级。即使我们没有给他们想要的支持级别,但我们已经给了他们明确的控制权,并让他们接触到他们团队的要求所产生的权衡,其中许多是他们在早期的模式中没有意识到的。

随着我们在SRE的推广稳定下来,感觉我们终于解决了这个问题。

这个SRE模型并不完美。它与合作伙伴团队一起蓬勃发展,在其他团队中则举步维艰,但它解决了它所设计的问题: 我们的合作伙伴团队正在取得可预测的进展,我们能够同时优先考虑可扩展性工作。最重要的是,它在没有任何全局自上而下的优先级指导的情况下解决了这个问题,而是依靠合作伙伴团队在本地解决他们的优先级。

SRE v2

优步更广泛的基础设施组织有一个方法来解决问题。从根本上说,这是一个自下而上的组织,有地方战略,但没有一个共同的总体战略,这造成了相当多的摩擦点。最终,随着公司规模的扩大,开始寻找我的直接经理的角色,最终我们聘用了优步的下一任基础设施主管。

新的基础架构负责人根据他们以前的经验,有一套非常具体的架构和基础设施组织的构建方法。几周内,他们启动了一个项目,重新构建优步的技术和基础设施。他对SRE应该如何工作也有具体的看法,并在几个月内聘请了一位以前的同事接管SRE团队。

在新领导加入并重新实施他们之前的设置后,通常情况下,关于事情如何运作的重要背景会被掩盖。我也没有很好地解释我们在优步的SRE组织中解决的具体问题。直到今天,我认为这些新领导人对优步的SRE组织正在解决的问题(使自下而上的组织具有高度流动性的优先权,而不是分解成一个单一的优先事项列表)有一个根本性的误解,而是从他们以前的经验的角度来看待它。因此,SRE很快从嵌入式模式转变为完全不同的模式。

名字没变,但很快就变成了一个截然不同的团队。这个名字的延续掩盖了一个重要的领导和文化转变的开始,这一转变在Susan Rigetti的《反思Uber, 非常奇怪的一年》中达到高潮。几个月后,我两年内的第五个老板出局了,我也紧随其后。(有点令人困惑的是,这位老板并不是新的基础设施主管。相反,他们是另一位新领导,与新的基础设施主管几乎同时加入,并在加入后六个月内离开。)

SRE组织仍然存在。我们建立的SRE组织消失了。

反思

当讲述像这样的故事或《Digg V4发布》时,总是有一种以最好的方式展示自己的倾向,但我尽量忠实地讲述这些事情。如果我可以重来一次,我会做很多不同的事情。也就是说,优步对我来说是一个突破性的角色,如果没有我最初在优步学到的一切,我就不会在后来的工作中取得成功。没有什么比我们一起完成的事情更让我自豪的了。对我在优步共事和学习的同事们:谢谢你们,你们让我的生活变得更好。

这并不是说这次经历完全是好的。在那个优步时代工作是要付出代价的。许多的其他人付出了更大的代价;我也是。作为一个领导者,我已经不知所措了,为此我很挣扎。在去优步立陶宛办事处的一次工作旅行中,我七年的伙伴打电话告诉我他们已经搬走了。写作曾是我最大的爱好,但我在那里的时候放弃了写作。有些章节丰富了我们的生活,但我们不会去重复,对我来说,优步无疑是其中之一。

2022年4月28日发布。

原文链接:Founding Uber SRE.(翻译:张亚龙)

0 个评论

要回复文章请先登录注册