DevOps 研究与评估 (DORA) 指标

DevOps Research and Assessment (DORA) 指标 为您的 DevOps 性能提供基于证据的洞察。 这四个关键指标展示了您的团队交付变更的速度 以及这些变更在生产环境中的表现。 当持续跟踪时，DORA 指标会突出显示您软件交付过程中的改进机会。

使用 DORA 指标进行战略决策，向利益相关者证明流程改进投资的合理性， 或将团队性能与行业基准进行比较，以识别竞争优势。

四个 DORA 指标衡量 DevOps 的两个关键方面：

• Velocity 指标跟踪您的组织交付软件的速度：

  • 部署频率：代码部署到生产环境的频率
  • 变更前置时间：代码到达生产环境所需的时间

• Stability 指标衡量软件的可靠性：

  • 变更失败率：部署导致生产环境故障的频率
  • 服务恢复时间：故障后服务恢复的速度

对速度和稳定性指标的双重关注帮助领导者在交付工作流程中找到速度与质量之间的最佳平衡。

有关视频说明，请查看 DORA 指标：用户分析 和 GitLab 速跑：DORA 指标。

部署频率

部署频率是指在给定日期范围内（每小时、每天、每周、每月或每年）成功部署到生产环境的频率。

软件领导者可以使用部署频率指标来了解团队成功将软件部署到生产环境的频率，以及团队能多快地响应客户请求或新的市场机会。 高部署频率意味着您可以更快地获得反馈并更快地迭代以交付改进和功能。

部署频率预测

部署频率预测（前称为价值流预测）使用统计预测模型来预测生产力指标并识别整个软件开发生命周期中的异常。 这些信息可以帮助您改进产品和团队的规划与决策。

观看 价值流预测 的概述。

部署频率的计算方法

在 GitLab 中，部署频率基于部署的结束时间（其 finished_at 属性）计算为给定环境每天的平均部署次数。 GitLab 根据给定日期的已完成部署数量计算部署频率。仅计算成功的部署（Deployment.statuses = success）。

计算考虑了生产环境的 environment tier 或命名为 production/prod 的环境。环境必须是生产部署 tier 的一部分，其部署信息才会显示在图表上。

您可以通过在 .gitlab/insights.yml 文件 中的 environment_tiers 参数下指定 other 来为不同环境配置 DORA 指标。

如何改进部署频率

第一步是衡量组和项目之间代码发布的节奏。接下来，您应该考虑：

• 添加自动化测试。
• 添加自动化代码验证。
• 将变更分解为更小的迭代。

变更前置时间

变更前置时间是指代码变更进入生产环境所需的时间。

变更前置时间不同于前置时间。在价值流分析中，前置时间衡量的是从请求工作（问题创建）到完成并交付（问题关闭）所花费的时间。

对于软件领导者来说，变更前置时间反映了 CI/CD 管道的效率，并可视化工作交付给客户的速度。 随着时间的推移，变更前置时间应该减少，而团队性能应该提高。低变更前置时间意味着更高效的 CI/CD 管道。

变更前置时间的计算方法

GitLab 根据成功地将合并请求交付到生产环境所需的秒数来计算变更前置时间：从合并请求合并时间（点击合并按钮时）到代码在生产环境中成功运行，而不将 coding_time 添加到计算中。数据在部署完成后进行聚合，略有延迟。

默认情况下，变更前置时间仅支持测量具有多个部署作业的单个分支操作（例如，从开发分支到暂存分支再到生产分支的默认分支）。当合并请求在暂存环境合并，然后在生产环境合并时，GitLab 将它们解释为两个已部署的合并请求，而不是一个。

在合并前完成的部署

在极少数情况下，部署可能在其关联的合并请求合并之前完成。

这种情况可能发生在以下场景：

• 部署流程独立于合并工作流触发。
• 在代码审查完成之前进行手动部署干预。

在这种情况下，GitLab 使用公式：GREATEST(0, deployment_finished_at - merge_request_merged_at)。 GREATEST 函数通过返回 0 而不是负值来确保前置时间值永远不会为负数。 此函数防止数据库约束违规，同时保持数据完整性。

如何改进变更前置时间

第一步是衡量组和项目之间 CI/CD 管道的效率。接下来，您应该考虑：

• 使用价值流分析来识别流程中的瓶颈。
• 将变更分解为更小的迭代。
• 添加自动化。
• 改进管道的性能。

服务恢复时间

服务恢复时间是指组织从生产环境故障中恢复所需的时间。

对于软件领导者来说，服务恢复时间反映了组织从生产环境故障中恢复所需的时间。 低服务恢复时间意味着组织可以承担新创新功能的风险，以推动竞争优势并提高业务成果。

服务恢复时间的计算方法

在 GitLab 中，服务恢复时间衡量的是事件在生产环境中打开时间的中位数。 GitLab 计算给定时间段内事件在生产环境中打开的秒数。这假设：

• GitLab 事件被跟踪。
• 所有事件都与生产环境相关。
• 事件和部署具有严格的一对一关系。一个事件仅与一个生产部署相关，任何生产部署最多与一个事件相关。

如何改进服务恢复时间

第一步是衡量团队对服务中断和故障的响应和恢复能力，在组和项目之间进行比较。接下来，您应该考虑：

• 提高对生产环境的可观测性。
• 改进响应工作流程。
• 改进部署频率和变更前置时间，以便修复能更高效地进入生产环境。

变更失败率

变更失败率是指变更导致生产环境故障的频率。

软件领导者可以使用变更失败率指标来了解所发布代码的质量。 高变更失败率可能表明部署流程效率低下或自动化测试覆盖率不足。

变更失败率的计算方法

在 GitLab 中，变更失败率衡量的是在给定时间段内导致生产环境事件发生的部署百分比。 GitLab 将变更失败率计算为事件数量除以生产环境的部署数量。此计算假设：

• GitLab 事件被跟踪。
• 所有事件都是生产环境事件，无论环境如何。
• 变更失败率主要用作高级稳定性跟踪，因此在给定的一天中，所有事件和部署都聚合为联合的每日费率。在 问题 444295 中提议添加部署和事件之间的特定关系。
• 变更失败率将重复事件计算为单独的条目，导致重复计算。问题 480920 提出了更准确计算的解决方案。

例如，如果您有 10 次部署（假设每天一次部署），第一天有两次事件，最后一天有一次事件，那么您的变更失败率为 0.3。

如何改进变更失败率

第一步是衡量组和项目之间的质量和稳定性。接下来，您应该考虑：

• 在稳定性和吞吐量（部署频率和变更前置时间）之间找到适当的平衡，不要为了速度而牺牲质量。
• 改进代码审查流程的效率。
• 添加自动化测试。

DORA 自定义计算规则

此功能是一项实验性功能。 要加入测试此功能的用户列表，这里有一个建议的测试流程。 如果您发现错误，请在此处提交问题。 要分享您的用例和反馈，请在 史诗 11490 中发表评论。

变更前置时间的多分支规则

与默认的变更前置时间计算不同，此计算规则允许测量每个操作具有单个部署作业的多分支操作。 例如，从开发分支的开发作业，到暂存分支的暂存作业，再到生产分支的生产作业。

此计算规则已通过更新 dora_configurations 表来实现，其中包含属于开发流程的目标分支。 这样，GitLab 可以将这些分支识别为一个，并过滤掉其他合并请求。

此配置会更改所选项目的每日 DORA 指标的计算方式，但不影响其他项目、组或用户。

此功能仅支持项目级传播。

为此，在 Rails 控制台中运行以下命令：

my_project = Project.find_by_full_path('group/subgroup/project')
Dora::Configuration.create!(project: my_project, branches_for_lead_time_for_changes: ['master', 'main'])

要更新现有配置，请运行以下命令：

my_project = Project.find_by_full_path('group/subgroup/project')
record = Dora::Configuration.where(project: my_project).first
record.branches_for_lead_time_for_changes = ['development', 'staging', 'master', 'main']
record.save!

衡量 DORA 指标

不使用 GitLab CI/CD 管道

部署频率基于部署记录计算，该记录为典型的基于推送的部署创建。 对于基于拉取的部署，不会创建这些部署记录，例如当容器镜像通过代理连接到 GitLab 时。

在这些情况下要跟踪 DORA 指标，您可以使用部署 API创建部署记录。 您必须设置配置了部署 tier 的环境名称，因为 tier 变量是为给定环境指定的，而不是为部署指定的。 有关更多信息，请参阅如何跟踪外部部署工具的部署。

与 Jira 配合使用

• 部署频率和变更前置时间基于 GitLab CI/CD 和合并请求（MR）计算，不需要 Jira 数据。
• 服务恢复时间和变更失败率需要 GitLab 事件进行计算。有关更多信息，请参阅如何使用外部事件衡量这些指标以及 Jira 事件复制器指南。

与外部事件配合使用

您可以衡量事件管理中的服务恢复时间和变更失败率。

对于 PagerDuty，您可以设置 webhook 为每个 PagerDuty 事件自动创建 GitLab 事件。 此配置要求您在 PagerDuty 和 GitLab 中都进行更改。

对于其他事件管理工具，您可以设置 HTTP 集成， 并使用它来自动：

1. 在触发警报时创建事件。
2. 通过恢复警报关闭事件。

分析功能

DORA 指标显示在以下分析功能中：

• 价值流仪表板 包含 DORA 指标比较面板 和 DORA 执行者评分面板。
• CI/CD 分析图表 显示 DORA 指标随时间的历史记录。
• 洞察报告 提供使用 DORA 查询参数 创建自定义图表的选项。
• GraphQL API（带有交互式 GraphQL 探索器）和 REST API 支持检索指标数据。

项目和组可用性

下表提供了 DORA 指标在项目和组中的可用性概述。

数据聚合

下表提供了 DORA 指标在不同图表中数据聚合的概述。