DevOps在你的组织内部运行的如何？如果你需要一些帮助来度量它的运行情况，我们已经准备了一个用于跟踪的关键DevOps指标的列表，这些度量可以帮助了解你的团队是如何随着时间的推移而运行的。
在团队内部明确DevOps的定义意义重大
DevOps这个词不同的人有不同的理解，有人说这是一种文化，业内的每个厂商都声称他们的工具帮助了DevOps，根据你如何定义DevOps，其中的一些度量可能对你的团队有重要的影响。
我将DevOps定义为与部署和监视应用程序相关的所有内容，从很多方面来说，这都是现实的可靠的工程问题。在Stackify，我们甚至没有运维团队，我们的开发人员直接部署到云上，我们的操作方式更多的是“NoOps”风格。
确定你的DevOps的挑战
在弄清楚DevOps度量标准是什么之前，你需要确定组织所面临的挑战以及要解决的问题。在Stackify，我们最大的问题不是经常部署，并且降低了缺陷逃逸速度。我们的执行团队正把重点放在2018年的具体指标上。
DevOps指标的类型
DevOps是尽可能快的持续交付和传输代码，你想要行动迅速而不是打破常规，通过跟踪这些DevOps指标，你可以评估在开始破坏之前，可以有多快。
Deployment frequency 部署频率
Change volume 容量变化
Deployment time 部署时间
Lead time 交付时间
Customer tickets 客户工单
Automated test pass % 自动化测试通过百分比
Defect escape rate 缺陷逃逸率
Availability 可用性
Service level agreements 服务水平协议SLA
Failed deployments 失败的部署
Error rates 错误率
Application usage and traffic 应用程序的使用和流量
Application performance 应用程序的性能
Mean time to detection (MTTD) 平均检测时间
Mean time to recovery (MTTR) 平均恢复时间
DevOps的目标：速度、质量、性能
DevOps的主要目标是速度、质量和应用程序性能。
希望尽可能快地发送代码，根据你的产品类型、团队和风险承受能力，你可以尽快的实现这一目标。
即使你没有在速度上跟踪任何DevOps指标，至少应该衡量在质量上的工作，也许你并不真的在乎到底有多快，但是，你总是关心质量，你最不想要的就是一直在疲于生产。
关于性能，你可以争辩说，这也与你的高速度和高质量的目标不一致，性能也与质量有关，但可能略有不同。
部署规模
跟踪有多少功能、特性请求和错误修复正在被部署，这是另一个良好的DevOps度量，取决于你的工作项目有多大，它们的数量可能会有很大差异，您还可以跟踪部署了多少个功能点或几天的开发工作。
部署频率
跟踪部署的频率是一个良好的DevOps度量，最终目标是尽可能多地部署更小的部署，减少部署的规模使测试和发布变得更加容易。
我建议单独计算生产和非生产部署，部署到QA或预生产环境的频率也很重要。你需要在QA中尽早部署，以确保测试的时间，在QA中发现bug很重要，可以降低缺陷的转化率。
部署时间
这看起来可能很奇怪，但是跟踪实际部署需要多长时间是另一个很好的度量。我们在Stackify的一个应用程序部署在Azure上，部署大约需要一个小时。这是一个噩梦，跟踪这些事情可以帮助识别潜在的问题，当实际执行任务的任务比较快时，更容易部署。
交付时间
如果目标是快速发布代码，这是一个非常关键的DevOps度量，我将把交付时间定义为从工作项开始到部署之间的时间。这可以帮助你知道，如果你今天开始一项新的工作项目，直到它开始生产，平均需要多长时间。
客户工单
应用程序问题的最好和最差的指示器是客户工单和反馈，你最不想要的就是让你的用户发现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的目标是协作，让开发人员更多地参与部署过程和应用程序监控。