关于DORA

DORA (DevOps Research and Assessment) - DevOps 研究与评估

1. 定义

DORA 也指 Google Cloud 的 DevOps 研究团队，以及他们提出的衡量软件交付效能的四个关键指标。

1	DORA Metrics = 衡量 DevOps 效能的"黄金指标"

2. DORA 四大指标

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

DORA 四大指标: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 1. 部署频率 (Deployment Frequency) │ │ └── 组织成功部署到生产环境的频率 │ │ │ │ 2. 变更前置时间 (Lead Time for Changes) │ │ └── 从代码提交到成功部署到生产的时间 │ │ │ │ 3. 变更失败率 (Change Failure Rate) │ │ └── 导致生产故障需要修复的部署百分比 │ │ │ │ 4. 服务恢复时间 (Time to Restore Service / MTTR) │ │ └── 从生产故障到恢复服务的时间 │ │ │ └─────────────────────────────────────────────────────────────┘ 前两个指标衡量"速度"，后两个指标衡量"稳定性"

3. 效能等级划分

等级	部署频率	变更前置时间	变更失败率	恢复时间
Elite	按需（一天多次）	< 1 小时	0-15%	< 1 小时
High	每天到每周	1 天 - 1 周	16-30%	< 1 天
Medium	每周到每月	1 周 - 1 月	16-30%	< 1 天
Low	每月到每半年	1 月 - 6 月	16-30%	> 1 周

4. 指标详解

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63

部署频率 (Deployment Frequency): ┌─────────────────────────────────────────────────────────────┐ │ 问题: 你的团队多久部署一次代码到生产环境？ │ │ │ │ Elite: 按需（一天多次） │ │ High: 每天到每周 │ │ Medium: 每周到每月 │ │ Low: 每月到每半年 │ │ │ │ 提升方法: │ │ ├── 自动化 CI/CD 流水线 │ │ ├── 小批量、频繁发布 │ │ ├── 特性开关 (Feature Flags) │ │ └── 主干开发 (Trunk-based Development) │ └─────────────────────────────────────────────────────────────┘ 变更前置时间 (Lead Time for Changes): ┌─────────────────────────────────────────────────────────────┐ │ 问题: 从代码提交到成功运行在生产环境需要多长时间？ │ │ │ │ Elite: < 1 小时 │ │ High: 1 天 - 1 周 │ │ Medium: 1 周 - 1 月 │ │ Low: 1 月 - 6 月 │ │ │ │ 提升方法: │ │ ├── 自动化测试 │ │ ├── 自动化部署 │ │ ├── 减少审批环节 │ │ └── 小批量变更 │ └─────────────────────────────────────────────────────────────┘ 变更失败率 (Change Failure Rate): ┌─────────────────────────────────────────────────────────────┐ │ 问题: 部署后导致故障需要回滚或修复的比例是多少？ │ │ │ │ Elite/High/Medium: 0-15% │ │ Low: 46-60% │ │ │ │ 降低方法: │ │ ├── 充分的自动化测试 │ │ ├── 代码评审 │ │ ├── 金丝雀发布 │ │ ├── 蓝绿部署 │ │ └── 监控和快速回滚 │ └─────────────────────────────────────────────────────────────┘ 服务恢复时间 (Time to Restore Service): ┌─────────────────────────────────────────────────────────────┐ │ 问题: 从生产故障发生到服务恢复需要多长时间？ │ │ │ │ Elite: < 1 小时 │ │ High: < 1 天 │ │ Medium: < 1 天 │ │ Low: 1 周 - 1 月 │ │ │ │ 缩短方法: │ │ ├── 完善的监控告警 │ │ ├── 快速回滚机制 │ │ ├── 故障演练 (Chaos Engineering) │ │ ├── 事件响应流程 │ │ └── On-call 机制 │ └─────────────────────────────────────────────────────────────┘

5. 2023 年新增指标

1 2 3 4 5 6 7 8 9 10 11 12

可靠性 (Reliability): ┌─────────────────────────────────────────────────────────────┐ │ 2023 年 DORA 报告新增第五个指标 │ │ │ │ 定义: 团队是否达到或超过其可靠性目标 │ │ │ │ 衡量方式: │ │ ├── SLO 达成率 │ │ ├── 可用性百分比 │ │ └── 用户体验指标 │ │ │ └─────────────────────────────────────────────────────────────┘

6. 如何实施 DORA 指标

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

DORA 指标实施步骤: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 1. 数据收集 │ │ ├── CI/CD 系统 (Jenkins, GitLab CI, GitHub Actions) │ │ ├── 版本控制 (Git commit 时间) │ │ ├── 部署系统 (部署时间、频率) │ │ ├── 事件管理 (PagerDuty, OpsGenie) │ │ └── 监控系统 (故障检测时间) │ │ │ │ 2. 指标计算 │ │ ├── 自动化数据采集 │ │ ├── 定期计算和汇总 │ │ └── 可视化展示 │ │ │ │ 3. 分析改进 │ │ ├── 识别瓶颈 │ │ ├── 制定改进计划 │ │ └── 持续跟踪效果 │ │ │ └─────────────────────────────────────────────────────────────┘

7. 常用工具

工具	用途
Sleuth	专门的 DORA 指标追踪
LinearB	工程效能分析
Jellyfish	工程管理平台
Faros AI	工程数据平台
GitLab	内置 DORA 指标
Grafana	自建 Dashboard

---

两种 DORA 的对比

维度	DORA (欧盟法规)	DORA (DevOps 指标)
全称	Digital Operational Resilience Act	DevOps Research and Assessment
领域	金融监管合规	软件工程效能
发布方	欧盟	Google Cloud
性质	法律强制要求	最佳实践指标
适用对象	金融机构	所有软件团队
目标	运营韧性	交付效能

---

总结

如果你是金融/支付行业：

• 关注 DORA 法案，确保 2025 年 1 月前合规
• 重点：ICT 风险管理、事件报告、第三方管理、韧性测试

如果你是软件研发团队：

• 关注 DORA 指标，衡量和提升交付效能
• 重点：部署频率、前置时间、变更失败率、恢复时间

需要我进一步展开某个方面吗？比如 DORA 法案的合规检查清单，或者 DORA 指标的具体实施方案？