DevOps 最初是作为简化软件交付的一个选项而崭露头角的。今天，DevOps 被广泛认为是交付过程的重要组成部分。关键的 DevOps 流程涉及从保护到维护应用程序的方方面面。DevOps 实践和原则本身并不能确保质量，如果没有正确集成，甚至可能导致更多问题。为了尽快将软件推向市场，公司冒着被最终用户发现的更多缺陷的风险。
端到端 DevOps 的现代时代要求仔细整合关键绩效指标 (KPI)。正确的指标可以确保应用程序发挥其最大潜力。理想情况下，DevOps 指标和 KPI 以清晰易懂的方式呈现相关信息。他们应该一起提供部署和更改过程的概述 - 以及可以改进的地方。在您努力提高效率和用户体验时，以下指标值得跟踪。
DevOps 指标和关键绩效指标
1. 部署频率
部署频率表示启动新特性或功能的频率。频率可以每天或每周测量一次。许多组织更喜欢每天跟踪部署，尤其是在它们提高效率时。理想情况下，频率指标要么随着时间的推移保持稳定，要么会出现轻微而稳定的增长。部署频率的任何突然降低都可能表明现有工作流程中的瓶颈。更多的部署通常会更好，但只是在一定程度上。如果高频导致部署时间增加或故障率增加，则可能值得推迟部署增加，直到现有问题得到解决。
2. 改变音量
如果大多数部署没有什么影响，那么部署频率就没有多大意义。部署的实际价值可能会更好地反映在变化量上。此DevOps KPI确定代码更改与保持不变的程度。部署频率的改进不应对变更量产生重大影响。
3. 部署时间
一旦获得批准，部署部署需要多长时间？自然，如果部署速度快，部署的频率会更高。部署时间的急剧增加值得进一步调查，尤其是在部署量减少的情况下。虽然缩短部署时间是必不可少的，但不应以准确性为代价。错误率增加可能表明部署发生得太快。
4. 部署失败率
有时称为平均故障时间，该指标确定部署提示中断或其他问题的频率。这个数字应该尽可能低。失败的部署率通常与更改量一起引用。较低的更改量以及不断增加的失败部署率可能表明工作流程中的某个地方出现了功能障碍。
5. 改变失败率
变更失败率是指发布导致意外中断或其他计划外故障的程度。较低的更改失败率表明部署快速且定期发生。相反，高更改失败率表明应用程序稳定性差，这可能导致最终用户产生负面结果。
6. 检测时间
较低的更改失败率并不总是表明您的应用程序一切正常。虽然理想的解决方案是尽量减少甚至消除失败的更改，但如果确实发生了故障，则必须快速捕获它们。检测 KPI 的时间可以确定当前的响应工作是否足够。检测时间过长可能会引发能够中断整个工作流程的瓶颈。
7. 平均恢复时间
一旦检测到失败的部署或更改，实际上需要多长时间才能解决问题并重回正轨？平均恢复时间 (MTTR) 是一项重要指标，表明您对已识别问题做出适当响应的能力。如果不进行同样快速的恢复工作，那么及时检测就毫无意义。MTTR 是最著名和最常被引用的DevOps 关键性能指标指标之一。
8. 交货时间
提前期衡量更改发生所需的时间。可以从构思开始并继续通过部署和生产来跟踪该度量。交付周期为整个开发过程的效率提供了宝贵的洞察力。它还表明了当前满足用户群不断变化的需求的能力。较长的交付周期表明存在有害的瓶颈，而较短的交付周期表明反馈得到及时解决。
9. 缺陷逃逸率
每个软件部署都有引发新缺陷的风险。在完成验收测试之前，这些可能不会被发现。更糟糕的是，最终用户可以找到它们。错误是开发过程的自然组成部分，应相应地进行计划。缺陷逃逸率反映了这一现实，承认问题会出现并且应该尽早发现。缺陷逃逸率跟踪在生产前与生产过程中发现缺陷的频率。这个数字可以提供一个有价值的衡量软件版本总体质量的标准。
10. 缺陷体积
该指标与上面突出显示的逃逸率有关，而是侧重于实际的缺陷量。虽然有些缺陷是意料之中的，但突然增加应该引起关注。特定应用程序的大量缺陷可能表明开发或测试数据管理存在问题。
11. 可用性
可用性突出了给定应用程序的停机时间。这可以衡量为完全（读/写）或部分（只读）可用性。更少的停机时间几乎总是更好。话虽如此，定期维护可能需要一些可用性失效。密切跟踪计划内停机和计划外停机，记住 100% 的可用性可能并不现实。
12. 服务水平协议合规性
为了提高透明度，大多数公司根据服务水平协议运营。这些突出了供应商和客户之间的承诺。SLA 合规 KPI 提供了必要的责任，以确保满足 SLA 或其他期望。
13. 计划外工作
有多少时间花在意料之外的努力上？计划外工作率 (UWR)根据计划工作所花费的时间来跟踪这一点。理想情况下，计划外工作率 (UWR) 不会超过 25%。较高的 UWR 可能表明在工作流程早期可能未检测到的意外错误上浪费了精力。UWR 有时与返工率 (RWR) 一起检查，这与解决工单中提出的问题的努力有关。
14. 客票量
正如缺陷逃逸率 KPI 所表明的那样，并非所有缺陷都是灾难性的。然而，理想情况下，他们会尽早被发现。这个概念最能反映在客户票数上，它表明最终用户生成了多少警报。稳定的用户量以及增加的票证量表明生产或测试中存在问题。
15. 周期时间
周期时间指标提供了应用程序部署的广泛概述。此 KPI 跟踪整个过程，从构思开始到用户反馈结束。较短的周期通常是可取的，但不会以发现缺陷或遵守 SLA 为代价。
开始衡量 Devops 的成功
在跟踪关键 DevOps 指标时，不要关注根据任何一个指标感知到的成功或失败，而是关注这些指标在一起检查时所讲述的故事。当与其他数据一起分析时，一个本身似乎有问题的结果可能看起来完全不同。仔细跟踪上面强调的 KPI 不仅可以确保更高的开发和生产效率，更重要的是，可以确保最佳的最终用户体验。拥抱 DevOps 指标，您会看到应用程序部署和反馈方面的巨大改进。
