CMDB: Wenn die Lösung zum Problem wird...

von Jürgen Höfling

Share
30.03.2009

…dann ist beim Aufbau einer Configuration Management Database (CMDB) einiges schief gelaufen. »Ich stecke knietief in über 300 000 Configuration Items und habe jetzt das Problem zu entscheiden, was ich damit mache«, zitiert Klaus Dettmer, Produktmanager beim Servicemanagementanbieter iET Solutions eine Stimme aus dem Off, will heißen: einen Teilnehmer aus einem Workshop, den das Unternehmen kürzlich mit seinen Kunden durchführte.

(Fortsetzung des Artikels von Seite 3)

(Bild: Gerd Altmann, pixelio)

In der Theorie ist die Sache ja ziemlich klar: IT-Dienstleistungen, sei es nun die Bereiststellung von Anwendungen oder die Fehlerbehebung, können angesichts der Komplexität heutiger IT-Architekturen nicht mehr ohne umfangreiche informationstechnische Hilfsmittel bereitgestellt werden. Im Mittelpunkt sollte dabei als Datendrehscheibe eine »Configuration Management Database« (CMDB) stehen, in der nicht nur alle Systeme und Komponenten einschließlich ihrer Einstellungen gespeichert sind, sondern idealer Weise auch logische Modelle der IT-Infrastruktur und IT-Services.

Für den sinnvollen Aufbau einer solchen Datenbank als Drehscheibe des IT- und Business-Servicemanagements müssen die Unternehmen erst einmal wissen, was sie an IT-Infrastruktur (Hardware und Software) überhaupt haben. Nur nach einer solchen Bestandsaufnahme lässt sich erkennen, wie die einzelnen IT-Gerätschaften zusammenhängen und was es für einen bestimmten Geschäftsprozess bedeutet, wenn ein Teil davon ausfällt. Wenn die eben beschriebenen Hausaufgaben gemacht sind, kann man eigentlich nicht mehr »knietief« in unverstandenen Items herumwaten.

Leider sind die Hausaufgaben aber oft nur halb oder gar nicht gemacht. Das kann fatal sein, denn eine schlecht gepflegte CMDB, in der nicht das ganze IT-Inventar verzeichnet ist oder in der Beziehungen nicht vollständig abgebildet sind, ist schlechter als gar keine.

Strukturieren, Restringieren und Relationieren

Aber gehen wir einmal von einer CMDB aus, die komplett und qualitätsmäßig gut in Schuss ist. In diesem Fall ist ein Incident, der beispielsweise vom Monitoring-System dem Servicedesk-Mitarbeiter gemeldet wird, einem passenden Datensatz zuordenbar, sodass der Mitarbeiter eine eindeutige Meldung erhält. »Das Monitoring-System sollte dabei so ausgelegt sein, dass über intelligente Korrelationsalgorithmen ein Ereignis-Hagel wegen eines einzigen Fehlers, verhindert wird«, mahnt Uwe Flagmeyer, Leiter Presales HP Software Deutschland.

Falls die Störungsmeldung oder Beschwerde von einem Anwender kommt (»Der Mail-Client braucht zwei Minuten, um eine Mail anzuzeigen«), dann muss der Servicedesk zusammen mit dem Anwender das Problem eingrenzen und möglichst exakt identifizieren. Auch hierbei kann eine gut gepflegte CMDB helfen, wenn komplexere Beziehungen, wie beispielsweise ein Bestellprozess als Datenbankeintrag vorhanden sind.

Strukturieren, Restringieren und Relationieren sind deshalb die Vorschläge von Roger Gloor, Director Business Service Management Central Europe bei Novell. Die Datenflut müsse »von einem Ausgangspunkt aus gezielt eingeschränkt werden«. Beispielsweise dürften bei einem Störfall im CRM-Service nur diejenigen CIs angezeigt werden, die für den betreffenden Service konstitutiv seien. Zusätzlich müsste den Anwendern ein einfaches und intuitives Interface zur Verfügung gestellt werden, mit dem sie gezielt Daten wiederfinden könnten.

Vergangenheit und Zukunft im Griff

Automatische Suchwerkzeuge sind unabdingbar, um die verschiedenen IT-Bestandteile und bestimmte Service-Beziehungen leicht auffinden zu können. Wichtig ist aber auch das Visualisieren von Abhängigkeiten, damit Administratoren und Servicedesk-Personal auf einen Blick sehen können, was für Auswirkungen eine bestimmte Störung hat oder was für Auswirkungen ein bestimmter Änderungsprozess haben könnte.

Einige neue Wege bei der Visualisierung geht jetzt die USU-Tochter Omegasoft. Die Datenbank myCMDB ist aus dem Discovery-Werkzeug »Insel« heraus entstanden und stellt die in Abhängigkeit stehenden Daten wie Config-Items, Vertragszuordnungen oder Lizenzangaben in einem optisch übersichtlichen Baumgeflecht dar, in das zusätzlich auch noch eine Zeitachsen-Perspektive integriert ist. Dadurch haben die Servicedesk-Mitarbeiter nach den Worten von Omegasoft-Vertriebsleiter Wolfgang Ottmar »Vergangenheit und Zukunft im Griff«.

Geschäftszweck als CMDB-Richtschnur

Trotz aller schönen und intelligenten Visualisierungen gibt es nicht den allein gültigen Weg zur CMDB, denn in den einzelnen Abteilungen eines Unternehmens herrschen unterschiedliche Sichtweisen und Anforderungen. Deshalb darf eine CDMB nicht proprietäre Systeme einzelner Gruppen abbilden, sondern muss Informationen zusammenzuführen, die für den Geschäftszweck (über)lebenswichtig sind. Insofern gibt es zwar keinen idealen Weg zu einer CMDB, aber doch einen deutlich markierten Pfad. Wenn dieser verpasst wird, dann kann es geschehen, dass man »knietief in den Configuration Items steckt« und sich denkt, dass hier die Lösung das Problem ist.

Eine deutlich erweiterte Fassung dieses Texts mit weiteren Praxisbeispielen und Argumentationen lesen Sie in der April-Ausgabe der InformationWeek. Erscheinungstag: 23. April 2009!
Verwandte Artikel