我们看到越来越多的组织重新关注采用和改进他们的 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。团队应确保将变更失败率降至最低。但这也不意味着要花太多时间构建和测试每个模块，因为这可能会影响交付时间。
优化变更失败的技巧
更改失败并不总是表示代码执行不当。有时，诸如需求不明确或小错误等外部因素会导致程序失败。
- 确保按照冲刺计划编写、审查和测试代码
- 保持冲刺速度和代码流失指标在检查中可以深入了解所做的更改及其背后的原因
平均恢复时间 (MTTR)
MTTR 是衡量部署后采取反制措施解决问题所需时间的指标。团队从故障中快速恢复的能力取决于他们在故障发生后立即识别故障 (MTTD) 并发布补救措施或回滚导致故障的任何更改的能力。这通常是通过持续监控系统健康状况并在发生故障时通知操作人员来实现的。
MTTR 如何影响开发过程
MTTR 测试团队解决错误或事件的速度。高绩效团队从事件中快速恢复，而低绩效团队可能需要长达一周或更长时间才能恢复。衡量 MTTR 是确保弹性和稳定性的重要实践。
如何测量
MTTR 可以通过计算事件发生和解决之间的时间来衡量。为解决事件，运营团队应配备正确的工具、协议和权限。
优化 MTTR 的技巧
要实现快速 MTTR 指标，请以小增量部署软件以降低风险，并部署自动化监控解决方案以预防故障。
- 构建在发布前经过测试的更健壮的系统
- 更好的日志记录提供数据以在出现故障时更快地诊断和发现问题
- 这可以通过不断检查错误和阻塞来实现
改进 DORA 指标的策略
关注框架
简单地使用 DORA 指标并不能改进开发过程。管理人员还应制定有关如何利用和提升 DORA 指标的策略。做到这一点的最好方法是对团队的当前地位进行基准测试，并绘制项目目标和计划的路线图。在定义目标和截止日期时要关注的两个主要因素是项目分配和项目计划的准确性。
管理人员应确定团队并根据业务优先级分配项目。优化的项目分配流程还有助于确保工程团队在任何给定时间都在正确的项目上工作，并在需要时进行修改。
项目规划使管理人员能够掌握时间线并确保在冲刺中实现目标。始终如一地衡量这一点有助于识别和解决阻碍进展的障碍。在这里，周期时间、代码搅动和冲刺速度等指标提供了实现每个冲刺目标和按时完成所需的支持。
促进合作
定义目标并调整团队以实现目标可以帮助取得更好的结果。一种有效的方法是召开每日站立会议，将团队聚集在一起并明确目标。站立会议还可以让每个人都了解谁在做什么，但更重要的是，它可以帮助团队识别障碍并规划路线图来解决这些问题。为了使站立会议高效和有效，管理人员可以采用异步站立会议，这不仅可以达到目的，还可以保留工程师的专注时间和文档信息以备将来参考。
建立更好的工作流程
管理人员应专注于创建基于数据的工作流程。他们应该有办法收集各种软件工程指标，例如拉取请求指标、开发人员专注时间、团队周期时间、代码流失和其他指标，以设计一个高质量且失败几率低的数据丰富过程。
呼吁 CI/CD
持续集成和持续交付结合了将所有编写的代码持续集成到共享存储库中，触发自动化测试，并最终提供持续交付手段的实践。CI/CD 使将新代码从提交到生产所需的大部分或全部手动干预自动化。这包括构建、测试和部署阶段。有了 CI/CD 管道，开发人员可以返工和更改代码，这些代码会自动测试并推送以进行部署。这促进了更高的开发频率和更改的提前期，同时也限制了更改失败的空间。
