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 Bedarf uns abzustimmen. Trotz Doku. Oder gerade: wegen der Doku. Diese Zeit nutzen wir lieber für Besseres und da gibt’s eine Menge!

Nach dem Umbau unseres Ablaufes sieht die Sache nun so aus: Wir erheben die Anforderung, erstellen die neue Maschine in i-doit und konfigurieren sie mit allen notwendigen Details. Was nicht genau dokumentiert ist, kann auch nicht provisioniert werden. Netzwerk, Speicher, SAN, IP-Adresse, auf welchem Cluster soll sie laufen und natürlich einem eindeutigen Namen. Ist die Sache „rund“, setzen wir den Status auf „zu provisionieren“. Der Rest passiert automatisch. Ein Script übergibt die Daten an die VMware Plattform, diese generiert die Maschine, eventuelle Errorcodes können natürlich behandelt werden. Ist der Vorgang erfolgreich, wird der Objekt-Status automatisch auf „provisioniert“ gesetzt.

Wir erkennen drei Vorteile: a) Die Doku ist vollständig. b) die Doku entspricht der Realität, zumindest mal am Anfang des Lebenszyklus. Und: c) der Faktor Zeit: Das Script macht es immer, sofort und immer gleich: Keine Abweichung, keine Wartezeit.

Share This