Coinbase的可伸缩性和开发人员生产力

在Coinbase，我们关心开发人员的生产力。随着我们从一项服务扩展到多项服务，我们对工具进行了投资，这些工具使我们有信心快速将新服务交付生产。像其他成长中的科技公司一样，我们一直在通过新的微服务来扩展我们曾经单一的基础设施，这些服务封装了定义明确的任务，降低了技术债务，并帮助我们快速行动。当我们沿着这条路走下去时，我们的DevOps团队一直在努力保持较高的开发人员生产力。我们已经使用数据来指导我们的工作，现在我们在这里分享，并希望更多的人也会这样做。这篇文章让我们一窥Coinbase部署背后的数据，也是我们看待开发人员生产力的一种方式。

在早期，Coinbase很简单。当我们在2015年初首次能够测量部署数据时，我们只运行一项生产服务：Coinbase.com。Coinbase是一款Rails应用程序，我们在Heroku上运行。生活很美好。部署是一个命令，我们行动迅速，我们构建了一项服务，为我们今天的发展奠定了基础。

2015年2月在Heroku上运行时，我们部署了120次，我们在一个小团队中部署频率最高的前3名人员占所有生产部署的58%。当时工程师每月的部署中值是8次。你可以在下面看到我们团队的一些部署趋势，寒假过后又回来了，一直持续到2015年。在这段时间里，我们只衡量我们在Heroku的部署情况。(虽然我们在2015年2月推出了后来成为GDAX的服务，但它的早期部署没有在这个数据集中衡量)。

随着2015年的到来，我们的基础设施发生了两大变化。我们的安全和合规性需求不断增长，以加速我们迁移到更安全的环境(我们选择了AWS)，我们开始为支持GDAX的分布式架构创建新服务。为了实现这两个目标，我们设计并开始部署到新的云基础设施中，以安全地提供多种服务。我们首先部署了GDAX和Coinbase，随后很快也部署了GDAX和Coinbase。

我们需要赋予开发人员快速行动的能力，同时提供系统安全可靠的信心。

当我们设计新的基础设施和使其可访问的部署管道时，我们努力改进的关键指标之一是部署速度，即开发人员能够安全地交付生产的频率。随着软件继续吞噬世界，像docker这样的公司正在努力使互联网变得可编程，开发人员可以比以往任何时候都更有能力-除非有什么东西阻碍了他们。当基础设施规模扩大和开发团队速度减慢时，公司会出现几种故障情况。高素质的工程师可能会去一个更有能力的环境，低总线因素可能会给您留下难以理解的服务，或者一个考虑不周的体系结构可能会使错误更难追踪。按照我们行业的发展速度，拖慢公司的发展速度是不可接受的。我们需要赋予开发人员快速行动的能力，同时提供系统安全可靠的信心。

我们努力改进的关键指标之一是部署速度，即开发人员能够安全地交付生产的频率。

为了在赋予工程师权力和管理安全性的同时保持较高的部署速度，我们设计了新的部署系统：Codeflow。

从2015年6月到7月，我们开始使用Codeflow自行部署Codeflow，并将GDAX和Coinbase迁移到我们在AWS中的新部署渠道。与此同时，我们开始让更多的工程团队成员登上Codeflow。在给予我们的工程师快速行动所需的信心的同时，我们努力鼓励更多的人更频繁地安全部署。我们为保持高部署速度所做的一些事情包括：

共识：没有一个人(或故障点)可以对我们的生产环境做出任何改变，但与不同程度的共识一起，工程师们被赋予了快速行动的能力。

安全部署：部署到生产环境总是安全的。任何人都可以随时重新部署任何服务。我们依靠服务级别运行状况检查来确保系统在蓝/绿部署完成之前正常运行。其他启发式方法，如防止部署旧的或不安全的提交，最大限度地提高了部署始终安全的可能性。如果Deploy按钮为绿色，则任何人都可以单击它。

入职：对于任何有自我意识的新员工来说，部署到生产中听起来都很可怕，所以我们鼓励新工程师在第一天就部署coinbase.com。我们希望每个人都知道这样做是安全的。

安全管道：在提交可部署或部署完成之前，多层内联安全扫描为已知或可能的安全问题提供尽可能快的反馈。

失败：部署总是失败。当这种情况发生时，我们很快就会强调这永远不是部署者的错。取而代之的是，我们看看如何从事后总结中吸取教训，并通过更好的自动化来防止这种失败再次发生。

有了共识，没有人能对我们的生产环境做出任何改变，但工程师们可以一起快速行动。

Codeflow对我们部署速度的影响立竿见影：尽管我们提高了进入更安全云的渠道的安全性和控制力，但从6到7月，我们的部署数量增加了450%，从128次增加到580次。这远远盖过了我们工程团队在那几个月里大约30%的规模增长，是我们工作正在加快公司速度的一个很好的指标。

随着我们服务复杂性的增加，我们的失败率也在增加。部署失败的原因可能有多种，既有好的，也有坏的。好的失败可能会保护我们免受重大更改或性能影响，使其无法投入生产，但其他错误或错误配置可能会降低部署速度。在过去的一年里，我们通过改进自动化来减少故障。当我们在7月份开始通过Codeflow部署我们所有的服务时，我们达到了27%的部署失败的峰值。随着我们提高了部署弹性，并增加了对工程师可能出现的问题的早期反馈，我们已将故障率降至约15%，并且仍在改进。

随着团队开始信任这个新的渠道，我们开始通过引入新服务来进一步提高开发速度。随着我们的反欺诈、安全、开发运营、产品团队不断扩大，这些服务包括更好地封装现有功能和全新的内部和外部产品。您可以在下面看到我们的服务的全面增长，目前已达到82项。包括在这些新服务中的是全新的支付和钱包服务，这些服务现在可以故意以比面向未来的产品更严格的方式发展。

自从迁移到我们的新部署渠道以来，我们现在有更多的人自信地部署更多的服务，比以往任何时候都更频繁。在我们运行自己的基础设施之前，每个工程师每月部署的中位数是8次。在迁移到Codeflow之后，这一数字增长到11次，现在每个开发人员每月部署的中位数是16次。您可以看到下面的图表，其中突出显示了我们部署最频繁的前5名工程师的部署情况。

现在我们有了高效扩展的基础，我们面临着新的挑战。使用量的显著增长正在对我们的系统进行压力测试，以前的小规模系统现在需要新的优化来支持我们的负载。展望下个季度，我们正致力于提高我们基础设施的可靠性、工作流程和弹性，而不会影响开发人员的工作效率。

想要分享更多关于开发人员生产力和速度的信息吗？我们写这篇文章的灵感来自于DevOps的年度状况报告，我们很想了解更多关于您的团队如何保持高效的信息。

如果您有兴趣让开发人员在一个很好的环境中快速行动，我们很乐意与您合作。我们在这里招聘各种工程师职位。

感谢格雷厄姆、杰克、卢克、萨索、杰里米和布莱恩帮助我们实现了这一点！