# Dora Metrics

> 度量项目交付效能时使用。适用于团队效能分析、季度复盘、改进决策。优先使用 Google DORA 四大指标（部署频率、前置时间、失败率、恢复时间）。

- Skill: `zhaoxuya520/dora-metrics` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add zhaoxuya520/dora-metrics`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhaoxuya520/dora-metrics/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zhaoxuya520 (https://skillmd.com/u/zhaoxuya520)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhaoxuya520/dora-metrics

---


# DORA 交付效能度量

参考来源：[Google DORA](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance)、[Accelerate](https://larridin.com/developer-productivity-hub/dora-metrics-explained-complete-guide-2026)

## 适用场景

- 团队/工作流效能度量
- 季度/年度交付能力评估
- 改进决策的数据支持
- 项目复盘时的客观指标

## 不适用场景

- 单个任务的成败（用 milestone-gate）
- 短期波动判断（DORA 是趋势指标）

## 核心原则

```text
不只看"是否按时完成"，要看"持续交付能力"

DORA 四指标是一组：
  - 速度指标（部署频率 / 前置时间）
  - 稳定性指标（失败率 / 恢复时间）

只看速度会忽略质量
只看稳定会牺牲速度
两者必须平衡
```

## 四大核心指标

### 1. 部署频率（Deployment Frequency）

```text
含义：多频繁可以把变更部署到生产环境
AI 工作流场景：每个功能模块从完成到可部署的频率

测量：
  - 每天/每周/每月部署次数
  - 单位：次/天

效能等级：
  Elite：每天多次（按需部署）
  High：每周一次到每天一次
  Medium：每月一次到每周一次
  Low：每几个月一次

目标：每个模块完成即可部署，不积压
```

### 2. 变更前置时间（Lead Time for Changes）

```text
含义：从代码提交到部署到生产的时间
AI 工作流场景：从任务开始到交付完成的总耗时

测量：
  - commit → production 的时间分布
  - 取 median 或 p90

效能等级：
  Elite：< 1 天
  High：1 天到 1 周
  Medium：1 周到 1 个月
  Low：> 1 个月

AI 工作流目标：
  - M 级项目 < 3 小时
  - L 级 < 8 小时
  - XL 级 < 1 天
```

### 3. 变更失败率（Change Failure Rate）

```text
含义：部署后导致问题需要紧急修复/回滚的比例
AI 工作流场景：交付后需要返工/回滚的比例

测量：
  - 失败部署数 / 总部署数 × 100%
  - 失败定义：服务降级、回滚、紧急修复

效能等级：
  Elite：0~15%
  High：16~30%
  Medium：31~45%
  Low：> 45%

目标：< 15%（门禁机制应该拦住大部分问题）
```

### 4. 恢复时间（Mean Time to Recovery / MTTR）

```text
含义：服务出现故障到恢复正常的时间
AI 工作流场景：发现问题到修复完成的时间

测量：
  - 从故障开始到完全恢复
  - 取 median

效能等级：
  Elite：< 1 小时
  High：< 1 天
  Medium：< 1 周
  Low：> 1 周

AI 工作流目标：< 30 分钟
（AI 修复速度快，瓶颈在定位）
```

## 效能等级综合

```text
所有 4 个指标都达标的层级：

Elite（精英）：
  部署频率：按需多次
  前置时间：< 1 天
  失败率：0~15%
  恢复时间：< 1 小时

High（高效）：
  部署频率：日均到周均
  前置时间：1 天~1 周
  失败率：16~30%
  恢复时间：< 1 天

Medium（中等）：
  部署频率：周均到月均
  前置时间：1 周~1 月
  失败率：31~45%
  恢复时间：< 1 周

Low（待改进）：
  任一指标长期处于最低层

商业影响（来自 Accelerate）：
  Elite 团队比 Low 团队：
    - 50% 高的市场资本增长
    - 2.5x 快的市场上市
```

## 数据收集

### 部署频率

```text
来源：
  - CI/CD 系统（GitHub Actions / Jenkins）的部署日志
  - 容器/Kubernetes 的滚动更新记录
  - Tag/Release 记录

AI 工作流：
  - 每个功能模块完成的时间戳
  - 工作流自动汇报"我完成了 X"的时间
```

### 前置时间

```text
来源：
  - Git commit 时间
  - PR 合并时间
  - 部署时间

AI 工作流：
  - 任务进入 in_progress 的时间
  - 任务进入 done 的时间
  - 计算差值
```

### 失败率

```text
来源：
  - 部署失败的告警
  - 回滚记录
  - 紧急修复 commit

AI 工作流：
  - 任务进入 rework 的次数
  - 上线后的紧急修复次数
```

### 恢复时间

```text
来源：
  - 监控告警的开始/结束时间
  - 故障单的处理时间

AI 工作流：
  - 阻塞开始/解除时间
  - 验收失败到修复完成
```

## 工作流程

```text
1. 项目启动时：
   - 确认要追踪的指标范围
   - 设置基线（项目开始前的数据）
   - 设置目标值
   ↓
2. 项目执行中：
   - 自动收集每个事件的时间戳
   - 不打扰执行流程
   ↓
3. 项目结束：
   - 计算四大指标
   - 与基线和目标对比
   - 输出 DORA 报告
   ↓
4. 定期（季度）复盘：
   - 对比多个项目的 DORA
   - 识别改进方向
   - 制定改进措施
```

## DORA 报告模板

```markdown
## DORA 效能报告 [项目名]

### 测量周期：[开始时间] ~ [结束时间]

### 四大指标

| 指标 | 当前值 | 基线 | 目标 | 等级 | 趋势 |
|------|--------|------|------|------|------|
| 部署频率 | 5 次/天 | 1 次/天 | 5+ 次/天 | Elite | ↑↑↑ |
| 前置时间 | 2.5 小时 | 8 小时 | < 3 小时 | Elite | ↑↑ |
| 失败率 | 12% | 25% | < 15% | Elite | ↑↑ |
| 恢复时间 | 25 分钟 | 2 小时 | < 30 分钟 | Elite | ↑↑↑ |

### 整体等级：Elite

### 关键发现

- 部署频率提升 5x（自动化 CI/CD 见效）
- 前置时间从 8h 降到 2.5h（并发编排起作用）
- 失败率减半（门禁机制有效）
- 恢复时间显著下降（监控告警完善）

### 改进建议

- 部署频率已 Elite，保持
- 前置时间还有空间，可以进一步优化联调环节
- 失败率从 12% 到 < 10% 是下个目标
- 恢复时间已优秀，不需要专门优化

### 下季度目标

- 部署频率：保持 5+ 次/天
- 前置时间：< 2 小时
- 失败率：< 10%
- 恢复时间：< 20 分钟
```

## 质量自检

```text
□ 是否四个指标都测了（不能只看部署频率）
□ 是否设置了基线（不能凭空对比）
□ 是否设置了目标值（不能"越好越好"）
□ 数据来源是否客观（不是自己估算）
□ 报告是否有趋势分析（一次数据没意义）
□ 是否提出了具体改进建议
```

## 常见坑

1. **只看速度指标**——部署频率高但失败率也高，不是真效能
2. **只看稳定性指标**——失败率 0% 但一年才部署一次，不是好事
3. **测量周期太短**——一周数据不能下结论
4. **没有基线**——不知道是进步还是退步
5. **指标 gaming**——为了好看的数字牺牲实际质量
6. **不行动**——测了不改进，等于没测
7. **指标用作 KPI 考核**——会扭曲行为，DORA 是诊断工具不是 KPI

## 配套模板

- `templates/dora-report-template.md` — DORA 报告模板
- `templates/dora-tracking-template.md` — 数据追踪表模板

## 与其他 skill 的协作

```text
上游：
  progress-tracking → 提供执行数据
  milestone-gate → 提供门禁通过率

平行：
  retrospective → 复盘时引用 DORA 数据

下游：
  改进决策 → 影响下个项目的 wbs / orchestration / risk
```