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