Was sind DORA Metriken: fünf Messgrößen der Delivery

Was sind DORA Metriken? Sie sind fünf Messgrößen für die Softwareauslieferung: Lead Time für Änderungen, Deployment-Häufigkeit, Wiederherstellungszeit nach fehlgeschlagenen Deployments, Fehlerquote bei Änderungen und Neubearbeitungsrate. Die ersten drei beschreiben den Durchsatz, die letzten zwei die Instabilität. Zusammen sagen sie aus, wie schnell Änderungen in die Produktion gelangen und wie oft diese Änderungen Probleme verursachen. Richtig eingesetzt zeigen sie auf den Engpass hin. Falsch eingesetzt werden sie zu einem Erfolgsmaßstab, der dein Team zum Gaming einlädt.

Woher die Zahlen kommen und warum sich die Terminologie so durchgesetzt hat

Ein Plattform-Lead sitzt in der Quartalsplanung. Der CTO stellt eine Frage: Shippen wir schneller als im letzten Jahr und fahren wir weniger kaputt? Ohne gemeinsames Vokabular ist die Antwort eine Sammlung von Anekdoten. DORA Metriken existieren, um die Anekdoten durch vier oder fünf Zahlen zu ersetzen, die du aus Systemen ziehen kannst, die du ohnehin betreibst.

Der Name kommt von DevOps Research and Assessment, ein Forschungsprogramm, das Jahre damit verbracht hat, Engineering-Teams zu befragen und ihre Lieferpraktiken mit Organisationsergebnissen zu korrelieren. Es ist nun Teil von Google Cloud und die Erkenntnisse werden jedes Jahr im DORA Forschungsprogramm veröffentlicht. Das Buch Accelerate popularisierte die ursprünglichen vier. Das Framework wurde seitdem überarbeitet, und diese Überarbeitung ist wichtiger als die meisten Blog-Posts zugeben.

Der Punkt, der oft verloren geht: Die Metriken waren nie als Rangliste gedacht. Sie kamen aus einer statistischen Erkenntnis. Teams, die bei Speed gut abschnitten, schnitten auch bei Stabilität gut ab. Geschwindigkeit und Sicherheit waren keine Abwägung, sie bewegten sich zusammen. Das ist eine Aussage über Korrelation über viele Teams hinweg, nicht ein Ziel für dein Team.

Die fünf Metriken, definiert wie ein On-Call Engineer sie definieren würde

Die aktuellen Definitionen im offiziellen DORA Metrics Guide teilen sich in zwei Gruppen auf. Lies sie mit einem bestimmten Service im Kopf, denn jede Definition fällt auseinander, wenn du sie auf „das ganze Unternehmen" anwendest.

Lead Time für Änderungen. Die Zeit von einem Commit bis dieser Commit in der Produktion läuft. Nicht vom Ticket-Öffnen an, und nicht vom Pull-Request-Genehmigen an. Von Commit zu Prod. Wenn deine Pipeline vierzig Minuten dauert und dein Release Train donnerstags fährt, wird deine Lead Time dominiert vom Donnerstag.

Deployment-Häufigkeit. Wie oft du in die Produktion shippst. Du kannst Deployments über einen Zeitraum zählen oder die Lücke zwischen ihnen messen. Ein Service, der elf Mal täglich deployed, und ein Service, der einmal im Monat deployed, sind völlig verschiedene Tiere, und deren Durchschnitt zu berechnen verschleiert beide.

Wiederherstellungszeit nach fehlgeschlagenen Deployments. Wie lange es dauert, sich zu erholen, wenn ein Deployment ein Problem verursacht, das Eingreifen erfordert. Das wurde früher Mean Time to Restore genannt, und die Umbenennung ist absichtlich. Es zählt nur Incidents, die deine eigene Änderung verursacht hat, nicht ein Cloud-Provider-Ausfall am Dienstag.

Fehlerquote bei Änderungen. Der Anteil der Deployments, bei denen sofort Maßnahmen nötig waren: ein Rollback, ein Hotfix, ein schnell geschobener Forward Fix. Zehn Deployments, zwei davon revertiert, eine Fehlerquote bei Änderungen von zwanzig Prozent.

Neubearbeitungsrate. Der Anteil der Deployments, die ungeplant sind, ausgelöst durch einen Produktions-Incident statt durch Roadmap-Arbeit. Das ist die neueste Ergänzung und erfasst etwas, das die Fehlerquote verfehlt: das Team, das nie rollback macht, aber die Hälfte seiner Woche damit verbringt, Notfall-Patches zu shippen.

Durchsatz gegen Instabilität: Warum du nie eine Metrik allein liest

Die ersten drei Metriken sind Durchsatz. Die letzten zwei sind Instabilität. Die Gruppierung ist der ganze Punkt.

Wenn du nur auf Durchsatz schaust, wirst du ein Team feiern, das vierzig Mal täglich deployed und still ein Viertel davon revertiert. Wenn du nur auf Instabilität schaust, wirst du ein Team belohnen, das einmal im Monat mit einer blütenreinen Bilanz shipped, weil niemand etwas ändert. Jede einzelne Metrik hat eine billige Methode, sie zu verbessern, die das System verschlechtert.

Deployment-Häufigkeit steigt, wenn du ein Deploy in fünf leere Deploys aufteilst. Fehlerquote sinkt, wenn du Hotfixes nicht als Fehler zählst. Lead Time schrumpft, wenn du den Start der Uhr umdefinierst. Das ist Goodharts Gesetz, das tut, was es immer tut: Wenn eine Messgröße zu einem Ziel wird, ist sie keine gute Messgröße mehr. Der offizielle Guide zählt es zuerst unter den Warnungen auf, und es ist das, das am härtesten beißt.

Die praktische Regel ist Paare. Lies Lead Time neben Fehlerquote. Lies Deployment-Häufigkeit neben Neubearbeitungsrate. Eine Bewegung in eine Richtung ohne eine angepasste Geschichte in der anderen ist ein Signal zum näher Hinschauen, nicht ein Sieg zum Ankündigen.

Benchmarks zirkulieren in jedem Vendor-Deck, und sie sind eine Falle. Das gemeldete Muster aus neuesten DORA Reports ist konsistent in der Form: Der stärkste Cluster von Teams deployed On-Demand, mit einer Lead Time unter einem Tag und erholt sich von einem gescheiterten Deployment in unter einer Stunde. Der langsamste Cluster sitzt im Wochen-bis-Monats-Bereich bei beiden.

Diese Zahlen sind für eine Sache nützlich: deine Intuition darüber zu kalibrieren, was möglich ist. Sie sind arm als Ziele. Ein Zahlungsservice mit obligatorischem Audit Gate wird nicht einer Marketing-Website entsprechen, und es sollte auch nicht versuchen. Die offizielle Anleitung ist explizit, dass du nur ähnliche Applikationen oder Services vergleichen solltest und dass du Verbesserung gegen deine eigene Baseline anstreben solltest statt Wettbewerb zwischen Teams.

Beginne mit deinem eigenen Median. Mess ihn einen Monat lang, bevor du ein Ziel setzt. Die erste Nummer ist fast immer beschämend, und das ist in Ordnung. Eine Baseline, die dich beschämt, ist eine Baseline, der du tatsächlich traust.

Wie man sie instrumentiert, ohne eine Data Platform zu bauen

Die meisten Teams überbauen das. Du brauchst kein Warehouse-Projekt. Du brauchst vier Zeitstempel und ein Flag.

Die Zeitstempel: Commit zum Main Branch gemergt, Build fertig, Deployment in der Produktion gestartet, Deployment fertig. Das Flag: ob das Deployment später revertiert, hotgefixt oder von einem ungeplanten Deploy innerhalb eines definierten Fensters gefolgt wurde.

Hier ist eine minimale Skizze in TypeScript. Sie nimmt eine Liste von Deployment-Records und gibt die Zahlen zurück, die zählen.

type Deploy = {
  service: string;
  committedAt: Date;
  deployedAt: Date;
  failed: boolean;       // revertiert, hotgefixt oder manuelle Intervention
  unplanned: boolean;    // ausgelöst durch einen Incident, nicht durch Roadmap-Arbeit
  recoveredAt?: Date;    // gesetzt wenn failed true ist
};

const median = (xs: number[]) => {
  const s = [...xs].sort((a, b) => a - b);
  return s.length ? s[Math.floor(s.length / 2)] : 0;
};

export function doraSummary(deploys: Deploy[], days: number) {
  const leadHours = deploys.map(
    d => (d.deployedAt.getTime() - d.committedAt.getTime()) / 36e5,
  );
  const failures = deploys.filter(d => d.failed);
  const recoveryMins = failures
    .filter(d => d.recoveredAt)
    .map(d => (d.recoveredAt!.getTime() - d.deployedAt.getTime()) / 6e4);

  return {
    leadTimeHoursP50: median(leadHours),
    deploysPerDay: deploys.length / days,
    changeFailRate: failures.length / Math.max(deploys.length, 1),
    recoveryMinutesP50: median(recoveryMins),
    reworkRate: deploys.filter(d => d.unplanned).length / Math.max(deploys.length, 1),
  };
}

Zwei Entscheidungen in diesem Snippet tragen das Gewicht. Erstens verwendet es den Median, nicht den Durchschnitt. Eine schlechte Woche mit einer dreitägigen Wiederherstellung zerstört einen Durchschnitt und sagt dir nichts über einen typischen Dienstag. Zweitens berechnet es alles pro Service. Aggregiere zu einem Team oder eine Abteilung nur, nachdem du die Services darunter angesehen hast.

Der harte Teil ist nicht der Code. Der harte Teil ist das failed Flag. Jemand muss entscheiden, was als Fehler zählt, es aufschreiben und jedes Mal gleich anwenden. Wenn dein Incident Tracker Incidents mit dem Deployment verlinkt, das sie verursacht hat, bekommst du das fast kostenlos. Wenn nicht, fang da an.

Die Tooling-Frage kommt nach der Datenfrage. Du besitzt schon die meisten rohen Daten. Dein Git Host hat Commit-Zeiten. Dein CI hat Build- und Deploy-Events. Dein Incident Tool hat die Fehler. Die Arbeit besteht darin, sie auf einer gemeinsamen Deployment-Kennung zu verbinden.

Observability-Plattformen sind ein natürlicher Ort, um Deployment-Marker über Fehlerquoten und Latenz zu überlagern, damit du sehen kannst, welches Deploy welchem Spike voraus war.

Wenn du lieber den Stack offen und selbst gehostet halten möchtest, macht eine Dashboard-Schicht über deine eigene Datenbank von Deployment-Events denselben Job zu niedrigerem Preis, mit mehr Rohrleitungsarbeit auf deiner Seite.

Es gibt auch eine Kategorie von Tooling, das deine Repositories und Delivery-Verlauf liest und Risiken anzeigt, etwa Hotspots, wo Code-Churn und vergangene Mängel sich clustern. Es wird die vier Zeitstempel nicht ersetzen, aber es erklärt, warum ein Service eine hohe Fehlerquote hat, wenn seine Nachbarn das nicht haben.

Eine Warnung zum Kaufen von etwas hier. Ein Dashboard, das die Zahlen zeigt, ist nicht dasselbe wie ein Team, das auf sie reagiert. Wenn niemand den Wiederherstellungszeit-Chart besitzt, ändert das Kaufen eines besseren Charts nichts.

Die Hebel, die jede Zahl tatsächlich bewegen

Metriken sind eine Diagnose. Die Behandlung liegt anderswo, und sie ist für jede unterschiedlich.

Für Lead Time, schau auf Wartezeiten, nicht Arbeit. Zieh ein Dutzend kürzliche Änderungen und markiere, wo jede Leerlauf hatte: Wartet auf Review, wartet auf einen Build-Slot, wartet auf ein Release-Fenster. Bei den meisten Teams überwiegt die Leerlaufzeit die Arbeitszeit um ein Vielfaches. Kleinere Pull Requests und eine Review Service-Level-Erwartung schlagen jedes Pipeline-Tuning.

Für Deployment-Häufigkeit, der Hebel ist Batch-Größe. Kleinere Änderungen sind leichter zu überprüfen, leichter nachzudenken und leichter zurückzuziehen. Trunk-Based Development und Feature Flags existieren, um dich sicheres Mergen unvollendeter Arbeit zu erlauben, was ist, wie du Deployieren vom Freilassen dekoppelst.

Für Fehlerquote bei Änderungen, der Hebel ist, wie viel des Blast Radius du sehen kannst, bevor es die ganze Flotte ist. Ein Rollout, das ein Prozent des Verkehrs exposiert, eine Fehlerrate gegen ein SLO überwacht und bei einer Verletzung steckenbleibt, verwandelt einen möglichen Incident in ein Nicht-Ereignis. Das ist die Lücke zwischen einem gescheiterten Deployment und einer gescheiterten Änderung, die niemand außerhalb des Teams bemerkt hat.

Für Wiederherstellungszeit, der Hebel ist das Revert. Wenn der schnellste Fix ein Rollback ist, dann ist die Wiederherstellungszeit, wie schnell du das Problem erkennst plus wie schnell du den Knopf drücken kannst. Das Automatisieren des Reverts bei einer Schwellenverletzung schneidet den Menschen aus den ersten zehn Minuten. Um 3 Uhr morgens zählt das mehr als jede Runbook.

Für Neubearbeitungsrate, der Hebel ist Upstream. Eine hohe Zahl bedeutet, dass Incidents Deployments generieren. Schau, welche Services die Notfall-Patches produzieren, und lies ihre Post-Mortems als Menge statt eine nach einer.

Was sich ändert, wenn KI mehr deinen Code schreibt

Die neueste DORA-Forschung zeigt auf etwas Unbequemes für jeden, der einen Coding Assistant verkauft. Assistants beschleunigen Low-Level-Tasks, aber die Gewinne führten nicht klar zu Lead Time oder Fehlerquote. Mehr Code geschrieben pro Stunde ist nicht dasselbe wie mehr Value delivered pro Woche.

Wenn überhaupt, drängt ein höheres Volumen von generierten Änderungen Druck auf Review und deine Delivery Pipeline. Größere Batches verletzen Stabilität, und Review-Kapazität skaliert nicht mit Tippgeschwindigkeit. Beobachte deine Fehlerquote und Neubearbeitungsrate genau in den Monaten nach, dass ein Team einen Assistant adoptiert. Wenn Lead Time fällt aber Neubearbeitung steigt, wurdest du nicht schneller, du hast die Kosten bewegt.

Wie man sie in einer Retro nutzt, ohne dein Team zu brechen

Hier ist, was in der Praxis funktioniert. Setz die Trend Lines auf den Bildschirm für das letzte Quartal und stell eine Frage: Was hat sich hier geändert und warum? Frag nicht wer. Das Ziel ist eine Hypothese über das System, nicht ein Urteil über eine Person.

Drei Gewohnheiten halten die Zahlen ehrlich.

Erstens, setz sie nie in individuelle Performance Reviews. In dem Moment, in dem eine Metrik an einem Namen hängt, optimiert Leute die Metrik und deine Daten stellen die Realität nicht mehr dar.

Zweitens, koppel jede Nummer mit einer Geschichte. Ein Anstieg der Wiederherstellungszeit ist ein Incident mit einem Namen und einem Post-Mortem. Lies das Post-Mortem, bevor du das Diagramm liest.

Drittens, ändere eine Sache auf einmal. Wenn du Feature Flags adoptierst, Pull Requests schrumpfst und Rollbacks automatisierst im selben Monat, wirst du nie lernen, welcher Hebel den Finger bewegte.

Überspring die Maturity-Model-Folie, die deine Org in Tiers sortiert und eine Trophäe verteilt. Wert stattdessen: eine einzelne Seite pro Service, monatlich aktualisiert, auflistend die fünf Zahlen, den Wert des vorherigen Monats und einen Satz über das, was sich änderte.

Angenommen, du hattest neunzig Tage sauberer Daten auf einem Service, und du sahst die Fehlerquote bei Änderungen langsam nach oben kriechen, während die Deployment-Häufigkeit flach blieb. Wo schaust du zuerst: auf die Größe der Änderungen, die Qualität der Review oder die Sichtbarkeit, die du in einen Rollout hast, während er noch klein ist? Deine Antwort sagt mehr über dein Delivery System aus als jeder Benchmark.