下面是优步工程的幕后故事司机团队继续开发我们的虚拟入职漏斗，让成千上万的司机合作伙伴在路上用优步赚钱。
规模对司机-合作伙伴的影响
我们的团队关心成长。我们建立了第一个合作伙伴网络入职流程来解决我们的规模问题，出于同样的原因，我们不得不完全修改最初的版本。优步发展迅速。
与优步签约可能很简单，但与优步合作本质上是一个更复杂的过程。直到2013年，新员工入职还是纯手工操作。在我们创建之前，潜在的司机合作伙伴必须去当地的优步办公室区域Greenlight地点——与运营经理一起通过一系列文书工作来创建一个账户。
经过六年的经营，我们最近达到了20亿次旅行在我们的平台上。优步目前在400多个城市和70多个国家开展业务。在所有这些地方提供接送服务意味着我们需要在世界各地吸引和批准司机合作伙伴。每周，成千上万的新司机开始他们的第一次旅行，并开始在我们的平台上赚钱。在这种规模下，亲自做任何事情都不是解决办法。我们必须为我们的驾驶伙伴提供更好的体验，所以我们把它作为一个工程挑战。
网络在线MVP
我们去了我们的司机-合作伙伴培训中心(现在被称为我们的培训中心)当地的Greenlight hub)，并详细分析了该过程是如何工作的。在大多数情况下，当有人想成为司机合伙人时，程序很短:
- 你的交通工具是什么?
- 你能通过筛选程序吗?
- 提供您的驾驶证件(驾照、车辆登记、车辆保险)。
- 观看一段有关优步应用程序如何工作的视频。
- 等待几天的筛选过程。如果OK，您终于被激活了。
为了让驾驶伙伴在线完成这些步骤，我们构建了一个我们称之为Web Onboarding的MVP，包含以下几个组件:
我们将数据存储在主程序中PostgreSQL数据库(我们已经切换到MySQL)在两个主要表格内:
- onboarding_steps表示一个步骤(例如，车辆或screening_process)表示一对城市和产品(例如，uberX在旧金山）
- onboarding_step_instances表示用户在步骤中的状态(即，不完整的或完整的）.
当用户成功提交一个步骤时，我们将其标记为完成，并找到下一个不完整的步骤。不同城市的步骤略有不同，但总体上用户的体验是相同的。很简单，Web Onboarding允许人们在任何位置成为司机的合作伙伴。
我们服务的可伸缩性挑战
很快，优步就超越了网上培训的能力。
Web Onboarding工作得很好，对我们很有帮助，但随着我们的发展速度，更多的城市和国家带来了更多的挑战:
- 不同的州和国家的筛选程序和规定各不相同．
- 一些国家对驾驶伙伴有一个很长的文件清单，有些需要几天或几周才能获得。
- 入职流程各不相同。添加新产品(UberEATS，uberCOMMUTE，换)对我们的架构提出了挑战，因为我们最初设计系统是为了解决一个特定的问题:车载拼车司机合作伙伴。
- 移动应用支持没有扩展。因为我们是将服务器端渲染与业务和显示逻辑相结合，所以不能重用相同的后端。这意味着我们将每个功能构建两次，从而产生了大量的代码复制。
例如，考虑巴黎入职流程图。每颗蓝绿色钻石都显示了常规入职过程的一种可能的替代方案:
保持高的工程生产力和自由以我们需要的方式构建我们的产品变得非常困难。我们没有继续在服务上添加新功能，而是停下来思考一个长期的解决方案。
重新思考一个优化的、可扩展的解决方案
当我们同时开发最初的iOS和Android应用时，我们尽量避免重复客户端的工作。
我们最初减少客户端工作重复的方法是在iOS和Android上呈现基于表单的UI的灵活框架。我们构建了一个完整的协议，允许我们将JSON模式中定义的一组组件转换为本地小部件，然后由移动客户端呈现。我们的目标是获得网络和本地世界的最佳效果:一个感觉快速并集成到系统中的UI，同时可以完全、远程和即时修改。它允许我们每周更新或添加步骤，以跟上不断变化的需求，而不会减慢用户的速度。
这也允许非常快速的迭代，并支持我们想要的任意数量的客户端，但是当我们开始面临增长带来的挑战时，表单模式很快就因为UI声明缺乏灵活性而成为约束。
在我们最初的工作完成近两年后，是时候让团队聚在一起，彻底重新思考我们的入职系统，以获得新的功能:
- 强大，灵活，可扩展的后端，支持每个客户端(web, iOS, Android)
- 一种状态机，可以轻松地将用户从一个加载引擎分支到另一个
- 负责其UI的无状态客户端
我们将后端构建为两部分:
- 一个上线状态机(OSM)，它允许我们存储每个城市和产品的需求，并派生出用户在这个独特的上线过程中需要做什么
- 将客户端映射到步骤的改进的入职API
OSM允许我们为每个国家、州、城市或我们需要的任何粒度级别的每个入行流程轻松地配置一组步骤，再加上一个事件系统，允许我们根据用户的操作或输入轻松地将用户从一个步骤切换到另一个步骤。然后，登录API可以轻松地查询OSM，以了解用户处于流程的哪个步骤。
例如，这里有一个用于车辆解决方案步骤的附加状态机，它使没有车辆的人能够申请新的车辆，而不是被困在车辆步骤中。
我们最终得到了一个更灵活的架构，能够满足更多的需求，以及一个既可扩展又允许工程师更快行动的系统。
车辆步骤的JSON看起来像这样:
我们从弗拉斯克到龙卷风，一个异步Python框架，允许更多的可伸缩性和速度。这个导入API使用了我们最初的JSON模式架构的一个轻量级版本，其中只有数据被传递给客户端(而不是UI定义)。这一决定允许我们将100%的业务逻辑保留在共享后端，同时受益于每个客户端本机UI框架的灵活性。
当一个潜在的驱动程序加载一个客户端(Android、iOS或web)时，客户端向onboarding API发出一个请求，该API通过ping OSM来查找用户的状态，然后返回渲染页面所需的所有数据。当用户提交信息时，也会发生同样的事情。如果成功，API将返回下一步的数据。在失败的情况下，它返回一个错误。
这个新的合作伙伴入职系统是一个全公司使用的平台——例如，中国增长团队在网上建立了一个完全不同的体验。有了我们的API，团队可以专注于对他们来说重要的事情，即客户体验。
过度增长的教训
以下是我们通过设计优步迄今为止最强大、可扩展的司机-合作伙伴网络入职流程学到的东西:
船早。不要过早优化。
我们构建最初的web入职流程的方式允许我们快速证明我们的想法，解决手头的问题，并开始获得关于如何使用工具的反馈。如果不是首先这么做，优步就不可能发展得这么快。
没有银弹。
当我们在寻找框架以确保我们能够构建与我们的业务一样快的扩展时，我们被Tornado所吸引。在Uber中存在Python和Tornado支持，因为它是异步的，这意味着我们可以减少延迟以获得更快的速度。
也就是说，编写异步应用程序需要一些调整。为了利用Tornado的事件循环，我们不得不投入更多的时间来优化我们编写代码的方式——速度不会因为我们使用Tornado而免费获得。我们还面临着难以调试的内存泄漏，这是我们在Flask中不会遇到的。
我们仍然面临着需要解决的难题。
尽管我们已经建立了一个更好的解决方案，让世界各地尽可能多的人帮助为每个人提供安全可靠的交通，但在任何地方提供虚拟上车体验仍然是一个挑战，需要我们更长的时间才能完全解决。
我们还有一段距离才能实现我们的最终目标，即司机合作伙伴在早上完成优步平台的注册流程，当天开车，然后使用当天晚上赚到的钱。与此同时，我们调整我们的代码以达到完美。
乔纳森·佩平(Jonathan Pepin)是一名出生于法国的工程师，在加拿大接受教育，在优步工程公司工作增长团队．他现在在阿姆斯特丹．
