DevOps braucht Multi-Cloud – und umgekehrt

Inhaltsverzeichnis

Wenn die Mitbewerber Updates und neue Funktionen in ihrem Online-Shop innerhalb von vier Stunden schaffen, wozu der eigene Betrieb Tage oder gar Wochen braucht, rücken Flexibilität und Schnelligkeit der eigenen IT auf die Tagesordnung von Unternehmensführungen. Die Antwort der IT lautet dann oft: Einführung von DevOps.

Doch innerhalb bestehender Abteilungssilos sind solche Einführungsinitiativen oft zum Scheitern verurteilt, weil sich die Kulturen von Entwicklung (Dev) und Betrieb (Ops) nicht miteinander in Einklang bringen lassen. Häufig finden sich Kommunikationsdefizite in beide Richtungen – etwa weil der Informationsaustausch fast ausschließlich über die jeweiligen Abteilungsleiter läuft, die sich für ihre Bereiche verantwortlich und damit auch ausschließlich sprachberechtigt fühlen. Aber solche hochkomplexen Sachverhalte nur über eine einzige Management-Ebene zu kommunizieren, führt immer dazu, dass es Ineffizienzen gibt und wichtige Informationen nicht weitergegeben werden.

Unterschiedliche Ziele bei Dev und Ops

Zudem weisen die Ziele der klassischen Dev- und Ops-Abteilungen per se in gegenläufige Richtungen und schließen einander aus. Während es die Aufgabe der Entwickler ist, vor allem Innovationen zu erzielen, muss der Betrieb vorrangig die Systeme am Laufen halten. Diese sich widersprechenden Ziele reichen bis in Arbeitsverträge hinein und werden nicht einfach durch die Einführung neuer Regeln obsolet.

Es handelt sich hier um eine grundsätzlich andere Arbeitskultur, die sich wiederum bis in feinste Vorgehensdetails wiederfindet. Zum Beispiel beim Thema "Fehlerkultur": Hier findet in traditionellen Organisationen das bekannte "Blame Game" nicht nur etwa deshalb statt, weil es die Mitarbeiter nicht anders kennen. Vielmehr sind ganze Prozessketten, Teamregeln bis hin zu Entlohnungsfragen nach diesem Prinzip geregelt.

Zunächst ist die Verantwortung für Fehler zu klären, die Lösung erfolgt erst im zweiten Schritt. Die DevOps-Kultur ist diesem Vorgehen diametral entgegengesetzt. In ihr kann es vielmehr vorkommen, dass ein bestimmter Fehler sehr willkommen ist, weil er das gesamte Vorgehen im Sinne eines explorativen Modus voranbringt, der dem Prinzip des "Trial and error" folgt.

DevOps-Metriken treiben den Wandel

Damit alte Gewohnheiten neue DevOps-Initiativen nicht schon im Keim ersticken, sind Metriken ein unverzichtbares Mittel, um für Transparenz bezüglich des aktuellen Stands der Dinge zu sorgen. Denn DevOps lässt sich messen – etwa die Häufigkeit und die Wege der Kommunikation: Finden regelmäßig Meetings zwischen Dev und Ops statt oder gibt es nur sporadische E-Mails?

Für die Auswahl und Definition der wichtigsten Kennzahlen bietet sich das sogenannte CALMS-Framework (Culture, Automation, Lean, Measurement, Sharing) für DevOps an, das erfolgsentscheidende Merkmale von DevOps aufführt. Auf Basis der so definierten und erhobenen Kennzahlen lassen sich dann wiederum Maßnahmen ableiten, um den gewünschten Fortschritt voranzutreiben. Wichtig dabei: Die gemessenen Stellschrauben lassen sich nicht nacheinander "abarbeiten", sondern sind gleichzeitig anzugehen, da sie ineinandergreifen und sich gegenseitig bedingen.

Das CALMS-Modell basiert dabei nicht auf Primärliteratur, sondern ist das Ergebnis von Konferenzen, bei denen insbesondere John Willis, Patrick Debois, Jez Humble und Damon Edwards den DevOps-Ansatz und das zugehörige CALMS-Modell vorgestellt und weiterentwickelt haben – zunächst nur als CAMS. Das Element "Lean" hat später Humble hinzugefügt.