2. DORA 度量体系概述：四大关键指标
DORA（DevOps Research and Assessment）团队经过多年实证研究，从数千个组织中提炼出四个最能反映软件交付与运维效能的核心指标。这四个指标共同构成了衡量团队效能的基础框架，被业界广泛采纳为 DevOps 与平台工程效能的黄金标准。
2.1 四大关键指标全景
DORA 四大指标分别从交付速度、交付稳定性和恢复能力三个维度刻画团队效能。下表展示了每个指标的名称、核心关注点及其在效能评估中的定位：
| 指标名称 | 英文缩写 | 核心关注点 | 效能维度 |
|---|---|---|---|
| 部署频率 | DF | 团队向生产环境交付代码的频次 | 交付速度 |
| 变更前置时间 | LT | 从代码提交到生产部署的端到端耗时 | 交付速度 |
| 变更失败率 | CFR | 部署导致生产故障的比例 | 交付稳定性 |
| 服务恢复时间 | MTTR | 从故障发生到服务完全恢复的时长 | 恢复能力 |
效能评估视角：速度指标（DF、LT）与稳定性指标（CFR、MTTR）需要联合解读。单纯追求高频部署而忽略变更失败率，可能导致团队陷入"快速制造故障"的恶性循环。
2.2 部署频率（Deployment Frequency, DF）
定义：团队向生产环境成功部署代码的频率。它直接反映团队持续交付的节奏和自动化流水线的成熟度。
计算方式：
- 统计周期：通常以周或月为单位进行统计。
- 计算公式：DF = 统计周期内成功部署到生产环境的次数 / 统计周期天数 × 7（标准化为每周部署次数）。
- 数据来源：CI/CD 流水线日志、部署工具（如 Jenkins、GitLab CI、ArgoCD）的审计记录。
效能分级（DORA 2023 基准）：
| 效能等级 | 部署频率 | 典型特征 |
|---|---|---|
| 精英 | 按需部署（每日多次） | 完全自动化流水线，主干开发，特性开关 |
| 高 | 每周一次到每日一次 | 高度自动化，少量人工审批 |
| 中 | 每月一次到每周一次 | 部分自动化，发布窗口固定 |
| 低 | 低于每月一次 | 手动部署为主，发布周期长 |
平台工程视角：服务目录应自动采集每个服务的部署频率，并与 DORA 基准进行对比。当某个服务的 DF 低于团队平均水平时，平台应提供自助化部署流水线模板，降低部署门槛。
2.3 变更前置时间（Lead Time for Changes, LT）
定义：从代码提交（Commit）到该变更成功部署到生产环境所经过的总时间。它衡量的是从"想法到交付"的端到端效率。
计算方式：
- 统计粒度：按每次变更（通常对应一个 PR 或一次合并）计算。
- 计算公式：LT = 部署完成时间 − 代码提交时间（单位：小时或天）。
- 聚合方式：取统计周期内所有变更前置时间的中位数（而非平均值），以消除极端值干扰。
效能分级（DORA 2023 基准）：
| 效能等级 | 变更前置时间 | 典型特征 |
|---|---|---|
| 精英 | 小于 1 小时 | 主干开发，自动化测试与部署，小批量提交 |
| 高 | 1 天到 1 周 | 特性分支，自动化 CI，手动部署审批 |
| 中 | 1 周到 1 个月 | 长周期特性分支，集成测试耗时 |
| 低 | 超过 1 个月 | 大版本发布，手动回归测试 |
常见误区：变更前置时间不等于代码审查时间。它包含从提交到部署的全链路耗时，包括 CI 构建、测试、审批、部署排队等所有环节。平台工程应通过服务目录可视化每个环节的耗时分布，帮助团队定位瓶颈。
2.4 变更失败率（Change Failure Rate, CFR）
定义：部署到生产环境的变更中，导致服务降级或故障的比例。它衡量的是交付质量的稳定性。
计算方式：
- 统计周期：与部署频率的统计周期保持一致。
- 计算公式：CFR = 导致生产故障的部署次数 / 总部署次数 × 100%。
- 故障判定标准：通常包括：服务不可用、响应时间显著增加（超过基线 50%）、错误率超过阈值、需要回滚或热修复。
效能分级（DORA 2023 基准）：
| 效能等级 | 变更失败率 | 典型特征 |
|---|---|---|
| 精英 | 0% – 5% | 全面自动化测试，灰度发布，可观测性完善 |
| 高 | 5% – 10% | 自动化测试覆盖核心路径，有回滚机制 |
| 中 | 10% – 15% | 部分手动测试，发布后监控不足 |
| 低 | 超过 15% | 缺乏自动化测试，频繁回滚 |
平台工程实践：服务目录应记录每次部署的变更失败事件，并与可观测性平台（如 Prometheus、Datadog）联动，自动判定部署是否导致故障。CFR 数据应作为服务健康度评分的重要组成部分。
2.5 服务恢复时间（Time to Restore Service, MTTR）
定义：从生产环境故障被确认到服务完全恢复正常所花费的时间。它衡量团队的故障响应和恢复能力。
计算方式：
- 统计粒度：按每次生产故障事件计算。
- 计算公式：MTTR = 服务恢复时间 − 故障确认时间（单位：分钟或小时）。
- 聚合方式：取统计周期内所有故障恢复时间的平均值或中位数。
- 关键时间节点：
- T0（故障发生）：用户或监控系统首次感知到异常。
- T1（故障确认）：团队确认故障并开始响应。
- T2（恢复完成）：服务指标恢复到正常基线。
效能分级（DORA 2023 基准）：
| 效能等级 | 服务恢复时间 | 典型特征 |
|---|---|---|
| 精英 | 小于 1 小时 | 自动化告警与自愈，完善的故障演练 |
| 高 | 1 小时到 24 小时 | 有值班机制，手动恢复流程清晰 |
| 中 | 1 天到 7 天 | 响应较慢，依赖特定人员 |
| 低 | 超过 7 天 | 缺乏监控，恢复流程混乱 |
2.6 四大指标的协同关系
DORA 四大指标并非孤立存在，它们之间存在内在的制衡与协同关系。理解这些关系对于正确解读度量数据至关重要：
- 速度 vs 稳定性权衡：高部署频率（DF）和短变更前置时间（LT）通常伴随着较低的变更失败率（CFR）——精英团队同时实现了"又快又稳"。这打破了传统认知中"速度必然牺牲质量"的假设。
- 恢复能力是安：即使变更失败率较高，只要服务恢复时间（MTTR）足够短，团队仍能维持较高的整体效能。MTTR 是降低故障影响的关键杠杆。
- 平台工程的整合视角：服务目录应同时展示这四个指标，并提供联合分析视图。例如，可以绘制 DF 与 CFR 的散点图，识别出"高频部署但高失败率"的风险服务。