Erster und wichtigster Grundsatz einer CMDB (Configuration Management Database) ist deren Aktualität und somit Zuverlässigkeit. Doch wie gelange ich zu einem funktionierenden CMDB Datenmodell?
Der Kern eines Configuration Managements ist die CMDB. Der CMDB Inhalt (logisches Abbild der IT Umgebung) dient weiteren ITSM Prozessen als Datenbasis. Eine effiziente Prozessdurchführung kann daher nur erfolgen, wenn die CMDB vollständige (in Bezug auf den Scope!) und verlässliche Informationen bereit hält.
Der Aufwand von Planung bis Implementierung einer CMDB wird oft unterschätzt oder noch schlimmer, der erwünschte Nutzen tritt aufgrund unzureichender Planung gar nicht ein und die CMDB verkommt zu einem Datengrab. In der richtigen Reihenfolge und mit systematischen Vorgehen, kann eine CMDB aus Konsumentensicht aufgebaut und somit für eine optimale Nutzung vorbereitet werden.
Ein grundsätzliches Schema zum Vorgehen könnte sein:
- Festlegen der Informationskonsumenten (Beispiel: Incident Management erfordert Betriebssystem Information der Clients
- Identifikation der benötigten Klasse und deren Attribute (Hier: Klasse gleich „Computer“ / Attribut „Operating System“)
- Identifikation des Informationslieferanten (Hier: Discoverytool wie z.B. Lansweeper oder Assetmanagement kann Information bspw. per JDBC Schnittstelle liefern)
- Implementieren der Schnittstelle und Abnahme der Anforderung
[the_ad_placement id=“dyn“]
Zur Veranschaulichung kann ein grobes Beispielschema von CI-Klasse, Relation und Attribut dienen:
Struktur:
- CI-Klasse
- Klassenname
- Beschreibung
- Abgeleitete Klasse
- Relationen
- von Klasse <Rel> nach Klasse
- Semantik
- Attribute
- Name
- Datentyp
- Semantik und Beispielwerte
- Provider und Attributname
- Umgang mit Änderungen (übernehmen, benachrichtigen)
Ein dazu passendes Beispiel:
- Interface (CI-Klasse)
- SIM (Klassenname)
- SIM verbindet ein Mobile Device mit dem Provider-Netz (Beschreibung)
- „SIM“ erweitert „Interface“ (Abgeleitete Klasse)
- Relationen
- SIM nutzt Telefonnetz (von Klasse <Rel> nach Klasse)
- Mobile Device nutzt SIM (Semantik)
- Attribute
- Kartenummer: String;
- Provider: N/A
- Format: „Mirco“ (Normal, Mini, Mircro)
- Provider: N/A
- Kartenummer: String;
Hält man dieses grobe Schema ein, kann als Projektleiter oder Configuration Manager recht stringent eine sinnvolle Verkettung von „Was brauchen wir, wie bilden wir es ab und wer kann es liefern“ erarbeitet werden. Die Integration möglichst vieler Nutznießer der CMDB ist dabei unabdingbar, da das Configuration Management ein unterstützender Prozess für andere Service Management Prozesse ist.
[the_ad_placement id=“dyn“]
Um die Aktualität und Validität der Daten künftig zu gewährleisten, bieten sich idealerweise Discoverytools an, welche in regelmäßigem Abständen den Stand der gewünschten Configuration Items (CI´s) per WMI oder ähnlichen Schnittstellen tracken und per Schnittstelle (z.B. JDBC) direkt in die CMDB melden. Ist dies nicht möglich, sollten entsprechende Auditmechanismen etabliert werden, welche, durch den Configuration Manager betreut, den aktuellen Stand der CMDB (bzw. ein Extrakt daraus) mit anderen Datenquellen auf Abweichungen vergleicht. Sind Abweichungen vorhanden, sollten diese nicht sofort korrigiert werden, da sie bspw. auf unautorisierte Change hindeuten können denen man zunächst nachgehen sollte, damit er künftig vermieden werden kann.
Mitunter der wichtigste, konsumierende Prozess ist das IT Change Management. Hieraus entwickelt sich jedoch schnell eine etwas größere Herausforderung des Implementierungsaufwands und zwar die Relationen, also die Beziehungen der in der CMDB befindlichen Elemente. Besteht nicht der Luxus einer toolgestützten Generierung von Businessservices, kann es durchaus tricky werden zu erarbeiten, welcher Port an einem Switch denn am Ende welche Geschäftsprozesse unterstützen.
Ist ein Service Katalog vorhanden, kann dieser als Ausgangsbasis dienen, das Zusammenspiel der benötigten CI´s zu identifizieren und deren Beziehungen anschließend in der CMDB abzubilden.
Am Ende zählt für eine erfolgreiche Implementierung und vor allem Etablierung einer CMDB das Credo „so viel wie nötig, so wenig wie möglich“ als Grundlage zur Zielerreichung einer validen und für die benötigten Zwecke vollständige CMDB.
Jan Kahmann