Viele Unternehmen haben den Betrieb ihrer Infrastrukturen heute mehr oder weniger vollständig nach ITIL organisiert. Das eigentliche Doing, also der Lebenszyklus der Infrastruktur vom Aufbau bis zum End-of-Life wird dabei allerdings meist noch größtenteils manuell durchgeführt. Das führt dazu, dass Changes in der Infrastruktur häufig nur langsam oder mit verminderter Qualität umgesetzt werden können. Die Dokumentation von Changes wird dazu meist vernachlässigt, da sie als zu zeitaufwändig empfunden wird. Das Ergebnis ist, dass die Infrastruktur in der Praxis durch viele undokumentierte Ad-hoc-Changes nur noch schwierig zu warten ist. Die Auswirkungen von Änderungen können häufig vorab nicht mehr bestimmt werden sondern manifestieren sich erst bei Durchfürung des Changes. Selbst wenn Testumgebungen existieren, so entspricht der Versionsstand nicht mehr dem der Produktivumgebung und die Aussagekraft von Tests geht gegen Null. Die Auswirkungen davon sind teilweise katastrophal.
Wie können wir also den Lebenszyklus der Infrastruktur so gestalten, dass:

• flexibel auf Ad-hoc-Changes reagiert werden kann
• Änderungen dokumentiert sind
• Änderungen mit geringem Aufwand vorab getestet werden können?

In Zeiten von Infrastructure as a Service und Software-defined-everything kann aus meiner Sicht die Antwort darauf nur sein, den Betrieb von Infrastrukturen weitgehend zu automatisieren. Da dann die Definition der Infrastruktur als Beschreibungsdatei im Textformat vorliegt, spricht nichts dagegen, die Infrastruktur in einem Quellcode-Repository analog zur Softwareentwicklung zu versionieren. Wenn das Repository mit einem Issue-Tracking-System verbunden ist, das heißt, Änderungen im Quellcode können mit den zugehörigen Issues verknüpft werden, ist das Problem der Dokumentation von Änderungen nebenbei gleich mit adressiert.

In den folgenden Blog-Artikeln werde ich näher auf die nötigen Komponenten und den Aufbau eines exemplarischen Beispiels eingehen.