写点什么

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

  • 2019-08-08
  • 本文字数:3291 字

    阅读完需:约 11 分钟

从亚马逊到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


核子可乐译


2019-08-08 14:0010837

评论

发布
暂无评论
发现更多内容

互联网研发效能专家怎么找?

laofo

互联网大厂研发效能团队的需求管理

laofo

互联网 DevOps cicd 研发效能 CI/CD

Reactor百万连接的并发

C++后台开发

reactor 高并发 epoll Linux服务器开发 C++后台开发

微信小程序商城源代码

源字节1号

软件开发 小程序开发

无聊科技正经事周刊(第 7 期):跟村上春树学跑步,向古川武士学养成

潘大壮

程序员 周刊 行业趋势 科技周刊 技术周刊

css 学习笔记【二】-背景,渐变,链接文档的MIME类,id选择器和类选择器的区别

恒山其若陋兮

5月月更

python实现连接两个数据库

YUKI0506

快速上手云原生安全平台 NeuVector

Rancher

Kubernetes k8s rancher NeuVector

活动报名:以「数」制「疫」,解密 Tapdata 在张家港市卫健委数字化防疫场景下的最佳实践

tapdata

数字化 数据孤岛 实时数据 疫情防控 活动报名

存储模组头部厂商嘉合劲威加入龙蜥社区

OpenAnolis小助手

开源 操作系统 芯片 龙蜥社区 嘉合劲威

面试突击49:说一下 JUC 中的 Exchange 交换器?

王磊

Java java面试

设施资产管理系统解决方案

低代码小观

资产管理 CRM CRM系统 企业设备管理 设备巡检管理系统

洞见科技中标渤海银行「联邦学习平台建设+营销场景建模服务」两大项目

洞见科技

金融科技 隐私计算

数据产品实战-toB产品实践心得

第519区

数字化转型 解决方案 数据产品 tob产品

Python unicode三明治

AIWeker

Python 人工智能 5月月更

互联网公司目标管理OKR和绩效考核误区

laofo

OKR 研发效能 互联网公司 快手 绩效考核 GRAD

私有化的IM即时通讯平台,企业首选的沟通工具

WorkPlus

互联网公司目标管理OKR实践落地与反思

laofo

互联网 OKR 研发效能 绩效管理 快手

基于GPU的并行集群系统在中国的发展状况

Finovy Cloud

gpu 云服务器 集群渲染 渲染服务

程序员,做业务还是做技术更有前途?

张泽豪

程序员

软件的license是什么意思?作用是什么?

行云管家

软件 运维 许可证

Tapdata x 轻流,为用户打造实时接入轻流的数据高速通道

tapdata

SaaS 数据同步 实时数据 轻流

Tapdata Cloud 2.1.5来啦:新增支持Amazon RDS数据库,错误日志查询更便捷,Agent部署细节再优化

tapdata

SaaS 数据同步 polarDB Amazon RDS

攻防演练 | 关于蓝队攻击研判的3大要点解读

青藤云安全

安全攻防 网络安全

Tapdata 在数字化防疫场景的最佳实践

tapdata

数字化 防疫 主数据管理 实时数据 数据虚拟化

零基础可以学云计算运维吗?怎样从才可以学好?

行云管家

云计算 运维 IT运维 云运维 服务器运维

融云首席科学家任杰:历练出人才,职场「经历>经验」

融云 RongCloud

员工考勤打卡时,如何避免非本人代替打卡?

华为云开发者联盟

人脸识别 打卡 华为云FRS 华为云FunctionGraph 华为云APIG

微信业务架构,学生管理系统架构设计

泋清

#架构实战营

架构实战营|模块1

KDA

#架构实战营

通过 Amazon API Gateway 和 Amazon Lambda 实现基于 Restful API 的 CloudFront Distribution 复制/克隆功能

亚马逊云科技 (Amazon Web Services)

Lambda Gateway

从亚马逊到Uber:在一名软件工程师眼中他们有什么不同?_文化 & 方法_Divij Vaidya_InfoQ精选文章