Warum DevOps in Ihrem Unternehmen nicht funktioniert

"DevOps ist eine Arbeitsweise, die bei Software-Entwicklungsteams immer beliebter wird, um ihre Agilität zu erhöhen und schneller bessere Software entwickeln zu können." Das Problem bei dieser Beschreibung ist der Fokus auf "Entwicklungsteams". Bei DevOps geht es nicht um Entwicklungs- oder Betriebsteams, sondern um einen Weg, auf jede erdenkliche Weise einen besseren Kundennutzen zu erzielen. Entwicklung und Betrieb sind traditionelle Teams, die im Mittelpunkt dieses Prozesses stehen, und deshalb konzentrieren sich die meisten Unternehmen nur auf diesen Bereich von DevOps. Die einzige Möglichkeit, mit DevOps wirklich erfolgreich zu sein, besteht darin, Teams zu bilden, die die volle Verantwortung für die von ihnen erstellten und betriebenen Customer Journeys übernehmen können.

Lernen Sie mit unserem DevOps Bootcamp, wie Sie DevOps richtig einsetzen, basierend auf exklusiven Erfahrungen anstelle von Lehrbuchbeispielen, und beschleunigen Sie Ihre DevOps-Einführung mit unserem DevOps Bootcamp.

DevOps erfordert Teams, die unternehmerisch denken und aus Ingenieuren bestehen, die mutig arbeiten und bereit sind, zu lernen und sich zu verbessern. Diese Denkweise ist notwendig, um das bestmögliche Kundenerlebnis zu schaffen und zu liefern.

Abbildung 1: Amöbenartige Struktur von Startups ohne Hierarchie vs. traditionelle hierarchische Organisation

Startups aus dem Silicon Valley wie Facebook, Uber und Spotify haben die DevOps-Bewegung populär gemacht. Was ist der große Unterschied zwischen ihnen und Ihrem Unternehmen? Diese digital nativen Unternehmen haben sich DevOps von Anfang an zu eigen gemacht und verfügen über eine Organisationsstruktur, die dieser Denkweise entspricht. Das Conwaysche Gesetz besagt: "Jede Organisation, die ein System entwirft, wird ein Design produzieren, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist." Und da die meisten Organisationen nicht mit dem Gedanken an DevOps geschaffen wurden, gibt es keine wirkliche Übereinstimmung mit DevOps.

Ein gemeinsames Problem, das diese Startups gelöst haben, besteht darin, dass sie die IT nicht als Kostenstelle betrachten, sondern als Teil der Wertschöpfungskette, die dem Kunden einen Mehrwert bietet. Das ist der Kern von DevOps: die Bereitstellung von Kundennutzen.

Manche Leute sehen in DevOps nur den Abbau der "Mauer der Verwirrung" zwischen Entwicklern und Betrieb. Solange diese Abteilungen oder Teams unterschiedliche Ziele verfolgen, werden sie nie harmonisch zusammenarbeiten.

Abbildung 2: Kostengetriebene IT-Organisationen

Wir haben viele Unternehmen auf ihrem Weg zu einer DevOps-Kultur begleitet und sehen regelmäßig, wie Unternehmen mit der Einführung von DevOps experimentieren (was eine gute Sache ist). Dabei stoßen wir häufig auf einige Anti-Patterns:

Diese drei Teamzusammenstellungen sind oft eine gute Initiative, wenn Menschen in einem Unternehmen die Geschwindigkeit erhöhen wollen, um sich besser auf die sich schnell verändernde Welt um sie herum einstellen zu können.

Wenn DevOps eine Initiative ist, die nur von Entwicklerteams unterstützt wird (A), dann sagen sie, dass sie keinen Betrieb brauchen, und das kann für wirklich kleine Anwendungen in Ordnung sein. Schwieriger wird es, wenn Anwendungen in eine größere Anwendungslandschaft integriert werden müssen oder anspruchsvolle betriebliche Anforderungen haben.

Das Gegenteil ist, dass DevOps nur Teil von Operations (B) ist. Das passiert oft, wenn Unternehmen versuchen, ihre Betriebsabteilung zu modernisieren und DevOps einzuführen. Dieser Ansatz hilft wahrscheinlich bei der Automatisierung einiger Prozesse, aber es fehlt die Integration mit den Entwicklungsteams, um schneller bessere Software erstellen zu können.

Eines der häufigsten Muster, die wir in Unternehmen gesehen haben, ist die Schaffung eines neuen DevOps-Teams zwischen Dev und Ops. Dies mag anfangs eine logische Entscheidung sein, um die Lücke zwischen den Teams zu schließen, aber dies führt oft dazu, dass das DevOps-Team zum neuen Ops-Team wird. Wenn sich weitere Entwicklungsteams der Bewegung anschließen, wird dieses Team mit operativen Aufgaben überlastet und am Ende gibt es keinen Unterschied mehr zwischen den Optionen B & C. Dieser Ansatz kann jedoch erfolgreich sein, wenn es sich bei diesem Team um ein temporäres oder virtuelles Team handelt.

Diese Antimuster haben eines gemeinsam. Sie erkennen die Lücke zwischen Entwicklung und Betrieb an und versuchen, diese mit Tools oder einem zusätzlichen Team zu schließen.

Häufige Ursachen für das Scheitern von DevOps-Implementierungen

Viele Unternehmen kämpfen damit, ihre tägliche Arbeit zu erledigen. Sie konzentrieren sich darauf, immer mehr Funktionen hinzuzufügen, vergessen dabei aber das große Ganze: die bestehenden Prozesse, die eine strenge statt einer schlanken Methodik vorschreiben.

Denken Sie an Ihre Ingenieure, die Ihnen berichten, dass sie einen bestimmten Server nicht anfassen können oder dass sie die Geschwindigkeit oder Nutzung von Funktionen nicht messen können. Oder wenn sie auf die Arbeit eines anderen Teams angewiesen sind und warten müssen, bis diese Arbeit abgeschlossen ist, bevor sie mit ihrem Teil der Änderung fortfahren können.

Durch die Software-Architektur verursachte Probleme

Ein Muster, das wir oft sehen, ist, dass alle Schichten einer Lösung in Dienste mit Kommunikation zwischen ihnen aufgeteilt werden, in dem Versuch, die Entkopplung der einzelnen Dienste zu erhöhen. In Wirklichkeit können diese Dienste jedoch nicht unabhängig voneinander aktualisiert werden, da die Verträge zwischen ihnen so streng sind, dass ein Dienst nicht mit einem anderen Dienst mit einer älteren Version kommunizieren kann.

In der Folge sehen wir immer noch Unternehmen, die ihre Teams horizontal nach der Architektur ihrer Software aufteilen: Front-End, Back-End und Dienste sind in verschiedene Teams aufgeteilt, wobei jede Schicht an ein anderes Team übergeben wird. Das bedeutet, dass bei jeder Änderung in der Kommunikation zwischen diesen Schichten mehrere Teams beteiligt sind. Diese Art von zeremoniellen Schritten nimmt zu viel Zeit und zu viele Leute in Anspruch. Hören Sie auf mit diesem ganzen Layering!

Eine Änderung der Architektur nach diesem Modell kann eine ziemliche Herausforderung sein. Geben Sie einem Team die Kontrolle über jeden Aspekt der Teile der Architektur, für die es verantwortlich ist. Wenn sie beispielsweise ein Feld zur Datenbank hinzufügen müssen, schaffen Sie eine einfache Möglichkeit, dies zu tun, ohne dass ein ganzer Ausschuss diese Änderungen genehmigen muss. Wenn Sie diese Datenbank einfacher aktualisieren können, haben Sie ein Hindernis für das Team beseitigt. Aktualisieren Sie die Teile des Prozesses, die prüfen, ob sich die Datenbank in einem guten Zustand befindet, während sie in die nächste Umgebung bereitgestellt wird, und Sie werden während des Freigabeprozesses immer mehr Vertrauen erleben.

Durch die Infrastruktur verursachte Probleme

Die Kluft zwischen Entwicklern und Betriebsingenieuren ist für einige Kunden immer noch ein großes Problem. Die Entwickler fühlen sich nicht verantwortlich für die Software, die in der Produktion läuft, haben keinen Einblick in die Telemetrie und zeigen bei fast allen Problemen mit dem Finger auf den Betrieb. Gleichzeitig werden die Betriebsingenieure nicht gebeten, an Meetings teilzunehmen, wenn neue Funktionen ausgearbeitet werden. Teams, die so strukturiert sind, können die Infrastruktur nicht ohne weiteres ändern und müssen jemand anderen bitten, diese Änderungen vorzunehmen. Wenn das Entwicklungsteam beginnt, schneller zu iterieren und in kleineren Schritten bereitzustellen, wird die Infrastruktur zu einem häufigen Hindernis. Wenn ein Entwicklungsteam das Betriebsteam um die Bereitstellung eines Servers bitten muss und mehr als eine Woche warten muss, hält es das erste Team auf. Für Unternehmen ist die Umstellung auf die Cloud schwer zu bewerkstelligen, weil die Mitarbeiter, die eine Änderung der Netzwerkinfrastruktur vornehmen müssen, oft nicht in der Lage sind, diese Änderung selbst vorzunehmen, was dazu führt, dass die Entwicklungsteams nur langsam vorankommen und dem Endbenutzer nur schwer einen Mehrwert bieten können. Beseitigen Sie die Hürden für Änderungen an der Infrastruktur und gehen Sie zu Infrastruktur als Code über, um ein besseres Verständnis für die notwendigen Elemente in Ihrer Architektur zu erhalten. Auf diese Weise sind Änderungen besser nachvollziehbar, haben weniger Auswirkungen und können leichter rückgängig gemacht werden.

Probleme mit Kultur und Menschen

Unternehmen scheitern oft daran, die Kultur zu ändern, weil sie die Kultur nicht in allen Teams ändern, sondern nur in einer Teilmenge. Es ist sehr wichtig, sich von einzelnen Rollen wie 'Entwickler' und 'Tester' zu lösen und die Einstellung zu ändern, dass man ein Team von Ingenieuren ist. Natürlich haben einige von ihnen starke Fähigkeiten, die mit ihren alten Rollen verbunden sind, aber jeder Ingenieur in einem Team sollte die gesamte Lösung verstehen, für die sein Team verantwortlich ist, und sollte in der Lage sein, eine Vielzahl von Aufgaben innerhalb seines Teams zu übernehmen. Auf diese Weise sind Sie weniger auf den einen Mitarbeiter angewiesen, der immer Firewall-Probleme behebt, oder auf die Bereitstellung, die zwischen zwei Umgebungen stecken geblieben ist (und natürlich ist sie gerade nicht verfügbar!).

Durch die Arbeitsweise verursachte Probleme

Ein häufiger Fehler, auf den wir stoßen, ist, dass es für ein Team keine klare Definition von 'Arbeit' gibt. Oder wenn es ein gewisses Verständnis dafür gibt, was Arbeit ausmacht, wird nicht auf die Definition von 'erledigt' geachtet: Wann sind wir uns einig, dass die Arbeit abgeschlossen ist? Ist das der Fall, wenn eine Funktion entwickelt, von den Entwicklern getestet und an den Betrieb übergeben wurde, der die neue Version in der nächsten Umgebung im DTAP-Fluss implementieren muss? Ist eine Änderung an einer bestehenden Funktion 'Arbeit'? Ist das Verteilen von Hotfixes 'Arbeit'? Eine klare Definition von 'Arbeit' kann die Einstellung und die Arbeitsweise der Mitarbeiter wirklich verändern. Eine gute Möglichkeit, die gesamte Arbeit zu klären, besteht darin, sicherzustellen, dass alle Arten von Arbeit berücksichtigt werden: Geschäftsprojekte, interne Projekte, Änderungen und ungeplante Arbeit. Vor allem die letzte Kategorie wird meist vergessen, obwohl sie oft der Grund dafür ist, dass ein Ziel nicht erreicht wird.

Bringen Sie DevOps in Ihrem Unternehmen zum Laufen

Die Unternehmen, die die digitale Revolution anführen, sind die Unternehmen, die die DevOps-Mentalität wirklich verinnerlicht haben. Auf den Kundenwert ausgerichtete Teams, die autonom arbeiten können und alle auf ein Ziel ausgerichtet sind: einen besseren Kundennutzen zu liefern.

Abbildung 4: Wertorientierte Organisationen

Wie können wir uns also von bestehenden Organisationen hierher bewegen? Um diese Ausrichtung einzuführen, müssen Sie die hierarchische Struktur Ihrer Organisation ändern und ein Umfeld für kreative, experimentelle und unternehmerische Teams schaffen.

Dies kann in bestehenden Organisationen erreicht werden, indem man mehrere (Entwicklungs- und Betriebs-) Teams von der bestehenden Hierarchie loslöst und sie ohne die bestehenden Grenzen und Regeln arbeiten lässt. Diese Teams können dort an die Hierarchie angebunden werden, wo sie tatsächlich von der Hierarchie profitieren, z.B. in der Personal- oder Finanzabteilung.

Abbildung 5: Amöbenartige Struktur in Verbindung mit traditioneller Hierarchie

Wir sehen viele Unternehmen, die nur an die finanziellen Kosten ihrer IT-Organisation denken. Jede mögliche Lösung muss vollständig spezifiziert werden, einschließlich der damit verbundenen Kosten (sowohl zeitlich als auch finanziell). Diese Unternehmen können ihren Kurs nicht auf effiziente Weise ändern und müssen neue Technologien mühsam testen. Dies führt auch dazu, dass die Mitarbeiter nicht die Freiheit haben, mit neuen Technologien zu experimentieren, wodurch sie sich entmachtet fühlen. Dabei kann diese Freiheit zu schnelleren Iterationen führen, die Qualität verbessern und sogar die Kosten für die Teams senken, wenn man es richtig anstellt. Sprechen Sie mit den Teams über den Wert, den sie schaffen können, und nicht über die Kosten, die sie für das Unternehmen verursachen. Geben Sie ihnen dann die Befugnis, die notwendigen Änderungen vorzunehmen, und übertragen Sie ihnen die Verantwortung dafür! Natürlich heißt das nicht, dass sie losgelassen werden und durch Wände rennen sollen, aber sie müssen mehr Kontrolle über alle Aspekte ihrer Arbeit haben.

Geben Sie den Teams die Freiheit, Server in einer kontrollierten und gesicherten Netzwerktopologie aufzusetzen, nehmen Sie einen Ingenieur mit speziellen Kenntnissen im Bereich Netzwerksicherheit in das Team auf und sprechen Sie über den Mehrwert dieser Vorgehensweise: Können sie schneller arbeiten? Können sie besser und kontrollierter testen? Bringt es wertvolle Erkenntnisse über die Codequalität? Hilft es bei der Verbesserung der Zuverlässigkeit der Website? Bringt es mehr Sicherheit und ein besseres Verständnis für die notwendigen Grenzen? Viele DevOps-Organisationen formalisieren die Einrichtung von Servern und anderen beweglichen Teilen einer Umgebung, indem sie ein Plattformteam einrichten: Sie bieten eine Selbstbedienungslösung an, bei der die Teams Anfragen für neue Server, Datenbanken usw. einreichen können. Dies ist eine großartige Möglichkeit, die Teams zu befähigen, diese Aufgaben selbst auszuführen.

Faktoren für eine gut funktionierende DevOps-Organisation

Eines der wichtigsten Dinge, die es zu beachten gilt, ist die Harmonie zwischen den vier Faktoren bei der Erstellung von Software, d.h. der Softwarearchitektur, der Infrastruktur, den Menschen und dem Team, das die Software erstellt, und der Art und Weise, wie die Arbeit auf sie verteilt wird.

Ein häufig begangener Fehler ist es, nur einen oder zwei dieser Bereiche in einem Unternehmen zu verändern und dann später Probleme zu bekommen, weil die anderen Bereiche zwangsläufig zu Hindernissen werden.

Alles gleichzeitig zu ändern, scheint eine wirklich große Veränderung zu sein, und das ist es auch! Aber sie ermöglicht es den Teams, wirklich unternehmerisch zu handeln und die beste Arbeit zu leisten. Beginnen Sie damit, Ihre größten Engpässe zu finden und dann Wege zu finden, diese zu beseitigen. Die Softwarearchitektur muss so eingerichtet werden, dass sie die Systeme nicht in einer Weise koppelt, die die Teams daran hindert, ihren Teil zu ändern und freizugeben. Ereignisbasierte Mikroservices und Domain Driven Design (DDD) sind Beispielmuster, die Ihre Architektur unterstützen, damit Teams Grenzen zwischen den Bereichen der Software schaffen können, für die ein Team verantwortlich ist. Es ist möglich, kleine Teile bestehender Legacy-Systeme herauszuschneiden und sie durch Messaging-Muster und Muster wie den "Anti-Corruption Layer" zu entkoppeln . Am besten fangen Sie damit an, ein kleines, einzelnes vertikales Stück zu schaffen, das alle Schichten der Landschaft betrifft, und beweisen, dass diese Architektur funktionieren wird. Danach können Sie einen bestehenden Monolithen in kleinere Stücke zerschneiden.

Wenn alle Teams eine gemeinsam genutzte Infrastruktur verwenden, die sie nicht selbst kontrollieren können, oder wenn sie sich auf andere verlassen, um Dinge wie die Bereitstellung oder das Hinzufügen von Datenbanken zur Landschaft zu erledigen, wird dies wahrscheinlich zu Reibungen und Verzögerungen führen. Vor allem, wenn das andere Team ein kostenorientiertes Team ist, das sich auf die Reduzierung der Kosten konzentriert. Öffentliche Clouds wie Azure oder AWS ermöglichen es Teams, ihre eigene Infrastruktur auf der Grundlage von Platform as a Service (PaaS)-Funktionen einzurichten und zu pflegen, was die (Neu-)Erstellung durch Infrastructure as Code erleichtert. Wenn Sie eine Umgebung in Minuten statt in Wochen aufsetzen können, können Sie viel schneller vorankommen. Die Art und Weise, wie die Arbeit verteilt wird, muss auf die Zusammensetzung der Teams abgestimmt sein. Sie sollte dem Team genügend Freiraum geben, um die beste Lösung für ein funktionales Problem zu finden, anstatt detaillierte Anweisungen von einem Architekten in einem Elfenbeinturm weit weg vom Team zu erstellen. Der Schwerpunkt sollte auch auf den Gesamtbetriebskosten liegen und nicht nur auf dem direkten Kundennutzen. Der kurzfristige Fokus auf den Kundennutzen erhöht oft die technischen Schulden, weil Abkürzungen verwendet werden, um die Anforderungen der Stakeholder erfüllen zu können.

All diese Faktoren erfordern Teams von Menschen, die bereit sind, Risiken einzugehen und unternehmerisch zu denken. Ohne diese Menschen ist ein Scheitern von DevOps fast garantiert. Diese Denkweise ist nur vorhanden, wenn die Unternehmenskultur dies zulässt. Martijn und René haben einen weiteren Artikel über die DevOps-Mentalität geschrieben: "Growing your DevOps mindset", den Sie ebenfalls in diesem Magazin finden können.

Fazit

Die Einführung von DevOps ist nicht einfach, vor allem in großen Unternehmen mit einer großen bestehenden IT-Landschaft. Wenn Sie den Übergang zu DevOps erfolgreich gestalten wollen, sollten Sie die vier Dimensionen im Auge behalten: Menschen, Arbeit, Architektur und Infrastruktur. Denken Sie daran, mit kleinen Experimenten zu beginnen und einen Prozess zu wählen, der sich auf mehr als ein bestehendes Team auswirkt: Verwandeln Sie die derzeitigen Schichten in Ihrer horizontalen Organisation in flexiblere, vertikal aufgestellte Teams, die funktionsübergreifend sind und einen durchgängigen Geschäftswert liefern können.

Experimentieren, scheitern, neu beginnen. Das sollte die Denkweise in einer DevOps-Organisation sein. Wenn Sie sich darauf konzentrieren, gemeinsam Werte zu schaffen und Ihre Mitarbeiter zu dieser DevOps-Mentalität befähigen, werden sie Großes erreichen.

Lernen Sie mit unserem DevOps Bootcamp, wie Sie DevOps richtig einsetzen, basierend auf exklusiven Erfahrungen anstelle von Lehrbuchbeispielen, und beschleunigen Sie Ihre DevOps-Einführung mit unserem DevOps Bootcamp.