祝贺你已经建立了DevOps实践。现在，完成了艰苦的工作，制定了DevOps指标和DevOps KPI，您可以坐下来放松，见证您的Dev和Ops团队之间的合作，因为他们可以更快地交付质量更好的软件。
要是那样容易就好了。
为什么度量在DevOps中很重要？
当我们审视当今的应用程序、微服务和DevOps团队时，我们看到领导者的任务是使用分布在多个位置的系统中的新技术来支持复杂的分布式应用程序。正因为如此，我们衡量和理解关键服务和应用程序的方式也发生了变化。
什么是DevOps指标？
DevOps指标和DevOps KPI对于确保您的DevOps流程、管道和工具达到其预期目标至关重要。与任何IT或业务项目一样，您需要跟踪关键的关键指标。
以下是九个关键的DevOps指标和DevOps KPI，它们将帮助您实现目标。
DevOps的四个主要指标是什么？DORA的四把钥匙
让我们从谷歌DevOps研究与评估（DORA）团队建立的四个最常见的指标开始，即“四个关键”。通过六年的研究，DORA团队确定了这四个关键指标是指DevOps团队的绩效，将他们从“低”排到“精英”，精英团队达到或超过组织绩效目标的可能性是他们的两倍。让我们深入了解这些DevOps KPI如何帮助您的团队更好地执行并交付更好的代码。
1.部署频率（Deployment frequency）
部署频率衡量团队成功发布到生产环境的频率。
随着越来越多的组织采用持续集成/持续交付（CI/CD），团队可以更频繁地发布，通常每天发布多次。高部署频率有助于组织更快地提供错误修复、改进和新功能。这也意味着开发人员可以更快地收到有价值的真实世界反馈，这使他们能够优先考虑最具影响力的修复和新功能。
部署频率衡量长期和短期效率。例如，通过每天或每周测量部署频率，您可以确定团队对流程更改的响应效率。长期跟踪部署频率可以指示您的部署速度是否随着时间的推移而提高。它还可以指示需要解决的任何瓶颈或服务延迟。
2.变更的交付周期（ Lead time for changes）
变更的交付周期衡量提交的代码投入生产所需的时间。
此指标对于了解团队对特定应用程序相关问题的响应速度非常重要。交付周期越短通常越好，但交付周期越长并不总是表明存在问题。这可能只是表明一个复杂的项目自然需要更多的时间。变更的交付周期有助于团队了解其流程的有效性。
为了衡量变更的交付周期，您需要捕获提交发生的时间和部署发生的时间。改进这一指标的两个重要方法是在多个开发环境中实施质量保证测试，以及自动化测试和DevOps流程。
3.变更失败率（ Change failure rate）
更改失败率衡量在生产中导致需要修复或回滚错误的失败的部署的百分比。
更改失败率着眼于尝试了多少次部署，以及这些部署中有多少在发布到生产中时导致失败。该指标衡量DevOps流程的稳定性和效率。要计算更改失败率，您需要部署的总数，以及将它们链接到由bug、GitHub事件标签、问题管理系统等导致的事件报告的能力。
更改失败率超过40%可能表明测试程序较差，这意味着团队需要进行超出必要的更改，从而降低效率。
衡量变更失败率背后的目标是实现更多DevOps流程的自动化。自动化程度的提高意味着发布的软件更加一致和可靠，更有可能在生产中取得成功。
4.恢复服务的平均时间 （Mean time to restore service）
平均恢复时间（MTTR）服务衡量组织从生产故障中恢复所需的时间。
在一个以99.999%的可用性为标准的世界里，衡量MTTR是确保弹性和稳定性的关键做法。在发生计划外停机或服务降级的情况下，MTTR可帮助团队了解哪些响应过程需要改进。要测量MTTR，您需要知道事件何时发生以及何时得到有效解决。为了更清楚地了解情况，了解是什么部署解决了事件，并分析用户体验数据以了解服务是否已有效恢复也很有帮助。
对于大多数系统，最佳MTTR可能小于一小时，而其他系统的MTTR小于一天。任何超过一天的时间都可能表明警报或监控不力，并可能导致更多受影响的系统。
为了实现快速MTTR指标，以小增量部署软件以降低风险，并部署自动化监控解决方案以预防故障。
五个补充DevOps KPI
DORA的“四个关键”为提高开发实践的性能奠定了良好的基础，但它们只是一个开始。以下是另外五个DevOps KPI，可帮助您的团队实现更优化的绩效。
5.缺陷逃逸率（Defect escape rate）
缺陷逃逸速度衡量“逃逸”测试并发布到生产中的bug数量。
此指标可帮助您确定测试过程的有效性和软件的总体质量。高的缺陷逃逸率表示过程需要改进和更多的自动化，而较低的比率（优选接近零）表示功能良好的测试程序和高质量的软件。
为了获得该度量的可见性，您需要跟踪在发布的代码和软件中发现的所有缺陷。这意味着要查看开发/QA和生产中的缺陷，以便深入了解从开发和QA进入生产的任何缺陷。通常，组织应该努力在发布进入生产之前找到QA中90%的缺陷。
6.平均检测时间（Mean time to detect）
平均检测时间（MTTD）衡量事件开始到发现之间的平均时间。
在其他DevOps度量中，此度量有助于确定您的监控和检测能力在支持系统可靠性和可用性方面的有效性。衡量MTTD受其他DevOps KPI指标的影响，包括平均故障时间（MTTF）和平均恢复时间（MTTR）。要计算MTTD，请将给定团队或项目的所有事件检测时间相加，然后除以事件总数。
MTTD面临的挑战是准确了解IT事件何时开始，这需要分析和评估历史基础设施KPI数据的能力。
7.自动化测试覆盖的代码百分比（Percentage of code covered by automated tests）
自动化测试覆盖的代码百分比衡量接受自动化测试的代码的比例。
自动化测试通常表明代码更稳定，尽管手动测试仍然可以在软件开发中发挥作用。自动化测试覆盖更高比例的代码是我们的目标，尽管总是有一些失败的测试是健康的——重要的是团队编写代码以按预期工作，而不仅仅是通过测试。
8.应用程序可用性（App availability）
应用程序可用性衡量应用程序完全运行和可访问以满足最终用户需求的时间比例。
高可用性系统旨在满足“五个9”（99.999%）这一黄金标准KPI。要准确衡量应用程序可用性，首先要确保您能够准确衡量真正的最终用户体验，而不仅仅是网络统计数据。虽然团队并不总是期望停机，但他们通常会因为维护而计划停机。计划内停机使DevOps和SRE团队成员之间的沟通对于解决不可预见的故障和确保前端和后端无缝运行至关重要。
9.应用程序使用和流量（Application usage and traffic）
应用程序使用情况和流量监控访问系统的用户数量，并通知许多其他指标，包括系统正常运行时间。
一旦您部署了软件，您就会想知道有多少用户正在访问您的系统，以及发生的事务数量，以确保一切正常运行。
例如，如果应用程序的流量和使用量过多，它可能会在压力下失败。同样，这些指标对于新部署和现有部署的间接反馈也很有用。如果使用量和/或流量下降，这可能是反馈，表明您所做的更改没有得到最终用户的好评。
拥有DevOps KPI（如这些应用程序使用情况和流量指标）可以让您查看是否有问题，以及何时出现流量异常峰值或其他异常使用或流量指标。同样，您可以针对专门支持关键应用程序的微服务来监控使用情况和流量。因此，您的DevOps团队可以使用这些指标来确保系统正常运行，并采取适当的行动，例如，恢复到以前的版本以使最终用户满意。
如何监控云资源和分布式系统的DevOps指标和KPI
一个成功的DevOps实践需要团队监控一组一致且有意义的DevOpsKPI，以确保流程、管道和工具满足更快交付更好软件的预期目标。
为了帮助团队了解DevOps工具和流程，Dynatrace为多云环境提供了自动的全栈可观察性。Dynatrace DevOps解决方案以人工智能为核心，从开发到生产，自动理解整个DevOps生命周期的数据。这种提供精确答案并与500多种技术集成的能力使团队能够定制和微调DevOps指标，自动化更多DevOps流程，并提高效率以获得卓越的用户体验。
