软件工程 / 架构设计方法论知识图谱 / 分组目录 / 方法论层 / DORA 交付效能指标
methodology · N · P0 · active

DORA 交付效能指标

DORA Software Delivery Metrics
P0进阶verified方法论 methodology方法N · 横切·团队与康威团队与康威GL-METHOD · 方法论层

§1摘要与结论

TL;DR · 一句话结论

以一组经过实证的软件交付效能指标——吞吐侧的变更前置时间、部署频率、失败部署恢复时间，与不稳定侧的变更失败率、部署返工率——衡量组织把变更交付到生产的效能，并用于改进而非考核。

别名：DORA metrics、交付效能指标、DORA 五指标、四键　|　英文：DORA Software Delivery Metrics　|　类型：方法 / measurement

§2局部关系图

DORA 交付效能指标 的 1-2 跳邻域关系图前置依赖（prerequisite）：同态关系是团队-架构边界耦合的理论基础前置依赖（prerequisite）：认知负荷是划定团队边界的依据细化（refines）：同态机制细化了组织即设计系统的论断前置依赖（prerequisite）：组织设计须管理团队的认知负荷依据推导（derives_from）：团队拓扑四类型依据认知负荷约束依据推导（derives_from）：交付效能指标度量组织作为设计系统的产出依据推导（derives_from）：团队边界治理依据边界耦合关系依赖关联（dependency）：边界治理以团队拓扑为参照促成（enables）：交付效能指标为边界治理提供反馈信号对照（contrasts）：约束性模板与持续边界治理的张力实现（implements）：交付指标的自动采集与仪表化落地实现（implements）：交付度量平台实现持续反馈闭环实现（implements）：规模化组织中落地团队拓扑四类型实现（implements）：以流动信号持续校准团队边界对照（contrasts）：仪表化平台区别于指标口径定义组合（combination）：度量反馈与团队拓扑落地协同实现（implements）：DORA 交付效能指标的度量实现组合（combination）：错误预算与交付指标共同度量稳定与吞吐DORA 交付效能指标DORA 交付效能指标（MTH-N-05）组织即设计系统组织即设计系统（ESS-N-05）团队边界治理团队边界治理（MTH-N-06）DORA 交付指标DORA 交付指标（TEC-K-06）交付效能度量与仪表化交付效能度量与仪表化（TEC-N-01）度量与反馈闭环度量与反馈闭环（MTH-O-11）团队拓扑四类型团队拓扑四类型（MTH-N-02）服务等级目标与错误预算服务等级目标与错误预算（TEC-K-03）组织-架构同态组织-架构同态（ESS-N-02）团队边界与架构边界耦合团队边界与架构边界耦合（ESS-N-03）认知负荷约束认知负荷约束（ESS-N-04）团队拓扑落地与规模化团队拓扑落地与规模化（TEC-N-02）
前置依赖实现依据推导案例印证对比冲突
以本节点为中心，静态内联 1–2 跳邻域：内环 4 个直接邻接、外环 7 个二跳节点，共 12 个节点；连线按边类型着色（六类配色见下）。构建期计算，无运行期脚本。

§3原理 · 为什么

交付效能需要可比较、可追踪的度量，否则改进只能凭感觉。DORA 指标的价值在于它把「交付得好不好」分解为少数几个直接可观测、且被研究反复验证的维度，使团队能定位瓶颈并验证改进。它最反直觉的结论是速度与稳定不是权衡：高效能团队在吞吐与不稳定两侧都表现更好，低效能团队则两侧皆差。因此不应在速度与质量之间二选一，而应追求同时改善。指标的设计指向系统与流程，而非个人产出，其目的是暴露约束、驱动改进，而不是评价个人。指标的另一价值是揭示速度与稳定的正相关，从而纠正「要快就得牺牲稳定」的常见直觉，把讨论引向系统改进而非取舍表演。

§4机制 · 如何运作

指标分两组三加二。吞吐侧包括变更前置时间（从提交到生产成功部署的耗时）、部署频率（部署次数或间隔）、失败部署恢复时间（从失败且需立即干预的部署中恢复的耗时）；不稳定侧包括变更失败率（需立即干预的部署比例）与部署返工率（因生产事故发生的非计划部署比例）。二者相互制衡：只追吞吐会掩盖质量恶化，只看稳定会掩盖交付迟滞。指标最适按单个应用或服务度量，并可随实践成熟而扩展；其理论基础来自多年实证研究，历史上由四指标演进而来，部分口径曾被重新定义。两组指标的设计意图是互相校验：任何一组的孤立改善若伴随另一组恶化，往往意味着改动只在转移问题，而非真正解决问题。这组指标本身也经历了演进：早期以部署频率、变更前置时间、恢复时间与变更失败率起步，其中变更失败率在统计上并未与其余指标显著相关，交付性能实际由少数变量刻画；其后固化为吞吐与稳定两组，并一度引入可用性与可靠性作为运营侧的度量，恢复时间也被重新定义，以排除非由生产变更引发的故障；近年又新增部署返工率。理解这一演进能避免把某一历史口径当作固定标准。

§5工程 · 怎么落地

实践上应把指标用于发现与改进，而非排名与考核。先建立可靠的数据采集，确保口径一致且可比较；再按服务或应用维度观察趋势，定位瓶颈发生在哪一环，并据此选择改进手段。同时采用多项指标，避免单指标独大导致失衡。明确指标的适用边界：不拿行业基准当不作为的借口，不跨异质应用直接比较，不把指标孤岛式归属到单个团队引发推责，不组织团队间竞赛。把指标与改进动作绑定，每次观察后都应有对应的流程或技术调整，并以后续数据验证其效果。采集应尽量自动化并统一口径，减少人工填报带来的偏差与博弈空间；同时保留对指标语境的解释，避免数字脱离系统现实。实践上应尽量自动化采集并统一口径，减少人工填报带来的偏差与博弈空间；观察时先看趋势而非单点，再定位瓶颈发生在交付链的哪一环，据此选择改进手段，并以下一轮数据验证效果。指标既是开发交付实践的滞后结果，也可作为组织健康与团队状态的先行信号，因此解读时需结合系统语境与人的因素，而不是只做数字比较。

§6权衡卡

代价 · 风险

交付指标最大的风险是被当作目标，从而触发古德哈特定律：当度量成为考核，人们会优化数字而非改善交付。

可能出现的博弈包括只提高部署频率而不改善质量、把变更拆碎以美化前置时间、或回避高风险改动。

原文要点
  • 跨异质应用比较也会误导，不同系统的基础不同，直接对比会把语境差异误读为能力差异。
  • 此外，指标主要度量交付实践的结果，无法单独解释原因，也可能同时反映组织绩效与员工福祉，误用会加害于团队。
  • 值得注意的是，相关研究显示新技术的采用可能同时提升个体体验与生产力、却降低交付的稳定性与吞吐，说明效能改进必须回到基本功与系统层面，而非依赖单一工具或单一指标的短期改善。
  • 因此指标应始终与改进闭环、多维度观察与语境判断绑定，并明确其作为趋势信号的定位，避免把度量本身变成新的问题。
  • 此外，度量不能脱离组织条件：研究发现组织优先级频繁变动会显著加剧倦怠并损害生产力，且这类损害难以靠局部改进缓解；新技术的引入也可能在提升个体体验的同时影响交付稳定性，使改进必须回到基本功与系统层面。
  • 鉴于部分结论来自单一报告口径，仍存在争议，解读时应保持谨慎，不把趋势信号拔高为定论。

权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。

§7案例带

CAS-X-16 · 2 跳派生：当前节点 → TEC-N-01 → MTH-O-11

控制理论⊗Agent 设计

将控制理论五维（负反馈 / 状态估计 / PID / 鲁棒 / 分层）系统映射到 Agent 工程环节，并以真实产品案例验证的跨学科方法论案例。

CAS-X-17 · 2 跳派生：当前节点 → TEC-N-01 → MTH-O-11

技术知识中枢交付法

从模糊需求到上线，把 AI Agent 驱动的端到端交付固化为四阶段加双共识加迭代的可迁移方法论的实战提炼案例。

§8信源与核验

核验状态True（verified）
置信度high
复核日期2026-10-11
生命周期active
规范信源VEN-036、VEN-037、VEN-038
书证核验BK-025 ChHigh Velocity（direct），ChRelationships Between Testing and Mean Time to Repair（direct）；BK-026 ChAutomate This Year’s Job Away（direct），ChShare Ownership with Developers（direct），ChThe Wisdom of Production（direct），ChUse the Same Tooling, Regardless of Function or Job Title（direct）
入口链接https://dora.dev/guides/dora-metrics/　https://dora.dev/insights/dora-metrics-history
勘误
常见误解：DORA 的经典口径是固定的「四键」
核验结论：现行官方为五指标（三吞吐加两不稳定）；原四键为历史口径，其中 MTTR 已被失败部署恢复时间取代，并新增部署返工率　[VEN-037]
勘误
常见误解：采用 AI 等新技术会全面提升软件交付效能
核验结论：2024 年研究显示其提升个体生产力与满意度，却可能降低交付的稳定性与吞吐，需以基本功与系统改进为前提（该结论存在争议，单一报告口径）　[VEN-038]

§9原始关系清单

展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
关系方向对端节点说明
依据推导→ ESS-N-05组织即设计系统
E-650		交付效能指标度量组织作为设计系统的产出
促成→ MTH-N-06团队边界治理
E-657		交付效能指标为边界治理提供反馈信号
实现← TEC-K-06DORA 交付指标
E-864		DORA 交付效能指标的度量实现
实现← TEC-N-01交付效能度量与仪表化
E-931		交付指标的自动采集与仪表化落地