DevOps ist kein Toolstack: Warum Kultur und Zusammenarbeit den Unterschied machen

Wer heute „DevOps“ googelt, landet schnell bei Jenkins, Kubernetes, Terraform und einer endlosen Liste von Tools. In Stellenanzeigen wird ein „DevOps Engineer“ gesucht, der möglichst viele dieser Werkzeuge beherrscht. Und in Boardrooms wird DevOps gerne als das nächste Infrastruktur-Upgrade verkauft: Pipeline aufsetzen, Container orchestrieren, fertig.

Das Problem dabei: DevOps war nie als Toolstack gedacht.

Der Begriff entstand 2009 aus einer simplen Beobachtung: Entwicklung und Betrieb arbeiten in den meisten Organisationen gegeneinander statt miteinander. Zwei Teams mit unterschiedlichen Zielen, unterschiedlichen Anreizen und einer Mauer dazwischen. Das eine Team will möglichst schnell neue Features liefern, das andere will, dass bloß nichts kaputtgeht. Das Ergebnis: Übergaben per Ticket, Schuldzuweisungen im Incident und ein Deployment-Prozess, der sich anfühlt wie ein Behördengang.

DevOps war die Antwort auf genau dieses Problem. Nicht durch ein neues Tool, sondern durch eine andere Art der Zusammenarbeit. Genau die sollte jeder verstehen, der DevOps nicht nur einführen, sondern auch zum Funktionieren bringen will. Schauen wir uns an, was sie ausmacht, woran sie scheitert und wie man erkennt, ob sie wirklich da ist.

Was DevOps-Kultur eigentlich bedeutet

Wenn wir von DevOps-Kultur sprechen, geht es im Kern um ein paar einfache, aber unbequeme Prinzipien:

Geteilte Verantwortung: Wer Software entwickelt, ist auch für deren Betrieb mitverantwortlich. Kein „Wir haben deployed, jetzt ist Ops dran.“ Wenn der Pager nachts summt, dann idealerweise bei dem Team, das den Code geschrieben hat.

Transparenz statt Silos: Informationen gehören nicht in einzelne Köpfe oder Teams. Monitoring-Dashboards, Incident-Reports, Deployment-Logs: All das muss für jede:n zugänglich sein, die/der es braucht. Wer für ein System verantwortlich ist, muss es auch vollständig sehen können. Verantwortung ohne Einblick funktioniert nicht.

Lernen statt Bestrafen: Wenn ein Deployment schiefgeht, lautet die erste Frage nicht „Wer war das?“, sondern „Was können wir am System ändern, damit das nicht nochmal passiert?“. Blameless Postmortems sind kein nettes Extra, sondern die Grundlage dafür, dass Menschen ehrlich über Fehler reden, statt sie zu vertuschen.

Kurze Feedbackschleifen: Je schneller ein Team sieht, was seine Änderung bewirkt hat, desto schneller kann es daraus lernen. Das betrifft nicht nur technisches Monitoring, sondern auch den Umgang miteinander: Wie schnell bekommt jemand eine Rückmeldung auf einen Pull Request? Wie lange dauert es, bis ein Problem eskaliert wird?

Nichts davon erfordert ein bestimmtes Tool. Alles davon erfordert, dass Menschen bereit sind, anders zu arbeiten.

Warum Tool-First-Ansätze oft scheitern

In der Praxis sieht die DevOps-Einführung in vielen Unternehmen ungefähr so aus: Die Geschäftsführung beschließt, „auf DevOps umzustellen“. Ein Budget wird freigegeben. Ein Tooling-Team evaluiert Plattformen, entscheidet sich für eine CI/CD-Pipeline, rollt sie aus. Nach ein paar Monaten gibt es automatisierte Builds, vielleicht sogar Infrastructure as Code.

Und trotzdem ändert sich wenig.

Die Deployments sind zwar technisch automatisiert, aber der Prozess drumherum bleibt derselbe. Das Ops-Team muss immer noch Tickets abarbeiten, die ein anderes Team erstellt hat. Monitoring-Alerts gehen an Leute, die den Code nicht kennen. Und wenn etwas schiefgeht, zeigt jede:r auf jemand anderen.

Das passiert, weil Tools Prozesse abbilden, aber keine Kultur erzeugen. Eine CI/CD-Pipeline kann Deployments beschleunigen. Aber wenn das Team dahinter kein Vertrauen hat, werden die Deployment-Fenster trotzdem klein gehalten, Change-Requests trotzdem dreifach abgesegnet und Releases trotzdem nur einmal im Quartal gemacht.

Ein konkretes Beispiel: Ein Unternehmen führt Kubernetes ein, weil das „zu DevOps gehört“. Die Infrastruktur wird komplexer, aber die Teamstruktur bleibt identisch. Plötzlich braucht man Kubernetes-Spezialist:innen, und statt einer Mauer zwischen Dev und Ops hat man jetzt eine Mauer zwischen Dev, Ops und dem neuen Platform-Team. Mehr Silos, nicht weniger.

Ein anderes Beispiel: Automatisierte Tests werden eingeführt, aber niemand fühlt sich für deren Pflege verantwortlich. Nach sechs Monaten sind die Hälfte der Tests flaky, die Pipeline dauert 45 Minuten, und die Entwickler:innen skippen sie routinemäßig. Die Automatisierung existiert, aber niemand vertraut ihr.

Das Muster ist immer dasselbe: Die Technologie wird eingeführt, aber die Arbeitsweise bleibt, wie sie war. Die versprochenen Verbesserungen bleiben aus.

Schlüsselprinzipien erfolgreicher DevOps-Teams

Was unterscheidet Teams, bei denen DevOps funktioniert, von denen, bei denen es ein Etikett bleibt? Aus der Erfahrung vieler Projekte kristallisieren sich ein paar wiederkehrende Muster heraus.

Cross-funktionale Teams statt Abteilungsgrenzen: Teams, die alle Fähigkeiten mitbringen, um ein Feature von der Idee bis zum Betrieb zu begleiten, treffen bessere Entscheidungen. Nicht weil Spezialisierung schlecht wäre, sondern weil die Alternative, also Handover-Ketten zwischen spezialisierten Abteilungen, zu Informationsverlust und Verantwortungsdiffusion führt. „You build it, you run it“ ist kein Slogan, sondern ein Organisationsprinzip.

Psychologische Sicherheit: Das klingt nach HR-Buzzword, ist aber messbar wirksam. Teams, in denen Menschen Fehler zugeben können, ohne Angst vor Konsequenzen zu haben, finden und beheben Probleme schneller.

Inkrementelle Verbesserung statt Big-Bang-Transformationen: Die erfolgreichsten DevOps-Initiativen beginnen klein. Ein Team ändert seinen Deployment-Rhythmus. Ein anderes führt Blameless Postmortems ein. Erfolge werden sichtbar, andere Teams werden neugierig. Das ist langsamer als ein Top-Down-Rollout, aber nachhaltiger, weil Kulturwandel nicht verordnet werden kann.

Gemeinsame Metriken: Wenn Development an Feature-Velocity gemessen wird und Operations an Uptime, arbeiten beide Teams rational gegen das jeweils andere Ziel. Erst wenn alle an denselben Ergebnissen gemessen werden, also an Deployment-Frequenz, Lead Time for Changes, Mean Time to Recovery und Change Failure Rate, entsteht ein gemeinsamer Anreiz zur Zusammenarbeit.

Kultur messbar machen – geht das überhaupt?

Die vier Metriken aus dem letzten Abschnitt sind keine Erfindung. Sie stammen aus der Forschungsreihe rund um den „State of DevOps Report“, die systematisch untersucht, was High-Performing-Teams von anderen unterscheidet. Später wurde daraus das DORA-Team (DevOps Research and Assessment), inzwischen Teil von Google Cloud. Die Datenbasis ist über die Jahre gewachsen und gilt als eine der belastbarsten Quellen in diesem Bereich.

Was die Forschung zeigt: Technische Praktiken und Kultur hängen zusammen, aber Kultur ist der stärkere Hebel. Teams, die technisch exzellent aufgestellt sind, aber in einem Umfeld mit Schuldzuweisung und Angstkultur arbeiten, performen schlechter als Teams mit soliden (nicht perfekten) Tools und einer Kultur des Vertrauens.

Lässt sich Kultur messen? Direkt eher schwer, aber indirekt sehr wohl. Deployment-Frequenz ist ein Proxy dafür, wie viel Vertrauen ein Team in seinen eigenen Prozess hat. Mean Time to Recovery zeigt, wie gut ein Team unter Druck zusammenarbeitet. Change Failure Rate sagt etwas darüber aus, wie ernst Qualität genommen wird. Nicht nur als Gate, sondern als gemeinsame Haltung.

Der Fehler, den viele Organisationen machen: Sie erheben diese Metriken und verwandeln sie sofort in Zielvereinbarungen. Damit wird aus einer Feedback-Quelle ein Kontrollmechanismus und die Zahlen verlieren ihren Wert. Deployment-Frequenz lässt sich leicht nach oben treiben, wenn man die Definition von „Deployment“ aufweicht. Sinnvoller ist es, diese Metriken als Gesprächsanlass zu nutzen: Warum ist unsere Lead Time gestiegen? Was hat beim letzten Incident gut funktioniert, was nicht?

Fazit: Technologie unterstützt Kultur – nicht umgekehrt

DevOps braucht gute Tools. Automatisierung ist wichtig, CI/CD-Pipelines sind wichtig, Infrastructure as Code ist wichtig. Aber all das sind Werkzeuge im Dienst einer Arbeitsweise, nicht ihr Ersatz.

Ein Team, das sich gegenseitig vertraut, offen über Fehler spricht und gemeinsam Verantwortung trägt, wird auch mit mittelmäßigen Tools gute Ergebnisse liefern. Ein Team, das in Silos arbeitet, Tickets über Abteilungsgrenzen wirft und Fehler bestraft, wird auch mit dem besten Toolstack nicht schneller oder stabiler.

Wer DevOps ernst meint, fängt deshalb nicht bei der Toolauswahl an, sondern bei einer ehrlichen Bestandsaufnahme: Wie arbeiten unsere Teams tatsächlich zusammen? Wo gibt es Reibung, die kein Tool lösen kann? Und sind wir bereit, die Strukturen zu verändern, die diese Reibung erzeugen?

Die Technik kommt danach. Und sie wird besser funktionieren, wenn die Grundlage stimmt.

Seminarempfehlung