在亚马逊与Uber工作有什么不同？
极客时间编辑部
讲述：子阳大小：2.20M时长：04:48
软件工程师迪维奇·维迪亚（Divij Vaidya）最近刚刚从亚马逊跳槽到 Uber 数据研发部门。他曾在亚马逊公司的多个部门与地区工作了六年半。他发文分享了在亚马逊与 Uber 工作的不同之处，并表示此文不打算讨论什么，只是基于他在与特定团队及组织合作中的观察，并不代表公司整体的文化。以下为主要内容，仅供开发者参考。
1.DevOps 负担
亚马逊和 Uber 的 DevOps 负担可谓无处不在。在不妨碍快速创新与持续生产发布的前提下，努力保持服务的高可用性一直是个难以解决的问题。对于亚马逊及 Uber 这样的大规模运营实体而言，情况自然变得更加复杂。两家公司都专注于实现卓越运营，不过亚马逊长期以来已经建立起解决问题的成熟流程，而 Uber 则仍在实验哪种策略最适合自己。
2. 开源
Uber 是一家开源优先型企业，这一点直接反映在其内部工具与技术的选择上，也体现在 Uber 的社区（Cadence、M3、Ludwig、Fx 以及 Marmaray 等）回馈记录中。
围绕开源技术构建内部基础设施的做法，使得开发人员能够自由选择适合工作内容的工具，从而将主要精力集中在解决需要创新的业务问题身上。这也意味着 Uber 能够在互联网上建立起多元化的开发者网络，以帮助企业解决第三方库调试问题时遇到的困难。相比之下，亚马逊则更多依靠内部开发的基础设施与工具，这虽然缩小了选项范围，但同时也限制了遇到问题时可用支持选项的数量。
Uber 公司不会亲自构建每一款开发者生产力工具（例如用于监控、仪表盘、分页以及招聘等等），而是从提供软件即服务的厂商处获取各类方案。这些拥有专项产品组合的小型企业倾向于提供专长范围内的最佳软件，这种少而精的定位为 Uber 提供巨大帮助。开发人员能够用到最新、最好的工具，提高自己的工作效率并改善软件开发生命周期。此外，这也能让开发人员专注于软件开发本身，进而解决 Uber 所面临的独特业务与功能问题。
3. 透明度
在 Uber，每周都会组织一次领导层碰面会，各位高管在这里回答员工们提出的问题。除此之外，执行链中各个层级的人员也都会定期与员工沟通。
这有助于开发人员将自身与公司目标紧密联系起来，保证将精力投入到正确的问题当中。此外，这种方式还能够让软件工程师了解到所在团队或组织之外，企业面临的其它挑战。再加上对文档记录的高度重视，员工将有机会深入了解每项“理由”的答案。
相比之下，亚马逊的透明度机制则受到严格控制，员工只能接触到自己有必要了解的信息。
4. 工程技术挑战
两家公司在工程技术挑战方面倒是没什么区别。无论是在亚马逊还是在 Uber，受到规模与可用性要求的影响，开发者都得面对现有解决方案无法解决的业务用例。虽然两家公司的具体业务问题可能有所不同，但从工程技术的角度来看，难题仍有共通之处：需要设计的系统必须规模更大、性能更强、使用更便捷，而且在速度上优于现有解决方案。这些解决方案专为满足企业内复杂而多样的具体业务用例而量身定制。二者最大的不同，可能在于负责解决实际问题的工程师数量。在亚马逊需要多人处理的问题，在 Uber 这边可能只需要一名开发人员。
5. 参与制定战略决策与路线图
在亚马逊，这方面工作主要取决于员工所在组织的定位，以及行政领导层设定的职能方向。在 Uber，内部产品相关决策可以由自己把控，包括确定现有差距到定义成功指标等等。总而言之，与亚马逊相比，Uber 的员工拥有更多自主权。
6. 创新活动
Uber 公司鼓励软件工程师们在与本职工作以及团队章程无关的领域内寻找并解决问题。如果你发现了一个能够让 Uber 受益的工程问题，那么管理层一般会允许你花点时间解决这个问题——即使这与你的日常工作没啥关系。相比之下，在亚马逊，不同部门很难理解彼此面临着哪些挑战。因此如果不是真的被调派到其他团队当中，那么帮助对方解决问题基本上没有可行性。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论