• DevOps 研究与评估 (DORA) 指标
• 部署频率
  • 部署频率预测
  • 部署频率的计算方式
  • 如何提高部署频率
• 变更前置时间
  • 变更前置时间的计算方式
  • 如何提高变更前置时间
• 恢复服务时间
  • 恢复服务时间的计算方式
  • 如何提高恢复服务时间
• 变更失败率
  • 变更失败率的计算方式
  • 如何提高变更失败率
• DORA 自定义计算规则
  • 多分支变更前置时间规则
• 测量 DORA 指标
  • 不使用极狐GitLab CI/CD 流水线
  • 使用 Jira
  • 使用外部事件
• 分析功能
• 项目和群组可用性
• 数据聚合

{{< details >}}

• Tier: 旗舰版
• Offering: JihuLab.com, 私有化部署

{{< /details >}}

DevOps 研究与评估 (DORA) 指标

DevOps 研究和评估 (DORA) 指标提供基于证据的洞察，以了解您的 DevOps 性能。这四个关键测量展示了您的团队交付变更的速度以及这些变更在生产中的表现如何。当持续跟踪时，DORA 指标能够突出软件交付过程中的改进机会。

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

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

• 速度指标 跟踪您的组织交付软件的速度：
  • 部署频率：代码部署到生产的频率
  • 变更前置时间：代码到达生产的时间
• 稳定性指标 衡量软件的可靠性：
  • 变更失败率：部署导致生产失败的频率
  • 恢复服务时间：故障后服务恢复的速度

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

部署频率

{{< history >}}

• 在极狐GitLab 16.0 中引入了对于 all 和 monthly 间隔的频率计算公式。

{{< /history >}}

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

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

部署频率预测

{{< details >}}

• Tier: 旗舰版
• Offering: JihuLab.com, 私有化部署
• Status: 实验

{{< /details >}}

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

部署频率的计算方式

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

计算考虑到生产 环境层级 或名为 production/prod 的环境。环境必须是生产部署层的一部分，其部署信息才能出现在图表上。

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

{{< alert type=”note” >}}

部署频率的计算方式为 平均值（mean），不同于其他使用中位数的 DORA 指标，因为中位数提供了更准确和可靠的性能视图。这一差异是因为在采用 DORA 框架之前，极狐GitLab 已经添加了部署频率，并且在将其纳入其他报告时，指标的计算保持不变。

{{< /alert >}}

如何提高部署频率

第一步是对群组和项目之间的代码发布节奏进行基准测试。接下来，您应考虑：

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

变更前置时间

变更前置时间是指代码更改到达生产的时间。

变更前置时间 与 前置时间 不同。在价值流分析中，前置时间衡量议题从请求（议题创建）到履行和交付（议题关闭）的时间。

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

变更前置时间的计算方式

极狐GitLab 根据成功将合并请求交付到生产的秒数计算变更前置时间：从合并请求合并时间（点击合并按钮时）到代码成功运行在生产中，不将 coding_time 添加到计算中。数据在部署完成后立即聚合，有轻微的延迟。

默认情况下，变更前置时间仅支持测量一个分支操作及多个部署作业（例如，从开发到暂存到默认分支上的生产）。当合并请求在暂存和生产中合并时，极狐GitLab 将其解释为两个已部署的合并请求，而不是一个。

如何提高变更前置时间

第一步是对群组和项目之间的 CI/CD 流水线效率进行基准测试。接下来，您应考虑：

• 使用价值流分析识别流程中的瓶颈。
• 将更改分解为更小的迭代。
• 添加自动化。
• 改善流水线性能。

恢复服务时间

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

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

恢复服务时间的计算方式

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

• 极狐GitLab事件 被跟踪。
• 所有事件都与生产环境相关。
• 事件和部署有严格的一对一关系。一个事件仅与一个生产部署相关，而任何生产部署不超过一个事件。

如何提高恢复服务时间

第一步是对群组和项目之间的团队响应和服务中断恢复进行基准测试。接下来，您应考虑：

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

变更失败率

变更失败率是指变更在生产中导致失败的频率。

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

变更失败率的计算方式

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

• 极狐GitLab事件 被跟踪。
• 所有事件都是生产事件，无论环境如何。
• 变更失败率主要用作高层次的稳定性跟踪，这就是为什么在给定的一天中，所有事件和部署都被聚合为一个联合的每日率。
• 变更失败率将重复事件计算为单独的条目，导致重复计数。

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

如何提高变更失败率

第一步是对群组和项目之间的质量和稳定性进行基准测试。接下来，您应考虑：

• 在稳定性和吞吐量（部署频率和变更前置时间）之间找到正确的平衡，不以牺牲质量为代价换取速度。
• 改善代码审查过程的有效性。
• 添加自动化测试。

DORA 自定义计算规则

{{< details >}}

• Tier: 旗舰版
• Offering: 私有化部署
• Status: 实验

{{< /details >}}

{{< history >}}

• 引入于极狐GitLab 15.4，使用名为 dora_configuration 的功能标志。默认情况下禁用。此功能为实验。

{{< /history >}}

{{< alert type=”flag” >}}

此功能的可用性由一个功能标志控制。有关更多信息，请参阅历史记录。

{{< /alert >}}

多分支变更前置时间规则

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

此计算规则通过更新包含开发流中目标分支的 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 创建部署记录。必须设置部署层级配置的环境名称，因为层级变量是为给定环境而不是为部署指定的。有关更多信息，请参阅如何跟踪外部部署工具的部署。

使用 Jira

• 部署频率和变更前置时间基于极狐GitLab CI/CD 和合并请求（MRs）计算，不需要 Jira 数据。
• 恢复服务时间和变更失败率需要 极狐GitLab事件 进行计算。

使用外部事件

您可以测量恢复服务时间和变更失败率用于事件管理。

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

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

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

分析功能

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

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

项目和群组可用性

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

数据聚合

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