DORA指标指南：衡量DevOps成功

DORA (DevOps研究与评估)指标是衡量软件交付性能的黄金标准。

基于多年对数千个团队的研究，这四个关键指标为您的DevOps能力提供了客观的洞察，并帮助识别改进领域。

这张重要的会议图片是由AI模型Flux 1 dev生成的。

什么是DORA指标？

由Nicole Forsgren、Jez Humble和Gene Kim发起的DORA研究项目自2014年以来一直在研究DevOps实践。通过“加速DevOps状态报告”，他们确定了四个预测软件交付性能的关键指标：

1. 部署频率 - 代码部署到生产环境的频率
2. 变更前置时间 - 从代码提交到生产部署的时间
3. 变更失败率 - 导致失败的部署百分比
4. 服务恢复时间 - 团队从事件中恢复的速度

这些指标与组织绩效、团队满意度和业务成果高度相关。在这些指标中表现优异的团队显示出50%更高的市值增长和2.5倍更快的上市时间。

四个关键指标详解

1. 部署频率

定义：您的组织成功将代码部署到生产环境的频率。

为什么重要：频繁的部署表明CI/CD实践成熟、批次大小较小且风险降低。部署更频繁的团队可以更快地解决问题并更快地为客户交付价值。

衡量等级：

• 精英：每天多次部署
• 高：每天一次到每周一次
• 中等：每月一次到每六个月一次
• 低：每六个月少于一次

如何跟踪：

# 示例：统计过去30天的部署次数
# 使用Git标签或部署日志
git log --since="30 days ago" --oneline | grep -i deploy | wc -l

# 或查询您的CI/CD系统
# Jenkins、GitLab CI、GitHub Actions等

当使用Git跟踪部署时，请参考我们的GIT命令速查表以获取版本控制和部署跟踪所需的全面Git操作。

提高部署频率的方法：

• 实施自动化的CI/CD流水线（参见我们的GitHub Actions速查表以获取CI/CD自动化示例）
• 减少部署批次大小
• 实践基于主分支的开发（与Gitflow分支模型进行比较，以了解不同的分支策略）
• 自动化测试和质量检查
• 使用功能标志进行更安全的部署

2. 变更前置时间

定义：从代码提交到版本控制，直到成功运行在生产环境中的时间。

为什么重要：较短的前置时间意味着更快的反馈循环、更快的错误修复和更迅速的交付。该指标反映了整个软件交付管道的效率。

衡量等级：

• 精英：少于一小时
• 高：一天到一周
• 中等：一个月到六个月
• 低：超过六个月

如何跟踪：

# 计算特定提交的前置时间
# 获取提交时间戳
COMMIT_TIME=$(git log -1 --format=%ct <commit-hash>)

# 获取部署时间戳（从您的部署系统）
DEPLOY_TIME=$(<deployment-timestamp>)

# 计算差异
LEAD_TIME=$((DEPLOY_TIME - COMMIT_TIME))

# 或使用工具：
# - GitHub Actions API
# - GitLab CI/CD指标
# - Jenkins构建时间戳

提高前置时间的方法：

• 优化CI/CD流水线速度
• 并行执行测试
• 减少手动审批关卡
• 实施自动化的质量检查
• 使用容器化以实现一致的环境
• 实践持续集成

3. 变更失败率

定义：导致生产环境中需要立即修复（热修复、回滚或补丁）的部署百分比。

为什么重要：低变更失败率表明代码质量高、测试有效且部署过程可靠。该指标在速度与稳定性之间取得平衡。

衡量等级：

• 精英：0-15%失败率
• 高：0-15%失败率
• 中等：16-30%失败率
• 低：16-45%失败率

如何跟踪：

# 计算过去一个月的失败率
TOTAL_DEPLOYS=$(count_deployments_last_month)
FAILED_DEPLOYS=$(count_failed_deployments_last_month)
FAILURE_RATE=$((FAILED_DEPLOYS * 100 / TOTAL_DEPLOYS))

# 使用以下工具进行跟踪：
# - 事件管理系统（PagerDuty、Opsgenie）
# - 监控警报（Datadog、New Relic、Prometheus）
# - 回滚日志
# - 热修复部署记录

提高变更失败率的方法：

• 增加测试覆盖率（单元、集成、端到端）
• 实施全面的监控和警报
• 使用金丝雀部署和蓝绿部署
• 实践混沌工程
• 改进代码审查流程
• 实施自动回滚机制

4. 服务恢复时间

定义：当发生服务事件（如计划外停机或服务受损）时，恢复服务所需的时间。

为什么重要：快速的恢复时间可最大限度地减少对客户的影响和业务损失。该指标反映了事件响应的有效性和系统弹性。

衡量等级：

• 精英：少于一小时
• 高：少于一天
• 中等：一天到一周
• 低：一周到一个月

如何跟踪：

# 跟踪事件解决时间
INCIDENT_START=$(<alert-timestamp>)
INCIDENT_RESOLVED=$(<resolution-timestamp>)
RESTORE_TIME=$((INCIDENT_RESOLVED - INCIDENT_START))

# 使用事件管理工具：
# - PagerDuty事件时间线
# - Opsgenie解决跟踪
# - 自定义事件跟踪系统
# - 监控系统警报到解决时间指标

提高恢复时间的方法：

• 实施全面的可观测性（日志、指标、追踪）
• 创建运行手册和操作手册
• 实践事件响应演练
• 使用自动回滚功能
• 改进监控和警报
• 建立值班轮换和升级流程
• 记录已知问题和解决方案

DORA绩效等级

根据团队的指标，团队被分为四个绩效等级：

精英团队

• 部署频率：每天多次
• 变更前置时间：少于一小时
• 变更失败率：0-15%
• 服务恢复时间：少于一小时

特点：精英团队表现出显著更好的业务成果，包括50%更高的市值增长和2.5倍更快的上市时间。

高绩效团队

• 部署频率：每天一次到每周一次
• 变更前置时间：一天到一周
• 变更失败率：0-15%
• 服务恢复时间：少于一天

特点：高绩效团队表现出强大的DevOps实践，并持续高效地交付价值。

中等绩效团队

• 部署频率：每月一次到每六个月一次
• 变更前置时间：一个月到六个月
• 变更失败率：16-30%
• 服务恢复时间：一天到一周

特点：中等绩效团队正在改进，但仍有大量优化机会。

低绩效团队

• 部署频率：每六个月少于一次
• 变更前置时间：超过六个月
• 变更失败率：16-45%
• 服务恢复时间：一周到一个月

特点：低绩效团队在软件交付方面面临重大挑战，需要进行根本性的流程改进。

实施DORA指标

第一步：建立基准指标

在改进之前，您需要了解自己的现状：

#!/bin/bash
# dora_metrics_collector.sh
# 收集基本的DORA指标

# 部署频率（过去30天）
echo "=== 部署频率 ==="
DEPLOY_COUNT=$(git log --since="30 days ago" --oneline | wc -l)
echo "过去30天的部署次数: $DEPLOY_COUNT"

# 变更前置时间（过去10次提交的平均值）
echo "=== 变更前置时间 ==="
# 这需要与您的CI/CD系统集成
# 示例概念性计算：
echo "平均前置时间: [需要CI/CD集成]"

# 变更失败率
echo "=== 变更失败率 ==="
# 这需要事件跟踪
echo "失败率: [需要事件系统集成]"

# 服务恢复时间
echo "=== 服务恢复时间 ==="
# 这需要事件管理系统
echo "平均恢复时间: [需要事件系统]"

第二步：选择测量工具

部署跟踪：

• Git标签和发布
• CI/CD流水线日志（Jenkins、GitLab CI、GitHub Actions、CircleCI）
• 部署自动化工具（Spinnaker、[ArgoCD、Flux和其他GitOps工具](https://www.glukhov.org/zh-cn/post/2025/07/devops-with-gitops/ “使用GitOps进行DevOps - 方法概述”））

关于自动化部署跟踪的实用示例，请参阅我们的指南使用Gitea Actions将Hugo网站部署到AWS S3，该指南演示了在实际CI/CD工作流程中如何测量部署频率。

前置时间跟踪：

• CI/CD流水线时间戳
• 版本控制系统时间戳
• 部署系统日志

失败率跟踪：

• 事件管理系统（PagerDuty、Opsgenie、Jira）
• 监控系统（Datadog、New Relic、Prometheus）
• 回滚日志

恢复时间跟踪：

• 事件管理系统
• 监控警报时间线
• 值班系统

第三步：创建仪表板

可视化您的指标以进行持续监控：

# 示例Prometheus查询用于DORA指标
# 部署频率
rate(deployments_total[30d])

# 变更前置时间（需要自定义指标）
histogram_quantile(0.95, 
  rate(lead_time_seconds_bucket[1h])
)

# 变更失败率
rate(deployment_failures_total[30d]) / 
rate(deployments_total[30d]) * 100

# 恢复时间
histogram_quantile(0.95,
  rate(incident_resolution_seconds_bucket[30d])
)

第四步：设定改进目标

根据您当前的水平设定可实现的目标：

• 低 → 中等：专注于自动化和CI/CD基础
• 中等 → 高：优化流程并减少批次大小
• 高 → 精英：微调并消除瓶颈

提高DORA指标的最佳实践

1. 从文化开始

DORA研究表明，文化比工具更重要：

• 促进开发与运维之间的协作
• 鼓励实验和从失败中学习
• 减少责备，专注于系统性改进
• 分享知识和文档

2. 实施自动化

• 自动化测试（单元、集成、端到端）
• 自动化部署（CI/CD流水线）
• 自动化基础设施配置（使用Terraform、Ansible的IaC）
• 自动化监控和警报

3. 减少批次大小

较小的更改更容易：

• 彻底测试
• 有效审查
• 安全部署
• 如有必要回滚

4. 改进测试

• 增加测试覆盖率
• 实施测试自动化
• 使用测试驱动开发（TDD）
• 实践持续测试

5. 提高监控

• 实施全面的可观测性
• 使用分布式追踪
• 设置主动警报
• 创建关键指标的仪表板

6. 实践持续学习

• 进行事后回顾
• 在团队间分享学习成果
• 记录运行手册和程序
• 实践事件响应演练

常见陷阱及避免方法

1. 关注指标而非结果

问题：在不考虑商业价值的情况下单独优化指标。

解决方案：始终将指标与商业结果联系起来。问“我们为什么要改进这个指标？”并确保它为客户带来价值。

2. 操纵指标

问题：团队人为夸大数字（例如部署空提交）。

解决方案：专注于提供价值的有意义部署。质量胜于数量。

3. 忽略上下文

问题：在不同上下文中比较指标（例如Web应用与嵌入式系统）。

解决方案：了解不同系统有不同的约束。与类似系统或您自己的历史表现进行比较。

4. 不测量所有四个指标

问题：优化一个指标而忽略其他指标（例如高部署频率但高失败率）。

解决方案：平衡所有四个指标。精英表现需要在所有领域都表现出色。

5. 缺乏工具集成

问题：手动收集指标导致数据不完整或不准确。

解决方案：将测量集成到现有工具中并自动化数据收集。

高级主题

DORA指标与平台工程

平台工程团队可以通过以下方式显著提高DORA指标：

• 提供自助服务的开发者平台
• 减少部署摩擦
• 标准化工具和流程
• 使实验更快

DORA指标在微服务中的应用

在微服务架构中测量DORA指标需要：

• 聚合跨服务的指标
• 了解服务依赖关系
• 跟踪部署协调
• 管理分布式故障场景

DORA指标与云原生

云原生技术可以加速DORA改进：

• Kubernetes：自动化部署和回滚
• 服务网格：更好的可观测性和故障处理
• 无服务器：简化的部署流程
• 容器：一致的环境

结论

DORA指标提供了一个数据驱动的框架，用于衡量和改进软件交付性能。通过跟踪和优化这四个关键指标，团队可以实现：

• 更快的上市时间
• 更高的代码质量
• 更好的团队满意度
• 更好的业务成果

请记住，这些指标是实现目标的手段——更好的软件交付为客户创造价值。专注于持续改进、文化变革，并平衡所有四个指标以实现精英表现。

今天开始测量您的DORA指标，建立基准，并踏上通往DevOps卓越的旅程。

衡量成功

跟踪您的改进过程：

1. 基准：建立当前指标
2. 季度审查：每季度评估进展
3. 目标设定：设定现实的改进目标
4. 庆祝成功：认可改进和学习成果
5. 持续改进：永远不要停止优化

有用的链接

• DORA研究项目
• 加速DevOps状态报告
• Google Cloud DevOps指标
• DORA指标实践
• 四个关键项目 - 用于测量DORA指标的开源工具

本网站的相关文章

• GIT命令速查表
• GitHub Actions速查表
• 使用Gitea Actions将Hugo网站部署到AWS S3
• 使用GitOps进行DevOps - Argo CD、Flux、Jenkins X、Weave GitOps等
• Gitflow详解：步骤、替代方案、优缺点