1. 交付效率度量体系总览
在开始搭建任何度量看板之前，必须先回答一个根本问题：我们到底要度量什么，以及这些度量之间是什么关系。很多团队一上来就打开 GitLab 的 Analytics 页面，把能看到的图表全部截图放进周报，结果指标越堆越多，却没人能说清"部署频率下降"和"合并请求周期变长"之间到底谁影响谁。本章的目标，是先把度量体系的骨架立起来，再进入后续的采集、计算与优化。
一、DORA 四指标：交付效率的"结果层"
DORA（DevOps Research and Assessment）经过多年大规模调研，收敛出四个被广泛验证的指标，它们衡量的是软件交付这条"流水线"最终产出的能力：
- 部署频率（Deployment Frequency）：单位时间内成功发布到生产环境的次数。它反映的是交付节奏，而不是工作量。
- 变更前置时间（Lead Time for Changes）：从代码提交（commit）到该变更在生产环境成功运行所经过的时间。注意起点是提交，不是需求提出。
- 变更失败率（Change Failure Rate）：导致生产事故、需要热修复或回滚的部署，占全部部署的比例。
- 服务恢复时间（Time to Restore Service / MTTR）：从生产故障发生到服务恢复的时间。
这四个指标构成一组"速度—稳定性"的平衡：前两个衡量交付速度，后两个衡量交付质量与韧性。单独看任何一个都会失真——部署频率很高但变更失败率同样高，说明团队只是在快速制造故障。
二、GitLab 原生指标：交付效率的"过程层"
DORA 指标回答"结果如何"，但不告诉你"卡在哪里"。GitLab 作为一体化 DevOps 平台，天然记录了从 Issue 到 Merge Request 再到 Pipeline 的全过程数据，这些原生指标正好补上过程层：
- Issue 周期：Issue 从创建到关闭的时间，反映需求流转效率。
- MR 周期（Merge Request 生命周期）：从 MR 创建到合并的时间，是 Lead Time 中最容易被拉长的环节。
- 首次响应时间：MR 创建后到第一位评审人给出反馈的时间，直接决定评审是否成为瓶颈。
- Pipeline 时长与成功率：CI/CD 流水线从触发到结束的耗时，以及成功/失败比例。
- 代码评审吞吐：单位时间内合并的 MR 数量、评审意见数、评论往返轮次。
这些指标的价值在于可归因：当 Lead Time 变长时，你可以下钻到是 MR 等待评审太久，还是 Pipeline 反复失败重跑，从而定位到具体环节。
三、两层指标的关系：结果由过程驱动
把两层放在一起看，关系就清晰了：GitLab 原生指标是因，DORA 指标是果。MR 周期缩短、Pipeline 成功率提升，会直接推动 Lead Time 下降和部署频率上升；而变更失败率与恢复时间，则更多受 Pipeline 质量门禁、回滚机制和可观测性影响。下图展示了这种驱动关系与下钻路径。
四、度量体系设计原则
指标选对了，还要设计得能长期运转。以下五条原则是后续所有章节的基础：
- 结果与过程配对：每个 DORA 结果指标，都要有至少一个 GitLab 过程指标作为下钻入口。没有下钻入口的指标，只能看不能改。
- 可自动采集：优先选择 GitLab API 能直接取到的数据，避免人工填报。人工数据必然衰减，三个月后就会失真。
- 口径先定义再采集：例如"部署频率"是按生产环境部署次数，还是按发布标签数？"Lead Time"起点是首次提交还是 MR 创建？口径不统一，跨团队对比毫无意义。
- 看趋势而非绝对值：不同团队、不同项目的历史包袱不同，绝对值横向比较容易引发防御心理。应关注自身趋势和变化率。
- 指标服务于改进，不服务于考核：一旦指标与绩效强绑定，数据就会被"优化"——拆分 MR、频繁小部署刷频率等。度量体系必须明确其用途是定位瓶颈。
五、课程实战项目介绍
本课程将围绕一个贯穿始终的实战项目展开：为一条真实的 GitLab CI/CD 流水线搭建交付效率度量看板，并基于数据完成一轮优化闭环。
项目设定如下（示例场景，参数为合理假设，用于教学演示）：
| 项目要素 | 设定 |
|---|---|
| 代码仓库 | GitLab 自建实例，项目名 delivery-metrics-demo |
| 分支策略 | 主干开发 + 短生命周期特性分支，MR 合并到 main |
| 流水线阶段 | build → test → deploy-staging → deploy-prod（手动触发） |
| 数据规模 | 约 40 个 MR、120 次 Pipeline 运行、15 次生产部署的历史数据 |
| 采集方式 | GitLab REST API + GraphQL，定时拉取并写入本地 SQLite |
| 看板工具 | 轻量脚本生成静态 HTML 报告，便于理解每个指标的计算过程 |
项目会经历四个阶段：采集（拉取 events、merge_requests、pipelines 数据）、计算（按统一口径算出 DORA 四指标与过程指标）、可视化（趋势图 + 下钻表）、优化（识别瓶颈并实施改进，再对比前后数据）。
例如在采集阶段，我们会用如下方式拉取一个项目的 MR 列表（示例命令，需替换为实际项目 ID 与 Token）：
curl --header "PRIVATE-TOKEN: <your_token>" \
"https://gitlab.example.com/api/v4/projects/123/merge_requests?state=merged&per_page=100&page=1"
返回的 JSON 中，created_at 与 merged_at 之差即为该 MR 的周期；merged_at 与首次 commit 时间之差，则参与 Lead Time 的计算。这些字段的具体含义与边界处理，会在后续章节逐一展开。
学完本章，你应该能回答三个问题：DORA 四指标各自衡量什么、GitLab 原生指标如何为它们提供下钻路径、以及本课程将用什么项目把这两层指标真正跑起来。接下来的章节，会从数据采集开始，一步步把这张度量体系落到可运行的代码与看板上。