DevOps

Wie ich finde eines der am meisten missverstanden Themen in der IT.

Der Begriff DevOps wurde schon 2009 auf der DevOpsDays-Konferenz in Gent etabliert. Der belgische Systemadministrator Patrick Debois erkannte, dass man durch bessere Zusammenarbeit von Dev und Ops eine fehlerfreiere und schnellere Softwareauslieferung erreicht. Seitdem gibt es verschiedene Definitionen zu DevOps und viele Prozessansätze. Eine Definition aus dem Jahr 2014 von Rob England:

Allerdings gab es DevOps schon früher, als die Unternehmen und die Teams noch klein waren und enger beieinander saßen, dort wurde automatisch DevOps betrieben. Mit der Zeit wurden die Unternehmen größer und dadurch wurden einzelne Abteilungen geschaffen und die Devs und Ops hatten kaum noch Kontaktpunkte. (Ausnahmen sind oft Spielefirmen, die immer noch als Cross-Functional-Teams arbeiten.) Auch in der Ausbildung wird kaum noch IT übergreifend unterrichtet, das muss sich wieder ändern.

Was können wir tun, um das zu ändern?

Es ist ein Wandel in der Unternehmensstruktur und -kultur notwendig, damit die Teams wieder mehr zusammenarbeiten. Die Berührungspunkte müssen wieder mehr werden:

• Softwareentwickler müssen sich wieder mehr mit der Betriebsumgebung auseinandersetzen auf denen Ihre Software später läuft, sie müssen sich mehr über Auswirkungen Ihres Handelns bezogen auf das Gesamtsystem im Klaren werden

• Systemadministratoren müssen sich mehr mit der Automatisierung des Betriebs beschäftigen, Stichwort „Infrastructure As Code“, mit Versionsverwaltung, mit Konfiguration von Anwendungen und vielleicht sogar Auswertung von log-files

Insgesamt müssen Prozesse geändert werden, Softwareentwickler und Systemadministratoren müssen mehr zusammenarbeiten, dann können wir auch DevOps gut umsetzen und somit schneller, effektiver und mit einer höheren Qualität Software entwickeln.

Es müssen cross-funcional Teams gebildet werden, die nicht nur aus Entwicklern und Testern bestehen, sondern auch aus Admins. Es ist ganz wichtig, dass auch schon in der Anforderungsphase Entwickler und Admins eng zusammenarbeiten. Besonders jetzt im digitalen Wandel, wo es immer mehr Anforderungen vom Kunden an das Gesamtsystem gibt, dass Ihre Anwendungen hochverfügbar, skalierbar, schnell sind und sehr kurze Release Zyklen haben sollen.

Diese Anforderungen können Entwickler und Admins nur gemeinsam realisieren. Man kann eine Anwendung noch so optimieren, wenn die Betriebsumgebung nicht auch optimiert ist kommt man als Entwickler schnell an seine Grenzen, genau das Gleiche auf der Betriebsseite, wenn die Software nicht optimiert ist, kommt die Betriebseite auch an Ihre Grenzen, aber zusammen können diese Grenzen noch weiter verschoben werden. Ich bin auch der Meinung, dass man 80% der Legacy Anwendungen, um 10 - 20% optimieren könnte, wenn Dev und Ops mehr zusammen gearbeitet hätten.

Die Angst, die im Management oft herrscht, dass mit Agilität und DevOps keine Regeln mehr bestehen und jeder macht was er will und man sich nicht mehr an seinen ITIL-Prozessen festhalten kann, kann ich gut verstehen, nur haben diese Manager Agilität nicht verstanden. Prozesse sollen nicht wegfallen sondern optimiert oder automatisiert werden.

DevOps, Agilität und moderne Entwicklung heißt nicht, dass man alles was man vorher gemacht hat vergisst und jeder macht was und wie er es will, sondern man muss seine Prozesse verstehen und diese dann auf die neuen Anforderungen an Continuous Integration, Continuous Delivery und Continuous Deployment anpassen. Prozesse, die wichtig sind damit ein System weiterhin gut läuft, müssen natürlich bestehen bleiben, können aber vielleicht optimiert und automatisiert werden. Dokumentieren, Freigeben, Testen, Monitoren, Loggen … ist und bleibt weiterhin wichtig, kann aber weitestgehend optimiert und automatisiert werden.

Beispiel

Ich selbst habe schon oft gemerkt, dass es so wichtig ist mit Kollegen aus dem Betrieb zu sprechen und zusammen die Anforderungen zu klären. Es gibt so viele Kleinigkeiten, die einem das Leben erleichtern, auf beiden Seiten. Zum Beispiel hat sich ein Kollege mal nebenbei beschwert, dass er im log-file immer nicht genau sieht ab wann unsere Anwendung anfängt zu loggen. Jetzt bekommt er immer eine Zeile ausgegeben, wenn unsere Anwendung gestartet ist. Das war für mich eine Kleinigkeit und für Ihn hat es enorm Zeit gespart.

Ein schönes Beispiel ist das Logging. Es ist echt ein schwieriges und komplexes Thema, wenn man es für Produktivsysteme richtig konfigurieren will. Logging führt auch immer zu Ärger im Betriebsteam. Die Entwickler loggen mit den diversen Libraries wie log4J schnell und einfach alle Informationen raus, in der Entwicklungsphase ist es auch gut und wichtig viel zu loggen. Viele vergessen dann aber, sich auch über das produktive Loogging Gedanken zu machen und es laufen im Betrieb megaweise log-Daten auf, die in der Menge gar nicht sinnvoll sind. Dem Admin platzt alle paar Tage der Speicher und er ärgert sich, weil keiner mit Ihm gesprochen hat was mit den ganzen log-files passieren soll. Würde man hier jetzt mehr miteinander sprechen und schon am Anfang eines Projektes einen Admin mit im Team haben, würde dieser zusammen mit dem Entwickler darauf achten, dass das Logging für die Produktivumgebung richtig konfiguriert wird.

Von dieser Art Beispiel gibt es noch viel mehr in der Praxis und ich bin der Meinung, durch bessere und engere Zusammenarbeit könnten viele Kosten, Nerven und Missverständnisse verringert werden.

Vorteile

Hier aus meiner Sicht die größten Vorteile einer guten Zusammenarbeit:

• Entwickler verstehen wieder warum sie auf bestimmte Sachen achten müssen
• Admins verstehen warum bestimmte Konfigurationen für die Entwickler so wichtig sind
• die Software kann besser für den Betrieb optimiert werden
• die Betriebsumgebung kann besser auf die entsprechende Software optimiert werden
• das Gesamtsystem ist stabiler
• Fehler können schneller anaysiert und behoben werden
• bessere log-Ausgaben sowohl für Entwickler als auch für Admins
• Kosten können gespart werden, da im Voraus alle Anforderungen in allen Teams klar sind und Machbarkeiten geklärt werden können
• Zunahme der Kundenzufriedenheit
• das Verständnis auf beiden Seiten nimmt kontinuierlich wieder zu und man arbeitet miteinander und nicht gegeneinander

Fazit

Meiner Meinung nach sollten Unternehmen folgende Punkte ändern, um DevOps leben zu können:

• einerseits müssen Unternehmensstrukturen (Silos) umstrukturiert/geändert werden,
• Prozesse müssen optimiert und automatisiert werden,
• das Cross-Functional-Team muss um das Betriebsteam erweitert werden,
• die Zusammenarbeit von Dev und Ops muss unterstützt und gefördert werden,
• die Mitarbeiter der Teams müssen sich regelmäßig austauschen, um voneinander zu lernen
• Tools müssen sinnvoll eingesetzt werden

Ich denke wir müssen an unserer persönlichen Einstellung arbeiten und gleichzeitig die Unternehmensstruktur und -kultur so ändern, dass damit wieder die Möglichkeit geschaffen wird, dass Dev und Ops mehr und besser zusammen arbeiten können. Ich denke die Bereitschaft ist auf beiden Seiten oft schon da, nur muss das gesamte Unternehmen (Mitarbeiter bis rauf zur Geschäftsführung) diese Einsicht auch haben, sonst wird es sehr schwer werden eine Unternehmensstrukturänderung umzusetzen.

Oft wird im Zusammenhang mit DevOps immer nur von den Tools gesprochen, dass ist meiner Meinung nach nicht der erste Schritt, den man gehen sollte, um in Richtung DevOps zu gehen. Es muss in den Köpfen, dann im Unternehmen und in der Unternehmenskultur anfangen. Natürlich braucht man auch entsprechende Tools, die uns das Leben und die Arbeit erleichtern, keine Frage. Diese Tools sind aber nicht DevOps oder nur weil man sie einsetzt macht man kein DevOps. Wer das denkt hat nichts verstanden und sollte sich dazu noch mal ein paar Artikel durchlesen. Es gibt weder DevOps-Tools, noch DevOps-Einzelpersonen, noch DevOps-Server …. DevOps ist eine Philosophie!

Bild von Patrick Debois

Ich wünschte mir oft den roten Schalter aus meiner Grundschulzeit zurück, wo die Rechner erst angeschaltet wurden wenn alle es verstanden haben. :)