03.02.2020

„Der Antrieb eines Informatikers ist seine Faulheit“

Ein Gespräch mit Lienhart Woitok, DevOps Engineer und Softwareentwickler bei netlogix Web Solutions, über Automatisierung, DevOps und die Faulheit der Informatiker

Worum geht es beim Thema Automatisierung aus deiner Sicht?

Automatisierung ist kein reines DevOps-Thema, jede IT-Abteilung hat Sachen, die sie automatisieren möchte. Entweder, weil man es nicht manuell machen will, weil dabei zu viele Fehler passieren oder es einfach enorm zeitintensiv ist. Der Knackpunkt ist festzulegen, wie weit die Automatisierung gehen soll und wie viel Zeit und Aufwand man dafür aufwenden kann. Wenn man sich das überlegt hat, bleibt die Frage: Wie fange ich an?

Nach welchen Kriterien entscheidet man, ob sich eine Automatisierung lohnt?

Es gibt verschiedene Fragestellungen, die bei der Entscheidung unterstützen können, ob und wie weit Aufgaben automatisiert werden sollten.

1. Wer muss es ausführen? Beispielsweise benötigt die Buchhaltung, um Rechnungen zu schreiben, die Verbrauchsdaten von verschiedenen Hostingsystemen. Dazu müssen die Kollegen auf Quellen zugreifen, mit denen sie sonst nicht arbeiten. Hier steckt also Potenzial für eine Automatisierung, um fachfremde Abteilungen nicht auf Produktivsysteme autorisieren zu müssen und ihnen gleichzeitig ein flexibles Arbeiten mit den Daten zu ermöglichen.

2. Wie oft wird etwas ausgeführt? Es lohnt sich meist nicht, viel Zeit für eine Automatisierung zu investieren, die einmal im Jahr eine halbe Stunde Zeit kostet. Oft hilft hierfür jedoch eine Anleitung als erster Schritt in Richtung Automatisierung, da man sich möglicherweise nicht mehr an alle Schritte erinnert. Wenn man  etwas täglich ausführt, lohnt es sich natürlich, da die Zeitersparnis enorm ist und der Prozess auch bei Urlaub und Krankheit gesichert ist.

3. Wie hoch ist die Zuverlässigkeit? Wird eine komplexe Aufgabe von Hand erledigt, passieren gelegentliche Fehler, auch nach einer vorgeschalteten Kontrolle durch eine zweite Person. Allerdings muss man einem automatisierten Prozess blind vertrauen, weil man nicht weiß, wie das Ergebnis letztlich zustande gekommen ist. Wenn man etwas manuell ausführt, sieht man möglicherweise anhand merkwürdiger Zwischenergebnisse bereits vorab, dass etwas nicht stimmt.

4. Um welche Anwendung handelt es sich? Manche Anwendungen lassen sich nicht automatisieren, andere stellen Schnittstellen und Plug-ins bereit, die Automatisierungsaufgaben relativ einfach machen.

5. Wie komplex ist der zu automatisierende Prozess? Hier spielt die Zuverlässigkeit wieder eine Rolle. Bei einer komplexen Aufgabe, die von Hand sehr fehleranfällig ist, lohnt sich schon deswegen die Automatisierung. Es ist aber in aller Regel auch sehr komplex, die Automatisierung für eine komplexe Aufgabe technisch bereitzustellen.

6. Wie viel Zeit wird für die Umsetzung benötigt? Welche Ressourcen werden zum einen für die Ausführung und zum anderen für die Programmierung der Automatisierung sowie deren Anpassung an neue Gegebenheiten benötigt?. Es ist ja meistens nicht so, dass man eine Automatisierung verwendet und dann wird diese die nächsten zehn Jahre ohne Änderung verwendet, sondern es kommen neue Anforderungen, Softwareupdates usw. dazu.

Grundsätzlich gilt auch: Es gibt keine feste Musterlösung zur Bewertung von Automatisierungsvorhaben. Jede einzelne Aufgabe muss individuell betrachtet werden.

Wie geht man mit diesen Kriterien anschließend in die Planung der Automatisierungs-Tasks?

Wenn die Auswahl der zu automatisierenden Aufgaben getroffen ist, muss die Reihenfolge festgelegt werden. Um die geplanten Tasks zu priorisieren, kann eine sogenannte Complexity-Value-Matrix genutzt werden. So erhält man eine grobe Übersicht, wie komplex die Automatisierung jeweils ist und welchen Nutzen sie stiftet.

Anhand dieser Einteilung kann eine erste Priorisierung erfolgen, definiert werden, was als zweiter Schritt sinnvoll ist, und es können ggf. auch Tasks gestrichen werden - auch das ist am Ende übrigens ein Ergebnis. Eine absolute Reihenfolge aufzustellen, ist in meinen Augen nicht sinnvoll.

Wie arbeitet man am besten mit der Complexity-Value-Matrix?

Idealerweise findet die erste Einteilung als Workshop statt. Jeder potenzielle Automatisierungs-Task bekommt einen Zettel und diese werden in der Matrix einsortiert. Bei jedem Zettel muss man sich überlegen, wie komplex die Aufgabe ist und wie viel sie bringt, und so die einzelnen Aufgaben anordnen.

Dadurch ergibt sich automatisch die Priorisierung anhand der vier Quadranten: Unten rechts stehen alle Aufgaben, die hohes Potenzial aufweisen und einfach umzusetzen sind, damit kann man direkt anfangen. Die Aufgaben oben rechts bringen zwar viel, sind aber komplexer. Daraus lohnt es sich Projekte zu machen, auch wenn der Aufwand höher ist. Unten links sind Aufgaben, die im Vergleich weniger Impact haben. Deshalb sind sie nicht per se sinnlos, aber haben meist auch nicht oberste Priorität. Oben links sind die undankbaren Aufgaben, die relativ viel Aufwand benötigen und verhältnismäßig wenig bringen, die werden vermutlich nicht weiterverfolgt.

Hat diese Methode auch Nachteile?

Die Einordnung ist nichts Dauerhaftes. Nach einer Weile haben sich die Voraussetzungen geändert, es ergeben sich andere Anforderungen. So kann es durchaus sein, dass Aufgaben, die vorher komplex waren, inzwischen einfacher geworden sind, andere sind wichtiger geworden (oder auch unwichtiger) und man muss seine Einteilung und Entscheidungen überdenken. Wichtig ist zu verstehen, dass manche Aufgaben auch mit weniger Impact nicht komplett sinnlos sind, nur weil sie gerade keine Priorität im Vergleich zu anderen Tasks haben. Die Skala ist nicht absolut, sondern hat ihre Bedeutung durch die relative Position zueinander.

Um wie hängen Automatisierung und DevOps nun zusammen?

Der Begriff DevOps setzt sich aus den Wörtern Dev und Op zusammen, also aus Developer und Operator. DevOps ist somit die erfolgreiche Zusammenführung dieser beiden Welten: auf der einen Seite der Serverbetreuer, der sich auf einem Server einloggt und ihn konfiguriert, auf der anderen Seite der Entwickler, der Code schreibt, in die Versionskontrolle eincheckt und seine Tests laufen lässt. DevOps ist der Versuch, die Prinzipien aus der Entwicklung wie Versionierung und Test von Code in den Serverbetrieb zu übernehmen. Das führt ganz automatisch dazu, den Serverbetrieb zu automatisieren.

„Ohne Automatisierung würden wir gnadenlos scheitern“

Wie wirkt sich Automatisierung in deiner täglichen DevOps-Arbeit aus?

Einen Server von Hand vollständig zu konfigurieren, dauert einige Stunden, während die Automatisierung in 15 bis 20 Minuten durchläuft. So kann ich beispielsweise vier Server in einer Stunde konfigurieren, für die ich ansonsten zwei Tage bräuchte. Das ist aus meiner Sicht der einzig sinnvolle Weg. Es spart nicht nur Zeit beim Aufsetzen von Servern, sondern bringt auch eine erhöhte Zuverlässigkeit. Loggt man sich auf jedem Webserver ein und konfiguriert von Hand, macht man beim dritten eventuell schon etwas anders, weil es notwendig ist oder optimiert werden kann. Und nach kurzer Zeit hat man dann Server, die alle unterschiedlich sind.

Welche Probleme entstehen durch die unterschiedlichen Server?

Wenn ich eine Konfigurationsänderung auf alle Server anwenden will, funktioniert es bei dreien und bei einem nicht, weil etwas anders ist. Das findet man dann meist nur schwer auf Anhieb heraus oder man erinnert sich nicht mehr sofort daran.

Bei der Automatisierung ist das Setup der Server überall gleich, sie haben keine historisch entstandenen Unterschiede in den Grundkonfigurationseinstellungen. Dank der Automatisierung kann ich mich nach zwei Jahren für ein Update auf einem Server einloggen und mir sicher sein, dass das, was auf dem einen funktioniert, auch auf dem nächsten funktioniert - bis auf die Fälle, wo bewusst Konfigurationsunterschiede eine Rolle spielen. Die sind dann aber dokumentiert.

Self-Service durch Automatisierung

In welchen Bereichen setzt ihr Automatisierung ein?

Alle Server, die wir in den letzten Jahren in Betrieb genommen haben, wurden automatisiert aufgesetzt. In der Entwicklung haben wir außerdem viele sinnvolle Automatisierungen im Bereich Deployment im Einsatz. Neben automatisierten Tests kann sich ein Entwickler z.B. automatisiert Daten von der Webseite holen, ohne sich auf dem Server einloggen zu müssen. Die Automatisierung der Liveserver können wir auch für die Entwicklungsserver nutzen. Das geht so weit, dass sich ein Entwickler seine Entwicklungsumgebung selbst aufbauen kann, ohne Unterstützung aus dem DevOps-Team zu benötigen.

Was bringt Automatisierung für deine Abteilung und die einzelnen Kollegen?

Wir ermöglichen durch die Automatisierung ganz viel Self Service. Außerdem passieren keine Überraschungen wie „works on my machine“ – es funktioniert beim Entwickler, aber auf dem Liveserver nicht - da wir die Entwicklungs- und Liveserver automatisiert mit dem gleichen Code aufbauen. Unsere Entwickler können sich alle Daten holen, die sie für ihre Arbeit benötigen, und sie können geänderten Code wieder auf die Liveserver aufspielen.

Betrachtet man außerdem unseren Code als Dokumentation, wird die „Dokumentation“ ja über die Automatisierung geändert. Es kommt natürlich mal vor, dass Code von Hand geändert wird, wenn es brennt, aber das muss nachgezogen werden, weil die Änderungen sonst beim nächsten Ausführen der Automatisierung verschwinden. So gesehen zwingt uns Automatisierung auch dazu, immer diesen Weg zu gehen, und wir haben eine stetige Dokumentation der Coding-Arbeit.

Auch in Zukunft unverzichtbar

Wie wichtig schätzt du das Thema Automatisierung für die Zukunft ein?

Durch Automatisierung erreicht man eine wesentlich höhere Grundstabilität der Arbeit und erhöht die Zuverlässigkeit im Betrieb von Servern, da diese einheitlicher sind und ein schnelleres Arbeiten ermöglichen. Unter Beachtung der genannten Kriterien kommt eigentlich niemand an der Automatisierung bestimmter Prozesse vorbei. Und der Nutzen, den sie bringt, überwiegt auf jeden Fall die Arbeit, die man am Anfang reinstecken muss.

Lienhart Woitok
DevOps Engineer/Softwareentwickler

Unsere Blogs