详解衡量DevOps成功的 9 个关键指标

这里有九个关键的 DevOps 指标和 DevOps KPI，它们将帮助您实现目标。

四大 DevOps 指标：DORA 的四个关键

让我们从 Google 的 DevOps 研究与评估 (DORA) 团队建立的四个最常见的指标开始，称为“四个关键”。通过六年的研究，DORA 团队将这四个关键指标确定为表示 DevOps 团队绩效的指标，将它们从“低”到“精英”进行排名，精英团队达到或超过其组织绩效的可能性是两倍之多。让我们深入了解这些 DevOps KPI 如何帮助您的团队更好地执行并交付更好的代码。

1.部署频率

部署频率衡量团队成功发布到生产环境的频率。

随着越来越多的组织采用持续集成/持续交付 (CI/CD)，团队可以更频繁地发布，通常每天多次。高部署频率有助于组织更快地提供错误修复、改进和新功能。这也意味着开发人员可以更快地收到有价值的现实世界反馈，这使他们能够优先考虑将产生最大影响的修复和新功能。

部署频率衡量长期和短期效率。例如，通过每天或每周测量部署频率，您可以确定您的团队响应流程变更的效率。跟踪较长时期内的部署频率可以表明您的部署速度是否随着时间的推移而提高。它还可以指示需要解决的任何瓶颈或服务延迟。

2. 变更准备时间

变更前置时间衡量提交的代码投入生产所需的时间。

该指标对于了解您的团队对特定应用程序相关问题的响应速度非常重要。较短的交货时间通常更好，但较长的交货时间并不总是表明存在问题。它可能只是表明一个自然需要更多时间的复杂项目。变更的前置时间有助于团队了解其流程的有效性。

要衡量更改的前置时间，您需要捕获提交发生的时间和部署发生的时间。改进此指标的两个重要方法是在多个开发环境中实施质量保证测试，以及自动化测试和 DevOps 流程。

3.更改失败率

更改失败率衡量导致需要修复或回滚的生产失败的部署百分比。

更改失败率查看尝试了多少部署，以及这些部署中有多少在发布到生产环境时导致失败。该指标衡量 DevOps 流程的稳定性和效率。要计算更改失败率，您需要部署的总数，以及将它们链接到由错误产生的事件报告、GitHub 事件标签、问题管理系统等的能力。

超过 40% 的变更失败率可能表明测试程序不佳，这意味着团队将需要进行不必要的变更，从而降低效率。衡量变更失败率背后的目标是自动化更多的 DevOps 流程。自动化程度的提高意味着发布的软件更加一致和可靠，并且更有可能在生产中取得成功。

4. 平均恢复服务时间

平均恢复时间 (MTTR) 服务衡量组织从生产故障中恢复所需的时间。

在以 99.999% 可用性为标准的世界中，测量 MTTR 是确保弹性和稳定性的关键实践。在计划外中断或服务降级的情况下，MTTR 可帮助团队了解哪些响应流程需要改进。要衡量 MTTR，您需要知道事件何时发生以及何时有效解决。为了更清楚地了解情况，了解哪些部署解决了事件并分析用户体验数据以了解服务是否已有效恢复也很有帮助。

对于大多数系统，最佳 MTTR 可能小于一小时，而其他系统的 MTTR 小于一天。任何需要超过一天的时间都可能表明警报或监控不佳，并可能导致大量受影响的系统。

要实现快速的 MTTR 指标，请以小增量部署软件以降低风险并部署自动监控解决方案以抢占故障

它需要超过四个 DevOps 指标

DORA 的四个关键为提高您的开发实践的性能奠定了良好的基础，但它们只是一个开始。这里还有五个 DevOps KPI，可帮助您的团队更优化地执行。

5. 缺陷逃逸率

缺陷逃逸速度衡量“逃逸”测试并发布到生产环境中的错误数量。

该指标可帮助您确定测试程序的有效性和软件的整体质量。较高的缺陷逃逸率表明流程需要改进和更多的自动化，而较低的缺陷逃逸率（最好接近于零）表明运行良好的测试程序和高质量的软件。

要了解此指标，您需要跟踪已发布代码和软件中发现的所有缺陷。这意味着查看开发/QA 和生产中的缺陷，以便您深入了解从开发和 QA 进入生产的任何缺陷。一般而言，组织应努力在 QA 中找到 90% 的缺陷，然后再将版本投入生产。

6.平均检测时间

平均检测时间 (MTTD) 衡量事件开始与发现之间的平均时间。

在其他 DevOps 指标中，此测量有助于确定您的监控和检测功能在支持系统可靠性和可用性方面的有效性。衡量 MTTD 受其他 DevOps KPI 指标的影响，包括平均故障时间 (MTTF) 和平均恢复时间 (MTTR)。要计算 MTTD，请将给定团队或项目的所有事件检测时间相加，然后除以事件总数。

MTTD 的挑战在于准确了解 IT 事件何时开始，这需要分析和评估历史基础设施 KPI 数据的能力。

7. 自动化测试覆盖的代码百分比

自动化测试覆盖的代码百分比衡量了接受自动化测试的代码的比例。

自动化测试通常表明代码稳定性更高，尽管手动测试仍然可以在软件开发中发挥作用。目标是自动化测试覆盖更高比例的代码，尽管总是有一些损坏的测试是健康的——重要的是团队编写代码以按预期工作，而不仅仅是通过测试。

8. 应用程序可用性

应用程序可用性衡量应用程序完全运行和可访问以满足最终用户需求的时间比例。

高可用性系统旨在满足五个 9 (99.999%) 的黄金标准 KPI。要准确衡量应用程序的可用性，首先要确保您可以准确衡量真正的最终用户体验，而不仅仅是网络统计数据。虽然团队并不总是期望停机，但他们经常会因为维护而计划停机。计划停机时间使得 DevOps 和SRE团队成员之间的沟通对于解决不可预见的故障并确保前端和后端无缝运行至关重要。

9. 应用使用和流量

应用程序使用情况和流量监控访问您系统的用户数量并通知许多其他指标，包括系统正常运行时间。

部署软件后，您将想知道有多少用户正在访问您的系统以及发生的事务数量，以确保一切正常运行。

例如，如果您的应用程序获得过多的流量和使用量，它可能会在持续压力下导致失败。同样，这些指标可用于对部署的间接反馈——新的和现有的。如果使用量或流量下降，这可能是您所做的更改没有被最终用户接受的反馈。

拥有诸如这些应用程序使用情况和流量指标之类的 DevOps KPI 可以让您查看是否有问题，以及何时出现异常的流量峰值或其他异常使用或流量指标。同样，您可以针对专门支持关键应用程序的微服务监控使用情况和流量。因此，您的 DevOps 团队可以使用这些指标来确保系统按应有的方式运行并采取适当的措施，例如，恢复到以前的版本以使最终用户满意。