DevOps ist als Buzzword gerade in aller Munde – jede IT-Abteilung, die etwas von sich hält, und jeder Manager oder Engineer, der „Project Phoenix“ gelesen hat, will es umsetzen, denn die Probleme sind allbekannt und die Lösungen doch offensichtlich einfach.

Nur: Es wird so nicht funktionieren.

Jedenfalls wird es nicht so funktionieren, wie es die Autoren von Project Phoenix gerne darstellen wollen und wie es auch gerne in Zeitschriften publiziert wird – nämlich in dem wir uns alle lieb anschauen, an den Händen fassen und gemeinsam singend durchs Leben schreiten.

Was fehlt?

Es fehlt oftmals etwas grundlegendes und im Roman (der übrigens wirklich lesenswert, wenn auch realitätsfremd ist, aber dazu später einmal mehr in einem eigenen Blogbeitrag) unterschwellig angesprochenes: Das richtige individuelle und übergreifende Mindset, das Verständnis dafür, was DevOps eigentlich ist.

Meine Erfahrung ist, dass sobald von einem Projekt als „euer Projekt“ gesprochen wird, das Thema DevOps bereits vom Tisch ist. Sobald es „DIE da“ heißt, kann man eigentlich aufhören. Dann stimmen Einstellung und Ownership bereits nicht mehr. Dann kann auch die ausgefeilteste Technik nix helfen.

DevOps: Entwicklung und Betrieb an einen Tisch setzen?

DevOps ist nämlich nicht, einen Entwickler und einen Betriebler an einen Tisch zu setzen – dann passiert nämlich nicht mehr, als das ein Entwickler und ein Betriebler an einem Tisch sitzen. Reden sie miteinander? Vielleicht. Arbeiten sie konstruktiv, strukturiert und lösungsorientiert miteinander? Nope. Sie versuchen es eventuell mal damit, werden aber schnell feststellen, dass sie einander nicht verstehen können und wollen. Wenn dann noch weitere Stakeholder mit ins Spiel kommen (Legal, Sales, etc.), dann wird die Sache um ein Vielfaches komplizierter.

DevOps ist eine Einstellungssache, eine Sache der Verantwortungsübernahme, ein Miteinander und ein Prozess. Alles gleichzeitig, alles dauerhaft, alles immer wieder neu.

DevOps: Einstellung und Mindset

Das richtige Mindset für DevOps ist zunächst mal das, dass man seine Komfortzone verlassen muss. Es ist total einfach, „DevOps!“ zu rufen und dann genau so weiter zu machen, wie bisher, denn die anderen müssen sich ja verändern. Aber genau so falsch ist es auch. Es sind die eigenen Einstellungen und Vorgehensweisen, die zu hinterfragen sind: Wie arbeite ich mit anderen Experten zusammen? Kann ich Andere überhaupt als Experten akzeptieren? Wie kann ich ein Verantwortungsdenken bei mir selbst etablieren? Wie bekomme ich die klassische Arsch-an-die-Wand-Mentalität – auch und gerade bei mir selbst – weg? Wie kann ich ein Miteinander etablieren und leben, auch wenn es manchmal schwer fällt? Wie kann ich meine Angewohnheiten und Vorgehensweisen ändern und anpassen?

Wenn diese Fragen nicht gestellt und beantwortet sind, dann wird DevOps nicht funktionieren. Dann muss man sich den anderen Aspekten von DevOps gar nicht erst widmen. Dann kann man sich gleich ein anderes Buzzword suchen (wie wäre es mit Bitmining oder KI / AI?), damit man modern und zeitgeistig klingt.

DevOps fängt zuallererst bei der eigenen Einstellung an! DevOps ist kein „Ihr müsst etwas ändern“-Ding, sondern ganz primär ein „Ich muss etwas ändern“-Thema.

DevOps: Verantwortung und Ownership

In einem DevOps-Umfeld geht es primär um Verantwortungsübernahme – neudeutsch: Ownership. Es gibt kein „das ist nicht mein Job“ und auch kein „Ihr da in der Entwicklung müsst mal“ und aucb kein „Na, wenn eure <Fäkalwort-Ihrer-Wahl-einfügen>-Applikation so <Fäkalwort-Ihrer-Wahl-einfügen> konfiguriert ist, dann kann’s ja nichts werden“!

Wenn diese Bemerkungen fallen, ist DevOps schon wieder Geschichte und gescheitert. Denn dann gibt es keine Zusammenarbeit und keine Verantwortungsübernahme, sondern altes Abgrenzungsdenken.

Die richtigen Vorgehensweisen wären stattdessen, auf Probleme und Schwierigkeiten hinzuweisen, aktiv an deren Beseitigungen zu arbeiten, sich selbst einzubringen und vor allem: „Euer“ durch „Unser“ zu ersetzen. Es ist „UNSER“ Projekt, es ist „UNSERE“ Applikation, es ist „UNSER“ Betrieb – egal, wo jemand sitzt und welche Aufgabe er in einem Projekt hat.

Sieht man ein Problem, dann muss man sich dafür verantwortlich fühlen, dass es gelöst wird – was keinesfalls bedeutet, dass man selbst hackt oder mal eben schnell zwanzig VMs von seinem Taschengeld provisioniert. Zuständigkeiten bleiben Zuständigkeiten, auch wenn sie sich oftmals schneller ändern, als einem lieb sein kann. Es geht viel mehr darum, dass man die Probleme proaktiv, offen und konstruktiv anspricht, sich an ihrer Beseitigung mit Wissen und Input beteiligt und eben auch dafür sorgt, dass diese Probleme angegangen und beseitigt werden. Das ist eine Einstellungssache, das ist Verantwortungsübernahme, das ist Ownership.

Und natürlich muss das gesamte Team das unterstützen – viel zu häufig werden Probleme und Anregungen unter den Tisch gekehrt, weil sie vom falschen Mitarbeiter zur falschen Zeit kamen oder weil sie gerade politisch nicht ins Konzept passen. Genau an dieser Stelle stellt sich wieder die Einstellungsfrage – DevOps findet nicht nur auf Ebene der Entwickler und Betriebler, sondern auf jeder Ebene in einem Projekt und vielleicht sogar weit darüber hinaus statt!

DevOps: Das Miteinander ist entscheidend!

Wie bereits schon oben dargestellt: Das Miteinander ist entscheidend! Wenn man ein Umfeld hat, in dem es „wir gegen die“ heißt, wird kein DevOps stattfinden können. Werden Schuldzuweisungen (Blaming) statt Problemlösungen in den Mittelpunkt gestellt, wird kein DevOps stattfinden können. Werden Projekte auf Fixpreis-, statt auf Budgetbasis ausgeführt, dann wird kein DevOps stattfinden können.

Kurz: DevOps kann nur in einem Umfeld funktionieren, das von Respekt, Anerkennung der Fähigkeiten jedes Einzelnen, Kritik- und Lernfähigkeit, Zielstrebigkeit und Lösungsorientierung, Mitdenken und Fehlerkultur geprägt ist. Fehlt auch nur eine dieser Komponenten, kann DevOps nicht stattfinden.

DevOps: Ist es ein Prozess?

An dieser Stelle sollte bereits klar sein, dass DevOps ein Prozess sein muss – in den Einstellungen, in der Verantwortungsübernahme, im Miteinander und in der Art der Interaktion der verschiedenen Rollen innerhalb eines Projekts miteinander. Es kann keinen Big-Bang geben, sondern es ist ein iterativer, inkrementeller und langfristig angelegter Prozess, der von Auf- und Abwärtsbewegungen und Rückschlägen ebenso geprägt ist, wie von positiven Erlebnissen und einer ganz anderen Zusammenarbeitskultur.

DevOps wird aber keinesfalls funktionieren, wenn auch nur einer der genannten Aspekte nicht gegebenen ist – und da haben wir über Transparenzen, Prozessanpassungen, Wissens- und Kenntnistransfers oder firmenübergreifender Zusammenarbeit noch gar nicht gesprochen! DevOps muss als Entwicklungs- und Betriebsprozess angesehen werden, als Ergänzung und Bestandteil klassischerer Projektmanagement-Ansätze, wie etwa Scrum oder dem V-Modell.

DevOps: Wo beginnt es überhaupt – und wo endet es?

Wenn man DevOps richtig leben will, wird man sehr schnell feststellen können, dass es zwar bei einem selbst beginnt, dort aber noch lange nicht aufhört – offensichtlich müssen andere Projektbeteiligte das gleiche Mindset, die gleichen Einstellungen haben, sonst kann es nicht funktionieren. Doch reicht das? Was ist mit dem Projektmanagement? Was ist mit Abteilungsleitungen? Was ist mit Fachbereichen? Was ist mit der Geschäftsführung?

Auf allen diesen Ebenen muss ein Umdenken erfolgen, eine andere Miteinander- und Zusammenarbeitskultur existieren, denn der oft praktizierte Teile-und-Herrsche-Ansatz kann nicht mit einer DevOps-Kultur kompatibel sein. Natürlich muss es Zuständigkeiten und Verantwortlichkeiten geben, natürlich müssen Entscheidungen getroffen und Verantwortung getragen werden, natürlich müssen Budgets überwacht und rechtliche Rahmenbedingungen eingehalten werden, und selbstverständlich gibt es auch noch persönliche und an die Abteilung / den Fachberech gebundene Ziele – das steht alles komplett außer Frage. Nur: Dies alles führt zu Königreichen und Silos, statt zu einem Miteinander von Experten – „Meins“ statt „Unser“, Abgrenzung statt Inklusion, Gegeneinander statt Miteinander. Und damit ist DevOps dann auch schon wieder ganz schnell tot.

Es ist also notwendig, die Kultur und den Umgang nicht nur auf Ebene von „kleinen“ Betrieblern und Entwicklern, sondern viel großmaßstäblicher zu ändern, über Projekt- und Abteilungsgrenzen weit hinaus.

DevOps: Kultur, nicht Technologie!

Deshalb ist DevOps offensichtlich weit mehr als Technologie, tatsächlich hat DevOps mit Technologie nur am Rande zu tun – vielmehr geht es um Einstellungen, Vorgehensweisen, Verantwortungen, soziale Aspekte und prozessuales Denken.

Das sind Dinge, die zum Teil auch aus Project Phoenix hervorgehen, weshalb das Buch in jedem Fall ein sehr guter Einstieg in die Thematik ist. Aber den kompletten Rahmen zeigt das Buch nicht auf, die Konsequenz wird angedeutet und nicht offen dargelegt – DevOps wird dort als IT-Thema behandelt, was es aber offensichtlich nicht ist.

DevOps ist eine Kultur, genauer: Eine Unternehmenskultur!

Und so lange das nicht verstanden wird, wird DevOps niemals richtig funktionieren.