Back to Details

dora-core

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

DORA Core Model

DORA核心模型

DORA measures how fast and how safely a team delivers software. It is the bridge between product strategy (what to build, when to release) and technical execution (how to build it reliably).
DORA用于衡量团队交付软件的速度与安全性，是产品策略（构建什么、何时发布）与技术执行（如何可靠构建）之间的桥梁。

The 4 Key Metrics

4项关键指标

MetricWhat it measures
Deployment Frequency (DF)How often code is deployed to production
Lead Time for Changes (LT)Time from code commit to running in production
Change Failure Rate (CFR)% of deployments causing a production incident
Time to Restore (MTTR)Time to recover from a production failure
指标衡量内容
Deployment Frequency (DF) 部署频率代码部署至生产环境的频次
Lead Time for Changes (LT) 变更前置时间从代码提交到在生产环境运行所需的时间
Change Failure Rate (CFR) 变更失败率引发生产事故的部署占比
Time to Restore (MTTR) 恢复时间从生产故障中恢复所需的时间

Performance Tiers

性能层级

TierDeployment FrequencyLead TimeChange Failure RateMTTR
EliteOn-demand (multiple/day)< 1 hour0–5%< 1 hour
High1/day – 1/week1 day – 1 week6–15%< 1 day
Medium1/week – 1/month1 week – 1 month16–30%1 day – 1 week
Low1/month – 1/6 months1 month – 6 months16–30%> 1 week
Elite and High performers deploy 973× more frequently and have 6,570× faster recovery than Low performers (DORA 2023 State of DevOps).
层级部署频率前置时间变更失败率恢复时间
精英级按需部署（每日多次）< 1小时0–5%< 1小时
高级每日1次 – 每周1次1天 – 1周6–15%< 1天
中级每周1次 – 每月1次1周 – 1个月16–30%1天 – 1周
低级每月1次 – 每6个月1次1个月 – 6个月16–30%> 1周
精英级和高级团队的部署频率比低级团队高973倍，恢复速度快6570倍（来源：DORA 2023年DevOps状态报告）。

Key Capabilities (The Drivers)

关键能力（驱动因素）

DORA research identifies capabilities that predict high performance. Focus on these highest-impact ones:
DORA研究确定了可预测高性能的能力，重点关注以下高影响力能力：

Technical Capabilities

技术能力

CapabilityImpactIntegration
Loosely Coupled Architecture#1 predictor of high DF
c4-model
L2 container boundaries, 
ddd-core
Bounded Contexts
Trunk-Based DevelopmentReduces integration debtShort-lived branches, feature flags
Continuous IntegrationReduces LT and CFRAutomated test on every commit
Test AutomationReduces CFRUnit + integration tests in CI
Deployment AutomationReduces LTOne-click or auto deploy to prod
Shifting Left on SecurityReduces CFRSecurity checks in CI, not post-deploy
Monitoring & ObservabilityReduces MTTRMetrics, logs, traces in production
Database Change ManagementReduces CFRSchema migrations versioned and automated
能力影响力集成方式
松耦合架构部署频率高的首要预测因素
c4-model
L2容器边界、
ddd-core
限界上下文
主干开发减少集成债务短生命周期分支、功能开关
持续集成缩短前置时间、降低变更失败率每次提交自动触发测试
测试自动化降低变更失败率CI中集成单元测试+集成测试
部署自动化缩短前置时间一键或自动部署至生产环境
左移安全降低变更失败率在CI中执行安全检查，而非部署后
监控与可观测性缩短恢复时间生产环境中的指标、日志、链路追踪
数据库变更管理降低变更失败率版本化并自动化执行 schema 迁移

Process Capabilities

流程能力

CapabilityImpact
Working in Small BatchesDirectly reduces LT and CFR
Streamlining Change ApprovalManual approval gates are the #1 LT killer
Team ExperimentationFaster learning → better product decisions
Customer FeedbackShorter feedback loop → less wasted work
能力影响力
小批量工作直接缩短前置时间、降低变更失败率
简化变更审批手动审批关卡是延长前置时间的首要因素
团队实验更快学习 → 更优产品决策
客户反馈更短反馈循环 → 减少无效工作

Cultural Capabilities

文化能力

CapabilityImpact
Generative Culture (Westrum)High trust, blameless postmortems → faster MTTR
Psychological SafetyTeams that can surface problems fix them faster
Learning CultureContinuous improvement on all 4 metrics
能力影响力
生成式文化（Westrum模型）高信任、无责事后复盘 → 更快恢复时间
心理安全感敢于暴露问题的团队能更快解决问题
学习型文化持续优化全部4项指标

DORA Assessment: How to Use

DORA评估：使用方法

  1. Measure current tier — ask for each of the 4 metrics in the last 30 days
  2. Identify the bottleneck metric — which metric is worst relative to its tier?
  3. Map to capability — use the table above to find the root capability gap
  4. Prioritize — fix the bottleneck capability first; others are downstream
  1. 衡量当前层级 —— 统计过去30天内的4项指标
  2. 识别瓶颈指标 —— 哪项指标相对于其层级表现最差？
  3. 映射至能力 —— 通过上表找到核心能力差距
  4. 优先处理 —— 先解决瓶颈能力；其他问题为下游影响

Quick Diagnostic Questions

快速诊断问题

  • "How often do you deploy to production?" → Deployment Frequency tier
  • "How long from 
    git commit
    to live in prod?" → Lead Time tier
  • "What % of deploys caused a hotfix or rollback in the last quarter?" → CFR tier
  • "When production broke last, how long to restore?" → MTTR tier
  • "你们多久向生产环境部署一次？" → 部署频率层级
  • "从
    git commit
    到上线需要多长时间？" → 前置时间层级
  • "过去一个季度中，有多少比例的部署需要热修复或回滚？" → 变更失败率层级
  • "上次生产故障时，花了多久恢复？" → 恢复时间层级

Integration with Other Skills

与其他技能的集成

→ 
diffusion-release-tracking

→ 
diffusion-release-tracking

Deployment Frequency is a prerequisite signal before advancing Rogers Gates:
  • Elite/High DF (daily+): can iterate rapidly through Innovator → Early Adopter gates
  • Medium DF (weekly): gate advancement is slower; plan for longer validation windows
  • Low DF (monthly): cannot run proper phased rollouts — fix DF first before attempting Rogers gate strategy
部署频率是推进Rogers阶段的先决信号：
  • 精英/高级部署频率（每日及以上）：可快速迭代完成创新者→早期采用者阶段
  • 中级部署频率（每周）：阶段推进较慢；需规划更长的验证周期
  • 低级部署频率（每月）：无法执行合理的分阶段发布 —— 先解决部署频率问题，再尝试Rogers阶段策略

→ 
collaborative-engineering-agent

→ 
collaborative-engineering-agent

DORA MetricCEA Practice
Lead Time ↓Atomic PRs (<200 lines), trunk-based dev reduces integration bottleneck
CFR ↓Dialectical Review Engine (DRE) catches issues before merge
MTTR ↓Automated fix-branch workflow, observability tooling
DORA指标CEA实践
前置时间 ↓原子PR（<200行）、主干开发减少集成瓶颈
变更失败率 ↓辩证评审引擎（DRE）在合并前发现问题
恢复时间 ↓自动修复分支工作流、可观测性工具

→ 
c4-model
+ 
ddd-core

→ 
c4-model
+ 
ddd-core

  • Loosely Coupled Architecture (DORA's #1 capability) is achieved through:
    • C4 L2: independent deployable containers with clear API boundaries
    • DDD: Bounded Contexts with anti-corruption layers prevent cascade failures
  • Conway's Law applies: if the org structure is tightly coupled, the architecture will be too — and DF suffers
  • 松耦合架构（DORA排名第一的能力）可通过以下方式实现：
    • C4 L2：具有清晰API边界的独立可部署容器
    • DDD：带防腐层的限界上下文防止级联故障
  • 康威定律适用：如果组织架构紧密耦合，技术架构也会紧密耦合 —— 进而影响部署频率

→ 
business-product-leadership

→ 
business-product-leadership

DORA TierProduct Strategy Implication
EliteDeploy on-demand → rapid MVP validation, tight Rogers feedback loop
HighWeekly deploys → manageable Early Adopter gate iteration
MediumMonthly deploys → must plan Rogers gate windows months in advance
LowCannot run agile product strategy — delivery is the bottleneck
DORA层级产品策略影响
精英级按需部署 → 快速MVP验证、紧密的Rogers反馈循环
高级每周部署 → 可管理的早期采用者阶段迭代
中级每月部署 → 需提前数月规划Rogers阶段周期
低级无法执行敏捷产品策略 —— 交付环节是瓶颈

Anti-Patterns

反模式

  • Measuring DF but ignoring CFR — high DF with high CFR = fast failure, not fast delivery
  • Using DF as a vanity metric — deploying to staging doesn't count; production only
  • Manual change approval gates — DORA research shows this is the single biggest LT killer, with no measurable CFR improvement
  • Optimizing MTTR with more process — MTTR is reduced by observability and psychological safety, not more approval steps
  • Treating DORA as a report card — metrics are diagnostic tools, not performance reviews
  • 只衡量部署频率却忽略变更失败率 —— 高部署频率+高变更失败率=快速失败，而非快速交付
  • 将部署频率视为虚荣指标 —— 部署至预发布环境不算数；仅统计生产环境
  • 手动变更审批关卡 —— DORA研究表明这是延长前置时间的最大单一因素，且对降低变更失败率无显著作用
  • 通过增加流程优化恢复时间 —— 恢复时间的缩短依赖于可观测性和心理安全感，而非更多审批步骤
  • 将DORA视为成绩单 —— 指标是诊断工具，而非绩效评估标准