度量与实践：DORA / 主干开发 / 左移
基于 CI/CD 通用模型 · 核于 2026-07
速查
- DORA 四大指标：①部署频率（Deployment Frequency）②变更前置时间（Lead Time for Changes：提交→上线耗时）③变更失败率（Change Failure Rate：生产变更中致故障需回滚/热修的比例）④服务恢复时间（MTTR / Time to Restore）。前两个衡量吞吐，后两个衡量稳定。
- 不是 DORA 指标：代码行数、测试数量等——DORA 不以「产出量」衡量效能。
- 精英团队：高部署频率 + 低变更前置时间 + 低变更失败率 + 快恢复——吞吐与稳定可兼得（非此消彼长）。
- 主干开发（trunk-based）：小批量高频合入主干 + 特性开关；避免长命分支的「合并地狱」，与高效能强相关。
- 左移（shift-left）：把测试/安全/质量检查尽量提前到流水线早期（PR 阶段），越早发现修复越便宜。
- 流水线即代码：流水线定义进仓库，可版本控制、Review、复现、随分支演进。
- 快慢测试分层：PR 跑快测试（秒/分钟级反馈），慢的全量 E2E 放合并后/定时。
- DevSecOps：安全扫描（SAST/依赖/密钥/容器）自动化进流水线做质量门，每次变更自动过安全检查。
一、DORA：用四个指标量化交付效能
DORA（DevOps Research and Assessment）多年研究提炼出四个关键指标，成为衡量软件交付效能的事实标准：
| 指标 | 衡量什么 | 类别 |
|---|---|---|
| 部署频率 Deployment Frequency | 多久部署一次生产 | 吞吐 |
| 变更前置时间 Lead Time for Changes | 一次提交到成功上线生产的耗时 | 吞吐 |
| 变更失败率 Change Failure Rate | 生产变更中导致故障、需回滚/热修/打补丁的比例 | 稳定 |
| 服务恢复时间 MTTR（Time to Restore） | 生产故障后恢复服务的耗时 | 稳定 |
- 前两个偏「快不快」（吞吐/速度），后两个偏「稳不稳」（可靠/韧性）。
- 关键洞察：吞吐与稳定并非此消彼长——精英团队往往同时做到「发得快」和「故障少、恢复快」。追求速度时不能牺牲稳定，反之亦然。
- 注意区分：变更前置时间（提交→上线，衡量速度）与 MTTR（故障→恢复，衡量稳定）——二者常被混淆。
「代码行数」「提交数」等不是 DORA 指标，DORA 刻意不以产出量衡量效能。
二、主干开发（trunk-based development）
要提升「部署频率」和「变更前置时间」，分支策略很关键：
- 主干开发：开发者小批量、高频地把改动合入主干（配合特性开关隐藏未完成功能），集成冲突小、反馈快、随时可发布。
- 对比长命特性分支：功能各自开发数周/数月才合并，差异巨大、冲突多、集成风险高（「合并地狱」），拖慢交付。
- DORA 研究表明主干开发与高效能强相关。它不等于「不评审」——评审仍在，只是更小、更快、更频繁。
三、左移（shift-left）
「左移」指把测试、代码质量、安全检查等活动尽量提前到开发/流水线的早期阶段（图示上的左边），而非等到快上线才做：
- 越早发现问题，修复成本越低（需求阶段发现 vs 生产发现，成本差几个数量级）。
- 体现在 CI：PR 阶段就跑单测、静态分析、依赖漏洞扫描、密钥泄露检测——问题在合并前就暴露。
四、流水线即代码（pipeline as code）
把流水线定义写成仓库里的文件（.github/workflows/*.yml、.gitlab-ci.yml、Jenkinsfile），相比在 UI 里点选配置：
- 可版本控制：流水线随代码一起分支、演进、回滚。
- 可评审：流水线改动经 Code Review。
- 可复现/可审计：任何时刻都能追溯「当时的流水线长什么样」。
UI 点选的配置难以审计、难以随代码分支/回滚——这是「配置即代码」理念在 CI 领域的体现。
五、快慢测试分层
单元测试快、E2E/集成测试慢。若每次 PR 都等全量慢测试，反馈太慢、拖累开发：
- PR 阶段：跑快测试（单测、lint、类型检查、快速集成），提供秒级/分钟级反馈，挡住大多数问题。
- 合并后 / 定时：跑慢的全量 E2E、性能、跨浏览器等。
这是在「反馈速度」与「覆盖深度」之间的务实平衡——不是放弃慢测试，而是把它们安排在不阻塞高频提交的地方。
六、DevSecOps：把安全也自动化进流水线
把安全扫描纳入 CI/CD 并作为质量门：
- SAST（静态应用安全测试）、依赖漏洞扫描（SCA）、密钥泄露检测、容器镜像扫描、（可选）DAST。
- 结果直接呈现在 PR/MR 里，发现新漏洞就提示甚至阻断合并。
- 相较传统「上线前人工安全评审」，它更快、更持续、覆盖更全——把安全「左移」并自动化，是现代交付流水线的标配。
七、把度量变成改进闭环
指标不是用来「考核个人」，而是用来发现瓶颈、驱动改进：
- 部署频率低 / 前置时间长 → 看流水线是否太慢、是否卡在人工环节、批量是否太大 → 引入并行/缓存/主干开发/自动化审批。
- 变更失败率高 → 加强测试/评审/金丝雀发布。
- MTTR 长 → 完善监控告警、可观测性、快速回滚能力。
CI/CD 的机制（并行、缓存、affected、质量门、蓝绿/金丝雀、回滚）最终都服务于这四个指标的改善。