两年前，优步之前的聊天应用开始显示出无法适应我们增长的迹象。出现了应用程序崩溃、性能中断和宕机等问题，削弱了我们公司有效在线沟通的能力。由于用户满意度处于历史最低水平，我们需要一个新的解决方案。
随着运营620个城市，我们为我们识别聊天解决方案至关重要，使Uber员工能够在桌面和移动中可靠地沟通，而不管他们在世界的位置。为实现这一目标，我们建立了一些核心要求。要开始，我们需要一些可以扩展的东西来支持我们不断增长的员工人口，以及作为副产品的控制成本。我们还需要一个平台，可以轻松地与各种内部工程，业务和操作工具集成。
我们评估了互联网中继聊天(IRC)和许多其他流行的聊天客户端，很明显，没有一个交钥匙的第三方解决方案能够满足优步的核心需求。
所以在测试了多个现成的替代方案后，我们利用开源平台建立了uChat，这是我们自定义的内部消息平台差了和木偶,这个超级标准用于部署配置管理。在本文中，我们将讨论我们的团队如何在短短三个月内将公司转变为一个新的解决方案，该解决方案能够在一个统一的聊天环境中每天向数万名用户可靠地发送超过100万条消息。
将开源
为了加快开发过程，我们决定在一个开源平台上构建我们的解决方案。鉴于我们希望直接影响路线图和控制长期重复成本，这一选择特别具有吸引力，如果我们从头开始，这将更加困难。
为了充分利用我们的混合构建方法，我们需要一个强大的开源构建块，它具有通用的API、高质量的代码库和一个充满活力的开发社区。我们评估了各种XMPP,Erlang和基于JavaScript的选项。由于我们的主要要求是支持优步增长的能力，因此我们特别注意聊天平台以其可扩展性而闻名。
作为性能验证的一部分，我们将每个开源产品推到它们的断点。例如，我们最初的目标之一是在一个聊天环境中模拟5万名用户的聊天行为。很快，这些平台中的许多都无法执行这些基本的负载测试。
对于剩下的选项，我们编写了一个测试工具来模拟成千上万的用户。测试套件的设计(上图1a)非常简单;这确保了我们的产品索赔可以通过最小的努力进行验证。在这个测试环境中，简单去塑造EntityConfig.（下面的图1B）封装了可以登录，加入通道和发送消息的用户。结合Go的本机科素，很容易达到我们的模拟目标。随着时间的推移，测试线束增长，提供更大的功能，更好地模拟复杂的用户方案。
经过几个月的测试和供应商审查，我们归零差了。大力超过了我们的最低性能预期，并与优步现有的良好技术堆栈。此外，他们的客户端用户界面与优步员工中流行的聊天应用程序相似。
下一个逻辑步骤是评估平台是否可以跟上优步的超生长，并维持我们对聊天的操作依赖。经过仔细考虑必要的因素，我们问自己：最重要的是到达超级尺度？
为了测试Mattermost适应这些条件的能力，我们的负载测试试图确定体系结构和服务器代码中可能影响性能的主要瓶颈。我们模拟了可变的消息发送速率、增加窗口和并发用户峰值，以建立一个基线。数以千计的虚假用户账号被创建，并被编程登录，加入房间，疯狂聊天，目的是触发崩溃和数据库锁定。
在测试期间，我们无法发现，发现它不仅仅是展出可扩展性有限的后端。我们测试的大多数用户界面都无法满足我们的攻击目标：例如，聊天室只能容纳100人左右，现有的用户界面无法同时搜索超过2万个频道。
当我们在规模测试中遇到瓶颈时，我们针对最具影响的性能违规者进行修复，并从已知的稳定负载级别重复此过程。与此同时，我们继续更新我们的测试以模拟日益现实的用例。我们最初的目标是70000个并发用户，每秒发送80到200条消息。如果能成功控制这一负荷，我们就能确保有足够的跑道供未来增长。
与开源社区合作，我们不断地剖析日志，确定根本原因，并发布新的补丁;周转速度是最重要的。随着每个新发现和构建，我们对整个系统的限制和快速适应规模需求的能力有了更深的认识。
随着时间的推移，很明显，最重要的是最能在优步规模成熟，我们在他们的平台上获得了信心。为了帮助别人使用我们的新合作伙伴开发，我们创建自己的聊天平台，我们做出了贡献我们的测试线束为开源社区工作。
用木偶管理Uchat架构
虽然负载测试最棘手的平台，但我们需要连续，可靠地对我们的新解决方案的基础架构和应用程序配置进行更改。最高的高可用性模式仍在早期的测试版中，因此我们经常在我们的代码中遇到错误。
在早期测试和开发阶段，UBER基础架构团队通过手工制作这些代码。稳定新的Uchat构建和服务器配置是一个可预测的繁琐和回归的过程，需要频繁更改以解决无意的配置错误。很明显，手动基础设施管理正在放缓我们下来，我们转向傀儡。
使用Puppet编码架构和服务器配置为管理支持快速Uchat改进所需的各种服务器和网络环境提供了坚实的基础。Puppet在我们的数据库拓扑中的许多机器中启用了一致和可重复的更改，并允许我们审核更改和执行部署代码审核。
在部署期间，傀儡的初步引入大大减少了无意的错误。然而，即使有基础傀儡基础设施 - 根据我们的一些重复性和一致性问题，我们仍然没有实现我们需要的速度。在这个阶段，我们没有使用不可变的服务器，这意味着对我们高可用架构的傀儡代码的变化具有相当大的副作用风险。此外，我们使用一个大型Monorepo，所有与傀儡相关的变化都必须收敛，增加这些并发症。
这种约束意味着我们无法快速部署新的基础架构和应用程序版本，以便我们的需求严重限制我们的迭代速率。因此，更新的Puppet部署配置可能需要一两天或两个以安全完成。同时，无关的Uchat绩效改进是每小时发货。我们的新木偶的工作流程更好，但仍有改进的余地。
为了提高uChat的部署速度，我们将基础架构代码作为Puppet模块转移到一个单独的存储库中。这将允许我们独立地对特定于uChat应用程序的配置更改进行版本、隔离和测试，而不考虑服务器基础设施配置。
重构和彻底测试我们的新Puppet模块后，我们依赖于木偶代码管理器将基础架构更改推向新铸造的暂存和生产环境。基于模块的方法允许我们将应用程序配置问题分离从基础架构/服务器配置问题，更轻松地分布更改，根据Uchat应用程序本身的需求和发布时间线。
使用Puppet模块，Puppet代码管理器和支持A / B部署，我们最终实现了我们需要的快速和一致的部署更改控制。现在，我们的整个分期和生产环境的娱乐可以在不到一天的时间内可靠地完成。
创建无缝的用户体验
在我们的基础设施日趋成熟的同时，我们还必须构建一套直观的、优步化的web、桌面和移动应用程序。为了抢占先机，我们将Mattermost桌面应用程序分成了分支，并开始为我们的内部客户端做一个简单的白色标签。另一方面，Mattermost的移动应用程序需要完全重组，以实现我们正在寻找的用户体验(UX)类型。
原始IOS和Android Uchat应用程序包含一个简单的WebView来加载整个Uchat网页，导致负载时间极慢。此外，WebView引起了强迫不必要的加载，不完整的文件下载和不均匀体验的刷新。为了增加我们的员工并加速我们的构建，我们与之合作Fullstack Labs.重新编写这些应用程序原生并且，正如我们尽最重要的平台所做的那样，贡献我们建立在开源社区的一切。
目前，uChat的移动客户端是通过我们的内部应用商店部署的，桌面客户端是通过厨师和系统中心配置管理器（SCCM）。为了限制移动uChat版本的数量和简化持续的支持，我们在iOS和Android应用中建立了自定义机制，当新的uChat版本可用时，会提示用户升级。我们还设计了在需要强制升级时使旧客户端版本失效的能力。
我们对平台的可扩展性的愿景确保了我们提供一个与我们生态系统中的其他工具集成的用户体验。为了实现这一点，我们花了几个月的时间将50多个遗留集成从之前的解决方案转换到uChat。api和webhook允许现有的内部服务集成并扩展聊天功能，而不仅仅是一对一的对话，比如Uber的内部部署系统，Udeploy.，它会在新构建完成时通知工程师，或者特使，支持我们的办公室访客登记服务。
与用户建立信任
在实现任何企业应用程序时，驱动用户采用和改变现有行为可能是一项挑战。在把公司转移到像uChat这样的本土工具上的同时，需要额外的小心来灌输uChat将比现有的消息平台更可靠的信心。为了建立这种信心，并尽可能无缝地过渡到uChat，我们预先为所有员工配备了账户，并迁移了近20,000个聊天室，这样员工就不必重新创建或重新加入他们以前工作过的任何聊天室。
尽管我们尽了最大努力，但还是遇到了困难。随着我们将越来越多的员工整合到uChat上，间歇性的宕机使得一些早期用户不愿意完全采用这个应用程序。为了减轻担忧，我们保留了传统的在线聊天，而uChat稳定下来，有更多的时间来建立自己。
为了进一步与员工进一步融合Uchat，我们对透明度翻了一番。我们承认错误，因为它们被发现，传达的修复计划和部署的修补程序。我们还广泛使用监控图，以便任何兴趣的人都可以看到Uchat的实时健康。
一旦我们能够持续展示uChat 99.9%的可用性，我们就开始贬低我们的传统聊天系统。通过缓慢地禁用诸如房间创建和集成等功能，直到我们完全停止使用遗留系统，从而实现了完全的关闭。我们定期发布产品更新，分享技巧，并收集常见问题和用户指南等资源，以确保员工感到充分支持。我们还开通了一个反馈渠道，员工可以立即得到帮助并提出新功能建议。
在我们的经验中学到的一个关键教训是，计划和组织的一致性需要拒绝现有聊天应用程序，这需要我们的用户比我们最初预期的更多的支持和协调。但通过保持透明性、可访问性和快速交付改进，我们与早期采用者建立了良好的关系基础，并随着时间的推移，转变了整个公司。
uChat的未来
在接下来的几个月里，我们打算实现更多的功能，继续监视用户反馈，并加入哈斯，公司和他们的开源社区。
Uchat只是我们团队的众多解决方案之一，以促进优步的合作，沟通和生产力。我们不断开发，部署和维护优步的内部工具包，每年在再生生产力和软件许可中保存公司数百万美元。如果为高级迅速增长的全球公司的工程到Next-Gen内部系统，就像优步声音一样有趣，考虑申请角色优步员工生产力工具团队的成员。
Marissa Alvarado-Lima是优步技术服务团队的技术作家，Stanley Chan和Chris Duarte是优步员工生产力工具的软件工程师，Ed Wolf是优步员工生产力工具团队的高级产品经理。软件工程师Sameer Patan和Josh Schipper，高级网站可靠性工程师Matt Beard，工程经理Benjamin Booth和产品设计师Nayong Park也对本文有贡献。
