DevOps ist der Versuch der IT-Branche, Softwareentwicklung grundlegend zu verbessern: menschliche Kosten wie Burnout senken, wirtschaftliche Verschwendung durch falsch entwickelte Software reduzieren und die Branche als Ganzes professionalisieren. Das CALMS-Modell konkretisiert DevOps in fünf Dimensionen: Culture, Automation, Lean, Measurement und Sharing. Vier Kennzahlen, die sogenannten DORA-Metriken, machen den Fortschritt messbar.
Das Wichtigste in Kürze
- Das CALMS-Akronym (Culture, Automation, Lean, Measurement, Sharing) macht DevOps konkret handhabbar und gibt Teams einen Rahmen, um vom abstrakten Ziel zur täglichen Praxis zu gelangen.
- Vier Kennzahlen reichen aus, um den DevOps-Reifegrad eines Teams zu messen: Lead Time for Changes, Deployment Frequency, Mean Time to Recovery und Change Failure Rate.
- Wer an einer Stelle der Software-Wertschöpfungskette arbeitet, beeinflusst immer auch die Person davor und danach; wird das ignoriert, entstehen die menschlichen und wirtschaftlichen Kosten, die DevOps abbauen soll.
- In akut belasteten Projekten bringt eine einzige kleine Verbesserung, etwa ein automatisiertes Skript oder ein gestrichenes sinnloses Meeting, sofort spürbaren Nutzen für andere im Team.
DevOps ist ein Schlachtruf, kein Phasenmodell
DevOps ist der Versuch der IT-Branche, ihre Arbeit besser zu organisieren, als sie es bisher getan hat. Hinter dem Begriff stehen Praktiken, Werte und Werkzeuge, die unter einem gemeinsamen Schirm zusammengeführt werden. Georgia König beschreibt DevOps als Ruf von IT-Leuten an IT-Leute: So wie es bisher lief, halten es viele bis zur Rente nicht durch.
Der Unterschied zur agilen Bewegung liegt in der Herkunft. DevOps wurde von Betroffenen selbst gefordert, entwickelt und immer wieder überarbeitet. Die treibenden Personen kamen aus dem Feld, hatten Zugang zu den Systemen und wollten nicht nur gute Ideen, sondern Lösungen, die man konkret programmieren, automatisieren und teilen kann.
Diese Praxisnähe macht DevOps zu einer möglichen Umsetzung dessen, was Agilität ursprünglich erreichen wollte. Agile entstand ebenfalls aus der Software heraus, wurde aber über die Jahre von Prozessbegleitern übernommen, die mit den Systemen selbst wenig zu tun haben. DevOps blieb näher am technischen Alltag.
Warum die IT-Branche DevOps überhaupt braucht
Es gibt drei Gründe, die DevOps rechtfertigen: menschliche Kosten, ökonomische Kosten und die Reife der Branche.
Die menschlichen Kosten sind real. Die IT hat eine hohe Burnout-Rate, Menschen leiden unter ihrem Job. DevOps soll diese Belastung mindern.
Die ökonomischen Kosten entstehen, wenn Software ineffizient entwickelt wird. Projekte werden eingestampft, das Falsche wird gebaut, es wird am Kunden vorbei entwickelt, oder gute Software landet nie beim Endkunden. DevOps soll verhindern, dass auf diese Weise Geld in Flammen aufgeht.
Der dritte Grund betrifft das Selbstverständnis. Die Informatik ist eine junge Branche mit Kinderkrankheiten, die ältere Domänen wie die Medizin längst überwunden haben. DevOps hilft, einen Standard zu etablieren und ernst genommen zu werden, jenseits der alten Bilder vom Kellerkind oder Hackerkind.
CALMS macht DevOps greifbar
Das CALMS-Akronym ist eine der praktischsten Möglichkeiten, DevOps zu konkretisieren. Es steht für Culture, Automation, Lean, Measurement und Sharing. Statt großer Ziele liefert es fünf Fragen, an denen ein Team konkret arbeiten kann.
- Culture: Welche Kultur unterstützt die Ziele, die mit DevOps erreicht werden sollen?
- Automation: Was muss automatisiert werden, damit es aus dem Weg ist?
- Lean: Worauf muss man sich beschränken, um mit minimalem Aufwand das maximale Ergebnis zu erreichen?
- Measurement: Welche Zahlen braucht das Team, um gute Entscheidungen zu treffen und schlechte zu lassen?
- Sharing: Wie wird Wissen verbreitet und Zugang geteilt?
Georgia setzt das Akronym in Workshops ein. Die Teilnehmer verstehen zuerst, wofür jeder Buchstabe steht, und überlegen dann, was sich davon explizit nutzen lässt. Welche Kultur müssen wir schaffen? Was müssen wir messen, automatisieren, teilen, reduzieren? So wandert DevOps von seinen hehren Zielen in den Alltag.
Im laufenden Projekt zählt der Effekt von morgen
In Projekten unter Druck darf eine DevOps-Intervention nicht mit wochenlangem Stillstand beginnen. Kunden, die unter Developer-Pains leiden, deren Projekte kurz vorm Aus stehen, brauchen schnell ein Ergebnis.
Die nützlichste Frage lautet deshalb: Was lässt sich in kurzer Zeit tun, das die nächsten Tage und Wochen erleichtert? Was könnte man in einer Stunde automatisieren, einfach damit es weg ist? Welches Meeting könnte man absagen, weil es dem Ziel nicht dient? Zu welchem Wissen müsste das Team Zugang haben, damit ein wiederkehrendes Problem verschwindet?
Der Maßstab ist der eigene Alltag in naher Zukunft. Du arbeitest so, dass du dir in einer Woche oder einem Monat denkst: Gut, dass ich mich darum gekümmert habe. Für zermürbte oder resignierte Projektmitarbeiter ist dieser schnelle, spürbare Effekt der Unterschied zwischen ernsthafter Veränderung und dem nächsten Berater, der nur ein weiteres Akronym mitbringt.
Vier Kennzahlen reichen, um Wirkung zu messen
Wer den Einfluss von DevOps messen will, sollte sich zunächst auf vier Kennzahlen beschränken. Die DevOps-Literatur empfiehlt die DORA-Metriken, benannt nach dem DevOps Research and Assessment.
| Metrik | Was sie zeigt |
|---|---|
| Lead Time for Changes | Wie lange eine Änderung bis zum Deployment braucht |
| Deployment Frequency | Wie oft tatsächlich deployt wird |
| Mean Time to Recovery | Wie schnell der Betrieb nach einem Ausfall wiederhergestellt ist |
| Change Failure Rate | Anteil der Änderungen, die zu Fehlern führen |
Die aufschlussreichste Frage ist oft die nach der Deployment-Frequenz. Wenn ein Team nur einmal im Jahr deployt, weil die Vorbereitungszeit sechs Monate beträgt, liegt der konstruktive Hebel offen: Was müsste passieren, damit diese Vorbereitung statt sechs Monaten nur noch einen Monat dauert?
Der Fokus auf wenige Kennzahlen ist zugleich eine Entlastung. Ein Team muss nicht alle Zahlen kennen und nicht überall schrauben. Schon der erste Schritt, die eigenen vier Werte überhaupt herauszufinden, ist häufig eine Intervention für sich.
Trau dich auf die Waage, guck dir die Zahl an, sei zwei Tage traurig, das ist völlig okay, und dann geht es los. (Georgia König)
Dafür eignet sich die Technik des magischen Dashboards: Wie sähe ein Dashboard aus, auf dem alle Zahlen stehen, die du je kennen wolltest? Die Werte erfassen, sich kurz erschrecken, und dann an ihnen arbeiten.
Die Wall of Confusion trennt, was zusammengehört
DevOps heißt Dev und Ops. Die Wall of Confusion beschreibt die Wand der Verwirrung zwischen Entwicklung und Betrieb. Sie macht deutlich: In jeder Phase gibt es jemanden davor und jemanden danach, und wenn diese Menschen nicht miteinander reden, läuft nichts so schnell, wie es könnte.
Niemand arbeitet im Vakuum. Wer Code ungetestet weiterreicht, belastet den Tester. Wer als Tester nur “alles grün” meldet und weitergibt, belastet den Betrieb. Wenn der Betrieb hinwirft, leidet die ganze Firma, weil der Kunde das Produkt nicht nutzen kann.
Daraus folgt der Community-Gedanke von DevOps. Werden Betriebsmitarbeiter schlecht behandelt, leiden die Entwickler. Werden Entwickler schlecht behandelt, hilft das dem Betrieb nicht. Es geht nicht um “wir hier und ihr dort”, die sich einmal im Jahr auf der Weihnachtsfeier sehen. Beide Seiten arbeiten an derselben Software, sie sind zwei Seiten derselben Münze.
Der DevOps-Achter, also die liegende Acht mit Phasen wie Planung, Entwicklung, Test, Deployment und Release, taugt vor allem als Checkliste. Er zeigt, dass an alle Phasen gedacht wird, sagt aber wenig darüber, was du morgen konkret tust, um deinen Arbeitsalltag besser zu navigieren. Als Vehikel für Marketingfolien funktioniert er, als Hilfe gegen Developer-Pains kaum.
So bringst du DevOps ohne großes Budget ins Rollen
Ein einzelner Vortrag oder ein kurzer Workshop reicht oft als Startpunkt. Entscheidend ist, dass jeder Teilnehmer für sich überlegt, wo er die DevOps-Konzepte in den eigenen Alltag übersetzen kann.
Ein Beispiel ist das S für Sharing. Wo gibst du Wissen nicht weiter, das anderen im selben Boot helfen würde? Schon kleine Änderungen können einen Stressor für die nächste Person in der Kette beseitigen, ohne dass dir das eigene Potenzial dafür vorher bewusst war.
Der erste Schritt ist deshalb ein Impuls, kein Großprojekt: Was du in der Wertschöpfungskette tust, hat immer einen Effekt auf die Person davor und danach. Daraus folgen die ehrlichen Fragen an dich selbst. Lebst du eine Kultur, von der andere profitieren? Erfasst du die richtigen Zahlen für deine Entscheidungen? Verteilst du dein Wissen zugänglich? Und streichst du, was nicht relevant ist, auch wirklich?
Der größte Hebel liegt in Klarheit über das Problem. Kluge Menschen lösen fast jedes Problem, wenn sie verstanden haben, was das Problem ist. Meistens wissen sie es nur nicht. Fehlende Klarheit ist häufiger die Ursache als fehlende Fähigkeit.
Eine Kultur, in der man Fragen stellen darf
DevOps braucht eine Kultur, in der man zugeben kann, etwas nicht zu verstehen. In der IT wird oft erwartet, dass das Gegenüber ein Tool sofort versteht, sofort drin ist, sich alles nebenbei per Suchanfrage beibringt. Wer nachfragt, hört manchmal nur: Bring es dir selbst bei. Damit endet der Austausch.
Das ist kein guter Nährboden für Offenheit. Man lernt nicht alles sofort, und manchmal braucht es mehr Anleitung, mehr Erklärung, mehr Ressourcen für gute Schulung. Offen zu sagen “Ich habe keine Ahnung, wovon du redest, erklär es mir bitte” sollte ohne Abwertung möglich sein.
Dazu gehört auch der Mut, beim Vorgesetzten nachzufragen, was eine Aufgabe eigentlich abschließt. Was ist die Definition of Done? Welches Maß an Verbesserung in Zahlen würde zeigen, dass es besser geworden ist? Welche Kosten müssten konkret eingespart werden? Solche Fragen verbinden Measurement mit Kultur, denn sie funktionieren nur, wenn das Umfeld sie überhaupt zulässt.
Offen zu fragen, statt sich heimlich auf die Suche zu machen, zahlt sich in der Praxis aus. Wer früh sagt “Holt mich mal mit rein”, spart sich das verdeckte Stochern und kommt schneller an die Information, die ihm fehlt.
Häufig gestellte Fragen
Was unterscheidet DevOps von der agilen Bewegung?
DevOps wurde von Betroffenen selbst gefordert, entwickelt und immer wieder überarbeitet. Die treibenden Personen kamen aus dem Feld, hatten Zugang zu den Systemen und wollten Lösungen, die sich programmieren, automatisieren und teilen lassen. Agile entstand ebenfalls aus der Software heraus, wurde aber über die Jahre von Prozessbegleitern übernommen, die mit den Systemen wenig zu tun haben. DevOps blieb näher am technischen Alltag.
Welchen Nutzen hat DevOps jenseits schnellerer Releases?
Drei Gründe rechtfertigen DevOps: menschliche Kosten, ökonomische Kosten und die Reife der Branche. Die IT hat eine hohe Burnout-Rate, und DevOps soll diese Belastung mindern. Wirtschaftlich geht es darum, dass Projekte eingestampft werden, am Kunden vorbei entwickelt wird oder gute Software nie beim Endkunden landet. Drittens hilft ein Standard der jungen Branche, ernst genommen zu werden.
Wofür stehen die fünf Buchstaben von CALMS?
CALMS steht für Culture, Automation, Lean, Measurement und Sharing. Aus jedem Buchstaben wird eine Arbeitsfrage: Welche Kultur unterstützt die Ziele? Was muss automatisiert werden, damit es aus dem Weg ist? Welche Zahlen braucht das Team für gute Entscheidungen? Worauf muss man sich beschränken? Wie werden Wissen und Zugang geteilt? Damit wandert DevOps von abstrakten Zielen in den Alltag.
Womit fängt man in einem Projekt an, das bereits unter Druck steht?
Mit einer kleinen Maßnahme, die in den nächsten Tagen spürbar wird, nicht mit wochenlangem Stillstand. Nützliche Fragen: Was ließe sich in einer Stunde automatisieren, einfach damit es weg ist? Welches Meeting könnte man absagen, weil es dem Ziel nicht dient? Zu welchem Wissen bräuchte das Team Zugang, damit ein wiederkehrendes Problem verschwindet?
Welche Kennzahlen zeigen, ob DevOps im Team etwas bewirkt?
Vier reichen: Lead Time for Changes, Deployment Frequency, Mean Time to Recovery und Change Failure Rate, bekannt als DORA-Metriken. Besonders aufschlussreich ist die Deployment-Frequenz. Deployt ein Team nur einmal im Jahr, weil die Vorbereitung sechs Monate dauert, liegt der Hebel offen. Schon das Erheben der eigenen vier Werte wirkt oft als Intervention.
Was passiert, wenn Entwicklung und Betrieb nicht miteinander reden?
Die Arbeit wird langsamer, als sie sein müsste, und die Belastung wandert weiter. Wer Code ungetestet weiterreicht, belastet den Tester. Wer als Tester nur “alles grün” meldet, belastet den Betrieb. Wirft der Betrieb hin, leidet die ganze Firma, weil der Kunde das Produkt nicht nutzen kann. Niemand in der Wertschöpfungskette arbeitet im Vakuum.
Hilft das bekannte DevOps-Phasenmodell, die liegende Acht, im Alltag?
Nur begrenzt. Der DevOps-Achter mit Phasen wie Planung, Entwicklung, Test, Deployment und Release taugt vor allem als Checkliste: Er zeigt, dass an alle Phasen gedacht wird. Er sagt aber wenig darüber, was du morgen konkret tust, um deinen Arbeitsalltag besser zu navigieren. Als Vehikel für Marketingfolien funktioniert er, als Hilfe gegen Developer-Pains kaum.
Warum fällt es in IT-Teams schwer, Verständnisfragen zu stellen?
Oft wird erwartet, dass jemand ein Tool sofort versteht und sich alles nebenbei per Suchanfrage beibringt. Wer nachfragt, hört manchmal nur: Bring es dir selbst bei. Damit endet der Austausch. Zu einer tragfähigen Kultur gehört, ohne Abwertung sagen zu können, dass man etwas nicht versteht, und beim Vorgesetzten nachzufragen, was eine Aufgabe eigentlich abschließt.
