DORA-Metriken bis zum ausgelieferten Release zurückverfolgen

DORA ordnet Software Delivery Performance seit 2024 mit fünf Kennzahlen ein. Change Lead Time, Deployment Frequency und Failed Deployment Recovery Time - die Wiederherstellungszeit nach einem fehlgeschlagenen Deployment - beschreiben den Durchsatz; Change Fail Rate und Deployment Rework Rate erfassen Instabilität. Die im Januar 2026 veröffentlichte Rückschau erklärt, wie sich dieses Set entwickelt hat. Die Namen der Metriken sind allerdings noch kein fertiges lokales Messverfahren.

Schon bei der Deployment Frequency muss ein Team festlegen, was es als Deployment zählt. Für die Failed Deployment Recovery Time braucht es einen bestimmten Start- und Endpunkt.

Ändert sich diese operative Definition, kann sich die Zeitreihe ohne entsprechenden Wandel im Betrieb verschieben. DORA empfiehlt, die Werte gemeinsam, im Kontext einer Anwendung oder eines Dienstes und als Entwicklung über die Zeit zu lesen. Vor irreführenden Vergleichen verschiedenartiger Anwendungen warnt der Leitfaden ausdrücklich.

Release-Herkunft

Der Messpunkt muss außerdem auf einen bestimmten Release zeigen. Ein Commit oder ein wiederverwendetes Versionslabel genügt dafür nicht. Abhängigkeiten, Build-Umgebung, Konfiguration, Migrationen und das erzeugte Artefakt prägen gemeinsam das ausgelieferte Verhalten. NIST SP 800-218 empfiehlt, die Integrität von Releases prüfbar zu machen und Release-Dateien, Herkunftsdaten sowie die zugehörigen Integritätsinformationen geschützt aufzubewahren. Damit lässt sich später unterscheiden, ob zwei Umgebungen wirklich denselben Stand erhalten haben.

Für die Zeitzuordnung reicht ein Release-Bezeichner ohne Auslieferungsfenster ebenfalls nicht. Bei einem gestaffelten Rollout können innerhalb derselben Messperiode mehrere Stände aktiv sein. Als lokale Messregel sollte deshalb festgehalten werden, ab wann eine Teilpopulation dem neuen Stand zugerechnet wird und welches Vergleichsfenster gilt. Sonst wird eine Veränderung möglicherweise dem Release zugeschrieben, obwohl die beobachtete Population noch gemischt war.

Canary und Fachwirkung

Beim Canarying wird eine begrenzte Teilauslieferung mit einer Kontrollpopulation verglichen. Das Google SRE Workbook verlangt getrennt auswertbare, vergleichbare Signale und eine Vorstellung davon, welches Verhalten noch akzeptabel ist. Vor dem Start sollten daraus Kriterien zum Fortsetzen, Anhalten oder Zurücknehmen abgeleitet werden. Eine erst nach Sichtung der Kurven formulierte Regel wäre kaum belastbar. Technische Signale zeigen dabei nicht automatisch die fachliche Wirkung. Ein auf HTTP-Ebene erfolgreicher Aufruf kann neben unvollständig verarbeiteten Aufträgen stehen; ein Rollback nimmt eine bereits versandte Nachricht oder ausgeführte Datenmigration nicht zurück. Für Rollouts mit solchen Nebenwirkungen sollte das Team deshalb festhalten, welches fachliche Signal es zusätzlich beobachtet und welche Folgen technisch reversibel sind.

Ein knappes Freigabeprotokoll kann diese Verbindung erhalten: eindeutig zugeordneter Release-Stand, verwendete Konfiguration, Messdefinition und die für diesen Rollout gewählten Abbruchbedingungen. Das ist keine zusätzliche DORA-Metrik, sondern eine lokale Brücke zwischen Zeitreihe, Provenienz und dem Stand, den Nutzer tatsächlich erhalten haben.

Hinweis: Diese Einordnung ersetzt keine Prüfung des Einzelfalls.