Bei jedem aufwändigen Projekt steht die Frage nach der Verhältnismäßigkeit im Raum: Ist der anfängliche Arbeitsaufwand gerechtfertigt durch den Nutzen, der am Ende herauskommen soll? Diese Frage wird noch drängender, wenn schnelle, greifbare Ergebnisse nicht in Sicht sind. Oder wenn manche Stimmen im Unternehmen die generelle Sinnhaftigkeit der Investition in Frage stellen. Und je nachdem, wie die Frage beantwortet wird, fällt die Akzeptanz ganz unterschiedlich aus.

Wir kennen solche Probleme auch von uns und unseren Kunden. Sei es der Versuch einer digitalen Transformation mit SAFe und unserer Atlassian-Lösung Agile Hive. Oder sei es das Vorhaben, ein Social Intranet mit Linchpin zu etablieren, das Informationen und Zusammenarbeit auf Augenhöhe fördert. Da kommt es durchaus vor, dass die Projektteams belächelt werden. Anderen Teams wird gar mit offener Feindseligkeit begegnet. Fast jedes Projekt, das etwas bewegen und verändern will, muss Widerstände überwinden.

In diesem Artikel will ich von einem internen Projekt zur Automatisierung unserer Hosting-Prozesse erzählen. Unser Beispiel bezieht sich dabei auf die Pflege von Atlassian-Systemen. Hierbei standen wir vor einer ganz ähnlichen Herausforderung. Ich berichte auch davon, wie wir ganz operativ in der Automatisierung gearbeitet haben, um in einem Zeitraum von über anderthalb Jahren endlich an einen Punkt zu kommen, wo Automatisierung aus unseren Prozessen nicht mehr wegzudenken ist.

Geholfen haben uns dabei die Open-Source-Lösungen Bundlewrap und Automatix, die wir im Unternehmen geschaffen haben und der Community gerne zur Verfügung stellen. Also los!

Warum brauchen wir Automatisierung?

Wer eine große Anzahl an Systemen verwalten und betreiben möchte, kommt wohl kaum mehr um Automatisierungen herum. Sowohl die Infrastruktur als auch die Systemkonfigurationen wollen strukturiert und einfach verwaltet werden. Dafür gibt es Tools wie Terraform, Ansible oder das schon genannte Bundlewrap – ein von uns entwickeltes Config-Management, das ähnlichen Prinzipien wie Ansible folgt.

Doch was ist eigentlich mit den Tasks, bei denen es nicht darum geht, einen gewünschten State zu beschreiben, den das Tool dann herstellt? Was ist mit den eher prozessualen Alltagsarbeiten eines Admins wie Updates und Migrationen?

Solche Dinge galten bei uns lange als unmöglich zu automatisieren – oder nur mit einem so immensen Zeitaufwand, dass sich das für Tasks mit individuellen Kundenanforderungen gar nicht lohnt. Und wenn man andere Teammitglieder fragt, ist eigentlich jeder Fall ein Spezialfall.

Doch auch individuelle Arbeiten an Systemen profitieren von Automatisierung:

• Arbeiten sind weniger abhängig von dem einen Admin, der den Testlauf durchgeführt hat, und den dabei erstellten Dokumentationen.
• Der Druck beim Go-live wird herausgenommen: Der Admin muss nicht mühevoll nachvollziehen, was beim Testlauf gemacht wurde, sondern kann sich auf Besonderheiten und Notfälle konzentrieren.
• Schnelle unkomplizierte Testläufe werden überhaupt erst ermöglicht.
• Mit automatisierten Rollbacks steht eine Exitstrategie zur Verfügung, falls beim Go-live alle Stricke reißen und man das ursprüngliche System wiederherstellen muss.

Das alles hilft, flexibler zu werden, und macht die Arbeiten besser skalierbar, weil Abhängigkeiten abgebaut werden und Druck aus speziellen Situationen entweicht. Auch parallele Arbeiten an vielen Systemen werden möglich, da die Konzentration auf das einzelne System nicht mehr unbedingt nötig ist.

Das Problem dabei: Einfache Bash- oder Python-Skripte nehmen dem Admin die Kontrolle, die er braucht, um auf die individuellen Anforderungen und Begebenheiten zu reagieren. Und sie sind schwer zu entwickeln. Wie oft fängt man an, vergisst eine Kleinigkeit und muss dann manuell aufräumen oder das halbe Skript auskommentieren, um die Probleme zu fixen? Der Wunsch lautet also: volle Kontrolle, integriertes Exception-Handling und ein frei wählbarer Einstiegspunkt.

Und damit zu unserem konkreten Beispiel und meinen Erfahrungen als Mitglied der Automation Task Force.

Zeitlicher Ablauf der Automatisierung bei //SEIBERT/MEDIA

Ende 2018: Update für Jira – Ein Systemadministrator aus dem Betriebsteam macht seinen Job

Ein Update für ein Jira-System steht an und so beginnt ein Systemadministrator mit den üblichen Tasks. Dazu gehören unter anderem die folgenden Arbeiten:

• Informationen heraussuchen, betroffene Personen informieren
• Jira herunterfahren
• ZFS-Snapshot zur Datensicherung
• Jira hochfahren
• Plugins checken
• Version im Config-Management hochdrehen
• ...
• Übergabe an den Kunden

Was das im Detail bedeutet? Über 15 Kommandozeilen-Befehle und jede Menge manuelle Schritte, die eine hohe Aufmerksamkeit erfordern. Bestenfalls hat der Kollege beim Test-Update eine Kurzdoku der jeweiligen Schritte im Jira-Ticket abgelegt. Mittendrin die Meldung: Alarm! Mitglieder aus verschiedenen Teams springen im Dreieck. Der Grund: Das Kundensystem ist nicht erreichbar. Aber zum Glück nur ein Fehlalarm. Der Kollege mit dem Update hatte vergessen, im Monitoring eine Downtime zu setzen.

Ein Update skripten, damit Dinge nicht mehr vergessen werden oder verloren gehen? Unmöglich, denn es sind zu viele Spezialfälle vorhanden. Jedes Update ist ein klein wenig anders als das vorherige. Und wenn das Skript nicht funktioniert, muss man eh wieder alles manuell machen.

März 2019: Benachrichtigung über eine kritische Sicherheitslücke

Alle Admins wechseln in den Notbetrieb. Überstunden werden geschoben. Innerhalb kürzester Zeit müssen nahezu alle von uns betriebenen Confluence-Systeme mit Sicherheits-Updates versorgt werden. Es ist immer wieder das gleiche Spiel. Während die Anderen fleißig updaten, bin ich am skripten. Schritt für Schritt durch das Update...

Spaß macht das nicht gerade: Zeitdruck, andauernd treten neue Probleme auf. Geübte Teammitglieder schaffen ein Vielfaches mehr an Updates als ich, weil meine Skripte immer wieder kaputtgehen, Fälle nicht bedenken, abstürzen. Doch sobald was läuft, machen auch die Teammitglieder mit. Wir verbessern Schritt für Schritt unsere Update-Skripte.

Okay, Sicherheitslücke – dafür haben wir jetzt ein Skript, oder? Dies kann für den Standardfall ein Update auf Sicherheitspatch-Level durchführen. Nun ja... manchmal... wenn kein böses Plugin installiert ist. Auch so manch anderer Fall ist unberücksichtigt und man traut dem Ganzen nicht so richtig. Letztendlich wacht dann doch immer ein Admin mit Argusauge über den Prozess und überprüft das Vorgehen nochmal doppelt. Ein Einsatz im Regelbetrieb ist nicht wirklich denkbar.

Mai 2019: Automatix

Das Thema geht mir immer wieder durch den Kopf. Erste Umsetzungsideen entstehen. An einem Freitagabend unterhalte ich mich mit meinem Kollegen Jo. Er zeigt mir, wie er Teile einer Migration skriptet. Ich merke, dass es an der Zeit ist, den Gedanken Taten folgen zu lassen: Voller Energie und mit einem neuen Bewusstsein für die Herausforderungen begebe ich mich umgehend an die Umsetzung eines kleinen Automatisierungs-Tools, das das Skripting unterstützen soll. Ich nenne es "Automatix".

Die erste Version steht schon am Samstagnachmittag. In den kommenden Wochen folgen viele Verbesserungen und Anpassungen an die Bedürfnisse der Admins. Auch die ersten Automatix-Skripte entstehen, unter anderem eines zur Bereinigung gehackter Systeme.

Exkurs: Warum nicht Ansible?

Wenn ich Kollegen von Automatix erzähle und beschreibe, welche Art von Aufgaben wir damit umsetzen, höre ich oft den Hinweis, dass Ansible ja genau dasselbe tut. Ich habe mich im Vorfeld der Entwicklung von Automatix auch damit auseinandergesetzt und geschaut, ob wir nicht eine etablierte Lösung bei uns einsetzen möchten.

Es mag sein, dass mit Ansible ebenfalls vieles möglich ist. Allerdings war mein Eindruck nach einer kurzen Analyse, dass der Fokus von Ansible ein anderer ist. Beispielsweise ist die Ausgabe der Shell-Befehle nur über Umwege und zum Debugging zu erreichen. Ein interaktiver Modus ist zwar vorhanden, allerdings sieht man den auszuführenden Befehl nicht. Auch das Error-Handling sieht meines Wissens nach keine User-Interaktion vor. Weitere Punkte sind die Übersichtlichkeit der Skripte und die Integration in unsere bestehenden Lösungen, die mir kompliziert erschien. Dagegen behandelt Ansible viele andere Anwendungsfälle, die für uns weniger relevant sind, weil sie beispielsweise von Bundlewrap übernommen werden.

Auch die Einarbeitungszeit in die Tools ist zu bedenken, da wir Ansible bei uns bisher nicht einsetzen. Um mal einen Eindruck von der unterschiedlichen Komplexität der Tools zu bekommen: Das gesamte Automatix-Repository umfasst momentan circa 1.800 Zeilen Code, davon etwa 400 Zeilen README. Die Kernfunktionalität von Automatix ist auf rund 500 Zeilen Code zu finden. Im Gegensatz dazu ist das Ansible-Repository fast 170 MB groß und enthält knapp 180.000 Zeilen Code. Also hundertmal so viel!

Mein Ziel war es, eine möglichst einfache Form zu finden, den gewünschten Prozess aufzuschreiben und die Admins bei der Entwicklung dieser Skripte bestmöglich zu unterstützen. Genau das schafft Automatix und vermeidet viel Overhead. Alle Versuche, gleiche Anwendungsfälle in Ansible oder gar direkt als reines Python- oder Shell-Skript zu implementieren, haben bisher zu unübersichtlicheren und längeren Skripten/Playbooks geführt, denen dann entscheidende Features gefehlt haben und deren Entwicklung länger gedauert hat. Gerne gehe ich da aber auch in den Austausch mit erfahreneren Ansible-Nutzern.

November 2019: Das Mega-Migrationsprojekt

Bei uns hat sich Automatix inzwischen etabliert. In unserem Betriebsbereich setzen wir sowohl sich wiederholende als auch sehr individuelle Aufgaben damit um. Wir schließen ein riesiges Migrationsprojekt mithilfe von Automatisierungen ab, die so vorher gar nicht denkbar waren! Zugegeben: Noch ist nicht alles perfekt. Wir befinden uns allerdings auf einem guten Weg. Dabei können wir feststellen: Das Automatisieren lohnt sich!

Heute: Automatisierung nicht mehr wegzudenken

Fast alle Updates und Migrationen gehen wir inzwischen mithilfe von Automatisierung an. Anfänglich mussten wir zusätzliche Zeit investieren, das stimmt. Aber mittlerweile verzeichnen wir einen deutlichen Zeitgewinn und die Vorteile sind klar geworden. Wir vermeiden Fehler. Die Dokumentation erfolgt als ausführbarer Programmcode. Das Vorgehen ist einheitlich und wird auch noch von der Schwarmintelligenz verbessert.

Die Nachteile konnten wir mit unserem Tool Automatix größtenteils eliminieren, das wir kontinuierlich weiterentwickeln und das als Open-Source-Lösung auf GitHub zu finden ist. Der Admin behält die volle Kontrolle; er kann Skripte stoppen oder mittendrin starten, Python- und Bash-Befehle beliebig mischen und direkt auf Fehler reagieren. Die Anbindung an unser Config-Management erlaubt darüber hinaus den einfachen Zugriff auf Systeminformationen und Secrets.

Unser Fazit

Automatisierung lohnt auch an Stellen, wo man das zunächst nicht vermutet, und bietet auch bei Einzelfällen einige Vorteile, wenn man die richtigen Tools und Hilfsmittel zur Verfügung hat.

Was es dazu letzten Endes braucht? Nun, einen Systemadminstrator kann das Tool nicht ersetzen. Und wer mit Automatix automatisieren möchte, benötigt ein tiefes Verständnis des zu administrierenden Linux-Systems und muss sich auf der Bash- und Python-Konsole zu Hause fühlen. Dann jedoch hat man nahezu unbegrenzte Möglichkeiten. Geht nicht, gibt's nicht! Man muss aber auch mal um die Ecke denken.

Ihr Partner für den Betrieb Ihrer Atlassian-Software

Haben Sie die eine oder andere Herausforderung Ihres Unternehmens bei der Wartung und Aktualisierung Ihrer Systeme in diesem Artikel wiedergefunden? Falls Sie der Ansicht sind, dass die Pflege Ihrer Atlassian-Instanz zu viel manuelle Arbeit beansprucht oder dass Updates sehr aufwändig sind und oft nicht zeitnah genug erfolgen können, dann lesen Sie sich doch mal in die Inhalte zu unseren Atlassian-Betriebspaketen ein.

Unsere erfahrenen technischen Teams kennen die Besonderheiten von Atlassian-Systemen genau und haben die Betriebs- und Hosting-Pakete auf diese spezifischen Anforderungen hin zugeschnitten. Möchten Sie mehr erfahren? Hier finden Sie ausführliche Infos zu unseren systemadministrativen Atlassian-Leistungen.

Weiterführende Infos

Betriebspakete werden zur Pflicht für unsere Notfall-Dienstleistungen
Transparenz und Vorbeugung vor bösen Überraschungen: Betriebspakete für Atlassian-Anwendungen mit Monitoring
Eine Geschichte von Datenverlust und Backup-Konzepten für Atlassian-Produkte

Mehr über die Creative-Commons-Lizenz erfahren