Viele IT-Automatisierungs-Lösungen sind skript-gebunden – warum auch nicht? Mit Skripten haben wir Automatisierung im IT-Betrieb in den letzten gut 30 Jahren umgesetzt und sie haben ihren Zweck erfüllt. Aber wenn wir Dinge nur so fortführen, wie wir sie schon immer gemacht haben, warum gibt es dann aktuell so einen Hype um die Automatisierung? Nun, ganz einfach weil die Kosten des IT-Betriebs zu hoch sind – trotz des Skriptings, das wir schon gemacht haben – und weil das Talent, das im IT-Betrieb geparkt wird, im Innovationsteil der IT fehlt – worum sich die IT eigentlich drehen sollte.

Die natürliche Reaktion auf das Bedürfnis nach einer besseren Automatisierung ist, die Dinge so wie sie sind, zu verfeinern und bessere Arten zu entwickeln, um Skripte zu schreiben, zu managen und zu pflegen. Alternativ kann ein disruptiver Technologiesprung eine komplett neue Art der Automatisierung erreichen (letzteres tun wir mit dem arago Autopilot for IT Operation).

In beiden Fällen muss man die Defizite von Skripten verstehen, um irgendeine Art von Verbesserung zu erreichen und dieser Post ist eine kurze und knackige Zusammenfassung dieser Mängel. Bitte versteht mich nicht falsch. Ich sage nicht, dass Skripten Müll ist und alle Leute, die Skripte geschrieben haben oder schreiben, Idioten sind – weit gefehlt. Wie ich bereits sagte, haben Skripte ihren Zweck gut erfüllt und werden weiterhin eine wichtige Rolle spielen, da sie die Basis des heutigen IT-Betriebs sind. Aber wir müssen die Begrenztheit von Skripten verstehen, um uns weiterzuentwickeln.

Wie ich in meinen Beiträgen geschrieben habe, haben Skripte drei Begrenzungen, die ich hier kurz darstellen werde.

1. Begrenzte Anwendbarkeit

Ein Skript – wie jedes imperative Computerprogramm – hat eine klare Vorbedingung, unter der es das gewünschte Ergebnis produziert. Grundsätzlich bedeutet das, ein Skript funktioniert wie ein Fließband. Es wird das richtige Ergebnis produzieren – zuverlässig und meist skalierbar – wenn es in dem Zusammenhang angewendet wird, für den es geschrieben wurde. Wenn sich der Kontext nur leicht ändert, sind die Ergebnisse falsch oder das Skript kann nicht ausgeführt werden. Das heißt, bei jeder leichten Änderung des Kontexts muss das gesamte Skript geprüft und entweder geklont oder geändert werden, damit es auch den leicht geänderten Kontext bewältigt. Dies bedeutet normalerweise, „if“ oder „case“-Anweisungen zum Skript hinzuzufügen, was es komplexer macht. Wenn man es lange genug wiederholt, wird sich das Skript in ein Tool verwandeln und wenn man an dieser Stelle nicht aufhört, hat man am Ende vielleicht sogar ein organisch gewachsenes Produkt. Das Problem mit solchen Tools ist, dass es absolut unmöglich ist, sie zu warten, da Skripte nicht wie Programmier-Projekte verwaltet werden (was nie die Absicht war), sondern sich schnell in riesige Programme verwandeln.

Diese begrenzte Einsetzbarkeit schafft entweder eine Vielzahl sehr ähnlicher oder einige sehr komplexe Skripte. Egal, welche Standard-IT-Betriebsumgebung man sich ansieht, man wird solche Skripte finden. Niemand möchte sie wirklich anfassen, außer wenn es absolut notwendig ist, da niemand sie komplett oder die Wechselbeziehungen zwischen den vielen Skripten in der Umgebung versteht.

2. Begrenzte Wiederverwendbarkeit

IT-Betrieb ist ein ad-hoc Business. Selbst wenn wir es nicht wirklich zugeben wollen, der Job des IT-Betriebs ist es, Vorfälle zu handhaben, wenn sie anfallen. Das bedeutet, es gibt keine lange Planungsphase, um die Wiederverwendung zwischen allen im Betrieb beteiligten Komponenten auf einen optimalen Level zu bekommen. Der Job des IT-Betriebs ist es, Dinge jetzt erledigt zu bekommen und auf diese Weise werden die meisten Skripte generiert. Jemand macht einen Job zum zehnten Mal und möchte ihn beschleunigen oder ist verärgert, dass diese Angelegenheit ihn davon abhält, andere wichtige Aufgaben zu erledigen. Damit sich das nicht wiederholt, schreibt er ein Skript. Dies funktioniert und produziert sofortige Ergebnisse (wonach wir ja suchen), aber es bedeutet auch, dass Dinge wieder und wieder geskriptet werden. Es bleibt einfach zu wenig Zeit, um die Wiederverwendung von bereits verfügbaren Dingen angemessen zu managen oder gar das Wissen darüber, was schon von anderen getan wurde, jedem zugänglich zu machen. Dies bedeutet nicht nur, dass viel Zeit damit verbracht wird, Teile von Skripten zu schreiben, die bereits existieren (was im Nachhinein schlecht ist, aber okay im Hinblick auf die erzielten Resultate), sondern auch, dass wenn Changes in einer Umgebung anfallen, es potentiell VIELE VIELE Orte gibt, wo sich dieser Change auf die aktuellen Betriebsabläufe auswirken kann.

3. Begrenzte Flexibilität

Da wir über 30 Jahre lang Skripte geschrieben haben, kann man davon ausgehen, denke ich, dass alle leicht erreichbaren Ziele realisiert wurden. Auf Skripte bezogen heißt das, dass alle leichten Skripte bereits existieren. Leicht bedeutet normalerweise, dass man etwas komplett alleine erstellen kann. Ja, ich weiß, du kannst alleine wundervoll komplexe Skripte und Programme erstellen, aber so lange du derjenige bist, der mit ihnen zu tun hat, sind sie einfach, weil du weißt, wie du mit ihnen umgehen musst. Skripte werden kompliziert, wenn man mehr als eine Expertise – d.h. Person – benötigt, um sie zu schreiben und zu warten. Denn erst ist es schwierig, diese zwei oder mehr Personen zusammenzubringen, um das neue Skript zu schreiben und dann wird es noch schwieriger, sie wieder zusammenzubringen, um es zu ändern. Das bedeutet, dass wegen dieser starken Abhängigkeit moderner Skripte von verschiedenen Fähigkeiten sie nur als Teil einer dezidierten Change- oder Refactoring-Anstrengung oder im Falle größter Not geändert werden. Da der IT-Betrieb genug zu tun hat, ist die dezidierte Change-Anstrengung etwas, wovon jeder träumt und niemand dazu kommt, es umzusetzen. Und dies bedeutet, dass eine Änderung des Kontexts – d.h. der Umgebung – in dem diese Skripte laufen, nicht vorgenommen werden kann, ohne eine Flut zusätzlicher Tasks zu verursachen, um all die Dinge zu ändern, die über die Jahre gewachsen sind und dabei helfen, die Umgebung zu erhalten.

Für mich ist der dritte Teil der schlimmste, da dies der einfache Grund ist, warum jeder versteht, dass die „never change a running system“-Regel nicht nur befolgt wird, sondern der Status quo eines Systems verteidigt wird, als sei es die letzte Bastion der Menschheit oder Admin-Wertschätzung. Wenn man seine Umgebung nicht ändern kann, kann man sich Geschäftsanforderungen nicht anpassen – oder Anpassungen sind stets für alle Beteiligten ein großer Kampf. Man kann sich definitiv nicht an Innovation als konstanten Begleiter der IT erfreuen – was laut der IT-Literatur, die ich gelesen habe, das ist, worum es in der IT gehen sollte und weswegen IT-Leute IT lieben.

Alle drei Punkte zusammen machen die Wartung einer IT-Betriebsumgebung zu einer teuren und zeitaufwändigen Aufgabe und das Ändern zu einer fast unmöglichen Mission.

Viele Leute haben diese Einschränkungen oder Zwänge von Skripten gesehen und es gibt da draußen viele Produkte, die uns dabei helfen, eine oder mehrere der oben genannten Zwänge zu bewältigen. Viele dieser Ansätze haben phantasievolle Namen wie Run-Book Automation oder Data-Centre-Automation, aber sie bieten nur einfachere Wege des Skript-Managements, die die Wiederverwendbarkeit von Skripten oder der Tasks, die geskriptet werden, managen.

Ich glaube nicht, dass das ausreicht, denn die IT ändert sich zu schnell, als dass ein Skript, das ein Lifecycle Management und alles was daran hängt, benötigt, ein effektiver Weg wäre, damit umzugehen. Das Ergebnis ausgeklügelten operativen Lifecycle Managements ist normalerweise eine sehr standardisierte Umgebung, die nur langsam auf neue Anforderungen reagiert. So eine Umgebung ist toll für Massenprodukte und –dienste wie Desktop Provisioning oder Server Provisioning, aber sie ist eher ungeeignet für Applikation Maintenance, User Feedback Management und ähnliches.

Deswegen ist ein anderer Ansatz sinnvoll. Unser Ansatz nennt sich Autopilot. Alles, was der Autopilot macht, ist, einen großen Wissenspool zu haben (so wie du) und „on the fly“ jedes Mal ein Skript zu schreiben, wenn ein Task auftaucht (wie du, wenn du etwas manuell bearbeitest). Die Wirkung ist einfach. Du machst die interessanten neuen Sachen und der Autopilot macht die langweilige Arbeit, sogar in einer sich ändernden und immer komplexeren Umgebung – ohne die Notwendigkeit, alles zu standardisieren.