(Artikel 2 von 12)

Die erste Baseline: Ist das IST auch das SOLL?

Will man eine CMDB im Unternehmen einführen und erstmalig mit Daten beladen, gilt es zu klären, ob der Zustand, den man aktuell vorfindet auch tatsächlich “stimmt”. Fragen wir einmal im Kreis herum, was “stimmt”, also einem gewünschten Soll-Zustand entspricht. Das ist gar nicht so einfach, wie folgendes Beispiel zeigt:

Ein Application Server wurde im Rahmen eines Projektes – es wurde eine neue CRM Software im Unternehmen eingeführt – mit 8GB RAM angefordert. Eine virtuelle Maschine wurde von der IT Abteilung wie vereinbart bereitgestellt und, nehmen wir einmal an, dass wir in einer größeren Organisation sind, auch so an die Fachabteilung verrechnet. In der Projektdokumentation – es handelt sich um eine PDF-Datei, steht der Server in der ursprünglichen Konfiguration beschrieben. Niemand hat diese verändert, denn das Dokument kam von einem externen Dienstleister. Hier handelt es sich um eine Soll-Dokumentation – jedoch zum Zeitpunkt des Projektstarts. Alle waren zufrieden, SOLL und IST waren gleich.

Nach Abschluss des Projektes und nach Einspielen eines Softwareupdates hat sich herausgestellt, dass der Speicher des Application Servers aufgerüstet werden muss. Unser freundlicher Admin hat das mit wenigen Mausklicks rasch erledigt und dem virtuellen Server 16GB RAM zugewiesen. So weit so gut. Das System läuft zur Zufriedenheit der Anwender. Doch nun laufen die dokumentierten Informationen auseinander: Streng genommen ist nach wie vor das SOLL mit 8GB definiert. Die Fachabteilung kennt unter Umständen nicht einmal die Schwierigkeiten, die beim Update aufgetreten sind. Worauf beziehen sich nun die weiteren Prozesse? Auf das IST, wird der IT-Admin sagen. Idealer Weise erinnert er sich im Fehlerfall daran, dass einst auf 16GB erweitert wurde. Auf die SOLL-Dokumentation, wird die Fachabteilung und eventuell sogar der externe Dienstleister sagen – denn diese Konfiguration war der Letztstand, den alle kannten.

Bezieht sich nun der Disaster Recovery Prozess auf das alte (und vielleicht einzige) Dokument, stellt man eventuell nach einem Ausfall eine alte Soll-Konfiguration wieder her. Dann hat man zwar formal alles richtig gemacht, aber die Applikation funktioniert nicht. Die Folge sind unnötige Recherche und Zeitverlust  bis zur Wiederherstellung des CRM-Service. Der Grund: nicht ausreichende Dokumentation des SOLL-Zustands.

Doch damit nicht genug: Gravierende Auswirkungen können kleine Änderungen von Konfigurationen auch auf das Lizenzmanagement und viele sicherheitsrelevante Punkte haben.

Doch zurück zum Anlass dieses Artikels: Was schreiben wir in unsere CMDB?

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

https://www.i-doit.com/itil-baselines-wer-hats-erfunden/