我忘记了我在优步的确切面试时间线，但大致是 “周二面试，周三录用，下周一开始上班” （这不是我在优步见过的最快的周转速度！
我曾经在星期五下午5:00左右给一个人发了offer，他立刻回复， 并在两天后的星期一开始上班）。我被聘用的职位是“经理”，最初我很紧张，我不太清楚是什么意思。在开始工作的前一个周末，我焦急地阅读了《The 》，试图对我刚刚被雇佣去做的事情进行复盘。
开始的时候团队建立的四个阶段，有五个团队在做“基础设施”工作。数据和地图工程团队也归入基础设施组织，但他们非常专注于其他工作，因此为了叙述方便我将省略他们。基础设施团队包括：
开发工具
专注于超越索引对磁盘空间的需求的基础激光设施工程
丹麦的一个团队，主要专注于部署工具
，负责订购和安装服务器以及网络设备
团队，负责其他的所有工作
在一个由200名工程师组成的工程组织中（人数每6个月就会增加一倍）， 这些团队加起来大约有20人。
我加入了名单上的最后一支队伍：。我们有五个人，负责维护公司的大部分服务器（优步当时没有使用任何云供应商）、请求路由基础设施（主要是）、Kafka、大部分数据库、服务供应（“面向服务的架构”中的概念）、一些安全方面的东西（当时只有一个专门的安全工程师，Alex，他比我早几个星期加入）、、和各种各样处在组织缓冲区的软件。
开始时，我评估了团队面临的挑战，并将其缩小到几个需要紧急关注的领域：保持网站正常运行（由于负载加速，大多数周五下午都会出现问题，人们的手机在12个小时的值班时间里会因为重复的寻呼而没电）；扩展Kafka，准备在优步的万圣节流量高峰之前从我们的第一个数据中心迁移出去（我们已经决定不在我们当前的数据中心购买任何的额外容量，因此这是一个艰难的截止日期），以及支持传入的服务调配请求。在第二周和第三周，我为每项工作都写了一个策略，这让我觉得我们有了一条清晰的前进道路。
就我极其客观且绝不自私的记忆来说，那些计划是最出色的计划。如此好的计划，以至于我的经理后来透露，他最初担心我立即解决他一直在努力解决的问题。当然，人们很快就会明白，那些非常优秀的计划只在纸面上效果最好。
我们的第一步是建立一个服务手册[1]：一个描述我们为其他团队所做工作的YAML文件，以及一个将该文件编译成UI的 Flask应用程序，该UI在可能的情况下自动执行这些请求，并生成包含完成任务所需信息的结构良好的票据， 包括完成任务的必要信息。
我们当时的票据系统不支持为不同类型的请求添加必填字段，因此服务指南通过简单地确保每个请求都包含正确的信息而提供了很多价值。更重要的是，服务指南为我们提供了我们一直缺少的东西：关于传入请求的数据。
随着使用数据的积累，我们很快发现，我们的大部分时间要么用于应对关键的生产事故 （这不是我们可以忽视的事情），要么用于供应新服务。
—1—
服务供应
在优步的单体架构中工作变得很困难：迁移有风险，部署很慢，调试场景具有挑战性，因为每个部署包括许多团队的提交等等。我们已经做出了废弃使用单体架构的决定，团队正在尽可能快地转移到新的服务中。
服务供应是一个杂乱无章的过程，遵循一个长期的运行手册，并要求在至少三个不同的主机层上顺序部署更新，此外还要修改（类似于的，但比它早几年；优步最初的基础设施技术栈大部分是由早期的工程师从Digg移植过来的）中许多容易出错的部分。
在这些步骤之后，你将不可避免地要开始调试你或者请求新服务的团队的错误之处。总之，你可以很容易地花半天时间来提供一个新的服务，然后再花一周时间与服务所属的团队来回沟通，让最后的部分正常工作。
我们每周都会在服务供应积压方面落后一点，而且我们无法在不占用其他紧急计划的情况下为服务供应工作增加更多的人手。所以我们把重点放在了我们剩下的最好的工具，即自动化。
我们没有很多人专门负责服务供应，所以最初只有我和一名与我同一天加入的工程师兼职做这件事。这还不够，所以我们很快就雇了第二个工程师Woody来全职工作。Woody在服务供应上花费了太多时间，以至于有人在得知Woody是一个人而不是一个机器人时感到困惑。
我们的服务手册为我们提供了一个接口来拦截传入的服务供应请求，我们不断扩展工具，直到同事们可以在没有任何团队支持的情况下完全供应服务。当时的一些临时步骤相当笨拙， 我特别记得有一个阶段，我们为每个新服务自动生成了配置，但是仍然需要请求的工程师实际还是需要合并他们自己的变更。大家都很困惑， 因为申请新功能的时候， 他们要把变化粘贴到我们的仓库中， 并希望它不会破坏任何东西。
另一个有趣的子挑战是服务发现和路由。我们通过进行服务发现，通过在本地主机上连接到服务的静态分配端口，可以路由到当前环境中的服务，然后会将该端口路由到在该环境中运行的实例。
当运行时，是在每台服务器上单独配置的，通常每台服务器每小时配置一次。（每小时一次的运行时间为20分钟，所以在无效的变更开始传播和整个机群崩溃之间大约5分钟的时间。我们擅长在胁迫下暂停推出，但我们也搞坏了很多东西）。
要提供新服务，就需要保留一个全局唯一的端口。如果重用一个端口，将不可避免地导致中断。端口最初被记录在某个地方的wiki页面中，尽管许多端口没有被记录在任何地方。为了使服务供应的这一步骤自动化，我们从手动分配转移到了自动分配（后来又摆脱了静态端口分配的恐怖）。这是一个很好的例子，说明我们不得不紧急解除许多早期的选择，以实现整个过程的自动化。
这些问题绝不是原始基础设施设置中“错误选择”的结果。相反，像大多数技术决策一样，这些方法不能在几个数量级的增长中完好无损地生存下来。我们遇到的许多挑战在今天几乎是闻所未闻的，今天解决这些问题的大多数工具在Uber的基础设施刚建立时根本不存在，也没有经过验证。（作为一个后来的例子，优步后来会运行Mesos而不是，因为在那个时候是一个早期项目，在负载方面没有多少使用。）
随着我们逐一解决这些问题，服务供应变得更快，更不容易出错。在18个月内，我们从15项服务扩展到2000多项服务，其中每一项服务都是由这个团队或他们构建的平台提供的。当团队达到顶峰时，大约有四个人在处理这个特殊的问题，绝大多数都是通过这个平台完成的。远离最初的跨团队、长达一周的艰苦工作，服务供应变得足够容易，以至于每个新入职工程师在第一天就可以供应一个新服务。
—2—
员工数量
除了自动化方面的工作，我们还加大了招聘力度。我遇到的第一个挑战是团队拒绝了每一个候选人。在我的面试过程中，我最终在白板上用做了一个旅行推销员问题[2]，这基本上是面试过程的一部分。没有标准化的问题，没有评估候选人的标准，每个招聘经理的整体结构也各不相同。
今天，我会从推出那些常见的实践开始，但是在我职业生涯的那个阶段，我从未见过或听说过那些最佳实践。因此，我会和我的招聘伙伴坐在一起，复盘为什么每次招聘流程下来都没能发出一份offer。对于我认为可以帮助我们在大量工作中生存下来的候选人，我会去和团队讨论为什么我们需要雇佣他们。最终，他们对和我进行同样的争论感到恼火，并开始同意雇佣一些候选人。
作为一个在加入优步之前雇佣过大概六名工程师的人，这是一次真正的火的洗礼。我在优步的第一年，每周我都要做十次电话筛选和四五次面试。我清楚地记得有一天我在这些玻璃房间里做了三次连续的电话筛选，并努力分辨分我笔记中的候选人。我们做了太多的面试，以至于我们制定了一个流程，当优秀的面试官开始精疲力竭时，我们会主动将他们从面试中轮换出来。
由于缺乏监督或标准化，我们也有过既好笑又可怕的招聘经历。我们拒绝了一个候选人，他的推荐人说服我们六个月后再面试他们，我们又再次拒绝了他。另一个团队没有被吓倒，坚持对候选人进行第三次面试。我联系了那个团队的经理来劝阻他们，但是他们坚持并提出了一个offer。候选人接受了邀请，从优步开始，然后在第一天工作几个小时后，他们接受了的第二份邀请（很方便，一个街区之外）。最终，他们在优步面试的次数比他们在那里工作的时间还要多。
以这种速度招聘团队建立的四个阶段，加上频繁的生产事故，以及频繁的沮丧的合作伙伴团队，毫无疑问是我工作过的最艰难的。这一切都很消耗精力。从好的方面来看，它确实有效。我们雇佣了相当多的人，在一年之内，我们已经从五个人发展到大约四十个人，完全由外部雇佣驱动。
—3—
创建SRE
随着我们团队的壮大和自动化程度的提高，我们的计划表明情况会有所改善。但事实并非如此。我们仍然深陷泥潭。我们的方法是可行的，但它的速度还不够快。我们周围的工程组织每六个月增加一倍，并且每几个月就会带来一个新的紧急项目，例如在中国建立两个新的数据中心。
我们还能做些什么来减轻这些工作负担呢？如果增加人力和软件能力还不够，那么我们想到能做的就是减少工作量。太明显了！
任何减少工作量的方法都必须满足两个具体要求。首先，我们需要保持我们的能力，为每六个月翻倍的工作负载所带来的不可预测但不可避免的生产问题配备人员。其次，我们必须为其他工程团队提供足够的支持，以便他们能够在关键的， 独立的目标上取得进展。
有一种理论认为，减少工作量的解决方案是迫使你的经理优先考虑你的工作量，但我只看到这种策略在自上而下的组织中奏效。这也是让你从领导者降级为经理的一种可靠方式。我承认我太专注于我们的团队自己克服这一挑战，而没有考虑寻求帮助。最终我们想出了另一种方法：我们能通过改变我们组织的形式来解决这些限制吗？
正是这个问题引发了优步SRE组织的建立。
如果我们能够保护基础设施免受传入的的工作请求影响，我们就有人员来扩展它们，所以我们专注于如何保护团队免受干扰，同时给予请求团队足够的支持来取得进展。该结构是有效的：
我们的三四个顶级组织合作伙伴将获得SRE的全力支持。合作团队将明确地优先考虑支持他们的SRE工作量。我们根据请求的数量而不是影响来定义“顶级”
其他人将获得自助服务平台团队的支持。他们会根据加速自动化的原则考虑工作的先后顺序
其余的基础设施将支持特定领域的可扩展性和操作，例如网络、Kafka。他们通常会优先考虑可伸缩性、可用性和效率
当我们开始推出这个项目时，遇到了一个典型的优步问题：我们没有任何人来为SRE团队配备人员。然而，没过多久，我们就聘请了优步的第一位SER经理——Rick， 然后招聘工作就开始逐步展开。
当Rick加入时，我对他的入职讲话并不太好，大概是这样的：“你真的很聪明，很有经验。你需要帮助这个合作伙伴团队完成他们的工作，而无需向更广泛的基础架构团队提出任何请求。不需要等待许可，只是去做事。祝你好运！
”完全是Rick的功劳，不知何故这成功了。
此后不久，另一名工程师受雇加入Rick，与同一个合作伙伴团队一起工作。然后又雇佣了两名工程师来支持名单上的下一个合作团队。之后的两个人支持了第三个团队，计划开始形成。我们继续这种模式，添加更多的SRE直接嵌入到顶级合作伙伴团队中，直到我们没有足够大的合作伙伴团队来支持。
合作伙伴团队最终有能力将基础架构要求与他们的工作协调起来，大部分都停止了升级。即使我们没有给他们想要的支持级别，但我们已经给了他们明确的控制权，并让他们接触到他们团队的要求所产生的权衡，其中许多是他们在早期的模式中没有意识到的。
随着我们在SRE的推广稳定下来，感觉我们终于解决了这个问题。
这个SRE模型并不完美。它与合作伙伴团队一起蓬勃发展，在其他团队中则举步维艰，但它解决了它所设计的问题：我们的合作伙伴团队正在取得可预测的进展，我们能够同时优先考虑可扩展性工作。最重要的是，它在没有任何全局自上而下的优先级指导的情况下解决了这个问题，而是依靠合作伙伴团队在本地解决他们的优先级。
—4—
SRE v2
优步更广泛的基础设施组织有一个方法来解决问题。从根本上说，这是一个自下而上的组织，有地方战略，但没有一个共同的总体战略，这造成了相当多的摩擦点。最终，随着公司规模的扩大，开始寻找我的直接经理的角色，最终我们聘用了优步的下一任基础设施主管。
新的基础架构负责人根据他们以前的经验，有一套非常具体的架构和基础设施组织的构建方法。几周内，他们启动了一个项目，重新构建优步的技术和基础设施。他对SRE应该如何工作也有具体的看法，并在几个月内聘请了一位以前的同事接管SRE团队。
在新领导加入并重新实施他们之前的设置后，通常情况下，关于事情如何运作的重要背景会被掩盖。我也没有很好地解释我们在优步的SRE组织中解决的具体问题。直到今天，我认为这些新领导人对优步的SRE组织正在解决的问题（使自下而上的组织具有高度流动性的优先权，而不是分解成一个单一的优先事项列表）有一个根本性的误解，即从他们以前的经验的角度来看待它。因此，SRE很快从嵌入式模式转变为完全不同的模式。
名字没变，但很快就变成了一个截然不同的团队。这个名字的延续掩盖了一个重要的领导和文化转变的开始，这一转变在Susan 的《反思Uber， 非常奇怪的一年[3]》中达到高潮。几个月后，我两年内的第五个老板出局了，我也紧随其后。（有点令人困惑的是，这位老板并不是新的基础设施主管。相反，他们是另一位新领导，与新的基础设施主管几乎同时加入，并在加入后六个月内离开。）
SRE组织仍然存在。我们建立的SRE组织消失了。
—5—
反思
当讲述像这样的故事或Digg V4发布时，总是有一种以最好的方式展示自己的倾向，但我尽量忠实地讲述这些事情。如果我可以重来一次，我会做很多不同的事情。也就是说，优步对我来说是一个突破性的角色，如果没有我最初在优步学到的一切，我就不会在后来的工作中取得成功。没有什么比我们一起完成的事情更让我自豪的了。对我在优步共事和学习的同事们：谢谢你们，你们让我的生活变得更好。
这并不是说这次经历完全是好的。在那个优步时代工作是要付出代价的。许多人付出了更大的代价；我也是。作为一个领导者，我已经不知所措了，为此我很挣扎。在去优步立陶宛办事处的一次工作旅行中，我七年的伙伴打电话告诉我他们已经搬走了。写作曾是我最大的爱好，但我在那里的时候放弃了写作。有些章节丰富了我们的生活，但我们不会去重复，对我来说，优步无疑是其中之一。
相关链接：
今天探讨的是团队，团队的背后是运营的分工与合作。如果你说咱公司小，运营一个人全包了，没关系，你把这些能力全吸收了，那得多牛啊！
尚且不论团队规模，光运营职能可以细化到什么程度，给大家一个比较折中的思路，折中意味着你可以整合其中几项，也可以进一步细化拆解。我们通常按照用户从售前到售后的路径，把运营团队分为如下7个职能，未来会有不少文章深入解析，今天简单做个引子：
市场运营
教育是一个“酒香也怕巷子深”的行业，虽说好的产品和服务会通过口碑进行发酵传播，但要抢占先机并扩大规模，就需要对目标市场及特定渠道进行快速开拓和持续优化。传统培训机构做营销一般是三板斧，搜索引擎+校园+产业链合作，基于城市辐射范围，抓单到店完成转化。
在互联网教育领域，因为招生范围从城市变成了全国甚至海外，基于APP的推广、新媒体的利用、社群的建立和扩散、直播平台的维护和电商平台的开拓等，就变得逐渐重要起来，总之可以推广的范围大了，手段多了。
需要关注的运营细节（尤其在提升ROI这点上）也多了，早不是随随便便全丢官网的年代，要知道现在的获客成本在某些特定领域已经令人咋舌。所以好的市场运营，一定是开源节流的高手，能抓住珍贵的渠道，并不断扩大产出。
产品运营
产品运营是大多数教培公司转型互联网过程中，容易忽视和掌握不好的一个部分，原因有很多，一是不知道哪里下手，二是不知道怎么下手，三是不知道下手的力度和节奏，给大家几个具象的产品运营场景：
1. 用户从下单到支付的成功率只有32%，五千元以上的课程订单中85%都没有支付成功，为什么，怎么办？
2. 用户下载了我们的app，但注册的不到下载的一半，使用产品核心功能的又不到注册的一半，怎么办？
以上类似的问题都是产品运营每天在思考的，正向的看，我们要思考，产品上线一个新功能如何让用户快速的用，用的舒服，对核心指标产生影响。反向的看互联网运营团队搭建，我们要关注，从产品核心目标倒推，哪些环节损耗最大，怎么来修正。补充一句，做好产品运营，需要两个核心条件：数据+用研。
商品运营
商品运营，说穿了就是对售卖的商品进行严谨而艺术的包装，以及精确且符合用户需求的呈现。这点其实电商可参考的经验最为丰富，目前大多数付费知识和在线教育的玩家都已经做的比较好了，大伙在文描包装、试听试用、用户评价等一切能加强用户付费决策的环节上，极尽能事。
内容运营
选择教育产品不像选择快消品，很多是非标的，同样一个用户想通过四六级考试，他需要了解自学和培训的区别在哪里，自己学校和培训机构的区别在哪里，线下和线上的产品区别在哪里，A机构和B机构的区别又在哪里？
是不是特别复杂？所以在我看来，内容就有了2个核心的价值：吸引流量，促进转化。
吸引流量自不用说，像学习资料、考试攻略、报名流程等都是非常好的吸流载体，BBS时期的沪江有一句广告语“8G学习资料应有尽有”免费获取了多少用户不用多说。
而促进转化同样重要，大多数用户知道自己大概想学什么，但对真的想学什么，怎么学其实是不清楚的，一些优质的PGC引导文和UGC经验文，往往是用户付费前的最后一剂助力。
另外除了以上两点，内容还有一个重要作用发生在用户学习后端，就是“促活”，大多数情况下用户对于长时间的课程学习都会呈现疲态，这时一些趣味的、短小的内容就会起到调剂的作用，帮助用户启动或串联不同的学习行为，当然，这里有些底线需要坚守，具体在指什么大家都懂的。
活动运营
互联网机构做活动搞事情的能力，一直是其运营实力的一种具体体现。
当然活动也分很多种，有促销互联网运营团队搭建，促学，拉新，维老等，电商喜欢搞周年庆、双十一，教培喜欢做开学季，寒暑假，背后的逻辑，其实都是在制定淡旺季的获客和销售打法。围绕活动运营，有很多可以聊的东西，比如哪些促销手段是教培领域应用效果比较好的？活动和活动间的节奏与配合是如何去做的？这方面是我比较擅长的领域，近期就会先给大家整理一下。
平台运营
我们知道，平台是由不同的品牌或品类组成的，他们之间的矛盾、冲突和共赢，是平台运营的机会，平台运营的两个核心价值在于：使单品类的流量价值最大化，使跨品类的用户价值最大化。而价值发生的前提，是平台运营者对平台用户的洞察，运营规则的把握，和行业发展的远见。
举个简单的例子，用户在天猫上，关注四六级课程，看到的到底是沪江网校还是新东方在线，这是一个话题，而学习完四六级课程推送雅思托福还是考研考证，也是一个话题，这些都非常值得被研究和讨论。话说需要用到平台运营职能的公司，其实并不多，但其背后一些通用的运营逻辑，大家可以借鉴。
用户运营
用户运营核心就是管理用户的生命周期，并谋求在生命周期内最大化用户的价值。举个例子，用户从访问到报班，从报班到学习，从学习到毕业，从毕业到续报，从续报到推荐，这所有的环节都是用户运营的同学需要核心关注和研究的。
他们甚至要通过了解用户，和用户做朋友，反向对产品、平台、商品、活动等进行修正，可以说，和用户走的有多近，你的竞争壁垒就有多高。早期小米在用户运营上的造诣，大家应该是有目共睹的。
结语
不知不觉说了那么多，其实这些还只是冰山一角，碍于篇幅今天先不深入，未来我会针对每个具体的话题进行展开，也会邀请行业内的达人来一起分享，敬请期待。
-The End-
◤这里的文章也好看◢
