软件工程 / 架构设计方法论知识图谱 / 分组目录 / 技术实践层 / DORA 交付指标
technology · K · P1 · active

DORA 交付指标

DORA Software Delivery Metrics
P1基础verified技术实践 technology技术K · 运维团队与康威质量属性GL-TECHNOLOGY · 技术实践层

§1摘要与结论

TL;DR · 一句话结论

用一组软件交付效能指标衡量组织的交付吞吐与稳定性；当前官方口径为五项指标，由早期四键扩展而来，并已用失败部署恢复时间取代平均修复时间。

别名：DORA Metrics、Four Keys、DORA 四键、软件交付效能指标、DevOps 指标　|　英文：DORA Software Delivery Metrics　|　类型：技术 / practice

§2局部关系图

DORA 交付指标 的 1-2 跳邻域关系图依赖关联（dependency）：错误预算政策以服务等级目标为输入依据推导（derives_from）：交付效能指标度量组织作为设计系统的产出促成（enables）：交付效能指标为边界治理提供反馈信号实现（implements）：交付指标的自动采集与仪表化落地实现（implements）：交付度量平台实现持续反馈闭环实现（implements）：以流动信号持续校准团队边界对照（contrasts）：仪表化平台区别于指标口径定义组合（combination）：度量反馈与团队拓扑落地协同实现（implements）：服务等级目标的度量与设定实现（implements）：错误预算与燃尽率告警实现实现（implements）：DORA 交付效能指标的度量实现促成（enables）：可观测信号使 SLO 可度量促成（enables）：可观测稳态为混沌实验提供判据组合（combination）：错误预算与交付指标共同度量稳定与吞吐组合（combination）：错误预算界定混沌实验可接受的爆炸半径DORA 交付指标DORA 交付指标（TEC-K-06）DORA 交付效能指标DORA 交付效能指标（MTH-N-05）服务等级目标与错误预算服务等级目标与错误预算（TEC-K-03）交付效能度量与仪表化交付效能度量与仪表化（TEC-N-01）度量与反馈闭环度量与反馈闭环（MTH-O-11）可观测性信号采集可观测性信号采集（TEC-K-02）混沌工程实践混沌工程实践（TEC-K-04）服务等级目标方法服务等级目标方法（MTH-K-01）错误预算政策与燃尽率告警错误预算政策与燃尽率告警（MTH-K-02）团队边界治理团队边界治理（MTH-N-06）团队拓扑落地与规模化团队拓扑落地与规模化（TEC-N-02）组织即设计系统组织即设计系统（ESS-N-05）
前置依赖实现依据推导案例印证对比冲突
以本节点为中心，静态内联 1–2 跳邻域：内环 3 个直接邻接、外环 8 个二跳节点，共 12 个节点；连线按边类型着色（六类配色见下）。构建期计算，无运行期脚本。

§3原理 · 为什么

DORA 研究以可度量的交付指标刻画组织的软件交付效能，并反复表明交付速度与稳定性并非此消彼长的权衡：高绩效团队在吞吐与稳定性两类指标上同时表现优异，而减小变更批量是同时改善两者的关键杠杆。因此这组指标既可用于诊断交付瓶颈，也可作为持续改进的反馈信号。其价值在于长期跟踪自身趋势、识别系统性改进点，而非用于跨组织排名或绩效考核——后者会诱发对指标的博弈，使数据失真并偏离改进目标。这组指标源自多年实证研究，强调用数据而非直觉判断交付体系是否健康，并指出组织文化、架构与流程共同决定交付表现；它把交付视为可度量的工程能力，而非不可言说的艺术。

§4机制 · 如何运作

当前官方口径含五项指标。吞吐类包括变更前置时间（change lead time，从代码提交到在生产运行的时间）、部署频率（deployment frequency），以及失败部署恢复时间（failed deployment recovery time）；不稳定类包括变更失败率（change failure rate）与部署返工率（deployment rework rate）。这些指标应从 CI/CD 流水线与版本控制系统的真实事件自动计算，而非人工填报。五项合并观察可避免单一指标被博弈，并与 SLO、错误预算共同构成交付与可靠性相互印证的度量闭环：交付指标衡量改得快不快、稳不稳，SLO 与错误预算衡量用户实际感受到的服务水平。指标的计算需要统一变更与部署的定义：例如一次部署是代码到达生产还是对用户生效，返工如何判定，这些定义的不一致会直接导致数据不可比；自动采集可减少人为修饰，但仍需防范口径被选择性解释；只有在口径透明且一致的前提下，跨期与跨团队的趋势比较才有意义。

§5工程 · 怎么落地

把指标采集接入现有流水线事件（提交、构建、部署、回滚、事故），用统一口径自动聚合，并按团队或服务维度分解以定位瓶颈。跟踪趋势而非绝对排名，避免演变为绩效考核工具。将指标与错误预算、SLO 联动：变更失败率与失败部署恢复时间上升时，检视发布流程、测试覆盖与回滚能力；缩小变更批量以同时改善吞吐与稳定性。记录所采用的口径版本（四键或五指标、是否包含返工率）以便跨期比较，并在组织内明确指标的定义与数据来源，防止各团队各算一套。为降低采集成本，可先用流水线已有的数据自动生成，再逐步补充事件关联；定期校准指标定义并公开口径，使不同团队的数据可对话；对指标异常应结合事故与发布记录进行归因，而非直接归咎于团队。指标看板应面向改进而非监督，营造心理安全，让团队敢于暴露失败与返工。

§6权衡卡

收益 · 正确姿势

这组指标也无法覆盖价值交付是否真正满足用户需求，速度与稳定性达标不代表产品有效，因此应与业务成果指标、用户体验指标结合使用，避免把工程效能误当成业务成功；组织规模、遗留系统与合规要求也会显著影响指标基线，简单横向对标容易得出误导结论。

反例 · 误区

指标易被博弈：拆分微小变更可抬高部署频率却未必改善价值交付，放宽变更失败率的判定也会美化数据，把指标当考核更是直接诱发 Game 行为，把指标与奖惩直接挂钩几乎必然导致数据失真。

口径随研究版本演进——由四键扩展为五项、平均修复时间（MTTR）被失败部署恢复时间取代——引用旧口径须标注版本。

原文要点
  • 单看某一项会误导，必须五项合看。
  • DORA 指标是结果度量，不能直接告诉团队该如何改进，其诊断力需要结合具体流程与架构分析才能发挥。
  • 跨组织比较意义有限，因为业务、技术栈与合规约束差异巨大，应聚焦自身纵向趋势。
  • 指标应服务于持续改进，而非制造排名压力。
  • 指标采集口径若随团队自定义而变化，跨期趋势也会失去可比性。

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

§7冲突 / 对比表

真实 对照 边：仪表化平台区别于指标口径定义
对照维度DORA 交付指标交付效能度量与仪表化
定位 / 依据层DORA 交付指标 · DORA Software Delivery Metrics交付效能度量与仪表化 · Delivery Performance Measurement and Instrumentation Platform
核心定义（原文）用一组软件交付效能指标衡量组织的交付吞吐与稳定性；当前官方口径为五项指标，由早期四键扩展而来，并已用失败部署恢复时间取代平均修复时间。把交付效能指标的采集、聚合与呈现平台化：从版本控制与流水线事件自动计算并持续反馈，并以治理机制约束指标被博弈（gaming）的风险，使度量服务于改进而非考核。
首条机制断言（原文）DORA 研究以可度量的交付指标刻画组织的软件交付效能，并反复表明交付速度与稳定性并非此消彼长的权衡：高绩效团队在吞吐与稳定性两类指标上同时表现优异，而减小变更批量是同时改善两者的关键杠杆。交付指标只有在被持续、低成本地采集并反馈给团队时才产生改进价值。
对照关系仪表化平台区别于指标口径定义（对照）同一条 对照 边的另一端
典型反例（原文）指标易被博弈：拆分微小变更可抬高部署频率却未必改善价值交付，放宽变更失败率的判定也会美化数据，把指标当考核更是直接诱发 Game 行为，把指标与奖惩直接挂钩几乎必然导致数据失真。口径随研究版本演进——由四键扩展为五项、平均修复时间（MTTR）被失败部署恢复时间取代——引用旧口径须标注版本。平台还把分散的流程数据集中，带来监控与信任张力：若缺乏心理安全，团队会隐藏失败与返工，使数据失真。
处置要点（原文）把指标采集接入现有流水线事件（提交、构建、部署、回滚、事故），用统一口径自动聚合，并按团队或服务维度分解以定位瓶颈。实施通常先接入现有流水线与版本控制事件，避免额外埋点负担，再逐步补充事件关联与返工识别；以服务为最小度量单元，保留团队维度以定位瓶颈但不用于横向排名。

§8案例带

CAS-X-09 · 2 跳派生：当前节点 → TEC-K-03 → TEC-K-02

harness 源码架构解析

对 deepseek-harness 官方源码做分层解析：镜像官方架构文档，按九个层与九十余模块建立文档集群，产出跨层联动矩阵与七条关键路径，并钉住「模型可见即已记录」、能力缝三角等设计不变量。

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 驱动的端到端交付固化为四阶段加双共识加迭代的可迁移方法论的实战提炼案例。

§9信源与核验

核验状态True（verified）
置信度high
复核日期2026-10-11
生命周期active
版本2024 (DORA four keys) / 2026 (DORA current five metrics)
规范信源VEN-018、VEN-036
书证核验BK-025 ChRelationships Between Testing and Mean Time to Repair（direct），ChThe Role of a Release Engineer（direct）；BK-026 ChChange Should Be Gradual（direct），ChCompare and Contrast（direct），ChConclusion（partial），ChMeasurement Is Crucial（partial），ChMove Fast by Reducing the Cost of Failure（direct），ChNarrow, Rigid Incentives Narrow Your Success（direct）
入口链接https://dora.dev/guides/dora-metrics-four-keys/　https://dora.dev/guides/dora-metrics/
勘误
常见误解：DORA 指标就是四键（four keys），共四项
核验结论：当前官方口径已由四键扩展为五项指标，新增部署返工率（deployment rework rate），并以失败部署恢复时间取代平均修复时间　[VEN-018]
勘误
常见误解：交付速度与稳定性存在权衡，追求速度必然牺牲稳定性
核验结论：DORA 研究反复表明速度与稳定性不冲突，高绩效团队两项均优；减小变更批量可同时改善两者　[VEN-036]

§10原始关系清单

展开：本节点的全部原始关系边（3 条，含边 ID 与方向）
关系方向对端节点说明
组合← TEC-K-03服务等级目标与错误预算
E-869		错误预算与交付指标共同度量稳定与吞吐
对照← TEC-N-01交付效能度量与仪表化
E-936		仪表化平台区别于指标口径定义
实现→ MTH-N-05DORA 交付效能指标
E-864		DORA 交付效能指标的度量实现