DevOps verstehen und den Lieferfluss messen

Worum es geht

Donnerstag, 19 Uhr, bei der Seeland Mobility AG in Biel. Zwei Entwickler sitzen vor einem Bildschirm, daneben eine ausgedruckte Checkliste mit 23 Schritten. Heute ist Release-Abend für die Buchungs-App des E-Bike-Sharings. Um 23 Uhr ist die neue Version online. Am Freitagmorgen meldet der Support, dass sich Firmenkundinnen nicht mehr anmelden können. Es folgt ein Hotfix, wieder von Hand, wieder mit Checkliste.

Selin ist im 4. Lehrjahr als Informatikerin Applikationsentwicklung in diesem Team. Ihre Berufsbildnerin fragt sie: «Wo verlieren wir eigentlich die meiste Zeit, und wie würdest du das belegen?» Genau darum geht es in diesem Modul. Bevor du irgendetwas automatisierst, musst du verstehen, wo eine Änderung heute hängen bleibt. Sonst baust du eine perfekte Pipeline für ein Problem, das gar nicht der Engpass ist.

In dieser Lektion lernst du, was DevOps wirklich bedeutet, wie du den Weg einer Änderung als Wertstrom aufzeichnest und wie du mit den vier DORA-Kennzahlen den Ist-Zustand messbar machst. Am Ende rechnest du die Kennzahlen selbst aus einem Deploy-Log aus, zuerst von Hand, dann mit Python.

DevOps ist eine Arbeitsweise, kein Werkzeug

Stell dir ein Restaurant vor, in dem die Küche nur kocht und der Service nur serviert. Die Küche will möglichst viele neue Gerichte ausprobieren, der Service will, dass abends nichts schiefgeht. Wenn ein Gericht kalt ankommt, zeigen beide aufeinander. Genau so sah es früher oft in der Informatik aus: Die Entwicklung wollte schnell Neues liefern, der Betrieb wollte Stabilität. Dazwischen stand eine Mauer, über die man Releases «geworfen» hat.

DevOps reisst diese Mauer ein. Entwicklung und Betrieb tragen gemeinsam Verantwortung dafür, dass Änderungen schnell und sicher bei den Nutzenden ankommen. Ein bekannter Leitsatz dazu lautet: «You build it, you run it». Wer eine Funktion baut, kümmert sich auch darum, wie sie in Produktion läuft.

Eine hilfreiche Merkhilfe für die Bausteine von DevOps ist CALMS:

Wichtig: Eine Pipeline allein ist noch kein DevOps. Wenn Pull Requests vier Tage auf ein Review warten, hilft die schnellste Pipeline wenig. Deshalb beginnt jede Verbesserung mit einer ehrlichen Analyse.

Der Weg einer Änderung: Wertstromanalyse

Eine Wertstromanalyse (Value Stream Mapping) zeichnet jeden Schritt auf, den eine Änderung vom Start der Arbeit bis zur Produktion durchläuft. Pro Schritt notierst du zwei Zeiten:

• Bearbeitungszeit: Jemand arbeitet aktiv an der Änderung (programmieren, reviewen, testen).
• Wartezeit: Die Änderung liegt herum und wartet (auf ein Review, eine Freigabe, das nächste Release-Fenster).

Selin hat zehn abgeschlossene Änderungen verfolgt. Dafür hat sie in Jira nachgeschaut, wann ein Ticket in «In Arbeit» wechselte, mit git log die Commit-Zeiten gelesen und im Release-Kalender das Produktionsdatum gefunden. Der typische Weg (Medianwerte) sieht so aus:

Die eckigen Kästen sind Arbeit, die runden sind Warten. Zusammengerechnet:

Daraus ergibt sich die Flusseffizienz: Bearbeitungszeit geteilt durch Durchlaufzeit. Hier 3 / 19 = rund 16 %. Mit anderen Worten: Eine Änderung verbringt 84 % ihrer Zeit mit Warten. Das ist in der Praxis nicht ungewöhnlich, aber es zeigt klar, wo der Hebel liegt. Würde das Team die Tests doppelt so schnell machen, sparte es einen halben Tag. Würde es das monatliche Release-Fenster abschaffen, sparte es bis zu 12 Tage.

Die vier DORA-Kennzahlen

Das Forschungsprogramm DORA (DevOps Research and Assessment) untersucht seit Jahren, was leistungsfähige Softwareteams auszeichnet. Daraus stammen vier Kennzahlen, die heute in vielen Firmen der Standard sind. Zwei messen das Tempo, zwei die Stabilität:

Die vierte Kennzahl heisst in neueren DORA-Berichten Failed Deployment Recovery Time. Gemeint ist dasselbe: Wie lange dauert es, bis ein fehlerhaftes Deployment wieder in Ordnung ist.

Die vielleicht wichtigste Erkenntnis aus der DORA-Forschung: Tempo und Stabilität sind kein Widerspruch. Teams, die oft und in kleinen Schritten ausliefern, haben in der Regel auch weniger Störungen und beheben sie schneller. Kleine Änderungen sind leichter zu prüfen, leichter zu verstehen und leichter zurückzunehmen. Spitzenteams liefern mehrmals täglich aus, ihre Änderungen sind in weniger als einem Tag live, und Störungen sind meist in unter einer Stunde behoben.

Schritt für Schritt: DORA-Kennzahlen aus Git und Deploy-Log

Selin will die Zahlen nicht schätzen, sondern belegen. So geht sie vor.

Schritt 1: Zeitraum und Definitionen festlegen. Sie nimmt die letzten 10 Monate, in denen es 10 reguläre Releases und 3 Hotfixes gab. Sie schreibt die Definitionen auf, damit sie in zwei Monaten genau gleich rechnen kann: «Deployment = jede Auslieferung in Produktion, auch Hotfixes. Fehlerhaft = das Deployment brauchte einen Hotfix oder ein Rollback.»

Schritt 2: Lead Time für sieben Beispieländerungen. Commit-Datum aus git log, Produktionsdatum aus dem Deploy-Log:

# Zeitpunkt des ersten Commits zu einem Ticket finden (Ticket-Nummer im Commit)
git log --reverse --format="%h %ad %s" --date=iso --grep="BOOK-412" | head -n 1

Sortiert: 12, 17, 19, 19, 21, 23, 26. Der Median (der mittlere Wert) ist 19 Tage. Der Durchschnitt wäre 137 / 7 = 19,6 Tage. Selin nimmt den Median, weil einzelne Ausreisser (eine Änderung, die drei Monate liegen blieb) den Durchschnitt stark verzerren können.

Schritt 3: Deployment-Frequenz. 13 Deployments in 10 Monaten sind 1,3 pro Monat. Selin schreibt «etwa monatlich», denn die Hotfixes sind keine geplanten Auslieferungen.

Schritt 4: Change Failure Rate. 3 der 13 Deployments verursachten eine Störung: 3 / 13 = 23 %. Zählt man nur die 10 regulären Releases, sind es 3 / 10 = 30 %. Beide Rechnungen sind vertretbar. Entscheidend ist, dass Selin ihre Definition notiert und beim Nachmessen genau gleich rechnet. Sie wählt die DORA-Definition mit allen 13 Deployments und erwähnt im Bericht, dass 3 von 10 Releases einen Hotfix brauchten.

Schritt 5: Time to Restore. Die drei Störungen dauerten vom Erkennen bis zur Behebung 5,5 Std., 3 Std. und 9 Std. Sortiert: 3; 5,5; 9. Median: 5,5 Stunden.

Schritt 6: Engpass benennen. Mit Wertstrom und Kennzahlen kann Selin begründen: Das monatliche Release-Fenster (12 Tage Wartezeit) ist der grösste Engpass, gefolgt vom Warten auf Reviews (4 Tage). Die manuellen Tests machen Releases zudem teuer und fehleranfällig. Ihr Vorschlag: zuerst kleinere Branches mit schnellen Reviews, dann eine CI-Pipeline, dann häufige automatisierte Auslieferung.

Jetzt bist du dran. Bring Python bei, die Kennzahlen aus einem Deploy-Log zu berechnen. Wenn alle Tests grün sind, hast du die Definitionen wirklich verstanden.

{"datum": "2026-06-11", "fehlerhaft": True, "wiederherstellung_min": 330}

Und weil die Lead Time die Kennzahl ist, die Teams am häufigsten falsch messen, rechnest du sie im zweiten Labor aus echten Zeitstempeln:

Typische Fehler

• Mit der Technik anfangen statt mit der Analyse. Eine neue Pipeline beschleunigt den Build um 5 Minuten, aber die Änderung wartet weiterhin 12 Tage auf das Release. Zuerst den Wertstrom zeichnen, dann den grössten Engpass angehen.
• Den Durchschnitt statt den Median nehmen. Eine einzige Änderung, die 120 Tage liegen blieb, macht aus 19 Tagen schnell 33 Tage Durchschnitt. Für Durchlaufzeiten ist der Median robuster.
• Lead Time ab Ticket-Erstellung messen. Ein Ticket, das ein halbes Jahr im Backlog lag, sagt nichts über den Lieferprozess. DORA misst ab dem Commit. Wenn du ab Arbeitsbeginn misst, nenne das Durchlaufzeit und schreib es dazu.
• Definitionen nicht festhalten. Wer vorher Hotfixes mitzählt und nachher nicht, «verbessert» die Change Failure Rate auf dem Papier. Schreib auf, was ein Deployment und was ein Fehler ist.
• Kennzahlen zur Bewertung von Personen nutzen. Dann beginnt das Team, Zahlen zu schönen, statt den Prozess zu verbessern. DORA-Werte beschreiben ein Team und sein System.

Zusammenfassung

• DevOps ist eine Arbeitsweise mit gemeinsamer Verantwortung von Entwicklung und Betrieb. CALMS: Culture, Automation, Lean, Measurement, Sharing.
• Eine Wertstromanalyse trennt Bearbeitungs- und Wartezeit. Flusseffizienz = Bearbeitungszeit / Durchlaufzeit.
• Die vier DORA-Kennzahlen: Deployment-Frequenz, Lead Time for Changes, Change Failure Rate, Time to Restore (neu: Failed Deployment Recovery Time).
• Tempo und Stabilität gehören zusammen: Kleine, häufige Änderungen sind sicherer.
• Für Zeiten nimmst du den Median, und du hältst deine Definitionen schriftlich fest.
• Der grösste Hebel liegt fast immer bei den Wartezeiten, nicht bei der Bearbeitung.