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, messen 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 Failure 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, Tools 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, Measurement, Lean 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?
- Measurement: Welche Zahlen braucht das Team, um gute Entscheidungen zu treffen und schlechte zu lassen?
- Lean: Worauf muss man sich beschränken, um mit minimalem Aufwand das maximale Ergebnis zu erreichen?
- 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 Failure | Zeit rund um Ausfälle |
| 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, das verbreitete Phasenmodell aus 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.
Das Prinzip des Essing, also 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.
