我们看到越来越多的组织重新关注采用和改进他们的DevOps实践，以帮助优化他们的软件开发生命周期并提高他们的交付速度以更快地到达市场和客户。以下是您需要了解的四个关键DevOps指标，以及团队如何使用它们来提高开发生产力和性能，从而为客户构建更好、更快的产品。什么是DevOps指标？DevOps指标是用于衡量团队DevOps软件开发过程的性能和效率的数据点。由于DevOps集成了开发和运营的功能，指标应该能够衡量和优化相关流程和人员的绩效。从DevOps指标中衡量和收集见解可以帮助管理人员收集对其团队流程和瓶颈的可操作见解，并在出现障碍时迅速采取补救措施。因此，DevOps指标使团队能够成功实现他们的目标。四个关键DevOps指标Google的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测试团队解决错误或事件的速度。高绩效团队可以快速从事件中恢复，而低绩效团队可能需要一周或更长时间才能恢复。测量MTTR是确保弹性和稳定性的重要实践。如何衡量MTTR可以通过计算事件发生和解决之间的时间来衡量。运营团队应配备正确的工具、协议和权限来解决事件。优化MTTR的提示要实现快速MTTR指标，请以小增量部署软件以降低风险，并部署自动监控解决方案以防止故障。构建在发布前经过测试的更健壮的系统更好的日志记录提供数据，以便在问题失败时更快地诊断和发现问题DORA指标不会改进开发过程。管理人员还应该制定关于如何利用和改进DORA指标的战略。最好的方法是对团队的当前状态进行基准测试，并制定项目目标和计划。定义目标和截止日期时要关注的两个主要因素是项目分配和项目计划的准确性。管理人员应根据业务优先级确定团队并分配项目。优化的项目分配流程还有助于确保工程团队在任何给定时间都在处理正确的项目，并根据需要进行更改。项目规划使管理人员能够掌握时间表并确保在冲刺中实现目标。始终如一地衡量这一点有助于识别和解决进步的障碍。在这里，周期时间、代码改动和冲刺速度等指标提供了实现每个冲刺目标和按时完成所需的支持。促进协作以定义目标并调整团队以实现目标可以帮助取得更好的结果。一种有效的方法是召开每日站立会议，将团队聚集在一起并明确目标。站立会议还可以让每个人了解谁在做什么，但更重要的是，它可以帮助团队识别障碍并制定解决这些障碍的路线图。为了使站会高效且有效，管理人员可以采用异步站会，这不仅可以达到目的，还可以保留工程师的专注时间和文档信息以供将来参考。建立更好的工作流程管理者应该专注于创建数据驱动的工作流程。他们应该有办法收集各种软件工程指标，例如拉取请求指标、开发人员专注时间、团队周期时间、代码流失等，以设计一个高质量、数据丰富且失败几率低的流程。称为CI/CD持续集成和持续交付结合了将所有编写的代码持续集成到共享存储库中，触发自动化测试，并最终提供持续交付手段的实践。CI/CD自动化了将新代码从提交到生产所需的大部分或全部手动干预。这包括构建、测试和部署阶段。借助CI/CD管道，开发人员可以返工和更改自动测试和推送部署的代码。这促进了更高的开发频率和更改的提前期，同时也限制了更改失败的空间。
