学习如何使用DevOps指标来提高开发团队的速度、一致性和效率。
人们看到越来越多的组织重新关注于采用和改进他们的DevOps实践，以帮助优化他们的软件开发生命周期，提高他们的交付速度，以更快地到达市场和客户。以下是关于DevOps的四个关键指标以及团队如何使用这些指标来提高开发效率和性能，为客户构建更好、更快的产品所需要知道的全部内容。
什么是DevOps指标?
DevOps指标是用来衡量团队DevOps软件开发过程的性能和效率的数据点。因为DevOps集成了开发和运营的功能，所以指标应该能够度量和优化流程和相关人员的性能。
通过DevOps度量和收集见解，可以帮助管理人员对团队的流程和瓶颈收集可操作的见解，并在遇到阻碍时迅速采取补救措施。因此，DevOps指标使团队能够成功地完成目标。
DevOps的四个关键指标
谷歌的DevOps研究和评估(DORA)团队已经确定了四个可以指示和优化DevOps性能健康状况的关键指标。DORA四键项目旨在生成有价值的数据和收集见解，以提高围绕DevOps实践的工程生产率。以下是四个核心DevOps指标，通常被称为DORA指标:
•部署频率:度量团队成功向生产发布变更的频率，表明团队交付软件的速度。
变更前置时间:从变更请求的工作开始到交付生产并最终交付给客户的这段时间称为变更前置时间。团队使用前置时间来确定开发过程的效率。
更改失败率:度量产品更改在发布后导致失败的比率。它是一个团队所产生的代码质量的指标。
•平均恢复时间:衡量通过生产变更解决事故或故障所需的时间。
部署频率和变更前置时间的度量计算团队的速度，而变更失败率和恢复度量的平均时间则关注软件的稳定性。
根据2019年DevOps加速状态报告，这种形式的DevOps指标分析并将团队分为低、中、高和精英表现者，后者达到或超过其组织绩效目标的可能性是后者的两倍。通过使用这些指标，组织可以跟踪并改进团队的绩效和过程的有效性。
部署频率
团队的部署频率直接转化为将代码或版本部署到生产中的速度。这个DevOps指标可能因团队、特性和组织而异。它还取决于产品和内部部署标准。例如，一些应用程序可能每年只发布几个大型版本，而另一些应用程序可以在一个季度内进行大量小型部署。
部署频率如何影响业务
更高的部署频率比可能表明团队正在更快地跟踪、改进或向市场推出新功能。更高的部署频率还为客户和团队之间的持续反馈循环铺平了道路，从而转化为向最终用户发布更好版本的产品。谷歌在DORA上的研究还表明，主动团队有更高的部署频率，这意味着他们可以按需部署。
如何衡量
在一段较长的时间内跟踪部署频率可以帮助跟踪速度的变化、跟踪瓶颈并更快地采取纠正措施。测量部署频率的一种有效方法是从GitHub、Jira和其他地方收集数据，以确定计划中的代码是否已交付。这样做不仅允许管理人员跟踪部署频率，而且还可以清除阻碍因素，因为对部署频率的常规关注可以揭示遗漏的部署，并了解其背后的模式和原因。
实现更高部署频率的技巧
•自动化部署过程中的重复任务，建立和配置连续交付管道
•对发布进行持续改进，以优化最终结果
•只在必要时获得持续的改进反馈
•明确需求和期望，不要给不必要的范围变动留下空间
•优化周期时间，使其更有效，以确保部署在定期进行
改变交货时间
团队使用变更前置时间(不要与周期时间/前置时间混淆)来确定开发过程的效率。较长的前置时间可能是由低效的过程或开发或部署管道中的瓶颈造成的。团队的目标通常是缩短交货时间，但较高的交货时间并不总是麻烦的迹象。有些版本可能很复杂，可能需要更多的时间来交付。
交货时间的改变如何影响业务
LTC指标有助于跟踪流程中的低效率。前置时间优化的主要目标之一是通过自动化(主要是测试过程)来增加部署，从而缩短部署的总体时间。与部署频率一样，前置时间也可能因团队和产品而异。因此，组织应该跟踪、设置基准，并随着时间的推移比较单个团队的表现，而不是将它们与其他团队进行比较。
如何衡量
前置时间是通过测量初始提交和发布版本投入生产之间的时间来计算的。由于交货期由开发周期中的多个阶段组成，团队应该计算开发过程的每个阶段的时间，以确定瓶颈。跟踪周期时间可以帮助理解开发过程中的不同步骤，确定有问题的区域，并执行相同的RCA。坚持这样做有助于发现瓶颈，并在未来的开发周期中更好地制定战略。
优化交货时间的建议
缩短交货时间的一个关键因素是改进测试和开发团队之间的协作，以改进质量保证。这有助于经理更好地理解DevOps的周期时间。
•自动化测试可以消除重复的工作和消耗开发人员时间的琐碎更改。
•工作在小增量保持在当前模块的顶部，以确保没有错误，可能需要在未来返工。
•对重复版本进行更改，以确保主代码不受影响。
更改失败率
更改失败率度量生产中部署失败的百分比，需要进行错误修复或回滚。这个DevOps指标检查部署次数与失败次数，以解码DevOps流程的效率。
变更失败率如何影响开发过程
更改失败率指标跟踪花费在纠正问题而不是开发新项目上的时间。这有助于管理人员了解他们的团队在哪些方面投入了精力，并有助于使团队和流程在编写新代码上花费更多的时间，而不是处理错误和返工。
如何衡量
用部署失败的次数除以部署的总次数就得到了CFR。团队应该确保变更失败率降到最低。但这也并不意味着要花费太多时间构建和测试每个模块，因为这可能会影响交付时间。
优化变更失败的提示
更改失败并不总是表明代码执行得很糟糕。有时，外部因素，如不明确的需求或小错误，可能导致程序失败。
•确保代码按照sprint计划编写、评审和测试
•控制sprint速度和代码变动指标，可以帮助了解所做的更改及其背后的原因
平均恢复时间(MTTR)
MTTR是衡量部署后为解决问题而采取的对策所花费的时间。团队快速从失败中恢复的能力依赖于他们在失败发生时立即识别失败(MTTD)并发布补救措施或回滚导致失败的任何更改的能力。这通常是通过持续监视系统运行状况并在发生故障时通知操作人员来实现的。
MTTR如何影响开发过程
MTTR测试团队解决bug或事件的速度。高绩效团队从事故中快速恢复，而低绩效团队可能需要长达一周或更长时间才能恢复。测量MTTR是确保弹性和稳定性的关键实践。
如何衡量
MTTR可以通过计算事件发生和解决之间的时间来测量。为了解决事故，运营团队应该配备正确的工具、协议和权限。
优化MTTR的技巧
要实现快速的MTTR度量，可以以小增量部署软件以降低风险，并部署自动监视解决方案以抢占故障。
•构建更健壮的系统，在发布之前进行测试
•更好的日志记录提供了数据，以便在故障发生时更快地诊断和发现问题
•这可以通过不断检查错误和阻碍来实现
改进DORA指标的策略
关注框架
简单地使用DORA指标并不能改进开发过程。管理者还应该制定如何利用和提高DORA指标的策略。做到这一点的最佳方法是对团队的当前状况进行基准测试，并为项目的目标和计划绘制路线图。在定义目标和截止日期时，需要关注的两个主要因素是项目分配和项目计划准确性。
管理人员应该根据业务优先级确定团队并分配项目。优化的项目分配过程还有助于确保工程团队在任何给定的时间都在正确的项目上工作，并在需要时进行修改。
项目计划使管理人员能够保持在时间表的顶端，并确保一个sprint又一个sprint地实现目标。持续地衡量这一点有助于识别和解决阻碍进展的障碍。在这里，诸如周期时间、代码周转和sprint速度等指标提供了实现每个sprint目标和满足截止日期所需的支持。
促进合作
定义目标并使团队朝着实现目标的方向调整可以帮助实现更好的结果。做到这一点的一个有效方法是每天召开站立会议，把团队聚集在一起，明确目标。站立会议还能让每个人都知道谁在做什么，但更重要的是，它能帮助团队识别阻碍因素并制定解决问题的路线图。为了使站立会议更加高效和有效，管理者可以采用异步站立会议，这样不仅可以达到目的，还可以保留工程师的注意力时间和文档信息以供将来参考。
建立更好的工作流程
管理者应该专注于创建基于数据的工作流。他们应该有办法收集各种软件工程度量，如拉请求度量、开发人员专注时间、团队周期时间、代码变动和其他度量，以设计一个数据丰富的过程，该过程具有高质量和低失败几率。
号召持续集成和持续交付
持续集成和持续交付结合了在共享存储库中持续集成所有编写的代码的实践，触发自动测试，并最终提供持续交付的方法。CI/CD自动化了将新代码从提交到生产中所需的大部分或所有手动干预。这包括构建、测试和部署阶段。有了CI/CD管道，开发人员就可以对代码进行返工和更改，这些代码将被自动测试并推动部署。这促进了更高的开发频率和变更的前置时间，同时也限制了变更失败的空间。
