从亚马逊到 Uber：在一名软件工程师眼中他们有什么不同？

我是一名软件工程师，最近刚刚从亚马逊跳槽到 Uber。我曾在亚马逊公司的多个部门与地区工作了六年半。在刚刚入职的这一个月里，我在西雅图的 Uber 数据研发部门效力。

之所以写下这篇文章，是为了回答我的朋友和同事们提出的问题——“在亚马逊与 Uber 工作有什么不同？”

本文不打算讨论什么

一家企业中的工程文化很难进行大致界定，因为其中的每一个团队与组织都是独一无二的。本文中提出的结论，只是基于我在与特定团队及组织合作中的观察，可能并不代表公司整体的文化。

本文与我的跳槽决定无关，所以这篇文章也不应被解释为优劣的比较。

从亚马逊到 Uber

两家企业的工作文化之间既存在不少共性，也有诸多差异。其中一些可能与公司的规模有关，而另一些则源于企业自身的固有 DNA。这里，我将概述自己发现的一些重要区别。

DevOps 负担

DevOps 负担可谓无处不在。在不妨碍快速创新与持续生产发布的前提下，努力保持服务的高可用性一直是个难以解决的问题。对于亚马逊及 Uber 这样的大规模运营实体而言，情况自然变得更加复杂。两家公司都专注于实现卓越运营，不过亚马逊长期以来已经建立起解决问题的成熟流程，而 Uber 则仍在实验哪种策略最适合自己。

亚马逊给软件工程师设定的运营负担那是出了名的沉重（具体请参阅文尾旁注 1），包括全天候值班以及技术支持待命等等。但在我看来，实际上每家企业都需要面对那些高度造福一方系统可靠性的客户，Uber 也不例外。因此，配合新兴平台的快速增长以及结构松散的运营流程，Uber 的 DevOps 负担一点也不比亚马逊轻，甚至可能还要要更重一些。

开源

在刚刚加入 Uber 时，开源软件的广泛使用成为我最大的惊喜。Uber 是一家开源优先型企业，这一点直接反映在其内部工具与技术的选择上，也体现在 Uber 令人印象深刻的社区回馈记录中（详见旁注 2）。

围绕开源技术构建内部基础设施的作法，使得开发人员能够自由选择适合工作内容的工具，从而将主要精力集中在解决需要创新的业务问题身上。这也意味着我们能够在互联网上建立起多元化的开发者网络，以帮助企业解决第三方库调试问题时遇到的困难。相比之下，亚马逊则更多依靠内部开发的基础设施与工具，这虽然缩小了选项范围，但同时也限制了遇到问题时可用支持选项的数量。

Uber 公司不会亲自构建每一款开发者生产力工具（例如用于监控、仪表盘、分页以及招聘等等），而是从提供软件即服务的厂商处获取各类方案。这些拥有专项产品组合的小型企业倾向于提供专长范围内的最佳软件，这种少而精的定位为 Uber 提供巨大帮助。作为开发人员，我们能够用到最新、最好的工具，提高自己的工作效率并改善软件开发生命周期。此外，这也能让开发人员专注于软件开发本身，进而解决 Uber 所面临的独特业务与功能问题。

透明度

在 Uber，我们每周都会组织一次领导层碰面会，各位高管在这里回答员工们提出的问题。除此之外，执行链中各个层级的人员也都会定期与员工沟通。

作为开发人员，我们通过这种制度了解影响到我们自身以及相关工作的决策及其背后的理由。这有助于我们将自身与公司目标紧密联系起来，保证将精力投入到正确的问题当中。此外，这种方式还能够让软件工程师了解到所在团队或组织之外，企业面临的其它挑战。再加上对文档记录的高度重视，员工将有机会深入了解每项“理由”的答案。利用这些“理由”，我们可以更具体地指导自己做出的任何一项决策（无论是否与技术有关）。这里假设一个场景，如果我的问题是“Uber 为什么倾向于利用 Go 替代 Java？”或者“为什么我们的组织结构是现在这样？”那么答案都能从对应的文档当中找到。

这种极高的透明度（无论是否与技术有关）确实令人耳目一新，而且能够帮助刚刚入职的新人快速了解现有基础状态。相比之下，亚马逊的透明度机制则受到严格控制，员工只能接触到自己有必要了解的信息。

告别 AWS

我很怀念在亚马逊的那段能够一键使用自动扩展、全托管 MySQL 兼容数据库的日子。其实在 AWS 工作那会儿，我没有真正意识到云基础设施即服务（IaaS）为软件工程师开发生命周期带来的宝贵便捷性。而在 Uber，使用云服务是有代价的——我们当然可以选择任何技术完成工作，但首先需要证明与自主管理/开发带来的成本相比，选择云服务解决方案的成本确实具有优势。

工作场所内的社交互动

由于 Uber 公司西雅图办公室的员工不多，所以工作场所也显得比较紧凑，我会接触到很多所在团队之外的员工。午餐时间的社交活动与专门的文化交流，帮助我很快融入到这个团结而统一的集体当中。相比之下，亚马逊公司的主体运营单位是小型职能团队，我的社交互动也仅限于”双披萨团队“之内（除非你刻意参加公司范围内的其它社交活动，但必须得说，这类活动总是「人满为患」）。

工程技术挑战

两家公司在工程技术挑战方面倒是没什么区别。无论是在亚马逊还是在 Uber，受到规模与可用性要求的影响，我们都得面对现有解决方案无法解决的业务用例（在某些领域中，AWS 的要求可能比 Uber 还更高一些）。虽然两家公司的具体业务问题可能有所不同，但从工程技术的角度来看，难题仍有共通之处：需要设计的系统必须规模更大、性能更强、使用更便捷，而且在速度上优于现有解决方案。这些解决方案专为满足企业内复杂而多样的具体业务用例而量身定制。二者最大的不同，可能在于负责解决实际问题的工程师数量。在亚马逊需要一个”双披萨团队“处理的问题，在 Uber 这边可能只需要一名开发人员。

参与制定战略决策与路线图

在亚马逊，这方面工作主要取决于员工所在组织的定位，以及行政领导层设定的职能方向。我就遇到过那种自上而下贯彻的硬性项目，要求我们在工程技术圆桌讨论中为产品制定未来 2 到 5 年的发展计划。在 Uber，我所参与的每一个内部产品相关决策都只由自己把控，包括确定现有差距到定义成功指标等等。我在 Uber 的供职时间还不长，但能感觉到这似乎是组织中的运作常态（这是一种平台型组织，而非产品型组织）。总而言之，与亚马逊相比，Uber 的员工拥有更多自主权。

远程办公条件

在亚马逊，我曾经在西雅图总部工作，能够在 10 分钟之内与所有利益相关者、合作伙伴以及上游合作伙伴进行当面交流。但在 Uber，这些利益相关者以及合作伙伴则分布在不同地方。虽然跟我在两家公司的具体职位有关，但这样的变化确实给我的工作方式带来了很大影响。对于远程合作伙伴与利益相关者，我们往往需要付出更多精力才能完成协同。视频通话不可能完全取代现场会议与面对面交流。偶尔进行的跨办公室沟通，也不像大家身处同一办公空间内直接喊话那么轻松自然。

创新活动

Uber 公司鼓励软件工程师们在与本职工作以及团队章程无关的领域内寻找并解决问题。如果大家发现了一个能够让 Uber 受益的工程问题，那么管理层一般会允许你花点时间解决这个问题——即使其与你的日常工作没啥关系。相比之下，在亚马逊我们甚至很难理解其他部门面临着哪些挑战。因此如果不是真的被调派到其他团队当中，那么帮助对方解决问题基本上没有可行性。

午餐/办公室里的零食（非常重要）

亚马逊方面并不为员工提供免费午餐，办公室里也没有能买到健康午餐的那种咖啡吧；Uber 则提供免费午餐以及全天候的美味点心。虽然乍看起来这么一点小差别在企业整体运营中似乎无关紧要，但根据我的切身体会，在办公室里吃午餐再随时配上点小零食，确实提高了我的工作效率。毕竟在饿了的时候，我用不着跑到拥挤的市区餐厅花上半个小时只为吃点东西。

总结

在完成了自己的新人过渡之后，我已经积累了不少关于 Uber 特色的经验，并意识到这家公司特别注意将核心价值观/原则渗透到日常工作当中——这也正是亚马逊所擅长的。作为开发人员，这些原则有助于推动决策流程，并使整个组织拥有更为统一的视野。当然，我还在继续学习，并将在后续的文章中不断分享这些心得体会。

旁注 1：虽然非常辛苦，但全程跟进归属于我的系统绝对是整个职业生涯中最有意义的经历。这敦促我从头开始编写出能够良好且安全运作的系统，我认为每一家企业都应该采用亚马逊的这套呼叫与运营流程模式。

旁注 2：参与的社区包括 Cadence、M3、Ludwig、Fx 以及 Marmaray 等。

原文链接：

https://medium.com/swlh/amazon-to-uber-from-the-lens-of-a-software-engineer-e5bd1c38caba

核子可乐译