这15个指标看你的公司成功落地DevOps了吗？

DevOps在团队内部需要如何运作？如果需要一些度量指标来衡量它的运行情况，本文准备了一个用于跟踪的关键DevOps指标的列表供以参考，它们可以帮助您了解团队是如何随着时间的推移进行的情况。

定义DevOps的指标，对团队意味着什么？

DevOps这个词汇虽然比较火热，但对不同的人又有着不同的含义，有人说它是一种文化，业内的每个厂商都在声称它们的工具帮助了DevOps的落地实践，根据自身如何定义DevOps，其中的一些度量可能会自身及团队产生重要的影响。

作者将DevOps定义为与部署和监控应用相关的所有内容，从很多方面来说，这都是现场可靠性工程的问题，在Stackify，作者的团队甚至没有一个运维团队去配合，开发人员直接部署到云端，操作方式更多是“NoOps”风格。

确定自身的DevOps挑战

在弄清DevOps度量标准之前，需要确定组织所面临的挑战和要解决的问题，在Stackify，最大的问题不是经常不输，并且降低了缺陷逃逸速，运维团队正将重点放在2018年的具体指标上。

DevOps的指标类型

DevOps是尽可能快的持续交付和传送代码。想要行动迅速而不是打破常规。通过跟踪这些DevOps指标，可以评估在开始破坏之前，可以移动多快。

部署频率

质量大小

部署时间

交付时间

客户反馈

自动化测试通过率

缺陷逃逸率

可用性

服务水平协议

失败部署率

错误率

应用程序的使用和通道

应用程序的性能

平均检测时间

平均修复时间

DevOps的目标：速度、质量、性能

DevOps的主要目标是速度、质量和应用程序性能。

开发希望尽可能快地发送代码。根据产品类型、团队和风险承受能力，可以有多快地实现这一目标。

即使没有在速度上跟踪任何DevOps指标，至少应该度量在质量上的工作方式。也许试着在能的时候去只想，并不真的在乎到底有多快。但是，总要关心质量。最不想要的就是一直在追逐生产。

部署规模

跟踪有多少故事、特性请求和错误修复正在被部署，这是另外一个良好的DevOps度量。取决于工作项目有多大，它们的数量可能会有很大差异。您还可以跟踪部署了多少个故事点或几天的开发工作。

部署频率

跟踪部署的频率是一个良好的DevOps度量。最终的目标是尽可能多且小的部署。减少部署的规模使测试和发布变得更加容易。

建议单独计算生产和非生产部署。部署到QA或预生产环境的频率也很重要。需要在QA中尽早部署，以确保测试的时间。在QA中发现Bug很重要，可以降低缺陷的转化率。

部署时间

这看起来可能很奇怪，但是跟踪实际部署需要多长时间是另一个很好的度量。在Stackify的一个应用程序部署了Azure工作者角色，部署大约需要一个小时。这是一个漫长的时间点。跟踪这些事情可以帮助识别潜在的问题。当实际执行任务的任务比较快时，更容易部署。

交付时间

如果目标是快速发送代码，这是一个非常关键的DevOps度量。作者将把交付时间定义为从工作项开始到部署之间的时间。这可以帮助自身知道，如果今天开始一项新的工作项目，它平均需要多长时间，直到它开始生产。这也是帮助BizDevOps的一个好方法。

客户反馈

应用程序问题的最好和最差的指示器是客户的支持和反馈。最不想要的就是让用户发现bug或者对软件有问题。因此，它们也能很好地反映应用程序的质量和性能问题。

自动化测试通过率

为了提高速度，建议团队广泛使用单元测试和功能测试。由于DevOps严重依赖于自动化，所以跟踪自动化测试工作的好坏是一个良好的DevOps指标。了解代码更改导致测试中断的频率是很好的。

缺陷逃逸率

知道在生产和QA中发现了多少软件缺陷吗?如果想要快速地发送代码，需要有信心，可以在他们开始生产之前发现软件缺陷。缺陷逃逸率是一个很大的DevOps度量，用来跟踪这些缺陷在生产过程中经常发生的情况。

可用性

最不想要的就是应用程序被关闭。根据应用程序类型以及如何部署它，可能会有一些停机时间作为计划维护的一部分。建议跟踪这一点，以及所有计划外的停机。

服务水平协议

大多数公司都有一些服务水平协议(SLA)。同样重要的是要追踪sla是否遵守。即使没有正式的SLA，也可能需要实现应用程序要求或期望。

失败部署率

我们都希望这种情况永远不会发生，但是部署经常会给用户造成中断或重大问题吗？反转失败的部署是大家永远都不想做的事情，但这是应该一直计划的事情。如果遇到了部署失败的问题，请务必跟踪这个度量。这也可以看作是对失败的跟踪平均时间(MTTF)。

错误率

在应用程序中跟踪错误率非常重要。它们不仅是质量问题的指示器，而且是持续的性能和与时间相关的问题。好的异常处理最佳实践对于良好的软件是至关重要的。

bug——在部署后识别在代码中抛出的新异常。

生产问题-用数据库连接捕获问题，查询超时和其他相关问题。

对于大多数应用程序来说，错误是生命的一个事实。在Stackify，于几百个服务器和上千个SQL数据库中处理数百万条消息。这里有一些错误，只是一个繁忙系统的部分噪音。重要的是，要对错误率保持一个脉冲，并寻找峰值。

应用程序的使用和通道

在部署之后，希望查看访问系统的事务或用户数量是否正常。如果突然之间没有“交通堵塞“，那么有些事情可能是错误的。

最不想看到的就是根本没有交通。如果使用的是微服务，还可以看到流量激增，而应用程序之一突然导致了大量的流量。

应用程序的性能

在进行部署之前，应该使用像Retrace这样的工具来查找性能问题、隐藏的错误和其他问题。在部署期间和部署之后，还应该寻找总体应用程序性能的任何变化。

在部署之后，可以看到特定SQL查询、web服务调用和其他应用程序依赖项的使用的主要变化。像Retrace这样的工具可以提供有价值的可视化效果，比如下面这个，可以帮助您轻松地发现问题。

平均检测时间(MTTD)

当问题发生时，重要的是要快速地识别它们。最不希望的是出现重大的部分或广泛的系统中断，而不知道它出现在哪里。拥有健壮的应用程序监控和良好的覆盖将有助于快速发现问题。一旦发现也必须快速修复它们！

平均恢复时间(MTTR)

这个度量可以帮助您跟踪从失败中恢复需要多长时间。对企业来说，一个关键的衡量标准就是将失败降到最低，并且能够迅速地从失败中恢复过来。它通常是按小时计算的，可能是指工作时间，而不是时钟时间。

拥有良好的应用程序监视工具可以快速识别问题并快速部署修复程序，这对减少MTTR非常重要。

应用程序指标

除了上面列出的DevOps指标之外，还可以跟踪许多其他的指标，这些指标都是特定于应用程序的。它们中的大多数与DevOps在部署应用程序方面不一定相关。但是，它们对于监视应用程序在生产中的使用和性能非常关键。

例如，在Stackify中，使用自定义度量来跟踪每分钟通过API接收的日志消息数量。这是一个重要的度量指标，帮助我们理解流经系统的数据量。根据应用程序的不同，可能有类似的自定义指标，对应用程序至关重要。

在部署之后，将希望监视所有关键的应用程序指标，以确保一切仍然正常。

摘要

如果想要将DevOps带到下一个级别，相信DevOps度量列表将帮助了解如何跟踪和改进。DevOps的目标是协作，让开发人员更多地参与部署过程和应用程序监控。