Amir Kirsh
简介
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 度量指标的优势
所有这些优势都归结于观察如何按照实现和一些行业标准切实进行 DevOps。这超出了虚荣度量指标的范畴，深入探究了我们希望 DevOps 能够完成的工作的核心：提供一种以可重复、一致和不出现错误的方式自动化交付软件和服务的方法。
从最初开始到交付，以及最终支持发布相关的事件度量指标，这些都是展示如今 DevOps 的优势的重要信息。虽然不一定存在能够快速达到这些 DevOps 度量指标的产品或服务，有一些行业正在研究帮助指导您获取最佳方式的方法。
也有可能收集太多或错误类型的数据。回到我们关于“成功构建次数”等虚荣度量指标的示例，团队可能会禁不住开始查看小块数据作为其绩效指标。某个特定团队可能会将添加更多代码行视为成功的标志，但实际值可能并不能说明交付时的成败。
通过在开始进行自动化时记住数据，可以在早期发现一些更常见的数据元素。这些元素可能会使你得到深刻理解。确定可供收集的数据，并记住该数据的处理方式以及如何将其作为关键绩效指标 (KPI)。KPI 属于可测值，能够显示出关键业务指标的进程。可以从特定目标的任务分配和 CI/CD 信息中获得“交付周期”等常见度量指标。
这些 DevOps 度量指标应遵循表示有用数据的行业公认特性和标准。你可能听说过“SMART”这个首字母缩写词：具体的、可衡量的、可达到的、和其他目标相关的和有时间限制的。以下给出了在软件开发生命周期中遵循 SMART 方法的特性相关恰当示例：
- 由于度量指标具有可取平均数（数字）或计数（例如，通过/未通过）的实际值，因此该指标应可供衡量。可以使用百分比表示具体度量指标之间的关系（例如，进行测试总数中打开的缺陷数量/测试行总数）。
- 度量指标之间存在的相关性是很重要的，通常取决于业务或服务。自然能明显地了解二者之间的相关性，这是因为对于实际业务结果无关的方面进行衡量和作出反应毫无意义（但是，不是很明显地了解到与实际业务结果相关的方面）。
- 防止团队成员伪造或夸大结果。应以灵活的方式记录度量指标。例如，“打开的缺陷数量”是一种很容易通过打开然后关闭虚假缺陷（例如，由想要呈现高活动水平的测试工程师进行）而造成“混乱”的度量指标。我们将讨论处理这些问题的方法。但是对于该示例，我们可以决定忽略已经关闭的状态为“不属于问题”或“不可再现的”缺陷。
- 通过纳入其它政策的自动化和实现工作流程，确定有助于改进整个流程的措施。这与相关性存在关联：由于无法确定会对度量指标产生影响的措施，因此您不会想要将精力投入到您无法控制任何改进的这些度量指标。
- 可溯源性是 DevOps 度量指标的一个重要特性。不仅仅是要表明失败，而必须要提供找到故障发生位置或者对应的数据元素的路径。
DevOps 研究和评估 (DORA) 帮助确定了作为重要数据点的关键度量指标。认为在大多数情况下能够以定向和容易的方式实现这些指标。有四种通常被作为 KPI 的这类度量指标，有助于捕获整体的交付履行情况：
- 部署频率
DevOps 自动化的首要原则之一是进行部署。这确实是一种展示自动化以及从代码存储库到部署目标之间的各种集成的价值的方法。您可能会无法了解这些部署的其他方面，例如，在这些部署中，有多少导致了影响其他关键度量指标的额外失败？
该度量指标的信息通常来自用于部署的软件。在大多数情况下，市面上的主要构建和部署产品在内部都具有可用于这类数据的报告功能。仅通过该数据点便可能会显示出 DevOps 已经实现了较高的绩效水平。但是，与大多数度量指标一样，需要结合其他信息一同查看该度量指标，确保部署频率不会因希望在没有进展的情况下显示进展而增加。
例如，Azure DevOps 将更多信息与发布度量指标联系起来。这有利于确定其他重要的数据点：可将工作项与软件开发过程联系起来，从而将更改历史和部署信息的简单频率都包括在内。其他源控制/
工具也具有类似的特性。
- 交付周期
想象一下计时器从开发人员提交更改的时刻开始到在生产环境中运行的时刻为止。这段时间通常被称为“交付周期”，可以快速表明显示 DevOps 自动化进展的进行情况。交付周期较长可能意味着在效率和自动化机会方面还有更多需要作出改进的地方。
要衡量该 DevOps 度量指标，要结合多个系统的信息来创建完整的视图。如果团队通过 Atlassian JIRA 完成工作，但通过 Jenkins 发布工作，可能存在必须通过这两个工具编译的数据，以显示出真实的交付周期。我们大多数人对 DevOps 工具的这种混合使用并不陌生。该度量指标可以很好地表明团队对反馈和特性请求的响应速度。虽然受具体项目、使用的工具和开发复杂度的影响，可能难以设定该度量指标的期望目标，但我们应为之奋斗的目标是随着时间的推移情况得到改善，例如，部署时间占几分钟而不是几小时就算胜利了。
- 平均恢复时间
故障常有发生。关键一点是要减少这些故障的影响。关键的度量指标要显示出在通常情况下从故障中恢复要花多长时间。平均恢复时间系指从故障中恢复需要花费的一段时间。收集该数据能够显示出团队如何能够响应需要发布代码、重新配置或采取其他故障排除措施的缺陷或中断。考虑到多种环境，收集的信息可能需要衡量多个点。例如，该值是否考虑了在开发和生产过程中进行恢复所要花费的时间？
通过使用关于内外部客户的服务票证的信息，可以构建用于计算度量指标的方法。票证和相关 SLA 度量指标是基于“交付周期”等其他度量指标进行衡量的，以得出“恢复时间”。通过平均值等统计计算方式，可使度量指标具有针对性。人们希望缩短恢复时间来提供更好的支持。问题在于，从出现主要问题的那一刻起，团队能多快确定、了解和解决根本原因以及部署解决方案。
- 变更故障率
该度量指标捕获了提交故障的比率（我们在此使用非常通用意义上的“提交”这一术语：你可以实现将代码提交到主分支，从开发部署到集成/系统测试等）。
该度量指标侧重于在生产过程中部署的代码的质量，以及 DevOps 门的质量。开始的时候你可能会认为 0% 的故障率属于最理想值，但这在真实场景中是不切实际的，且在大多数情况下可能会指向较高的开发质量，而不是 DevOps 门的较低质量。较高的更改故障率能够显示是按设计方式进行自动化的，但您在开发时可能会遇到问题，或者缺失之前的门。
应该强调的是，应对门作出研发，以便在提交之前进行自检。底线：如果变更故障率较高，即使在最佳状态下进行 DevOps，也不是太好的一个情况。这就是为什么这是一个较好的度量指标！通过使用发布管理软件，可以非常容易地找到该度量指标。此外，如果我们能够将变更情况追溯到提交内容，便可以分析具体情况，从而确定问题的根本原因，查看问题是否来自特定区域，我们是否缺失某个之前的门，等等。
还有哪些可能的 DevOps 度量指标？
虽然我们如上讨论的“北极星”度量指标在许多情况下都适用，但其他度量指标需要基于不同的标记来表明成败或显示进展情况。请记住一些度量指标更具有“虚荣”性质，而一些度量指标恰恰为该应用场景中所需的度量指标。
- 部署时间——这一度量指标对于其他团队来说要么非常重要，要么并不那么重要。有时，受运算顺序的影响，需要达到较高的部署率。而在其他时候，该度量指标表明构建代理需要更多的资源。该度量指标为“交付周期”的一个子集，仅侧重于部署部分，不关注构建和测试的 CI 管道。
- 部署失败——与发布失败不同，该度量指标是关于尝试时有多少次部署出错。这通常表明发布环境不稳定，但也可能是在执行构建和发布的过程中发生配置错误，可能是在部署前缺失门，或者在该过程中有部件松动。这在开发人员能够使用 YAML 或其他类似定义来控制构建过程的领域可能尤其成立。
- 代码提交——它是一个可容易从源控制工具中检索到的简单度量指标。良好、平均和低提交率更多地取决于具体项目，应视具体情况进行说明。较高的提交率可以说明保持更新功能分支的良好实践。较低的提交率可以表明完成的工作少于预期，或者可能是开发人员在防止其经常提交代码的本地分支上开展工作。这两种情况都是有利的！
- 注入完成的活动——注入完成或未经计划的活动会对软件发布过程带来持续的影响。除了缩短用于特定工作项目的时间之外，人们通常希望使用该度量指标证明其他资源。一个关于可衡量活动的示例可能为向 DevOps 工程师提供的支持票证的数量，以及他们在与团队直接合作时开展的项目工作。
- 应用程序使用见解——对于那些发布前端应用程序的人而言，人们如何使用软件绝对是一项因素。如今，通过日志记录和使用跟踪功能，数据可以显示功能或缺陷修复如何影响消费者的反应。该度量指标虽然并非适用于所有行业，但能够很好地表明某种变化如何直接影响主要产品。例如，可以查看人们在应用程序发布后加以使用所产生的错误数量。如果该数值超过某个阈值，则表明某个方面在软件发布中受到损坏。
如你所看到的，许多这些 DevOps 度量指标都相互影响。在许多主要度量指标到位之后，它们之间如何相互影响就很明显了。这意味着如果“代码提交”度量指标显示的数值较低，但你拥有许多注入完成的活动，你可以推测由于在进行其他活动，提交的代码数量较少。
让我们测试另一个场景。对于“北极星”度量指标，“交付时间”和“应用程序使用见解”绝对会显示相互关联的趋势。会如何显示呢？比如，对于消费者提出的特性请求，你的交付周期较预期值长。使用见解可能会显示越来越少的应用程序访问次数，或者甚至与订阅相关的更深层次的度量指标。由于发布周期较长，这些和其他 DevOps 度量指标可能会显示损失。
如今如何使用 DevOps 度量指标，以及您应该如何使用这些度量指标？
显然很重要的是要进行衡量。不进行衡量，便很难以有方法的方式得到改进。对于改进流程，从长远来看，只靠直觉是不够的，尤其是组织和代码库在扩大时，甚至超出了单个团队的水平。但是，在不了解实际含义的情况下单独实现和进行度量指标应小心。这可能会造成错误和有偏见的行为（例如，不必要的频繁部署），表明进程进展顺利，但事实并非如此。这几乎适用于所有度量指标，也是寻求组合度量指标的原因，有助于了解真实情况，而不是在有遮挡的情况下进行查看。
有趣的是，使用度量指标来衡量 DevOps 成功与否的一些方面已经被边缘化了。可以获得关于这一主题的信息，但是在 DevOps 环中并没有太多这类信息。这究竟是由于需要优先考虑其他举措，还是缺少让所有人达成一致的成功实现，这很难说。我们大多数人都认为重要的是要持续改进我们自动化流程。这并不是说不使用 DevOps 度量指标——我们正在使用这些度量指标！但可能没有达到你所预期的使用程度，尤其是在与更具体的开发度量指标相比时（例如“代码覆盖率”，专门用于测试，且使用率较高。观察一件狭窄的工件（即使非常重要），主要部分更有趣，且有时会被忽略）。
值得注意的是，不同的组织和产品会考虑不同的度量指标，并为各项度量指标获得不同的实际值，这是自然的情况。但是任何寻求改进的组织都应基于各自的衡量情况设定目标。
展望未来，可以从 AI 系统获得其他度量指标。 DevOps 在未来可能会更关注自动化、基础设施即代码以及可以获得的海量数据。以创造性和有用的方式查看数据中的指标对于显示结果将变得越来越重要。
