帮助中心
企业应该跟踪的15个DevOps度量标准和KPI

DevOps是当今简化软件交付的热门解决方案。DevOps被广泛认为是交付过程的重要组成部分,关键的DevOps流程涉及从安全到维护应用程序的所有方面。


仅仅部署DevOps无法确保质量,如果未正确集成,甚至可能导致更多问题,如果只是为了尽快将软件推向市场,那么公司面临许多软件上面的问题和用户使用的问题。


端到端DevOps的现代时代要求仔细整合关键绩效指标(KPI),正确的指标可以确保应用程序达到最大潜力。


理想情况下,DevOps Metrics和KPI  以清晰易懂的方式呈现相关信息,他们应该共同提供部署和变更流程的概述 - 以及可以在哪些方面进行改进。


在您努力提高效率和用户体验时,以下指标值得追踪。



DevOps指标和关键绩效指标


1.部署频率

部署频率表示启动新功能的频率,频率可以每天或每周测量,许多组织倾向于每天跟踪部署,尤其是在提高效率时。


理想情况下,频率指标要么保持稳定,要么保持稳定增长,部署频率的任何突然降低都可能表明现有工作流程中存在瓶颈。


更多部署通常更好,但只能达到一定程度,如果高频导致部署时间增加或故障率更高,则可能值得暂缓部署增加,直到可以解决现有问题。


2.改变变更数量

如果大多数部署都没有什么后果,那么部署频率就很小。

更改量可以更好地反映部署的实际价值。此DevOps KPI确定代码更改的程度与剩余静态的关系,部署频率的改进不应对变更量产生重大影响。


3.部署时间

一旦获得批准,部署就需要多长时间?

当然,如果快速实施,部署可以更频繁地发生,部署时间的大幅增加需要进一步调查,特别是如果它们伴随着减少的部署量,虽然缩短部署时间至关重要,但不应以牺牲准确性为代价,错误率的增加可能表明部署发生得太快。


4.部署率不合格

有时也称为平均故障时间,此度量标准确定部署提示中断或其他问题的频率。

这个数字应该尽可能低。失败的部署率通常与更改量一起引用。较低的变化量以及增加的失败部署率可能表明工作流中某处存在功能障碍。


5.失败率

更改失败率是指版本导致意外中断或其他意外故障的程度。较低的更改失败率表明部署快速且定期进行。相反,高变化失败率表明应用稳定性差,这可能导致最终用户的负面结果。


6.检测时间

较低的更改失败率并不总是表明您的应用程序一切顺利。

虽然理想的解决方案是尽量减少甚至根除失败的变更,但如果发生故障,必须尽快发现故障。检测KPI的时间可以确定当前的响应工作是否足够。检测时间过长可能会导致瓶颈,从而导致整个工作流程中断。


7.平均恢复时间

一旦检测到部署或更改失败,实际解决问题并重新回到正轨需要多长时间?

平均恢复时间(MTTR)是一个重要指标,表明您能够对已发现的问题作出适当的回应。如果没有同样快速的恢复工作,即时检测意味着很少。MTTR是最着名和最常被引用的DevOps关键绩效指标指标之一。


8.交付时间

提前期衡量变更发生的时间。

可以从创意启动开始跟踪该度量,并继续进行部署和生产。提前期为整个开发过程的效率提供了宝贵的见解。它还表明了当前满足用户群不断变化的需求的能力。较长的交付周期表明存在有害的瓶颈,而较短的交付周期表明反馈得到及时解决。


9.BUG发现率

每个软件部署都存在引发新BUG的风险。在验收测试完成之前,可能无法发现这些信息。更糟糕的是,最终用户可以找到它们。

错误是开发过程的一个自然部分,应该相应地进行规划。BUG发现率通过承认问题将会出现并尽早发现它们来反映这一现实。

缺陷逃逸率跟踪在生产前和生产过程中发现缺陷的频率。该数字可以为软件版本的总体质量提供有价值的指标。


10.缺陷量

此度量标准与上面突出显示的转义率相关,而是关注实际的缺陷量。虽然预计会出现一些缺陷,但突然增加应引起关注。特定应用程序的大量缺陷可能表明开发或测试数据管理存在问题。


11.可用性

可用性突出显示给定应用程序的停机时间。

这可以测量为完整(读/写)或部分(只读)可用性。减少停机时间几乎总是更好。话虽如此,定期维护可能需要一些可用性的失误。及时跟踪计划停机时间和计划外停机,请记住100%的可用性可能不太现实。


12.服务水平协议合规性

为了提高透明度,大多数公司根据服务水平协议运营。这突出了提供商和客户之间的承诺。SLA合规性KPI提供必要的责任,以确保满足SLA或其他期望。


13.计划外工作

多少时间致力于意想不到的努力?该计划外的工作率(UWR)相对于花费在计划的工作时间跟踪此。理想情况下,计划外工作率(UWR)不会超过25%。

高UWR可能会揭示在工作流程早期可能未检测到的意外错误所浪费的努力。UWR有时会与返工率(RWR)一起检查,这与解决票证中出现的问题有关。


14.客户统计

由于缺陷逃逸率KPI表明,并非所有缺陷都是灾难性的。然而,理想情况下,他们会很早被抓住。此概念最好反映在客户票证量中,该量表示最终用户生成的警报数量。稳定的用户量以及增加的票证量表明生产或测试中存在问题。


15.周期时间

周期时间指标提供了应用程序部署的广泛概述。

此KPI跟踪整个过程,从构思开始到用户反馈结束。较短的周期通常是优选的,但不以牺牲发现缺陷或遵守SLA为代价。


开始衡量Devops的成功

在跟踪关键的DevOps指标时,根据任何一个指标,更少关注感知的成功或失败,而是根据故事,这些指标在一起检查时告诉我们。当与其他数据一起分析时,看起来有问题的结果可能看起来完全不同。

仔细跟踪上面强调的关键绩效指标不仅可以确保更高的开发和生产效率,更重要的是确保最佳的最终用户体验。拥抱DevOps指标,您可以看到应用程序部署和反馈方面的巨大改进。


购物车