衡量DevOps成功的15个标准

作者 | Matt Watson

翻译 | 袁思思

原文 | https://dzone.com/articles/15-metrics-for-devops-success

DevOps在你的组织中运行的如何？如果你需要帮忙衡量它运行的如何，我们准备了一些DevOps的关键指标来进行追踪。这些指标可以帮助理解你的团队过去做的如何。

定义DevOps对你的组织意味着什么

DevOps这个词，不同的人不同理解。有些人说他是一种文化并且行业中的每个供应商声称，他们的工具有助于DevOps。取决于你如何定义DevOps，这些指标会对你和你的团队多多少少有些帮助。

我把DevOps定义为与部署和监视应用相关的所有内容。从许多方面来说，这都是现场可靠性工程的问题。在Stackify，我们都没有一个操作团队来合作。我们的开发人员直接部署到云上，我们的操作方式更多的是“NoOps”风格。可以看我的博客，了解我对DevOps的更多看法。

确定你的DevOps挑战

在弄清楚DevOps衡量标准是什么之前，需要确定组织所面临的挑战以及你要解决的问题。在Stackify，我们最大的问题不是频繁部署，和降低的bug逃逸率。我们的执行团队正把重点放在2018年的具体指标上。

DevOps衡量标准的类型

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

部署频率

体积变化

部署时间

交付时间

客户反馈

自动化测试通过百分比

bug逃逸率

可用性

服务水平协议

失败部署

错误率

应用的使用和流量

应用性能

平均检测时间(MTTD)

平均恢复时间(MTTR)

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

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

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

即使没有在速度上跟踪任何DevOps指标，至少应该在质量上评估下工作方式。也许在可能的情况下试着发布，而且并不在意有多快，但是质量你总是关心的。你最不想要的就是总是在追着生产的灾难。

方程式的第三个部分是性能。你可以说，这也与你的高速度和高质量的目标不一致。性能也与质量有关，但可能略有不同。

部署大小

跟踪多少stories、特性请求和错误修复正在被部署，这是DevOps一个很好的衡量标准。根据你的项目有多大，它们的数量可能会有很大差异。还可以跟踪部署了多少个story points或这几天开发工作的价值。

部署频率

跟踪部署频率是DevOps一个良好的衡量标准。最终，目标是尽可能多地做更多小型部署。减少部署的大小让测试和发布变得更加容易。

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

部署时间

这看起来可能很奇怪，但是跟踪实际部署需要多长时间是很好的指标。我们在Stackify的一个应用中部署了Azure工作者角色，部署大约需要一个小时。这是一个噩梦。跟踪这些事情可以帮助识别潜在的问题。当实际执行比较快时，更容易频繁部署。

交付时间

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

客户反馈

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

自动化测试通过百分比

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

bug逃逸率

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

可用性

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

服务水平协议

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

失败部署

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

错误率

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

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

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

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

应用使用和流量

在部署之后，想查看访问系统的事务或用户数量是否正常。如果突然之间没有流量或者流量有大幅上升，那么有些东西可能是错误的。

最不想看到的就是根本没有流量。如果使用的是微服务可以看到流量激增，而你某个应用突然导致了大量的流量。

应用性能

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

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

平均监测时间（MTTD）

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

平均恢复时间（MTTR）

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

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

应用指标

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

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

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

总结

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