衡量重要指标

交付前置时间（Delivery Lead Time）

交付前置时间（DLT）是指从工程师开始工作一个功能，到该功能对最终用户可用的时间。可以说是从代码提交到生产环境的时间——但通常是在团队开始处理某个需求并将其状态更改为“进行中” 或类似的状态时开始计时。

从系统中自动获取这个指标并不容易。在第 7 章《运行工作流》中，我将向你展示如何结合使用 GitHub Actions 和 Projects 来自动化该指标。如果无法从系统中获取该指标，可以设置一个调查，选项如下：

根据你在该尺度上的位置，进行调查的频率会有所不同。当然，从系统生成的值会更为理想，但如果你处于该尺度的上端（几个月），那就无所谓了。如果是测量小时或天数，情况会更加有趣。

部署频率（Deployment Frequency）

部署频率（DF）侧重于速度。它衡量的是交付变更的时间。一个更加关注吞吐量的指标就是部署频率。它表示你将更改部署到生产环境的频率。部署频率反映了你的批量大小。在精益生产中，减少批量大小是理想的目标。较高的部署频率表明较小的批量大小。

乍一看，似乎很容易在系统中度量部署频率。但仔细想想，实际上有多少次部署最终能成功到达生产环境呢？在第 7 章 《运行工作流》 中，我将解释如何通过 GitHub Actions 来捕获这个指标。

如果你暂时无法度量该指标，也可以使用调查来代替。可以选择以下选项：

一个衡量稳定性的好指标是平均恢复时间（MTTR）。它衡量的是在发生故障时，恢复你的产品或服务所需的时间。如果你衡量的是系统的正常运行时间，它实际上就是服务不可用的时间跨度。

要衡量正常运行时间，你可以使用烟雾测试，例如在应用程序洞察（Application Insights）中进行测试（请参见： https://docs.microsoft.com/en-us/azure/azure-monitor/app/monitor-web-app-availability ）。如果你的应用程序安装在客户端机器上且无法访问，则会更为复杂。通常情况下，你可以依赖于帮助台系统中某种特定类型的工单处理时间。

如果你完全无法测量该指标，你仍然可以使用调查来代替，提供以下选项：

但这应该仅作为最后的手段。MTTR应该是一个可以轻松从系统中提取的指标。

与性能的交付周期时间（DLT）类似，平均恢复时间（MTTR）是衡量稳定性的时间指标。而与交付频率（DF）关注吞吐量相对应的是变更失败率（CFR）。对于 “你们的多少次部署导致了生产环境中的失败？” 这个问题，CFR 作为一个百分比指标来衡量。

为了确定哪些部署应计入该指标，你应该使用与 DF 相同的定义标准。

基于 DORA 研究的这四个指标是衡量你在 DevOps 旅程中进展的一个很好的方式。它们是改变与管理层对话的良好起点。将这些指标放在仪表板上，并为它们感到自豪。如果你还不是精英表现者，也不用担心——重要的是要在这条旅程上，并且不断改进。

从基于调查的数据开始是非常简单的。但如果你想使用自动生成的系统数据，可以使用四个关键指标（Four Keys）项目将数据展示在一个漂亮的仪表板上（见图 1.4）。

该项目是开源的，基于 Google Cloud（见： https://github.com/GoogleCloudPlatform/fourkeys ），但它依赖于 Webhook 从您的工具获取数据。您将在第 7 章《运行工作流》中学习如何使用 Webhook 将数据发送到仪表板。

重要的是，这些指标不应该用来比较团队之间的表现。您可以将它们聚合起来以获得组织的概览，但不要比较各个团队！每个团队都有不同的情况，重要的是这些指标朝着正确的方向发展。

此外，指标不应成为最终目标。仅仅为了获得更好的指标并不是我们想要的。重点应该始终放在那些带来这些指标的能力上，这些能力是本书中讨论的内容。专注于这些能力，指标自然会跟随而来。