衡量 DevOps 成功与否的重要度量指标

简介

DevOps 理念已经掌握了软件交付流程的许多方面。因此，我们值得深入了解能够表明成功标志和需要改进方面的日常运营，而不是仅仅关注表明“正常状态”的日常报告。如今的 DevOps 度量指标侧重于在（或应在）公司的 DevOps 实现过程中收集的可衡量数据。

收集这些度量指标的信息和工具包括部署数量等简单的进度指标，以及支持证明额外自动化的数据的组合视图等等。那些对衡量 DevOps 度量指标的履行情况感兴趣的人员希望透过“放大镜头”研究 DevOps。我们将更深入地了解帮助提供该数据的度量指标和工具。

成功实现 DevOps 是一种什么情况？

确定在证明成功实现 DevOps 与否时涉及的基准和其他因素是很重要的。除了我们将会讨论的可衡量的度量指标之外，成功的 DevOps 实现取决于公司提供的产品和服务相关特定因素。

总的来说，实现 DevOps 的主要目标是以作出更少人工干预的方式实现软件交付的自动化。在这一过程中，通过各种方式提高了质量。Pre-commit git 钩子用于检查一组特定的策略。这些策略有助于防止代码到达代码库。可以通过自动化 QA 方法在合并代码之前对 API 和 UI 进行广泛测试。

那么，这是否意味着如果您在管道中执行这些步骤，您就已经成功实现 DevOps 了呢？事实并非如此。这些只是 DevOps 希望协助解决的整体问题的一小部分，特别是对于如今的软件交付的其他自动化需求而言。通过一组 DevOps 度量指标衡量成功与否，有助于忽略小成就，展示理念的整体效益。我们还能如何确定是否值得投入精力到其他 DevOps 自动化方面，以及如何持续作出改进呢？

关键是要持续进行评估和改进

在初步实现了 DevOps 过程之后，需要更广泛地关注实现过程的履行情况。在孤岛模式下开展的工作从未被证明对软件团队有用，重要的是要能够查看和持续改进 DevOps 过程。

在 DevOps 等服务类型设置中开展工作的最佳方式是什么？有一些可能比其他因素更具有衡量性的因素。如果你所在的团队处理了服务台等票证，你可以使用 SLA 等来展开跟踪。如上所述，在修改自动化之后生成的支持事件的数量可能非常重要。

对其他 DevOps 度量指标之外的这些因素进行进一步分析之后，可以更恰当地了解整体情况，展示出包括虚荣数字的元素。虽然了解成功完成了多少次构建可能会很有趣，但当与更深入探究这些构建的下游影响的其他度量指标（包括与 sprint 或类似的软件交付时间表相关的发布）相比时，该数字将有更多的含义。

数据驱动型 DevOps 度量指标的优势

所有这些优势都归结于观察如何按照实现和一些