Teil F — Wie man misst. Zurück zur Übersicht.
Lernziel
Nach diesem Kapitel kennst du die vier DORA-Kennzahlen, kannst sie in deinem Umfeld erheben und weißt, warum Geschwindigkeit und Stabilität kein Gegensatz sind. Du kannst SLI, SLO und SLA unterscheiden und erklären, wozu ein Fehlerbudget dient.
Achtung, Namensgleichheit. In diesem Kapitel geht es um die DORA-Metriken aus der Forschungsgruppe DevOps Research and Assessment. Damit hat die DORA-Verordnung der EU — der Digital Operational Resilience Act aus Kapitel 17 — nichts zu tun. Zwei völlig verschiedene Dinge mit demselben Kürzel. In einem Haus, in dem beide vorkommen, lohnt es sich, das im Gespräch klarzustellen.
Die Forschungsgruppe um Nicole Forsgren, Jez Humble und Gene Kim hat über Jahre tausende Organisationen befragt und dabei vier Kennzahlen identifiziert, die leistungsfähige von weniger leistungsfähigen IT-Organisationen unterscheiden. Nachzulesen in Accelerate und den jährlichen State of DevOps-Berichten.
| Kennzahl | Frage | Misst |
|---|---|---|
| Deployment-Frequenz | Wie oft liefert ihr aus? | Durchsatz |
| Lead Time for Changes | Wie lange von Commit bis Produktion? | Durchsatz |
| Change Failure Rate | Welcher Anteil der Auslieferungen verursacht eine Störung? | Stabilität |
| Time to Restore Service | Wie lange bis zur Wiederherstellung? | Stabilität |
Später kam als fünfte Größe die Zuverlässigkeit hinzu — im Sinne der Einhaltung der eigenen Zusagen, was zum SLO-Teil dieses Kapitels führt.
| Kennzahl | Hoch | Mittel | Niedrig |
|---|---|---|---|
| Deployment-Frequenz | mehrmals täglich | wöchentlich bis monatlich | seltener als monatlich |
| Lead Time | unter einem Tag | Woche bis Monat | mehr als ein Monat |
| Change Failure Rate | unter 15 % | 15–30 % | über 30 % |
| Time to Restore | unter einer Stunde | unter einem Tag | Tage bis Wochen |
Die genauen Schwellen verschieben sich von Bericht zu Bericht — als Orientierung taugen sie trotzdem. Wichtiger als der Vergleich mit anderen ist ohnehin der Vergleich mit dem eigenen Wert vom letzten Quartal.
Geschwindigkeit und Stabilität sind kein Gegensatz.
Das ist das überraschendste und wichtigste Ergebnis der DORA-Forschung. Die intuitive Annahme lautet: Wer schneller ausliefert, geht mehr Risiko ein. Die Daten zeigen das Gegenteil — dieselben Organisationen, die häufig und schnell ausliefern, haben auch die niedrigeren Fehlerraten und die kürzeren Wiederherstellungszeiten.
Der Zusammenhang ist plausibel, wenn man ihn einmal gesehen hat: Häufige Auslieferung bedeutet kleine Auslieferung. Kleine Änderungen sind leichter zu prüfen, brechen seltener, und wenn doch, ist die Ursache offensichtlich. Die dafür nötigen Fähigkeiten — Testautomatisierung, Rollback, Überwachung — verbessern gleichzeitig die Stabilität.
Die Umkehrung gilt ebenso: Wer aus Vorsicht seltener ausliefert, sammelt Änderungen an und macht jede einzelne Auslieferung riskanter. Die Vorsicht erzeugt genau das Risiko, das sie vermeiden soll.
Daraus folgt die Regel für den Umgang mit den Kennzahlen: Immer paarweise betrachten. Eine gestiegene Deployment-Frequenz allein sagt nichts. Zusammen mit einer gleichbleibenden Fehlerrate sagt sie sehr viel.
Alle vier Kennzahlen lassen sich aus vorhandenen Daten gewinnen.
#!/usr/bin/env bash # # Grobe Erhebung der DORA-Kennzahlen aus Git und der Pipeline. # set -euo pipefail ZEITRAUM="${1:-90}" # Tage SEIT="$(date -d "${ZEITRAUM} days ago" +%Y-%m-%d)" echo "=== Zeitraum: letzte ${ZEITRAUM} Tage ===" # --- 1. Deployment-Frequenz: Tags auf produktiven Releases --- ANZAHL=$(git tag --list 'v*' --sort=-creatordate \ --format='%(creatordate:short) %(refname:short)' \ | awk -v seit="$SEIT" '$1 >= seit' | wc -l) echo "Deployment-Frequenz: ${ANZAHL} in ${ZEITRAUM} Tagen" echo " = $(echo "scale=2; ${ANZAHL}/${ZEITRAUM}" | bc) pro Tag" # --- 2. Lead Time: Commit-Zeit bis Tag-Zeit --- echo echo "Lead Time je Release (Stunden):" git tag --list 'v*' --sort=-creatordate --format='%(refname:short)' \ | head -20 | while read -r tag; do tag_zeit=$(git log -1 --format=%ct "$tag") erster=$(git log --format=%ct "${tag}" --not "${tag}^{}~20" 2>/dev/null | tail -1) [[ -z "$erster" ]] && continue echo " ${tag}: $(( (tag_zeit - erster) / 3600 ))" done # --- 3. Change Failure Rate: Anteil der Releases mit Revert/Hotfix --- FEHLER=$(git log --since="$SEIT" --oneline \ --grep='^revert' --grep='^hotfix' --grep='^fix!' -i -E | wc -l) echo echo "Change Failure Rate: ${FEHLER} von ${ANZAHL}" # --- 4. Time to Restore: aus dem Störungssystem, hier nicht automatisierbar --- echo echo "Time to Restore: aus Postmortems/Ticketsystem ermitteln"
Die Erhebung muss nicht perfekt sein. Eine grobe, konsistent erhobene Zahl ist unendlich viel wertvoller als eine exakte, die niemand erhebt. Wichtig ist nur, dass das Verfahren über die Zeit gleich bleibt — sonst misst man die Änderung des Messverfahrens statt die Änderung der Leistung.
Kennzahlen dienen der Selbststeuerung, nicht dem Teamvergleich.
Sobald Teams anhand ihrer Deployment-Frequenz verglichen oder gar bewertet werden, steigt die Deployment-Frequenz. Nicht weil besser gearbeitet wird, sondern weil man Änderungen aufteilt, leere Auslieferungen erzeugt oder Störungen nicht mehr als solche verbucht.
Auch der Vergleich zwischen Teams ist selten sinnvoll: Ein Team, das an einer Weboberfläche arbeitet, hat andere Rahmenbedingungen als eines, das ein Kernsystem mit Nachtverarbeitung betreut. Der einzige belastbare Vergleich ist der mit dem eigenen Vorquartal.
| Begriff | Bedeutung | Beispiel |
|---|---|---|
| SLI — Indicator | die gemessene Größe | Anteil der Anfragen unter 500 ms |
| SLO — Objective | das interne Ziel | 99,5 % der Anfragen unter 500 ms im Monat |
| SLA — Agreement | die vertragliche Zusage mit Folgen | 99,0 %, sonst Gutschrift |
Die Reihenfolge ist wichtig: Ein SLO liegt immer strenger als das SLA. Der Abstand dazwischen ist der Sicherheitspuffer, der zum Handeln zwingt, bevor eine vertragliche Zusage verletzt wird.
| Verfügbarkeit | Ausfall pro Monat | Ausfall pro Jahr |
|---|---|---|
| 99 % | 7,2 Stunden | 3,65 Tage |
| 99,5 % | 3,6 Stunden | 1,83 Tage |
| 99,9 % | 43 Minuten | 8,76 Stunden |
| 99,95 % | 22 Minuten | 4,38 Stunden |
| 99,99 % | 4,3 Minuten | 52,6 Minuten |
| 99,999 % | 26 Sekunden | 5,26 Minuten |
Jede weitere Neun kostet ungefähr das Zehnfache.
Bei 99,99 Prozent bleiben im gesamten Monat 4,3 Minuten Ausfall. Das schließt geplante Wartung, Netzwerkstörungen, Fehler bei Ausrollvorgängen und die Reaktionszeit eines Menschen mit ein. Praktisch bedeutet es: keine manuellen Eingriffe mehr, redundante Auslegung über Standorte hinweg, automatische Umschaltung.
Die Frage an den Fachbereich lautet deshalb nie „Wollen Sie hohe Verfügbarkeit?„ — die Antwort ist immer ja. Sie lautet: „Was kostet Sie eine Stunde Ausfall, und wie viel darf die Vermeidung kosten?“ Erst diese Frage erzeugt eine belastbare Anforderung.
Ein eleganter Gedanke: Wenn das Ziel bei 99,9 Prozent liegt, sind 0,1 Prozent Ausfall erlaubt. Das sind rund 43 Minuten im Monat — und dieses Budget ist eine Ressource, die man ausgeben darf.
Fehlerbudget im Monat (SLO 99,9 %) = 43 Minuten
Budget noch offen → Neues ausrollen, experimentieren,
Risiko eingehen
Budget aufgebraucht → Ausrollstopp für Funktionen,
nur noch Stabilisierung
Der Nutzen liegt darin, dass ein alter Konflikt zu einer Rechenaufgabe wird. Statt „die Entwicklung will zu schnell„ gegen „der Betrieb bremst“ gibt es eine gemeinsame Zahl. Ist das Budget offen, hat die Entwicklung freie Fahrt — der Betrieb kann nicht ohne Begründung bremsen. Ist es aufgebraucht, wird stabilisiert — auch wenn der Fachbereich drängt.
Bemerkenswert ist die andere Richtung: Ein dauerhaft ungenutztes Fehlerbudget ist ebenfalls ein Befund. Es bedeutet, dass das SLO zu locker gewählt ist oder dass zu vorsichtig gearbeitet wird. Beides kostet Geld, nur eben unsichtbar.
Die zugehörige Regel — was genau passiert, wenn das Budget aufgebraucht ist — muss vorher vereinbart und von der Leitung getragen sein. Eine Regel, die im Ernstfall verhandelt wird, ist keine.
Aufgabe 1. Erhebe die vier DORA-Kennzahlen für ein Projekt aus deinem Umfeld, notfalls durch Zählen von Hand für die letzten drei Monate.
Aufgabe 2. Formuliere für den KFZ-Rechner ein SLO. Beispiel:
SLI: Anteil der Anfragen an /api/praemie mit HTTP 2xx und
Antwortzeit unter 500 ms
SLO: 99,5 % über 30 Tage rollierend
Fehlerbudget: 0,5 % -> bei 500.000 Anfragen im Monat
sind das 2.500 Anfragen, die schiefgehen dürfen
Regel: Bei über 75 % verbrauchtem Budget keine neuen Funktionen
mehr, nur noch Stabilisierung.
Aufgabe 3. Baue das SLO als Prometheus-Regel auf Basis von Kapitel 12 und stelle den Budgetverbrauch in Grafana dar.
- record: kfz:sli_erfolgsrate expr: | sum(rate(kfz_anfragen_gesamt{ergebnis="erfolg"}[30d])) / sum(rate(kfz_anfragen_gesamt[30d])) - record: kfz:fehlerbudget_verbraucht expr: (1 - kfz:sli_erfolgsrate) / 0.005 - alert: FehlerbudgetFastAufgebraucht expr: kfz:fehlerbudget_verbraucht > 0.75 labels: severity: warnung annotations: summary: "Über 75 Prozent des Fehlerbudgets verbraucht"
Aufgabe 4. Diskutiert im Team: Was wäre bei euch die Konsequenz eines aufgebrauchten Budgets — und wer müsste dem zustimmen?
| Anti-Pattern | Folge | Abhilfe |
|---|---|---|
| Kennzahlen zum Teamvergleich | Zahlen werden optimiert, nicht die Arbeit | zur Selbststeuerung nutzen |
| Nur Durchsatz messen | Tempo auf Kosten der Stabilität | immer paarweise |
| SLO ohne Fehlerbudgetregel | schöne Zahl ohne Konsequenz | Regel vorher vereinbaren |
| SLO strenger als nötig | teuer, ohne dass es jemand merkt | am Bedarf ausrichten |
| SLO = SLA | kein Puffer bis zur Vertragsverletzung | SLO strenger ansetzen |
| Verfügbarkeit als einzige Kennzahl | langsame, aber erreichbare Systeme gelten als gut | Latenz und Fehlerrate ergänzen |
| Messen ohne Handeln | Bericht wird erstellt und abgelegt | feste Auswertung im Quartal |
| Perfekte Messung anstreben | man beginnt nie | grob anfangen, verfeinern |
Welche der vier Kennzahlen könntest du für deinen Bereich heute Nachmittag erheben — und welche Zahl erwartest du?
Der Vergleich zwischen Erwartung und Ergebnis ist oft der lehrreichste Teil der Übung.
Weiter mit Kapitel 16 — Wertstromanalyse und DMAIC