Lücken schließen: Die Bedeutung der DevOps-Kommunikation

Auch wenn uns die DevOps-Methodik schon seit geraumer Zeit begleitet, ist sie immer noch das Zentrum hitziger Diskussionen. Unternehmen wollen es, wissen aber nicht, wie sie es angehen sollen.

DevOps ist überall. Und obwohl es ein interessanter Trend ist, sollte er an Produkte angepasst werden, nicht umgekehrt.

Aber manche Leute sehen das nicht so. Mir werden oft Fragen gestellt wie: „Denkst du, wir sollten mit Docker beginnen oder direkt zu Kubernetes springen?“ Solche Fragen sind bedeutungslos, ohne überhaupt zu wissen, worum es bei dem Produkt geht.

All diese ausgefallenen Begriffe – Cloud, Kubernetes, Container, Konfigurationsmanagement, Infrastructure-as-Code – versprechen einige Verbesserungen. Aber sie sind für DevOps genauso wichtig wie Teleskope für die Astronomie. Sie können nützlich sein, sind aber nicht notwendig.

Im Kern zielt DevOps darauf ab, die Lücke zwischen dem, was der Kunde bestellt hat, und dem, was das Entwicklungsteam geliefert hat, zu schließen. Der Schwerpunkt liegt auf kurzen Release-Zyklen, einem iterativen Designansatz und der Automatisierung sich wiederholender Schritte. Was ist Ihrer Meinung nach am wichtigsten, um diese Wirklichkeit werden zu lassen?

Wenn Sie „großartige Kommunikation“ gesagt haben, haben Sie Recht. Die Werkzeuge sind alle in Ordnung. Aber sie sind das investierte Geld nur wert, wenn sie die Kommunikation verbessern.

Ein Aspekt der Kommunikation besteht darin, zu wissen, was notwendig ist, um die Arbeit zu erledigen. Und der Job bedeutet nicht, dass „Code an das Repository übergeben wird“. Betrachten Sie es eher als „der Kunde hat die Änderung in der Produktion gesehen und akzeptiert“.

Sobald dieser erste Schritt feststeht und jeder weiß, was passieren muss, ist der beste Zeitpunkt, ihn aufzuschreiben. Woher? Nun, ich bin ein großer Befürworter der Pflege einer README.md . Jede Person in einem Team kann jederzeit einen Blick darauf werfen und den Status eines Projekts einsehen, und es ist eine natürliche Anlaufstelle für Projektneulinge.

Die Automatisierung, der nächste Schritt nach dem Schreiben einer README-Datei, ist optional. Es ist jedoch ein natürliches Ergebnis der Dokumentation des Prozesses. Und ja, Automatisierung ist das, was einem oft in den Sinn kommt, wenn man an DevOps denkt.

Moment mal … Automatisierung ist optional, wenn es um DevOps geht? Ist DevOps nicht die Abteilung der Person, die Bereitstellungen durchführt?

Unter dem Begriff „DevOps Engineer“ verstehen die Leute normalerweise entweder einen Software Reliability Engineer, einen Platform Engineer oder einen Operations Automation Engineer. Dies sind alles gültige Rollen, die das Praktizieren von DevOps ermöglichen, aber die Verwendung des Sammelbegriffs „DevOps-Ingenieur“ ist möglicherweise etwas zweideutig.

Werfen wir also einen genaueren Blick auf DevOps selbst.

DevOps erklärt

Lassen Sie mich Ihnen zunächst zeigen, was DevOps nicht ist:

1. Es ist nicht nur ein Job-Titel-Präfix
2. Es ist kein Team (aber „Dev“ und „Ops“ sind es)
3. Es ist keine Technologie
4. Es bedeutet nicht „ein Systemadministrator, der programmieren kann“
5. Es bedeutet nicht „Zeug automatisieren“
6. Es bedeutet nicht „es gibt jetzt kein Betriebsteam“

Wenn Sie dies wissen, wissen Sie jetzt, dass Sie in einem Unternehmen nicht einfach „einen DevOps-Ingenieur einstellen“ oder „ein DevOps-Team aufbauen“ können, um sicherzustellen, dass Sie zukunftssicher sind. DevOps ist mit der agilen Entwicklung verwandt. Würden Sie als solchen einen Agile-Entwickler einstellen? Wahrscheinlich nicht. Entweder Sie entwickeln Produkte agil oder nicht.

Wie lässt sich DevOps also beschreiben? Es ist eine Methodik. Oder vielleicht eine Kultur. Vielleicht sogar ein Geist. Ein Produkt nach DevOps-Prinzipien zu entwickeln bedeutet, dass jeder – sei es Entwickler, Betriebsingenieur oder Produktmanager – eine gemeinsame Vision teilt und diese durch Kommunikation aufrechterhält. In geringerem Maße bedeutet dies auch, dass alle die gleichen Tools verwenden. Diese Tools sind nicht dazu gedacht, einer einzelnen Gruppe von Menschen zu helfen. Sie sollen das Produkt vorantreiben.

Die Umsetzung dieses Konzepts erfordert eine ernsthafte Änderung der Denkweise, die das Haupthindernis darstellt. Warum ist das so? Das liegt daran, dass die Menschen ihre Komfortzone verlassen und anfangen müssen, mit Menschen zusammenzuarbeiten, die andere Kompetenzen haben. Entwickler müssen plötzlich lernen, wie die Cloud funktioniert, und anfangen, ihren eigenen Code bereitzustellen. Das Betriebspersonal muss manuelle Einstellungen aufgeben und mit dem Codieren beginnen. Jeder muss neue Konzepte lernen. Jeder hat neue Aufgaben .

Das ist nicht einfach, aber mit guter Kommunikation und einem gemeinsamen Ziel durchaus machbar. Diese Kommunikation beinhaltet die Etablierung einer Kultur, die Einrichtung einfacher Prozesse und die Aufrechterhaltung einer ordnungsgemäßen Dokumentation.

DevOps-Automatisierung ist Dokumentation

So hast du wahrscheinlich nie darüber nachgedacht. Aber die meisten Tools, die üblicherweise mit DevOps in Verbindung gebracht werden, sind Dokumentationstools :

• Zur Lesbarkeit geschriebene Build-Skripte dienen der Dokumentation des Build-Prozesses
• Kontinuierliche Integrationspipelines dokumentieren den Integrationsprozess, von der Erstellung einzelner Teile bis hin zu einem vollständigen Produkt
• Kontinuierliche Bereitstellungspipelines gehen noch weiter, indem sie dokumentieren, wie ein Produkt bereitgestellt wird, das Ihr Kunde verwenden kann
• Konfigurationsverwaltungsdateien dokumentieren den Prozess der Installation und Konfiguration
• Infrastructure-as-Code-Spezifikationen dokumentieren die notwendige Infrastruktur (eigentlich ganz formell!)
• Container werden mit ihren eigenen Dockerfile , die dokumentieren, wie ein bestimmter Microservice erstellt und konfiguriert wird

All diese ausgefallenen Konzepte bewirken im Wesentlichen eines: Sie helfen den Teammitgliedern, besser zu kommunizieren, indem sie Prozesse dokumentieren. Diese Prozesse können dann manuell ausgeführt oder automatisiert werden. Wichtig ist, dass jeder Projektbeteiligte ihnen folgen kann.

Die Dokumentation Ihrer Prozesse als Code hat einen großen Vorteil gegenüber herkömmlichen Bedienungsanleitungen. Code kann verifiziert werden und verhält sich vorausschauend. Bei gleicher Eingabe erzeugt es die gleiche Ausgabe.

Mit schriftlichen Anweisungen haben Sie so viele Interpretationen, wie es Leser gibt. Wenn Sie eine mehrdeutige oder vage Dokumentation schreiben, wird die Person, die sie liest, die Lücken füllen. Der Punkt ist, dass Sie keine Kontrolle darüber haben, was in die Lücken kommt.

Mit Code ist es viel einfacher. Ohne konkrete Schritte wird das Programm eingestellt. Diese konkreten Schritte sind ein wesentlicher Aspekt der DevOps-Kommunikation.

DevOps-Kommunikation: Der einzige Weg, die Lücke zwischen Entwicklung und Betrieb zu schließen

In dem Buch The Phoenix Project werden wir Zeuge der Probleme eines kürzlich beförderten Managers, der mit der Umsetzung eines großen Projekts beauftragt wurde. Da niemand weiß, was passiert, bekämpfen alle Brände ohne große Fortschritte. Der Untertitel des Buches erwähnt, dass es sich um eine Geschichte von DevOps handelt. Ich stimme dem zu.

Interessant ist jedoch, dass im Laufe des Buches kein einziges neues Tool eingeführt wird. Können Sie einen Zustand von DevOps erreichen, indem Sie allein die Kommunikation verbessern? Die Protagonisten des Buches haben es geschafft, also gibt es auch für Sie Hoffnung!

Auch wenn der Ansatz der Protagonisten als „old school“ bezeichnet werden kann (mit echten Papierkarten anstelle eines richtigen Fehlerverfolgungssystems), ändern sich die Dinge zum Besseren, wenn alle Beteiligten beginnen, miteinander zu sprechen.

Sie denken vielleicht, dass es nur möglich ist, die Zusammenarbeit zwischen Entwicklung und Betrieb zu verbessern, indem man bessere Schnittstellen zwischen ihnen schafft, wie z. B. Service Level Agreements oder Incident Backlogs. Aber das Gegenteil ist wahr. Indem Sie die Schnittstellen abreißen und Empathie und eine gemeinsame Sache einführen, haben Sie ein Team, das auf ein gemeinsames Ziel hinarbeitet.

DevOps-Teamstruktur: Wer gehört zu einem Team?

Idealerweise sollte jedes Produkt nur ein Team haben: das Produktteam.

Ich war einmal in einem Entwicklungsteam, wo es kein gemeinsames Ziel mit anderen Teams gab. Das Entwicklungsteam wollte so viele Änderungen wie möglich vorantreiben. Das Validierungsteam hatte die Aufgabe, die Einführung von Fehlern zu verhindern. Sie hatten unterschiedliche Manager und wurden einzeln bewertet.

Das Ergebnis? Entwicklung und Validierung spielten Ping-Pong mit Fehlerberichten. Als die Validierung einen Test fand, der nicht bestanden wurde, war die Entwicklung mehr daran interessiert, Fehler im Testcode selbst zu finden, als zu versuchen, ihren eigenen Code frei von Fehlern zu machen.

Der Veröffentlichungszyklus blähte sich natürlich auf, da ein enormer Overhead erforderlich war, um die Berichte, die Gegenberichte usw. ordnungsgemäß auszufüllen. Was die meisten nicht zu erkennen schienen, war, dass beide Teams in Bezug auf das Produkt ein gemeinsames Ziel haben und zusammenarbeiten sollten, um es zu erreichen. Aber der Mangel an angemessener Zusammenarbeit und Silo-Mentalität machte es sehr schwer, es zu bemerken.

Der Kampf gegen Verschwendung ist eine gemeinsame Anstrengung

Bei der Lean-Production-Mentalität, die das Manifest für agile Softwareentwicklung inspirierte (das uns wiederum mit DevOps bekannt machte), ging es um die Bekämpfung von Verschwendung. Unter Verschwendung verstehen wir alles, was nicht direkt mit der Bestellung des Kunden zusammenhängt. Aufgehäuftes Work-in-Progress ist Verschwendung. Jeder Prozessschritt, der nicht eindeutig zu einer Freigabe führt, ist Verschwendung.

Verschwendung sieht man aber nur von oben. Im Rahmen eines Teams können einige Verfahren wesentlich erscheinen. Aus Produktsicht können sie jedoch durchaus nutzlos sein.

Um herauszufinden, welche Bemühungen verschwendet werden, müssen Sie Ihre Kräfte bündeln und den Lebenszyklus eines versendeten Produkts berücksichtigen. Sie müssen auch aus der Perspektive des Kunden denken. Ist diese Funktion etwas, was der Kunde wollte? Wenn nicht, können Sie es jetzt auch überspringen. Sind Ihre Prozesse einfach und schlank? Werfen Sie einen genaueren Blick auf diejenigen, die Teamgrenzen überschreiten.

Möchten Sie sicherstellen, dass die Entwicklung eines Produkts so effizient wie möglich ist? Laden Sie einen Außenstehenden ein, um zu sehen, wie Sie arbeiten. Eine Person, die nicht zu Ihrem Team gehört, kann aufschlussreiche Fragen stellen und neue Verbesserungsmöglichkeiten erkennen.

DevOps-Prinzipien: Ruhe bewahren

CALMS ist eine sehr genaue Beschreibung, wie man DevOps praktizieren sollte:

• Kultur
• Automatisierung
• Schlank
• M essung
• Teilen

Beachten Sie, dass es wie ein Sandwich geformt ist. Die drei mittleren Werte sind eher technisch, die äußeren beziehen sich auf Soft Skills. Aber die Basis jeder Kultur ist Kommunikation: Wir tauschen unsere Werte und Überzeugungen mit anderen Teammitgliedern aus, bis wir einen Konsens darüber erzielen, wie sich die Dinge verhalten sollen.

Gleiches gilt für das Teilen. Etwas Grundlegendes wie Essen zu teilen, erfordert keine Kommunikation. Die Geste selbst kann aber auch als Akt der Kommunikation gesehen werden. „Ich sorge mich um dich, also teile ich mit dir.“ Wir wollen den Anwendungsbereich nicht nur auf die verbale Kommunikation beschränken.

Der Austausch von Ideen und Tools erfordert jedoch Kommunikation. Wie sollen wir sie teilen? Wo sollen wir sie hinstellen? Sind sie für jede Person in einem Team oder nur für eine kleinere Gruppe nützlich?

Wenn Sie sich nur auf die eher technischen Aspekte – Automatisierung, Lean und Messung – konzentrieren, verfehlen Sie den Sinn von DevOps. Was ist so gut daran, ein automatisiertes Bereitstellungsskript zu haben, das niemand außer dem Autor verwendet? Wenn das Drehbuch ihr etwas Zeit spart, dann könnte es gerechtfertigt sein. Aber stellen Sie sich vor, wie viel Zeit gespart werden könnte, wenn alle dieses Skript teilen würden. Das sagt etwas über die Bekämpfung von Verschwendung aus!

DevOps bringt Unternehmen näher an die Entwicklung heran

Einige sagen, dass DevOps den Betrieb näher an die Entwicklung bringt. Das ist wahr, aber es ist nicht die ganze Wahrheit. Wenn es richtig gemacht wird, bringt DevOps jede Einheit näher zusammen. Es ermöglicht Unternehmen und Kunden fast in Echtzeit zu sehen, was die Entwicklung tut.

Diese kürzere Feedback-Schleife kommt allen Beteiligten zugute. Die Arbeit ist im Allgemeinen besser sichtbar, und auch Entwickler können leicht sehen, wie Kunden den von ihnen erstellten Code verwenden. Bei der herkömmlichen Bereitstellung können Sie mehrere Monate warten, bis jemand Fehler oder fehlende Anforderungen bemerkt. Mit Continuous Deployment kann jeder auf auftretende Probleme reagieren. Entwickler, Betrieb, Unternehmen und Kunden können in einem Raum sitzen und die funktionierende Anwendung an die aktuellen Anforderungen anpassen.

DevOps-Tools zuerst? Denk nochmal

Natürlich sind alle Tools erforderlich, um dies zu ermöglichen.

Aber keine Menge Tools kann eine gute Kommunikation und Empathie im Unternehmen ersetzen. Ich habe einmal ein Produkt beobachtet, bei dem der Build-Prozess einem Team gehörte, während der bereitgestellte Code einem anderen gehörte.

Probleme mit dem Build-System waren häufig. Die Entwickler waren sich nicht sicher, wie sie es verwenden sollten. Es basierte auf Standardwerkzeugen, die jedoch so angepasst wurden, dass sich jede im Internet verfügbare Dokumentation als nutzlos erwies.

Alle wollten die Situation verbessern, aber es gab kein Verständnis zwischen den beiden Teams. Das bedeutete, dass beide Seiten neue Tools einführten, ohne sich mit der anderen Seite abzustimmen. Dadurch vergrößerte sich die Lücke nur, anstatt sie zu schließen.

Wenn Sie eine DevOps-Transformation in Ihrem Unternehmen einleiten möchten, beginnen Sie damit, die Art und Weise, wie Sie kommunizieren, zu verbessern. Gehen Sie nicht einfach von einer Lösung aus: Brainstormen Sie zuerst unvoreingenommen . Dann stellen Sie möglicherweise fest, dass beispielsweise die Werkzeugunterstützung für Ihre Anforderungen nicht ausreicht. An diesem Punkt können Sie erwägen, Ihre aktuellen Tools zu optimieren oder einige neue einzuführen – andernfalls werden Sie wahrscheinlich zum ursprünglichen Problem beitragen.

Der schnellste Weg zur Einrichtung von DevOps? Bessere Kommunikation!

In der Einleitung erwähnte ich die Frage, die mir Kunden oft stellen: „Soll ich mit Docker gehen oder sollte ich direkt zu Kubernetes springen?“ Nachdem Sie diesen Artikel gelesen haben, können Sie sehen, dass eine solche Frage am besten beantwortet wird, nachdem Sie einige Vorbereitungen getroffen haben – mit einer DevOps-Mentalität.

Wenn Sie wissen, dass Ihr Produktteam die Vorteile von DevOps für sich und den Kunden versteht, können das Team und der Kunde damit beginnen, ihre Erwartungen festzulegen. Dann können Ingenieure das Entwicklungs- und Bereitstellungsmodell erarbeiten. Schließlich können Sie bestimmen, welche Werkzeuge benötigt werden.

Sobald alle Anforderungen dokumentiert sind, lassen sich Technologieentscheidungen viel einfacher treffen.

Ich bin ein Verfechter all der großartigen DevOps-Automatisierungstools, die unsere Arbeit einfacher und überschaubarer machen. Aber unsere tägliche Arbeit ist die Arbeit mit Menschen . Lassen Sie uns etwas Zeit investieren, um diesen Aspekt der Best Practices von DevOps zu verbessern, anstatt ein weiteres Technologiezertifikat zu erwerben.