(Artikel 6 von 9)

Eine Konfiguration ist mehr, …

… als Discovery leisten kann.

Was nicht so einfach ist, ist das Herausfinden, was alles zum IT-Verbund unseres CRM Services gehört. Hier ist noch mehr der Mensch als die Maschine gefordert.

Bereits in der Begriffserklärung der Configuration wird darauf hingewiesen, dass es nicht nur um die Eigenschaften bzw. die Konfiguration einzelner CIs oder Assets geht, sondern auch um die Abhängigkeiten dazwischen. Im Deutschen kennt man den schönen Ausdruck IT-Verbund, der leider in ITIL nicht vorkommt. Doch genau um das geht es: Die Relationen, die Abhängigkeiten, den Verbund mehrerer technischer und von Menschen erbrachter Services die den Service, den Anwender nutzen, erst ermöglichen.

Wie kann nun Discovery helfen, eine Service-Konfiguration festzustellen und wo sind die Grenzen? Dazu gehen wir wieder zu unserem Beispiel zurück und sehen uns nochmals das ursprüngliche Design des Lieferanten aus seiner Dokumentation an:

Start von Discovery

Nach dem Lauf des Discovery befinden sich im Idealfall auch jene drei Server, die wir weiter betrachten wollen. Dass diese für unser CRM-Service die Rolle Database-Server, Application-Server und Web-Server innehaben, können wir Menschen ahnen oder aus vielen anderen Informationen ableiten. Auch Discovery kennt Hinweise: Es laufen spezielle Dienste, Services, Daemons. Jedoch alleine die Tatsache, dass ein Dienst auf einem Server läuft bedeutet noch lange nicht, dass er auch erwünscht oder notwendig ist. Auch wissen Dienste selten wem sie dienen. 

Dass das übergeordnete Service das CRM-Service ist, müssen wir Menschen den Systemen mitgeben, das finden sie nicht selbst heraus. Discovery geht es da nicht besser. Denn Discovery kann sich zwar die Verbindungen zwischen gesprächigen Geräten ansehen und diese analysieren. Die sogenannte “Network Topology” kann analysiert und aufgezeichnet werden. Aber die Interpretation bleibt weitgehend Menschensache.

Discovery der Netzwerk-Topologie

Verlockend klingt nun die Funktion mit Hilfe einer automatisch durchgeführten Analyse unserer Netzwerk-Topologie unser CRM Service dokumentiert zu bekommen, Doch alleine die Tatsache, dass beim Lauf der Discovery Software zwei Server miteinander KEINE Verbindung hatten, bedeutet nicht, dass es nicht zu anderen Zeitpunkten eine Verbindung gibt. Ebenso ist die Tatsache, dass vielleicht auf Port 1433 zwei Server miteinander “sprechen” nicht gleichbedeutend mit dem Einsatz eines MS-SQL-Servers als Datenbank-Server – auch wenn das der übliche Standard-Kommunikationsport ist. Und schon gar nicht bedeutet ein geöffneter Port auf einer Firewall, dass er auch benötigt wird. Zweifellos ist eine solche Discoveryfunktion großartig und erspart uns enorm viel Analyse-Zeit. Diese Information ermöglicht weitere Analysen und gibt uns viele weitere Anhaltspunkte, ist aber nicht gleichbedeutend mit “Wahrheit”. Dokumentieren wir diese, von Discovery identifizierten Informationen nun 1:1 als SOLL? Oder als IST? Vorsicht ist angebracht: Wir sind beim Mustervergleich, keinesfalls beim Wissen!

Die Dokumentation von SOLL und IST-Zuständen

Um nun diese vielen Informationen und Sichten in eine gemeinsame Datenbasis, wie sich eine CMDB nun einmal darstellt, einbringen zu können und nicht beim Betrachten der Information einen Übersetzer zu benötigen, braucht man ein Dokumentationsmodell, dem alle Beteiligten folgen können und das am besten selbsterklärend ist. Wir bieten einige unterschiedliche Modelle an, welche in der 7.ITIL Baseline beschrieben werden.