DevOps通过一系列追求敏捷思维的实践来提高软件交付速度以及质量。提到DevOps，大家首先想到的是持续集成、持续交付和部署、协作、自动化和监控。

DevOps对不同的团队有不同的含义。有的团队追求自动化，而有的团队手动操作也仍然认为是在做DevOps。有些人认为它是一种文化和思维方式的塑造者。

由于DevOps围绕着持续交付和快速代码传输，因此在没有任何重大错误的情况下快速运行是至关重要的。这就是为什么跟踪DevOps指标能够帮助你实现这一目标。

因此，在开始使用DevOps之前，你的团队就应该确定DevOps对他们来说意味着什么。更重要的是，团队还应该了解到他们采用DevOps之后所面临的最大挑战是什么。然后，他们将更容易决定他们需要更积极地监控哪些DevOps指标，以改进和创建更高质量的软件交付流程。

以下是大多数团队认为重要的DevOps指标：

部署频率

---

对于企业而言，发展和保持竞争优势以更优质的质量和准确性提供更新、新功能和技术升级十分重要。增强交付强度有助于提高灵活性，可以更好地满足消费者不断变化的要求。

因此这一指标应该达到的目标应该是允许尽可能频繁地进行较小的部署。当部署规模较小时，软件测试和部署就会更加自如。

定期测量部署频率将为开发者提供更丰富的观察视角——了解哪些改动比较成功，哪些环节需要改进。频率的快速下降可能表明其他任务或手动操作正在扰乱工作流程。对于可持续的增长和发展来说，微小但持续变化的部署频率指标是最佳的。

更进一步的实践是，让测试更易于管理，这样可以同时衡量生产和非生产部署。如此一来，你就能确定你对QA的部署频率，并对早期和较小的部署进行优化。

部署时间

---

这个指标衡量了你需要多长时间来执行一次部署。尽管最初可能看起来无关紧要，但测量部署时间是可以表明潜在问题的DevOps指标之一。例如，如果你的部署需要一个小时，那一定是有问题的。这就是为什么最好关注更小但更频繁的部署。

自动化测试通过的百分比

---

强烈推荐团队有效利用单元和运行测试，以最大限度地提高速度。由于DevOps严重依赖自动化，因此一个有用的DevOps指标是衡量自动化测试的执行情况。并且需要了解多少代码调整导致测试崩溃。

代码提交次数

---

这一指标能够计算团队在软件投入生产之前软件代码的提交次数。这既能衡量开发速度，也能衡量代码的准确性。团队应该设定一个标准的代码提交范围，并且要求每个成员遵守。

大量的提交次数可能意味着代码质量不佳或缺乏明确的开发目标。另一方面，当数量低于标准范围时，可能预示着团队成员缺乏生产力或良好的组织能力。因此团队负责人有必要了解提交次数下降或增加背后的原因，以保持效率和项目节奏，同时让团队成员能够在工作中获得快乐。

缺陷逃逸率

---

无论你在DevOps方面多么有经验，失误都是不可避免的——特别是当你经常进行调整时。软件开发总会涉及到试验，作为过程的一部分，你需要预见错误。

缺陷逃逸率指标显示了你在软件缺陷进入生产之前能够捕捉到它们的能力。如果你想快速交付代码，这一点尤为重要。为了成功实现这一目标，你需要高效地检测缺陷。

成  本

---

虽然云计算是削减基础设施成本的一个很好的解决方案，但一些计划外的错误和事件会导致成本攀升。这就是为什么你需要及时发现不必要的成本，并尝试削减它们。可视化你的支出来源可以了解到在哪方面支付了昂贵的成本。你可以点开下方文章，了解成本监控可视化工具：

看得见的成本！1款工具实现K8S资源成本监控可视化

部署失败和环境健康

---

部署经常会给你的用户带来问题，有时候，我们不得不撤销失败的部署。尽管这不是我们想要的结果，但我们应该时刻意识到有可能发生。频繁失败的部署预示着我们的环境健康可能出现问题，这就引出了下一个指标。

检测时间

---

虽然减少甚至消除失败更改是最佳方法，但更为重要的是在出现故障时迅速捕捉故障。KPI的识别时间将决定当前的响应工作是否合适。高检测时间可能会触发制约因素，从而扰乱整个工作流程。

非计划内的工作

---

这是你花在不在初始计划中任务上的时间。在标准项目中，UWR(非计划工作率)不应该超过25%。高UWR可能会暴露出那些浪费在意外失误上的时间，而这些错误在工作流程的早期显然没有被发现。与返工率(RWR)一起，UWR也是一个重要的指标，它指的是试图解决计划中提出的问题。

平均故障时间(MTTF)

---

平均故障时间(MTTF)是指一个有缺陷的系统运行到失效的平均时间。该时间从系统发生重大缺陷时开始，到机制最终崩溃时结束。

MTTF用于跟踪不可修复的系统组件状态，并评估它们在失效前能工作多久。这个指标还可以让DevOps团队在识别故障时维护关键任务系统中使用的组件的状态。

应用程序性能

---

在执行部署之前，你应该检查性能故障、未知的bug和其他问题。你还可以观察整个部署过程中和部署后整体程序输出的变化。

在发布之后，看到某些SQL查询、Web服务器调用和其他程序需求的使用出现重大调整是正常的。为了检测它们，你可以使用监控工具来精确地显示这些变化。

平均检测时间(MTTD)

---

当问题真的出现时，你必须能够轻松地识别它们。你一定不希望出现严重的局部或大面积的机器故障而不自知的情况。那么，设置强大的应用程序监控可以帮助你轻松发现错误。

平均恢复时间(MTTR)

---

MTTR是衡量企业解决问题有效性的指标。分析业务和客户体验效果的能力为全面理解和确定优先事项提供了所需的视角。

MTTR计算了从失败到解决的总响应时间，并提供了关于客户是否无法控制、遇到延迟或放弃系统的信息。提高MTTR可以降低这些问题的影响，维持用户的幸福感。

通过掌握实用的应用管理工具，快速、无感地发现问题并执行补丁，对降低MTTR至关重要。

交付时间

---

衡量工作流程和效率的一个重要指标是估算一个项目从概念到实施所需的平均时间。较少的准备时间表明团队是灵活的、反应迅速的并且能够快速响应反馈。

DevOps相关的敏捷方法论可以让框架改进有一个快速的处理期，满足消费者的需求，并关注变化的趋势。你可以使用Jira和Trello等工具来有效地获取你的准备时间。

更改量

---

由于DevOps涉及频繁的更改，因此你必须衡量部署之间的更改率，以支持你的部署频率。最终的目的应该是集中精力进行有意义的改进以减少不便，并带来更流畅的体验。对于每个部署，监控变更量可以更精确地描述开发情况。你可以从GitHub、Bitbucket和Jira等工具中获得这些信息。

客户服务记录

---

积极的客户体验对产品的生存至关重要。满意的客户和良好的客户服务会带来销售量的增加。这就是为什么客户服务记录表明了客户的满意程度，反映了你的DevOps流程的质量。数字越小，服务越好。

总  结

---

DevOps的目的是促进开发团队和运维团队之间的协调和协作，以支持应用程序的快速执行，同时最大限度地减少中断、延迟和对最终用户体验产生负面影响的问题。

这取决于你所在领域的特定问题和需求来选择具体的DevOps指标进行跟踪。选择合适的指标进行监控，将有助于指导与开发和技术相关的战略决策，同时支持当前DevOps活动的执行。

文章来源：RancheLabs / 可点击查看原文链接

作者：

Sara Miteva

链接：

https://dzone.com/articles/13-devops-metrics-for-increased-productivity

END

---

Kubernetes CKA实战培训班推荐：深圳：11月13-15日