特别说明：本文是在原文基础上的改写，但总体不影响原文表达，特此说明。
1 - 自我认知
通过跟踪关键的DevOps指标，随着时间推移，可以有效了解DevOps在团队内部实施和落地的情况，衡量DevOps的运行状态。
通常都会根据自身定义一些常见的指标来评估DevOps的效果，期望产生积极的影响。
- 平均交付时间
- 缺陷逃逸率
- 新增代码单元测试覆盖
- 日均自动化部署次数
- 功能和性能测试周期
- 每轮回归测试周期
- 。。。
但定义DevOps指标指标之前，应该弄清两个基本问题：
- “定义DevOps的指标，对团队真正意味着什么？”
- “从DevOps角度来看，组织所面临的核心挑战和要解决的主要问题是什么？”
这两个基本问题的实质，其实是在要求对自身真实情况和需求，能够有一个清晰完整的认知。
2 - DevOps的指标类型
DevOps期望尽可能快的持续交付和传送代码，想要行动迅速，但不一定非要打破常规。
通过跟踪这些DevOps指标，可以评估在开始“破坏”之前，可以“移动”多快。
Change volume 容量变化（部署规模）
Deployment frequency 部署频率
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) 平均恢复时间
3 - DevOps的目标：速度、质量、性能
希望尽可能快地发送代码，根据你的产品类型、团队和风险承受能力，你可以尽快的实现这一目标。
即使你没有在速度上跟踪任何DevOps指标，至少应该衡量在质量上的工作，也许你并不真的在乎到底有多快。
但是，你总是关心质量，你最不想要的就是一直在疲于生产。
关于性能，你可以争辩说，这也与你的高速度和高质量的目标不一致，性能也与质量有关，但可能略有不同。
4 - 十五项指标
# 部署规模
跟踪有多少故事、特性请求和错误修复正在被部署，这是另外一个良好的DevOps度量。
取决于工作项目有多大，它们的数量可能会有很大差异。
还可以跟踪部署了多少个故事点或几天的开发工作。
# 部署频率
跟踪部署的频率是一个良好的DevOps度量，最终的目标是尽可能多且小的部署，减少部署的规模使测试和发布变得更加容易。
建议单独计算生产和非生产部署，部署到QA或预生产环境的频率也很重要。
需要在QA中尽早部署，以确保测试的时间，在QA中发现Bug很重要，可以降低缺陷的转化率。
# 部署时间
跟踪实际部署需要多长时间是另一个很好的度量，可以帮助识别潜在的问题。
当实际执行任务的任务比较快时，更容易部署。
# 交付时间
如果目标是快速发送代码，这是一个非常关键的DevOps度量。
可以将交付时间定义为从工作项开始到部署之间的时间。
这样能够帮助自身知道，如果今天开始一项新的工作项目，直到它开始生产，平均需要多长时间，。
# 客户工单
应用程序问题的最好和最差的指示器是客户工单和反馈。
最不想要的就是让用户发现bug或者软件有问题。
因此，它们也能很好地反映应用程序的质量和性能问题。
# 自动化测试通过率
为了提高速度，建议团队广泛使用单元测试和功能测试。
由于DevOps严重依赖于自动化，所以跟踪自动化测试工作的好坏是一个良好的DevOps指标。
解代码更改导致测试中断的频率是很好的方法。
# 缺陷逃逸率
知道在生产和QA中发现了多少软件缺陷吗?
如果想要快速地发布代码，需要有信心，可以在他们开始生产之前发现软件缺陷。
缺陷逃逸率是一个很大的DevOps度量，用来跟踪这些缺陷在生产过程中经常发生的情况。
# 可用性
最不想要的就是应用程序被关闭。
根据应用程序类型以及部署方式，可能会有一些停机时间作为计划维护的一部分。
建议跟踪这一点，以及所有计划外的停机。
# 服务水平协议
服务水平协议(SLA)是一种由服务供应商与用户签署的法律文件，其中承诺只要用户向服务供应商支付相应费用，就应享受到服务供应商提供的相应服务质量。
大多数公司都有一些服务水平协议(SLA)。
同样重要的是要追踪sla是否遵守。
即使没有正式的SLA，也可能需要实现应用程序要求或期望。
# 失败部署率
部署经常会给用户造成中断或重大问题吗？希望这种情况永远不会发生。
回滚失败的部署是永远都不想做的事情，但这是应该一直计划的事情。
如果遇到了部署失败的问题，请务必跟踪这个度量，这也可以看作是对失败的跟踪平均时间(MTTF)。
# 错误率
在应用程序中跟踪错误率非常重要。
它们不仅是质量问题的指示器，而且是持续的性能和与时间相关的问题。
好的异常处理最佳实践对于良好的软件是至关重要的。
对于大多数应用程序来说，错误是生命周期的一部分，
可能有一些错误，只是一个繁忙系统的部分噪音，重要的是，要对错误率保持监控，并寻找峰值。
# 应用程序的使用和流量
在部署之后，查看访问系统的事务或用户数量是否正常。
如果突然之间没有业务流量，那么有些事情可能是错误的，最不想看到的就是根本没有业务流量。
如果使用的是微服务，还可以看到流量激增，某个应用程序之一突然导致了大量的流量。
# 应用程序的性能
在进行部署之前，应该使用工具来查找性能问题、隐藏的错误和其他问题。
在部署期间和部署之后，还应该寻找总体应用程序性能的任何变化。
在部署之后，可以看到特定SQL查询、web服务调用和其他应用程序依赖项的使用的主要变化。
性能工具可以提供有价值的可视化效果，可以帮助发现问题。
# 平均检测时间(MTTD)
当问题发生时，重要的是要快速地识别它们。
最不希望的是出现重大的部分或广泛的系统中断，而不知道出现在哪里。
拥有健壮的应用程序监控和良好的覆盖将有助于快速发现问题。
一旦发现问题，必须快速修复它们。
# 平均恢复时间(MTTR)
这个度量可以帮助跟踪从失败中恢复需要多长时间。
对企业来说，一个关键的衡量标准就是将失败降到最低，并且能够迅速地从失败中恢复过来。
它通常是按小时计算的，可能是指工作时间，而不是时钟时间。
拥有良好的应用程序监视工具可以快速识别问题并快速部署修复程序，这对减少MTTR非常重要。
5 - 应用程序指标
除了上面列出的DevOps指标之外，还可以跟踪许多其他的指标，这些指标都是特定于应用程序的。
它们中的大多数与DevOps在部署应用程序方面不一定相关。
但是，它们对于监视应用程序在生产中的使用和性能非常关键。
根据应用程序的不同，可能有类似的自定义指标，对应用程序至关重要。
在部署之后，将希望监视所有关键的应用程序指标，以确保一切仍然正常。
6 - 总结
如果想要将DevOps带到下一个级别，相信DevOps度量列表将帮助了解如何跟踪和改进。
DevOps的目标是协作，让开发人员更多地参与部署过程和应用程序监控。