# DORA-Metriken: was Entwicklungszyklen wirklich verkürzt

URL: https://www.mikebild.dev/de/blog/dora-metriken-was-zyklen-verkuerzt/

Deployment Frequency, Lead Time for Changes, Change Failure Rate, Failed Deployment Recovery Time: vier Messwerte, die niemand schätzen und über die niemand abstimmen muss. Sie fallen in Systemen an, die ohnehin laufen – Commit-Timestamp im Versionskontrollsystem, Deploy-Event der CD-Pipeline, Incident-Log. Kein Board, keine Punkte, keine Selbstauskunft. Die Recovery-Metrik hieß in älteren DORA-Texten „Time to Restore Service“.

**Redaktionelle Einordnung (Juli 2026):** Dieser Beitrag beschreibt das damalige Modell aus vier Delivery-Metriken. DORA ergänzte 2024 die **Deployment Rework Rate** als fünfte Kennzahl. Der aktuelle Kanon besteht damit aus drei Throughput- und zwei Instability-Metriken; die historische Vierergruppe im Haupttext bleibt als Ausgangspunkt erhalten.

Eine Velocity-Kurve entsteht auf dem umgekehrten Weg. Sie summiert Story Points, die ein Team sich selbst zugeschrieben hat, und kann steil nach oben zeigen, während Releases zäh bleiben, Hotfixes sich stauen und freitags niemand deployen will. Die vier Messwerte oben können das nicht. Sie beschreiben den Weg einer Änderung vom Commit bis in Produktion – und was passiert, wenn diese Änderung Schaden anrichtet.

Diese vier DORA-Keys stammen aus der DevOps-Research-and-Assessment-Arbeit rund um Nicole Forsgren, Jez Humble und Gene Kim, sind im Buch *Accelerate* (2018) statistisch unterfüttert und werden seither jährlich im *State of DevOps Report* fortgeschrieben. Ihr Wert liegt in der Diagnose: Sie zeigen, an welcher Stelle der Kette es hakt. Im Folgenden geht es darum, wo genau die Keys den Engpass sichtbar machen und wie man sie erhebt, ohne dass daraus ein neues Zahlenspiel wird.

Die Messgrößen lassen sich zuerst nach der Frage ordnen, die sie beantworten. Das verhindert, dass Tempo und Instabilität zu einer scheinbar eindeutigen Gesamtnote verschmelzen.

::::comparison{title="Delivery-Leistung hat zwei Achsen" role="primary" preferredPattern="comparison-matrix"}
:::side{label="Throughput"}
- Deployment Frequency · Wie oft erreicht eine Änderung Produktion?
- Lead Time for Changes · Wie lange dauert der Weg vom Commit bis zum Deploy?
:::
:::side{label="Instability"}
- Change Failure Rate · Welcher Anteil der Änderungen verursacht eine Störung?
- Failed Deployment Recovery Time · Wie lange dauert die Erholung nach einem fehlgeschlagenen Deploy?
- Deployment Rework Rate · Welcher Anteil erzeugt ungeplante Nacharbeit?
:::
::::

Die Einteilung ist keine Rangliste. Erst gemeinsam zeigen beide Seiten, ob ein Team schnell liefern kann, ohne die Kosten fehlgeschlagener Änderungen auszublenden.

## Zwei Achsen statt einer Zahl

Der erste Denkfehler ist, Delivery-Performance als eine einzige Größe zu behandeln. Die vier Keys spannen bewusst zwei Achsen auf.

Auf der Throughput-Achse liegen **Deployment Frequency** – wie oft geht Code in Produktion – und **Lead Time for Changes** – wie lange dauert es vom Commit bis zum erfolgreichen Deploy. Das ist die Tempo-Seite: kleine Batches, kurze Wege.

Auf der Stability-Achse liegen **Change Failure Rate** – welcher Anteil der Deploys eine Störung oder einen Rollback auslöst – und **Failed Deployment Recovery Time** – wie lange die Erholung nach einem fehlgeschlagenen Deployment dauert. Das ist die Seite der Robustheit: wie teuer ein Fehler wird.

Die zentrale, kontraintuitive Erkenntnis aus *Accelerate*: Diese beiden Achsen stehen nicht im Gegensatz. Die Daten zeigen, dass Elite-Teams auf **beiden** gleichzeitig gewinnen – häufiger deployen *und* seltener scheitern *und* schneller wieder online sind. Der alte Reflex "Wenn wir schneller liefern, sinkt die Qualität" ist empirisch widerlegt. Genau deshalb ist es fahrlässig, nur zwei der vier Metriken zu messen. Wer allein Deploy-Frequenz und Lead Time trackt, optimiert Tempo und blendet die Stabilität aus – und produziert exakt die Vanity-Illusion, gegen die die DORA-Keys eigentlich antreten.

```mermaid
quadrantChart
  title Throughput vs. Stability
  x-axis Low Throughput --> High Throughput
  y-axis Low Stability --> High Stability
  quadrant-1 Elite
  quadrant-2 Slow but Safe
  quadrant-3 Low Performer
  quadrant-4 Fragile Speed
  Elite Team: [0.85, 0.85]
  Big-Batch Team: [0.2, 0.6]
  Move-Fast-Break-Things: [0.8, 0.25]
  Stuck Team: [0.2, 0.2]
```

Die Matrix macht klar: Das Ziel ist rechts oben, nicht ein Kompromiss auf der Diagonale. Und sie erklärt, warum eine einzelne Zahl in die Irre führt – ein Team im Quadranten "Fragile Speed" sieht auf einer reinen Tempo-Metrik glänzend aus und brennt trotzdem.

## Wo der Zyklus klemmt

Der eigentliche Wert der Keys liegt nicht im Benchmark, sondern in der Lokalisierung. Jede Metrik hängt an einem anderen Segment der Wertschöpfungskette vom Commit bis zur Produktion – und zeigt damit, an welcher Stelle es hakt.

```mermaid
flowchart LR
  A[Commit] --> B[CI Build]
  B --> C[Test]
  C --> D[Deploy Gate]
  D --> E[Production]
  E -->|Incident| F[Restore]
  F --> E
  A -. Lead Time for Changes .-> E
  D -. Deployment Frequency .-> E
  E -. Change Failure Rate .-> F
  F -. Failed Deployment Recovery Time .-> E
  style D fill:#e8543f,color:#fff
```

Ein Beispiel aus der Praxis: Ein Team klagt über "langsame Releases". Die Lead Time liegt im Median bei elf Tagen. Zerlegt man sie, stecken davon neun Tage zwischen "Feature fertig" und "Deploy Gate" – die Pipeline und der manuelle Freigabeschritt sind der Engpass, nicht das Programmieren. Ein anderes Team hat eine gute Lead Time, aber eine Change Failure Rate von 30 Prozent und eine Restore-Zeit von Stunden: Hier ist nicht das Tempo das Problem, sondern die Umkehrbarkeit von Änderungen. Dieselben vier Zahlen, völlig unterschiedliche Therapie. Eine aggregierte Velocity hätte in beiden Fällen nur "das Team ist ausgelastet" gesagt.

Lead Time for Changes ist dabei mein wichtigster Frühindikator. Sie ist definiert als die Zeit vom Code-Commit bis zum erfolgreichen Lauf in Produktion und korreliert eng mit der Batch-Größe. Große Batches verlängern das Feedback, erhöhen das Fehlerrisiko und machen jedes Deployment zum Event – darauf pochen Donald Reinertsen und Jez Humble seit Jahren, und *Accelerate* belegt es mit Daten. Kurze Lead Time zwingt fast automatisch zu kleinen, kontinuierlichen Änderungen.

## Change Failure Rate und Recovery-Zeit sind gekoppelt

Ein verbreitetes Missverständnis ist, Stabilität heiße „keine Fehler“. Das ist nicht die Aussage der DORA-Daten. Die Kopplung aus Change Failure Rate und Failed Deployment Recovery Time sagt etwas Feineres: Nicht die Abwesenheit von Fehlern zählt, sondern deren Preis. Hohe Deploy-Frequenz plus niedrige Change Failure Rate plus kurze Recovery-Zeit bedeutet, dass Änderungen klein und umkehrbar sind. Ein Fehler, den ich in Minuten zurückrolle, ist billig. Ein Zero-Defect-Anspruch, der jeden Release zur Zitterpartie macht, ist teuer – gerade weil er selten geübtes, riskantes Deployen erzwingt.

Deshalb schlägt eine kurze Restore-Zeit in der Praxis den Anspruch auf Fehlerfreiheit. Und deshalb gehören die Nachbar-Techniken hier direkt dazu: Feature Flags, um Änderungen ohne Deploy scharf oder wieder unscharf zu schalten; Canary- und Blue-Green-Releases, um Blast-Radius zu begrenzen; Circuit Breaker und Bulkheads aus Michael Nygards *Release It!*, um Ausfälle einzudämmen. Keine Buzzwords: genau das sind die Hebel, mit denen man Change Failure Rate senkt und Restore-Zeit verkürzt.

Im Code sieht die Kopplung von umkehrbarem Rollout und automatischem Recovery zum Beispiel so aus:

```typescript
// Canary rollout gated by the live error rate.
// Ties Change Failure Rate and recovery time together in one control loop.
interface RolloutConfig {
  canaryPercentage: number;
  maxErrorRate: number;      // e.g. 0.02 -> roll back above 2%
  observationWindowMs: number;
}

async function progressiveRollout(
  release: Release,
  config: RolloutConfig,
): Promise<RolloutResult> {
  await featureFlags.enableForCohort(release.id, config.canaryPercentage);

  const errorRate = await metrics.observeErrorRate(
    release.id,
    config.observationWindowMs,
  );

  if (errorRate > config.maxErrorRate) {
    await featureFlags.disable(release.id); // instant, no redeploy
    return { status: "rolled_back", observedErrorRate: errorRate };
  }

  await featureFlags.enableForCohort(release.id, 100);
  return { status: "promoted", observedErrorRate: errorRate };
}
```

Es geht nicht um die konkrete Bibliothek, es geht um das Prinzip: Recovery passiert per Flag-Toggle in Sekunden, nicht per Notfall-Deploy. Genau das drückt sich später in einer niedrigen Restore-Zeit aus.

## Die Metriken messen, ohne sie zu erfinden

Damit die Keys ehrlich bleiben, müssen sie aus Systemen kommen, die man nicht von Hand pflegt. Lead Time zum Beispiel lässt sich vollständig aus zwei Quellen ableiten: dem Commit-Timestamp im Versionskontrollsystem und dem Deploy-Event der CD-Pipeline. Keine Schätzung, keine Selbstauskunft.

```typescript
// Lead Time for Changes, derived from VCS + deploy events.
// leadTime = deployedAt(prodDeployment) - firstCommitTime(changeSet)
function leadTimeForChange(deployment: ProdDeployment): number {
  const firstCommit = deployment.changeSet
    .map((commit) => commit.authoredAt.getTime())
    .reduce((min, t) => Math.min(min, t), Infinity);

  return deployment.deployedAt.getTime() - firstCommit;
}

// Aggregate as a median over a rolling window -- means get skewed by outliers.
function medianLeadTime(deployments: ProdDeployment[]): number {
  const values = deployments.map(leadTimeForChange).sort((a, b) => a - b);
  const mid = Math.floor(values.length / 2);
  return values.length % 2 === 0
    ? (values[mid - 1] + values[mid]) / 2
    : values[mid];
}
```

Zwei Details sind wichtig. Erstens der Median statt des Mittelwerts – ein einzelner liegengebliebener Branch würde jeden Durchschnitt ruinieren. Zweitens das rollierende Zeitfenster: Die Zahl ist ein Trend, kein Tagestreffer.

Noch wirksamer wird das Ganze, wenn man eine Metrik nicht nur anzeigt, sondern in die Pipeline zurückkoppelt. Neal Ford, Rebecca Parsons und Patrick Kua nennen das in *Building Evolutionary Architecture* eine Fitness Function – eine ausführbare Regel, die eine Architektur-Eigenschaft überprüfbar macht. Eine DORA-Fitness-Function kann die Pipeline rot färben, wenn die Change Failure Rate über der Schwelle liegt:

```python
# Executable fitness function: assert a DORA metric as a CI gate.
def assert_change_failure_rate(window_days: int = 30, threshold: float = 0.15):
    deployments = metrics_db.query_deployments(window_days)
    failed = [d for d in deployments if d.caused_incident or d.rolled_back]

    if not deployments:
        return  # nothing to assert yet

    change_failure_rate = len(failed) / len(deployments)
    assert change_failure_rate < threshold, (
        f"Change Failure Rate {change_failure_rate:.0%} "
        f"exceeds threshold {threshold:.0%} over {window_days}d"
    )
```

So verbindet sich DORA mit der Idee der evolutionären Architektur: Die Metrik ist keine Folie fürs Quartalsmeeting mehr, sondern eine Bedingung, die das System an sich selbst stellt.

## Der Fallstrick: Metriken als Ziel

Damit zur größten Gefahr. Sobald eine Metrik zum Ziel wird, hört sie auf, ein gutes Maß zu sein – Goodhart's Law in Reinform. Deployment Frequency lässt sich mit trivialen Leer-Deploys aufblähen. Change Failure Rate lässt sich schönen, indem man "Failure" so lange umdefiniert, bis kaum noch etwas hineinfällt. Wer die Keys als Team-Ranking oder Bonus-KPI benutzt, bekommt genau dieses Gaming – und DORA selbst warnt ausdrücklich davor, Teams damit zu vergleichen. Die vier Zahlen sind Diagnose, nicht Wettbewerb.

Zwei weitere Verwechslungen sehe ich häufig. Erstens: Die Keys sind kein Ersatz für Story-Point-Velocity im Sinne von "gleiche Sache, bessere Zahlen". Es ist ein anderes Konstrukt – Velocity misst den Output eines einzelnen Teams und ist weder vergleichbar noch fälschungssicher; die Keys messen den Fluss vom Commit bis Produktion über das ganze Delivery-System. Zweitens: Schnelle Deploys ohne Wirkung sind "faster to nowhere". Deshalb hat DORA in den Reports 2021 und 2022 eine fünfte Dimension ergänzt, die **Reliability** beziehungsweise operative Performance. Die Aussage von 2022: Hohe Delivery-Performance zahlt nur dann auf den Organisationserfolg ein, wenn auch die Zuverlässigkeit im Betrieb stimmt. Ich behandle Reliability bewusst als jüngere, weichere Ergänzung – nicht als fünften, gleichrangigen Kanon. Aber der Gedanke gehört ins "ehrlich statt Vanity"-Framing: Tempo ohne Betriebsstabilität ist eine Vanity-Metrik mit besserem Marketing.

## Fazit

Der rote Faden ist einfach. Velocity misst, was ein Team von sich behauptet. Die vier DORA-Keys messen, was tatsächlich passiert – vom Commit bis Produktion und zurück, wenn es kracht. Sie tun das auf zwei Achsen, Tempo und Stabilität, und die Kernaussage von *Accelerate* ist, dass diese Achsen kein Tradeoff sind: Die guten Teams gewinnen auf beiden.

Praktisch nutze ich die Keys als Suchscheinwerfer. Lange Lead Time zeigt große Batches oder eine verstopfte Pipeline. Hohe Change Failure Rate zeigt fehlende Umkehrbarkeit. Lange Restore-Zeit zeigt, dass Recovery nicht geübt ist. Jede Zahl deutet auf eine konkrete, technische Gegenmaßnahme – kleine Batches, Trunk-Based Development, Feature Flags, Canary-Releases, Circuit Breaker. Das ist der Unterschied zwischen einer Metrik, die den Zyklus verkürzt, und einer, die nur ein Dashboard füllt.

Und die Disziplin dabei: Die Keys diagnostizieren, sie belohnen nicht. In dem Moment, in dem sie zum Ziel werden, verlieren sie ihren Wert. Wer das aushält – Zahlen anschauen, ohne sie zu jagen – bekommt etwas Seltenes: einen ehrlichen Blick darauf, wo der eigene Zyklus wirklich klemmt.

## Weiterführende Quellen

- [DORA Metrics – dora.dev](https://dora.dev/guides/dora-metrics/)
- [Accelerate State of DevOps Report 2022 – dora.dev](https://dora.dev/research/2022/dora-report/)
- [DORA 2022 Report – Google Cloud Blog](https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now-out)
- [Four Keys to measure DevOps performance – Google Cloud](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance)
- [A history of DORA's metrics – dora.dev](https://dora.dev/insights/dora-metrics-history/)