DevOps 研究和评估 (DORA) 关键指标

DevOps 研究和评估 (DORA) 团队确定了衡量 DevOps 性能的四个指标。使用这些指标有助于提高 DevOps 效率并向业务利益相关者传达性能，从而加速业务成果。

DORA 包括四个关键指标，分为 DevOps 的两个核心领域：

对于软件开发领导者而言，跟踪速度和质量指标可确保他们不会为了速度而牺牲质量。

极狐GitLab 中的 DORA 指标

极狐GitLab 提供关于 DORA 指标的不同分析和洞察，这些指标在以下分析功能中可用：

部署频率

  • all 和 monthly 间隔的频率计算公式修复于 16.0 版本。

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

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

部署频率预测

部署频率预测（之前叫做价值流预测）使用统计预测模型来预测生产力指标，并识别软件开发生命周期中的异常。此信息能够帮助你改进产品和团队的规划和决策。

如何计算部署频率

在极狐GitLab 中，部署频率是根据部署的结束时间（finished_at 属性），通过特定环境每天的平均部署次数来衡量的。 极狐GitLab 根据特定日期完成的部署次数来计算部署频率。

生产环境或名为 production/prod 的环境计算在内，环境必须是生产部署级别的一部分，其部署信息才能显示在图表上。

如何提高部署频率

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

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

变更的前置时间

变更的前置时间是代码更改投入生产所需的时间。

“变更的前置时间”与“前置时间”不同。在价值流中，“前置时间”度量的是解决议题的工作从提出请求（议题创建）到完成并交付（议题关闭）所需的时间。

对于软件开发领导者来说，变更的前置时间反映了 CI/CD 流水线的效率，并可视化了向客户交付工作的速度。 随着时间的推移，变更的前置时间应该会减少，您的团队的效率应该会提高。更短的变更的前置时间意味着更高效的 CI/CD 流水线。 在极狐GitLab 中，变更的前置时间是度量将合并请求合并到生产（来自 master 分支）环境所需的中位时间。

如何计算变更的前置时间

极狐GitLab 根据成功将提交交付到生产环境中的秒数，计算变更的前置时间 - 从代码提交到代码在生产中成功运行，而不将编码时间计算在内。

如何缩短变更的前置时间

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

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

恢复服务时间

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

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

如何计算恢复服务时间

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

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

如何缩短恢复服务时间

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

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

变更失败率

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

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

如何计算变更失败率

在极狐GitLab 中，变更失败率为在特定时间段内导致生产事件的部署所占百分比。 极狐GitLab 通过用事件数除以部署到生产环境的数量来计算。需要满足以下条件：

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

如何降低变更失败率

第一步是对团队和项目之间的质量和稳定性进行基准测试。

要改进此指标，您应该考虑：

  • 在稳定性和吞吐量（部署频率和变更准备时间）之间找到正确的平衡，而不是为了速度而牺牲质量。
  • 提高代码审核流程的效率。
  • 添加更多自动化测试。

DORA 自定义计算规则

  • 引入于极狐GitLab 15.4，使用名为 dora_configuration 的功能标志。默认情况下已禁用此功能。此功能是实验性的。
在私有化部署的极狐GitLab 上，此功能默认不可用。要想为每个项目或整个实例启用此功能，管理员必须启用名为 dora_configuration 的功能标志。在极狐JihuLab.com 上，此功能不可用。

此功能是一个实验。

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

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

通过使用属于开发流程一部分的目标分支来更新 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'])

To update an existing configuration, run the following command:

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 指标数据

要获取 DORA 数据，您可以使用 GraphQL 或 REST API。

下面的示例使用 GraphQL API 来检索给定时间段内的每月部署频率：

{
  project(fullPath: "gitlab-org/gitlab") {
    dora {
      metrics(
        startDate: "2023-12-01"
        endDate: "2024-01-31"
        interval: MONTHLY
      ) {
        date
        deploymentFrequency
        leadTimeForChanges
        timeToRestoreService
        changeFailureRate
      }
    }
  }
}

您还可以使用交互式 GraphQL explorer 来探索 GraphQL API 资源。

衡量 DORA 指标

在不使用极狐GitLab CI/CD 流水线情况下衡量 DORA 指标

部署频率是根据部署记录计算的，该记录是为典型的基于推送的部署创建的。这些部署记录不会为基于拉取的部署创建，例如，当使用代理来实现容器镜像与极狐GitLab 连接时。

要追踪这些例子中的 DORA 指标，您可以使用部署 API 创建部署记录。您必须设置环境名称，因为环境变量是为给定环境指定的，而不是为部署指定的。更多详情，可查阅追踪外部部署工具的部署。

使用 Jira 来衡量 DORA 指标

使用外部事件衡量 DORA 恢复服务时间和变更失败率

对于 PagerDuty，您可以设置 webhook 以自动为每个 PagerDuty 事件创建极狐GitLab 事件。此配置需要您在 PagerDuty 和极狐GitLab 同时变更。

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

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

DORA 指标可用性

下面的表格提供了项目和群组中可用的 DORA 指标：

指标 级别 注释
deployment_frequency 项目 部署计数单位。
deployment_frequency 群组 部署计数单位。聚合方法是平均。
lead_time_for_changes 项目 单位是秒。聚合方法是中位数。
lead_time_for_changes 群组 单位是秒。聚合方法是中位数。
time_to_restore_service 项目和群组 单位是天。聚合方法是中位数。（在极狐GitLab 15.1 及以后版本，在 UI 上可用）
change_failure_rate 项目和群组 部署百分比。（在极狐GitLab 15.2 及以后版本，在 UI 上可用）

DORA 指标数据聚合

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

指标名称e 衡量值 价值流仪表盘中的数据聚合。 CI/CD 分析图表中的数据聚合。 自定义洞察报告中的数据聚合。
部署频率 成功部署的次数 每个月的平均天数 平均天数 day（默认）或 month
变更前置时间 将一次提交成功部署到生产环境所花费的秒数 每个月的平均天数 中位数事件 day（默认）或 month
服务恢复时间 事件打开的秒数 每个月的每天中位数 天数的中位数 day（默认）或 month
变更失败率 引发生产事件的部署百分比 每个月的平均天数 失败部署的百分比 day（默认）或 month