Seit vielen Jahren erstellen wir mit der IT-Dokumentation ein nachträgliches Abbild der Realität. Nun probierten wird es einmal umgekehrt: Aus der Dokumentation die Realität schaffen. Natürlich war unser Anspruch: „Automatisch“. Das Ergebnis des Versuchs ist vielversprechend und macht unsere Admins und den Chef wieder ein Stück zufriedener. In i-doit pro 1.6 wurde die Möglichkeit geschaffen, „Events“ zur Steuerung und Automatisierung zu verwenden. Seither juckte es einige KollegInnen in den Fingern. Viel versprechend scheinen die Möglichkeiten der Automatisierung im Rechenzentrum, wenn auch zuerst einige eingefahrenen Denkmodelle, na sagen wir mal: „überarbeitet“ werden mussten. „Hier konfiguriere nur ich …” sagte der Admin und wurde trotzdem überzeugt, uns mal machen zu lassen.

 

Und so gingen wir, befreit von Tabu und Dogma, als erstes an unsere VMware Plattform heran. Jeder Hersteller hat seiner virtuellen Plattform die Möglichkeit gegeben Maschinen ferngesteuert zu provisionieren, ebenso sie zu ändern, zu starten, anzuhalten, zu stoppen. Uns war natürlich auch bewusst, dass wir nicht die ersten sind, die sich mit dem Thema beschäftigen und das Thema in vielen IT-Organisationen „gegessen“ ist. Da gibt es natürlich ganz tolle Lösungen, die das alles fix und fertig anbieten. Aber ähnlich wie viele unserer Kunden haben wir eine Mittelstands-IT mit dem  Budget eines Einzelunternehmers. Wir setzen selbst i-doit als IT-Dokumentationslösung/CMDB für die Abbildung der Realität nach einer Änderung ein.

Der bisherige Ablauf bewirkt zwei Themenstellungen:

a) Doppelte Arbeit. Auch wenn es nur wenig Aufwand ist: Es ist unangenehm, zuerst alle Daten zu erheben (wie soll die neue Maschine konfiguriert sein, wie viel Speicher, mit welchem Storage verbunden, in welches Netzwerk, …), dann die virtuelle Umgebung mit diesen Daten zu füttern und im Anschluss das Ganze nochmals in die Dokumentation aufzunehmen. Nur ein Mal muss man raten, welcher dieser Arbeitsschritte nicht gerne, nicht komplett oder gar nie stattfindet. Auf den nächsten Discovery-Lauf zu warten bis die Daten in der CMDB auftauchen ist oftmals unpraktisch, denn wir wollen ja, wenn wir schon tippen, gleich auch weitere Daten zur Maschine hinzu dokumentieren.

 

b) Die Methode an sich ist schon eine Fehlerquelle mit unangenehmen Folgen: Manche KollegInnen dokumentieren konsequent und „zeitnah“, andere anders. Wir können aber nicht davon ausgehen, dass alle Menschen gleich sind oder gleich arbeiten. Daher ist die Dokumentation genau so bunt wie unsere MitarbeiterInnen. Das gibt uns aber beim Betrachten und Vergleichen kein gutes Gefühl: Stimmt es nun oder stimmt es nicht? Finden wir eine Maschine, die mehr Speicher dokumentiert hat als „eingebaut“: Was tun? Wie sollte es sein? Korrigieren wir nun die Dokumentation oder korrigieren wir, in dem wir der Maschine mehr Speicher zuweisen? Auf jeden Fall haben wir eine Menge