In unserem Blog-Post „DevOps: Niemand hat die Absicht eine Wall of Confusion zu errichten“ haben wir beschrieben, was alles schiefgehen kann, obwohl man vermeintlich nach DevOps-Prinzipien arbeitet. Probleme können sich in unterschiedlichen Symptomen zeigen. Angefangen bei einer längeren Zeit, die benötigt wird, um neue Entwicklungen in Produktion und somit einen tatsächlichen Mehrwert für den Kunden zu bringen. Bis hin zu einem Dev- und einem Ops-Team, die einander mit Anschuldigungen konfrontieren und einer Systemlandschaft, die nur noch geflickt und nicht mehr weiterentwickelt wird.
In diesem Blog-Post wollen wir beschreiben, an welchen größeren Stellschrauben gedreht werden kann, um eine erfolgreiche DevOps-Kultur zu etablieren.
Teile und herrsche … oder lieber doch nicht?
Nun ja, wie alle, die schon mal etwas mit Software-Entwicklung zu tun hatten, wissen, fällt Software nicht einfach vom Himmel (zumindest noch nicht 😉), sondern sie wird von Menschen entwickelt und genau bei diesen müssen wir natürlich auch ansetzen.
Das Wichtigste ist die Kommunikation zwischen den Personen, die die Software entwickeln, und denjenigen, die sie in Betrieb nehmen müssen. Das bedeutet, dass jeder, der mit Entwicklung und Betrieb in Kontakt kommt, möglichst auch jederzeit über alle Vorgänge und Probleme im Bilde sein sollte und diese bei seiner Arbeit berücksichtigt.
Aber dann müssen sich ja beide Teams mindestens täglich abstimmen? – Genau! Aber lasst uns doch diese unnötige organisatorische Hürde entfernen und aus beiden Teams wieder ein Team machen, sodass jedes Teammitglied automatisch die gleichen Meetings durchläuft und alle ein gemeinsames Verständnis davon haben, was das Problem und was der Plan ist.
Spielen wieder alle in einem Team, ist es auch wieder die gemeinsame Verantwortung, dass die Software stabil läuft und die Entwicklung ihren ganz entscheidenden Teil dazu beiträgt.
Mit Workarounds in den Teufelskreis
Das können wir nicht machen! Wir können unsere Entwickler nicht mit Betriebsthemen stören, während sie den nächsten Game-Changer implementieren. – Eh … doch. Denn was nützt der nächste Game-Changer, wenn er aufgrund von anderen Problemen niemals oder erst verspätet in Betrieb kommt?
Probleme, welche den Betrieb und zumeist auch die Entwicklung blockieren, bezeichnet man als “technischen Schulden”. Werden technische Schulden nicht zeitnah beglichen, indem man die Probleme behebt, führt dies in aller Regel schnell dazu, dass „Workarounds“ gebaut werden. Workarounds erhöhen die Komplexität eines jeden Software-Projektes, aber auch einer jeden Systemlandschaft, da sie spezifisches Wissen über das System beinhalten und sich das System plötzlich nicht mehr so verhält, wie der User es erwarten würde. Durch jeden Workaround entstehen neue technische Schulden, was zu einem Teufelskreis führt, aus dem man immer schwerer ausbrechen kann.
Licht am Ende des DevOps-Tunnels
Doch dann – ein Lichtblick. Durch die Zusammenführung der Teams haben die Mitarbeitenden, die zuvor im Betriebsteam waren, die Erlaubnis und hoffentlich auch die Motivation erhalten, aktiv am Code des Systems mitzuwirken. Somit gibt es nun immerhin ein paar Teammitglieder, die sich den Betriebsthemen auf Entwicklungs-Seite annehmen können. Sie sind zu tatsächlichen DevOps-Engineers geworden, da sie den Betrieb und die Entwicklung eines Systems verinnerlicht haben und fortan beide Seiten bedenken. Sie planen, bauen, testen, deployen und monitoren ihre Änderungen und basierend auf ihren Erfahrungen, die sie im letzten Zyklus gesammelt haben, können sie wieder in die nächste Planungsphase einsteigen und von Neuem beginnen.
Ziel sollte es nun sein, dass alle im Team interdisziplinär und gleichermaßen dafür verantwortlich sind, dass neue Features entwickelt, Bugs behoben und die Änderungen, die sie vorgenommen haben, auch in den laufenden Betrieb überführt werden.
Gelingt dies, folgen alle Teammitglieder dem DevOps-Leitmotiv: „You build it, you run it!“
Natürlich ist in diesem Beispiel bei vielen Punkten der Teufel an die Wand gemalt, aber wir sind sicher, dass sich viele Developer (für Dev und Ops) schon einmal in einer vergleichbaren Situation wiedergefunden haben. Wir selbst ertappen uns auch hin und wieder in Situationen, bei denen wir genau entgegen dieser DevOps-Philosophie handeln. Wichtig dabei ist, dass man sich selbst reflektiert und die ein oder andere Entscheidung ggf. nochmal korrigiert.
Für uns hat DevOps in erster Linie also gar nichts mit irgendwelchen Tools wie CI/CD-Pipelines oder dergleichen zu tun. Für uns geht es darum, dass jedes Teammitglied das Mindset entwickelt, dass die entwickelten Features auch durch sie oder ihn ausgerollt werden, der Betrieb bewertet und die Erfahrungen in die nächste Planung einbezogen werden können.
Unterstützende Techniken
Im Gegensatz zur Entwicklung neuer Features kann das regelmäßige deployen einer neuen Version natürlich sehr schnell äußerst eintönig werden. Super, monotone Aufgaben lassen sich hervorragend automatisieren, z.B. durch eine lebendige CI/CD-Pipeline. Das erspart ggf. Fehler beim manuellen Ausrollen und natürlich auch jede Menge Zeit, sodass sich das Team wieder verstärkt auf andere Bereiche, wie z.B. die Entwicklung eines Systems konzentrieren kann.
Durch eine entsprechende Automatisierung wird das Vorgehen im Team standardisiert und der Projekt-Fortschritt für alle beteiligen Entwickler, aber auch für Projektmanager und Kunden transparenter. Dinge wie eine CI/CD-Pipeline fördern also den DevOps-Zyklus, aber man macht nicht automatisch „DevOps“ nur weil man eine CI/CD-Pipeline aufgebaut hat.
Zusammengefasst möchten wir also die folgenden Tipps mit an die Hand geben:
- DevOps ist in erster Linie eine Arbeitseinstellung
- die Entwicklung einer Software und der Betrieb stehen in Symbiose zueinander und sollten disziplinarisch und kulturell nicht getrennt werde (z.B. durch zwei Teams)
- Methoden wie CI/CD-Pipelines oder ein funktionierendes Release-Management fördern die DevOps-Kultur da sie automatisierte Standards für die Arbeitsweise definieren, führen aber nicht zwangsläufig dazu, dass man DevOps macht
- nicht nur die Entwicklung einer Software, sondern auch die Entwicklung eines automatisierten Betriebs macht Spaß
Wir hoffen, wir konnten mit diesem Blog-Beitrag unsere Sicht auf das schon etwas in die Jahre gekommene, aber immer noch aktuelle Thema DevOps darstellen.
