Das DevOps Research and Assessment Programm (DORA) bei Google veröffentlicht seit 2014 jährlich Daten zur Softwarelieferleistung tausender Teams weltweit. Eine der beständigsten Erkenntnisse dieser Studie: Der Unterschied zwischen den besten und schlechtesten Teams liegt nicht darin, welche Tools sie benutzen. Er liegt darin, wie sie arbeiten.
Das ist keine weiche Aussage. Die DORA-Metriken sind messbar, und die Unterschiede sind erheblich.
Was DORA-Metriken eigentlich messen
DORA unterscheidet vier Schlüsselmetriken, die gemeinsam beschreiben, wie gut ein Softwareteam liefert:
Deployment Frequency – Wie oft wird deployt? Elite-Teams deployen mehrmals täglich. Low-Performer weniger als einmal im Monat.
Lead Time for Changes – Wie lange dauert es von der ersten Code-Zeile bis zur Produktivsetzung? Bei Elite-Teams unter einer Stunde. Bei Low-Performern zwischen einem und sechs Monaten.
Change Failure Rate – Wie viel Prozent der Deployments führen zu einem Incident oder Rollback? Elite: unter 5%. Low-Performer: 46–60%.
Mean Time to Restore (MTTR) – Wie lange dauert es, einen Produktionsausfall zu beheben? Elite: unter eine Stunde. Low-Performer: eine Woche bis zu einem Monat.
Wer sich diese Zahlen ansieht und dann fragt, ob sein Team eher links oder rechts dieser Skala liegt, bekommt meistens eine unbehagliche Antwort.
Die typische Fehldiagnose
Wenn Teams mit diesen Zahlen konfrontiert werden, ist die häufigste Reaktion: “Wir brauchen eine bessere CI/CD-Pipeline.” Oder: “Wir sollten Kubernetes einsetzen.” Oder: “Wir brauchen mehr Automatisierung.”
Das ist fast immer die falsche Diagnose.
Ein Team, das einmal im Monat deployed, tut das nicht weil seine Pipeline langsam ist. Es tut das, weil Deployments riskant sind – weil jedes Deployment groß ist, weil große Änderungen zu mehr Fehlern führen, weil Fehler lange dauern zu beheben, also deployt man seltener, also werden Änderungen größer. Das ist ein selbstverstärkender Kreislauf, und eine schnellere Pipeline bricht ihn nicht auf.
Der Kreislauf beginnt nicht beim Tooling. Er beginnt bei der Frage: Wer trägt die Verantwortung, wenn etwas schiefgeht?
Das Silo-Problem, konkret
In vielen Organisationen gibt es zwei separate Welten: Entwicklung und Betrieb. Die Entwickler schreiben Code und übergeben ihn an den Betrieb, der ihn deployen und betreiben soll. Der Betrieb hat andere Prioritäten – Stabilität, Compliance, Change-Management-Prozesse – und bremst naturgemäß Deployments, die ihm zusätzliches Risiko bringen.
Das Ergebnis ist die sogenannte “Wall of Confusion”: Entwickler optimieren auf Features, Betrieb optimiert auf Stabilität, und zwischen ihnen häufen sich Tickets und Missverständnisse.
DevOps als Konzept adressiert genau das. Aber “DevOps Engineer” als Jobtitel hat in vielen Unternehmen dieses Problem nicht gelöst – es hat es nur versteckt. Man stellt jemanden ein, der Pipelines baut, nennt das “DevOps” und wundert sich, dass sich an den Lieferzeiten nichts ändert.
Was sich tatsächlich ändert: Wenn ein Softwareteam von Anfang an für den gesamten Weg eines Features verantwortlich ist – von der Anforderung bis zum Betrieb in Produktion, inklusive Monitoring, Alerting und On-Call. Das ist unangenehm und erfordert Veränderungen an Teamstruktur, Verantwortlichkeiten und Vergütungslogik. Keine Pipeline schafft das.
Was sich konkret ändern lässt
Es gibt drei Hebel, die in der Praxis tatsächlich wirken – unabhängig vom Toolstack:
Kleinere Deployments. Das ist der wirkungsvollste Einzelhebel. Wer statt einer monatlichen großen Release täglich kleine Änderungen deployed, senkt das Risiko pro Deployment drastisch. Wenn etwas schiefgeht, ist die Ursache offensichtlich und der Fix schnell. Das setzt voraus, dass Entwickler anders arbeiten – Feature Flags statt langer Feature-Branches, Trunk-Based Development statt monatelanger Parallelentwicklung.
Definition of Done, die Produktion einschließt. Fertig ist ein Feature erst, wenn es in Produktion läuft, überwacht wird und ein Rollback-Plan existiert. Nicht wenn es auf dem Rechner des Entwicklers funktioniert. Das ist eine kulturelle Entscheidung, die in jede Retro und jede Sprintplanung einfließen muss.
Blameless Postmortems. Wenn ein Incident passiert und die erste Frage ist “wer hat das verzapft?”, lernt das Team nichts. Wenn die erste Frage ist “wie konnte das System so scheitern und was ändern wir?”, lernt es. Google hat diesen Ansatz popularisiert, aber er funktioniert nur, wenn die Führungsebene das ehrlich mitträgt.
Sie kommen zuletzt – aber sie kommen. Wenn ein Team kleine, häufige Deployments anstrebt, werden Automatisierung und CI/CD nicht optional. Wenn Monitoring und schnelle Reaktion auf Incidents erwartet werden, braucht man einen vernünftigen Observability-Stack.
Der Unterschied ist: Das Tool löst dann ein bekanntes, reales Problem. Nicht ein hypothetisches.
Ein konkreter Test für eigene Projekte: Wie lange dauert es von einem leeren Git-Repository bis zu einer laufenden Produktionsumgebung? Nicht geplant – tatsächlich, Schritt für Schritt ausgeführt. Teams, die diese Frage nicht innerhalb von Stunden beantworten können, haben eine Automatisierungslücke. Teams, die sie nicht innerhalb von Tagen beantworten können, haben ein Strukturproblem.
Das ist kein Urteil. Es ist ein Startpunkt.