Datenbasis für das Service-Management
Keine CMDB ohne Business Case
Das Aufbrechen des Silodenkens, eine engere Zusammenarbeit und Automatisierung sind die Auslöser und zugleich die Herausforderungen bei der Einführung einer Configuration Management Database (CMDB).
Innerhalb der heute meist vorherrschenden IT-Silos wie Netzwerk, Server, Host oder Clients gibt
es eine Vielzahl von Datenbeständen. Will man diese vernetzen, Abhängigkeiten aufzeigen und in
Richtung Business-Sicht gehen, führt kein Weg an der Nutzung einer CMDB vorbei. Das Referenzwerk
ITIL (IT Infrastructure Library) hat die CMDB als Querschnittswerkzeug bereits seit vielen Jahren
im Gepäck. Dennoch tun sich viele Unternehmen bis heute schwer, autonome Strukturen zugunsten von
interdisziplinärem IT-Wissen aufzubrechen.
Organisation und Technik einfangen
Die Herausforderungen bei der CMDB-Einführung sind gleichermaßen organisatorischer wie
technischer Natur. Mit der Einführung einer CMDB entsteht in einem vorher nicht gekannten Ausmaß
der Zwang zum Konsens, zum Aushandeln gemeinsamer Ziele und zu Abmachungen zwischen den
Abteilungen. Hinzu kommen technische Hürden wie etwa die automatisierte Erkennung von
Abhängigkeiten.
In der Praxis hat es sich als nützlich erwiesen, eine CMDB aus einer Keimzelle heraus wachsen
zu lassen. Diese Keimzelle kann etwa ein IT-Standort oder ein Technikbereich wie Server oder
Netzwerk sein. Ein anderer erprobter Ansatz ist das Entstehen mehrerer solcher Keimzellen, die man
dann über eine Metaebene zur "Federated CMDB" zusammenführt. Der Sinn leuchtet ein: CMDB-Projekte
sind sehr komplex und in der Regel langwierig – ein Unternehmen mit einfachen IT-Strukturen kommt
gar nicht erst in die Verlegenheit, sich mit Configuration-Management auseinandersetzen zu müssen.
Stellt man sich aber dieser vielschichtigen Herausforderung mit dem Anspruch, alle Bereiche
simultan einzubeziehen, vergeht oft soviel Zeit, bis erste Erfolge sichtbar sind, dass das Projekt
an Fahrt verliert und einschläft.
Dies lässt erkennen, wie sorgfältig die Einführung einer CMDB zu planen ist. Am Beginn steht
daher die Frage: Wem nutzt die per CMDB bereitgestellte Information? Erst danach geht es daran
festzulegen, wo die Daten herkommen, wer sie für welche Zwecke nutzt und wie detailliert sie sein
müssen. Das entstehende Datenmodell ist sinnvollerweise keine Eigenentwicklung, sondern orientiert
sich am Marktstandard, da auch die meisten verfügbaren Tools dies tun. Am weitesten verbreitet ist
das Common Information Model (CIM) der DMTF (Distributed Management Task Force), der über 200
IT-Unternehmen angehören.
Das Datenmodell ermitteln
Einer der schwierigen Aspekte bei der Einführung einer CMDB ist es, sich auf ein zu
verwendendes Datenmodell und die zugehörige Attributliste zu einigen, gerade weil die Informationen
abteilungsübergreifend bereitgestellt und genutzt werden. Kommt dann noch die Business- oder
Prozesssicht ins Spiel, müssen die Attribute zusätzlich zwischen IT und Fachbereichen verhandelt
werden. Dies ist keine Kleinigkeit, da oft nicht einmal die verschiedenen IT-Abteilungen dieselbe
Sprache sprechen.
Die Datenbestände in den vorhandenen Systemen haben bereits feste Strukturen und Formate,
auch eine Reihe von Attributen sind dort bereits definiert. Diese gilt es nun in das neue System zu
überführen und zu normieren (Reconciliation). Mapping-Tabellen helfen zu bestimmen, welches
Attribut aus dem Quellsystem welchem Attribut in der CMDB entsprechen soll. In der Regel haben die
verschiedenen Abteilungen bereits unterschiedliche Sichten auf die Systeme oder CIs (Configuration
Items), die es nun ebenfalls zu vereinheitlichen gilt.
Sind unterschiedliche Datenquellen vorhanden, die ein gemeinsames Feld befüllen sollen, lässt
sich nur noch regelbasiert entscheiden, welches die führende Datenquelle sein soll.
Organisatorische und technischen Anforderungen gehen also auch hier Hand in Hand.
Bei den eigentlichen Objekten der CMDB, den CIs, ist das Problem ähnlich gelagert: Wo ist die
Definitionsgrenze? Ein PC ist ein CI, ein Server, ein Switch und eine Applikation ebenfalls.
Schwieriger ist es schon bei Server-Bausteinen wie Prozessoren, Festplatten oder Netzteilen.
Rechenzentren betrachten diese oft als eigenständige CIs: Sie sind komplett austauschbar und
liefern zudem für die Betriebsüberwachung wesentliche Informationen wie Prozessorlast, Plattenplatz
und Wärmeabgabe.
CI-Definition
Feste Vorgaben gibt es also nicht. Jedes Unternehmen muss auf Basis der eigenen Anforderungen
festlegen, was ein CI ausmacht und was eben nur eine CI-Komponente ist. Grundsätzlich gilt, dass
die Qualität einer CMDB nicht mit der in ihr gespeicherten Datenmenge steigt, sondern mit dem
Nutzungsgrad gespeicherter Information. Daher ist der häufig anzutreffende Ansatz, alles in die
CMDB aufzunehmen, was per Discovery identifizierbar ist, falsch.
Ein geringer Detaillierungsgrad mit flachen Datenstrukturen und wenig Vererbungen zwischen
den CI-Klassen bringt weitere Vorteile mit sich: Aktualisierungen haben eine kürzere Laufzeit,
können daher öfter durchgeführt werden und verursachen weniger Fehler beim Datenimport. Außerdem
ist der spätere Aufbau grafischer Beziehungsgeflechte wesentlich performanter. Kurz: Eine CMDB ist
dann optimal, wenn man bei der Beschreibung der CIs und Services nichts mehr weglassen kann.
Hat man sich auf die Detailtiefe geeinigt, gilt es, die Datenlieferanten zur vollständigen
und zeitnahen Bereitstellung zu verpflichten. Ist ein Datenlieferant jedoch für die CMDB
gleichzeitig einziger Nutzer der bereitgestellten Informationen, haben diese dort nichts verloren.
Es ist wichtig, sich die CMDB als Datendrehscheibe für alle Nutzer und Prozesse vorzustellen, wobei
jeder Lieferant die CI-Informationen anreichert und eine andere Sicht auf die Daten nutzt.
Schnittstellen einbauen
Als integratives Werkzeug benötigt die CMDB Update-Schnittstellen zur Discovery, zu externen
Administrations- und Monitoring-Tools sowie zu prozessunterstützenden Werkzeugen, die
CI-Informationen verändern oder ergänzen. Hier reicht es nicht, mit Copy and Paste oder mit
manuellen Ex- und Importen zu arbeiten. Der Datenabgleich sollte regelbasiert und zuverlässig immer
zu den gleichen Zeiten ablaufen. Nur aktuelle, vollständige und richtige Daten erhalten das
Vertrauen in die Inhalte der CMDB aufrecht.
Ob Discovery-Mechanismen für die Befüllung der CMDB nötig sind, hängt von der Größe des
Unternehmens und der Datenhaltung ab. Manche Attribute lassen sich noch manuell erfassen oder über
Werkzeuge wie Microsoft SMS auslesen. Eine vollständige Discovery geht jedoch darüber hinaus und
erkennt auch Abhängigkeiten zwischen CIs. Dieser Fähigkeit sind jedoch dort Grenzen gesetzt, wo
Unternehmen viele selbst entwickelte Anwendungen einsetzen, die von marktüblichen Discovery
Patterns nicht erkannt werden.
Zwar sind moderne Discovery-Werkzeuge lernfähig, jedoch muss der "Trainingsaufwand" in
Relation zum Nutzen stehen. Wo Discovery nicht das probate Mittel ist, bleibt nur der Weg über
prozessgesteuerte Änderungen. Beispielsweise kann der softwaregestützte Change-Prozess gleichzeitig
mit der erfolgreichen Umsetzung von Changes die CI-Updates übernehmen. Selbstverständlich sind
diese CMDB-Änderungen über Prozesse in regelmäßigen Abständen über Audits und Stichproben zu
verifizieren.
Die Befüllung der ersten CMDB-Keimzelle, beispielsweise physische Server, sollte bereits
einen sichtbaren Nutzen generieren. Diese Anfangserfolge geben dem CMDB-Projekt die notwendige
Dynamik, um sukzessive weitere CI-Typen aufzunehmen: virtuelle Server, Anwendungen,
Netzwerkkomponenten, schließlich auch IT-gestützte Business-Services. Idealerweise orientiert man
sich dabei am OSI-Schichtenmodell und nimmt immer benachbarte CI-Typen hinzu, da mit diesen in der
Regel auch die Beziehungen bestehen.
In den letzten Jahren hat leistungsfähigere CMDB-Technik die Verbreitung so genannter "
Federated CMDBs" begünstigt. Im Gegensatz zur klassischen Datenreplikation verbleiben hier viele
CI-Informationen auf ihre Quellsysteme verteilt. Zum Zugriffszeitpunkt wird dann aus den aktuellen
Daten die Gesamtsicht auf das CI und seine Relationen aufgebaut. Für den Nutzer ist der
unterschiedliche Datenursprung nicht erkennbar.
Diese Federation bietet sich überall dort an, wo Sichten auf stark volatile Daten (zum
Beispiel aus dem Monitoring) im CI- oder Service-Zusammenhang erforderlich sind. Das kann der
Auslastungsgrad eines SAN-Laufwerks sein, die Prozessorlast eines Anwendungs-Servers oder die
aktuelle Datendurchsatzrate in einem LAN-Segment.
Der Nachteil föderierter Systeme ist, dass sich die (Hoch-)Verfügbarkeitsanforderung dann
nicht mehr nur auf eine CMDB, sondern auf alle vorgelagerten Datenbanken bezieht, was zum Aufbau
sehr kostspieliger Strukturen führen kann.
Zwischen der CMDB und dem Change-Management existiert eine sehr enge Verbindung. Unternehmen,
die nicht beides gleichzeitig einführen können oder wollen, müssen eine Reihenfolge bestimmen.
Dabei gilt: Keine CMDB ohne Change-Management, wohl aber ist Change-Management ohne eine CMDB
möglich. Man kann das Change-Management auch als Pflegeprozess für die CMDB betrachten, da sich
durch Changes die in der CMDB gespeicherten Konfigurationsinformationen ändern. Die Dokumentation
dieser Änderungen in einer CMDB ist also sinnvoll, aber nicht zwingend. Ist aber eine CMDB
vorhanden, müssen Änderungen auf jeden Fall einem Change-Management-Prozess unterworfen sein. Nur
so lassen sich beispielsweise unautorisierte Changes auf-decken.
CMDB-Zugriff
Die Sicht auf die Infrastruktur und der CMDB-Zugriff müssen direkt aus dem Change-Management
heraus erfolgen können, ohne dafür das Tool zu wechseln. Der Change-Planer muss unmittelbar
erkennen, welche Auswirkungen die geplante Änderung auf verbundene CIs, SLAs oder parallel
angesetzte Changes hat.
Jeder Change hat potenziell Auswirkungen auf Verfügbarkeiten, Kapazitäten, Produktionsmengen
in der IT, aber auch auf Geschäftsprozesse, die sich auf die IT stützen. Alle Auswirkungen bergen
Risiken, die nur bei sorgfältiger Planung und Kenntnis aller Zusammenhänge beherrschbar sind. Wenn
eine CMDB von so zentraler Bedeutung ist, warum gibt es dann keinen Marktstandard? Die Antwort: Es
gibt einen – oder zumindest Ansätze dafür. Die DMTF hat zum Thema Federation eine eigene
Arbeitsgruppe ins Leben gerufen, in der sich große CMDB-Hersteller mühevoll, aber erfolgreich auf
einen Standard (CMDBf) geeinigt haben. Da aber in vielen Punkten unterschiedliche Technik für
CMDB-Funktionen zum Einsatz kommt, sieht jeder Hersteller sein eigenes Produkt als Standard.
Hinzu kommen Weiterentwicklungen der zugrundeliegenden Theorie: So spricht ITILv3 nicht mehr
von einer CMDB, sondern verwendet bewusst den Begriff CMS (Configuration Management System).
Aber ob CMDB oder CMS: Die Krux bei beiden ist, dass sie sehr komplexe Gebilde ohne
standardisierten Aufbau sind. Daher empfiehlt sich die Zusammenarbeit mit erfahrenen externen
Beratern, die bereits entsprechende Projekte durchgeführt haben und die Fallstricke kennen. So
lassen sich kostspielige Kardinalfehler wie das unnötige Aufblähen der CMDB wegen zu groß gewählter
Detailtiefe von Anfang an vermeiden.
Zehn goldene Regeln für CMDB-Projekte
- Daten auf Prozessnutzen prüfen
- Kritischer Erfolgsfaktor Vollständigkeit
- Kritischer Erfolgsfaktor Aktualität
- CMDB-Datenlieferanten ermitteln und verpflichten
- CMDB-Datenkonsumenten ermitteln und Vertrauen aufbauen
- Datenmodell an Standard anlehnen
- Datenmodellierung in mehreren Stufe aufbauen
- Einführung erst als "Meta-Directory"
- Vertrauen bei den Anwendern schaffen
- Externen Berater als erfahrenen Vermittler zwischen den Silos nutzen
Martin Hagenauer ist Senior Consultant bei Materna in Dortmund.
Lesen Sie mehr zum Thema
