想象一下，您的团队获得了一笔预算，可以将软件工程师的数量增加一倍。那太好了！您终于可以修复所有错误，实施新想法，并清理多年来积累的所有技术债务。对吗？等等，等等……不要那么快。

首先，招聘新软件工程师并让他们入职需要时间。他们需要了解产品领域，深入研究技术堆栈，还要了解公司特定的工具。他们应该熟悉流程并与同事建立联系。即使入职进展顺利，一年内你也可能无法使团队的绩效翻一番[参见：布鲁克定律]。

那么，让我们用资深员工换下初级员工吧！或者让我们开始与人力资源部门讨价还价，这可能会给你带来错误的人选。好吧，这也可能行不通。优秀的人才确实很重要，但正如爱德华·戴明曾经说过的“坏的制度每次都会打败好人”（另请参阅著名的红珠实验或 [ Walt88 Ch4]）。

想想看。不知何故，你已陷入了难以跟上所有这些任务和错误的境地，对吧？如果你设法增加了额外的资源，但一年后，你所得到的只是以更快的速度累积的技术债务，那该怎么办？

来源我参加我梦想的明年的预算会议。

好的。让我们改进系统。但是我们到底需要做什么呢？让我们遵循一种行之有效的持续改进方法。首先，选择对您的公司重要的以结果为导向的指标 [ Seid19，Hubb14 ]。然后，通过逐一解决最制约的因素来专注于改进它们 [ Gold04 ]。

在本文中，我们分享了我们的团队如何在不增加额外资源的情况下，在一年内将软件交付绩效提高一倍。我们使用DORA指标，因为它们可以预测组织绩效和幸福感的改善 [ Fors18 ]。

DORA 指标

DevOps 研究与评估 ( DORA ) 是一项正在进行的研究计划。它旨在了解推动软件交付和运营绩效的能力。DORA 建议使用四个关键指标来预测组织绩效：

部署频率 (DF)：贵公司多久将代码部署到生产环境一次？变更前置时间 (LTFC)：从代码提交到生产环境运行需要多长时间？变更失败率 (CFR)：生产变更中有多少百分比导致服务质量下降并需要补救？恢复时间 (TTR)：当发生影响用户的服务事件或缺陷时，通常需要多长时间才能恢复服务？

我们的金融科技业务部门的团队于 2022 年中期成立，负责金融领域下的多个流程。

图 1. 2023 年初的服务状况

所有功能都是在五年前作为单体应用的一部分实现的（见图 1）。从那时起，大部分后端逻辑都被提取到微服务中。

团队开始跟踪 DF 和 LTFC 指标，并在年初设定了基线。在接下来的几个月里，团队进行了一系列改进。这些变化导致指标在年底前提高了一倍。

图 2. 根据 DORA 指标衡量，团队交付指标提高了两倍。

提高交付速度却损害质量，这将是一场惨胜。不幸的是，我们发现很难使用建议的 DORA 稳定性指标 CFR 和 TTR（参见 [ Dav21、Void22、Mor23 ]）。相反，团队使用了可靠性指标和未解决缺陷数量。后者需要跟踪影响许多用户的重大事件。前者是为了解决可靠性指标未捕获的个别客户的问题。

3 月份，后端服务的 DF 为每月 15 次，LTFC 约为 14 小时。后一个指标意味着软件工程师通常需要等待近一天的时间才能将更改部署到生产中。这表明开发人员体验不太好，并且上市时间更长。

图 3. 后端服务的统计数据和实施的主要改进。

主要问题是代码难以理解且难以更改。如果报告了错误，则需要数周时间进行诊断、找到修复方法并将其部署到生产中。单元测试覆盖率很低，团队对此没有信心。每个人都不愿意进行任何改进，担心这会以意想不到的方式破坏代码。

测试自动化、文档和内部质量看起来是最主要的制约因素。团队决定开始测量和改进它们。

团队采用了童子军规则，通过重构和测试自动化来提高代码质量，同时不停止所有功能工作。在实施更改或修复缺陷的同时，您还努力改进周围的代码。这不需要是一个巨大的改进。这可能很简单，比如为您接触的类添加单元测试或进行小规模重构以对抗代码异味。

我们发现童子军规则使重构更加高效。首先，改进刚刚处理的代码所需的时间更少。其次，您更有可能改进更改更频繁的代码。

童子军规则

“离开露营地时，一定要保持干净。”如果你发现地上一片狼藉，不管是谁弄的，你都要把它清理干净。你有意为下一批露营者改善环境。罗伯特·C·马丁。[ Hen10 ]

不幸的是，要掌握重构，光读大师们的好书是不够的，例如 [ Fow18、Mar08、Ker04、Cla21 ]。重构技能需要花时间学习，经常练习才能熟练。在实际任务中练习重构非常困难，因为我们经常面临时间压力，而且实际代码也更复杂。因此，团队开始练习重构技巧，以获得更多解决代码异味的实践经验。我们还发现它们对于测试我们的想法很有用。

“如何才能成为全明星运动员？显然，体能和天赋会有所帮助。但伟大的运动员每天都要花上好几个小时练习” [ CodeKata ]。

6 月份，代码审查显然是最大的瓶颈。合并请求(MR) 通常非常大，在代码审查期间浏览它们非常困难且耗时。这是一项痛苦且不受欢迎的任务。改善这种情况的方法是采用小批量工作（即支持小 MR）并同意将代码审查作为优先事项。结果，团队在 7 月份的代码审查时间大幅减少。

7 月份，测试覆盖率的提高使得团队几乎无需手动回归测试即可部署到生产环境中。此时，部署过程平均需要 40 分钟。它需要许多手动步骤，包括两次金丝雀部署和验证。根据我们的观察和统计，所有这些手动步骤都是多余的。例如，过去在金丝雀部署期间从未出现过任何问题。如果是这样，为什么要花时间在它们上面呢？

尽管过去没有人这样做过（至少在我们部门没有），但团队还是决定自动化部署。这个想法是让 MR 在合并到主干后直接部署到生产中，而无需任何手动验证。显然，人们担心这会破坏质量。另一方面，团队也有不错的安全网：良好的测试自动化、同行代码审查、小改动等。

团队决定尝试一下。如果出现任何问题，可以借助我们与质量相关的指标检测到，并恢复到旧的“安全”程序。幸运的是，这一变化并没有影响质量，而是将部署时间从 40 分钟缩短到 4 分钟。DF 和 LTFC 指标也反映了这一改进，8 月份部署次数增加到每月 43 次，部署时间为 1.3 小时。

来源如果我们一遍又一遍地做同样的事情，我们就会得到同样的结果（引述）。

总体来看，截至10月，DF从3月份的每月15个改善到10月份的每月37个，LTFC从3月份的13.8小时改善到10月份的4.2小时。

单体的紧密耦合和部署工具是我们无法绕过的问题。每月 6-8 次部署的 DF 和 2-3 天的 LTFC 导致糟糕的开发性能和体验。工程师被激励批量提交，并不惜一切代价避免部署。我们公司处理此问题的推荐方法是将页面迁移到微前端(MFE) 技术。

图 5. UI 页面的统计数据。MFE 迁移项目于 8 月完成。这导致 DF 大幅提高，LTFC 也降低。MFE 的 MR 审核流程的变化导致 10 月及之后的 LTFC 有所改善。

该团队针对几个最重要的页面启动了迁移项目。

微前端，MFE

微前端是一种前端 Web 开发模式，其中可以通过不同的构建构建单个应用程序。它类似于微服务方法，但适用于用 JavaScript 编写的客户端单页应用程序。它是多个前端应用程序分解和路由的解决方案（维基百科）

新的 MFE 页面于 9 月面向所有用户推出。团队发现性能有所改善。然而，一天的 LTFC 远未达到我们的预期。当我们收集统计数据时，这让我们大吃一惊。经过这么多努力，我们仍然需要等待这么长时间才能将我们的更改投入生产！什么？

来源：我，当团队发现 MFE 迁移并没有给我们带来我们所希望的性能时。

我们需要查看过去一个月的所有 MR。对于每个 MR，我们都会记录其提交、评论、批准、合并和部署时的统计信息。

事实证明，MFE 申请的 MR 审核流程比平时更复杂。例如，它需要团队外的专家 MFE 社区的批准。因此，批准 MR 的平均时间为 17.1 小时。

我们联系了 MFE 专家社区，讨论了如何微调流程。我们实施了几项优化措施，将获得批准的平均时间缩短至 8 分钟（是的，没错，这是因为我们有很多小型 MR）。随着批准时间缩短，我们还同意尽量不批量部署。这使得部署时间缩短至 1 小时。

结果，10月份，LTFC缩短至14小时，这是一个很大的进步，并被视为显著的性能提升。

上述所有变化都使团队的软件交付性能提高了一倍，如图 2 所示。其中一些变化需要大量的开发工作。许多变化涉及改变团队的工作方式，不需要做太多工作。一些变化需要改变思维方式和开发新技能。所有这些都不需要增加额外的资源。

所有这些努力最重要的成果是，他们开启了一种新的工作方式——专注于内部质量和实验。如果软件工程师发现代码异味，通常更容易修复它，而不是管理额外的技术债务。团队现在可以验证最重要的决策，而无需将它们与其他优先级较低的决策分批处理。

管理、协调和沟通也变得更加容易。首先，因为需要部署的代码更少。例如，软件工程师可以与我们的 UX 设计师坐在一起，随时进行细微更改。他们将在几分钟内完成工作，无需任何文书工作和管理。其次，因为所需的资源更少。

最后，当你能在几小时而不是几天内看到你的工作成果时，你会感到更满意！

有人可能会说，软件交付是价值流中很重要但又微不足道的一部分，因此，我们可能没有为公司带来多大改变。这很公平。然而，破窗理论在这里适用：如果我们改进了软件交付，那么它也会鼓励其他人也改进。如果项目经理要等一个月才能向客户交付任何有意义的东西，他们为什么要考虑快速试验呢？

特别感谢团队和为本文做出贡献的人。非常感谢您的帮助！

作者:Egor Savochkin

出处:https://medium.com/booking-com-development/dora-metrics-at-work-46c835a86a89