CMDB erfolgreich einführen – ein Anwendungsfall

In unserem vorherigen Blogpost haben wir bereits geklärt was eine CMDB ist und wofür sie eingesetzt werden kann.

Nachfolgend klären wir wie wichtig eine erfolgreiche und gut strukturierte Einführung einer CMDB im Unternehmen ist und verdeutlichen das an einem konkreten Anwendungsfall.

Step by Step

Zunächst einmal, seien Sie sich bewusst, dass Sie Aufwand sowohl für die Implementierung der CMDB als auch für die anschließende Wartung einplanen müssen. Die darin enthaltenen Daten müssen aktuell gehalten werden, denn sonst hilft die beste CMDB nicht im täglichen Business.

Sollten Sie mit dem Gedanken spielen, eine CMDB einzuführen, stellen Sie sich zunächst die Frage welchen Nutzen diese haben soll:

• Wie kann die CMDB nützlich sein?
• Wer arbeitet mit der CMDB?
• Welche geschäftlichen Bedürfnisse sollte sie unterstützen?
• Welche Erwartungen sind mit einer Einführung verbunden?

Kurzum: Welches Ziel visieren Sie mit der Einführung einer CMDB an?

Weiterhin ist es hilfreich, einen Verantwortlichen für das Configuration Management zu benennen. Dieser kann zusammen mit einem interdisziplinär zusammengestellten Team die notwendigen Fragen beantworten und das Projekt ins „Rollen“ bringen. Nachdem die Configuration Items erfasst wurden, sollte ein Prozess für die Pflege der in der CMDB enthaltenen Daten definiert werden. Denn wie bereits erwähnt, nützt die beste CMDB nichts ohne aktuelle Daten.

Bestandteile einer CMDB

Ein Configuration Item ist nach ITIL^® V3 „ein Asset, eine Service Komponente oder ein Objekt, das unter der Kontrolle des Configuration Managements steht oder stehen wird“. In welchem Umfang CIs erfasst werden sollten, beschreibt ITIL^® V3 wie folgt: „Configuration Items sollten anhand erprobter Selektionskriterien ausgewählt, gruppiert, klassifiziert und identifiziert werden, sodass es während des gesamten Service Lifecycle möglich ist, sie zu verwalten (managen) und nachzuverfolgen (trace).“ Kurzum: Ein Asset kann etwas sein, was zur Erbringung eines Service benötigt wird. Wenn das Asset verwaltet wird, wird es als Configuration Item geführt.

Was also sollte in einer CMDB enthalten sein? Dazu gibt es einige knappe Thesen zur Orientierung:

• Erfassen Sie, was notwendig ist.
• Erfassen Sie nichts, was nicht benötigt wird.
• Erfassen Sie lediglich, was gemessen werden kann.

Als Faustformel gilt: Haben Sie immer den Pflegeaufwand der Daten im Auge!

Eine CMDB besteht in der Regel aus den folgenden Komponenten:

• Configuration Items
• Komponenten
• Attributen
• Relationen

Vermeintlich kompliziert, aber hilfreich strukturiert

In der Umsetzung kann die Einführung einer CMDB wie folgt aussehen:
Ein Cloudanbieter hat die OTRS CMDB eingeführt und nahezu sein gesamtes Rechenzentrum an eine CMDB angebunden, was zu sehr detaillierten CI-Klassen führt.

Dieses Unternehmen hat sich zu einer für sich sehr detaillierten CMDB entschieden. Das bedeutet, die erste CI-Klasse sind „Standorte“. Ein Firmenstandort kann wiederum aus mehreren Gebäuden bestehen. Ein „Gebäude“ kann wiederum eine CI-Klasse darstellen. In einem dieser Gebäude gibt es mehrere Räume, wie zum Beispiel Serverräume. Ein solcher Serverraum besteht aus mehreren Cubes, in denen einzelne Server Racks vorhanden sind, die auch wieder eine CI-Klasse darstellen. Ein sogenannter Server Rack besteht aus mehreren Höheneinheiten (dt. HE / engl. Height Unit (HU)). In einer oder mehreren Höheneinheiten befinden sich die Server und Netzwerkgeräte, wie Switch, Router, usw. Server und andere Geräte bestehen aus Netzwerkkomponenten, die eine oder mehrere IP-Adressen vergeben bekommen haben. Diese IP-Adressen sind wiederum als Assets in einer entsprechenden CI-Klasse abgebildet. Die IP-Adressen als einzelne CIs sind somit über ihren Status übersichtlich dargestellt. Dadurch ist es möglich zu erkennen, welche IP-Adressen noch frei sind und welche bereits belegt. Bei der Menge an IP-Adressen, die der Cloudanbieter zur Verfügung hat, ist eine solche Übersicht dringend notwendig.

Die Relation der CI-Klassen untereinander ist durch das OTRS Feature AddOn „CI References“ gewährleistet und wird zudem als Attribut direkt gespeichert. Dadurch lässt sich darstellen, dass eine IP-Adresse zu einer Netzwerkkomponente gehört oder, dass ein Server Rack, bestehend aus mehreren Höheneinheiten, in einem Cube steht, der wiederum zu einem Raum gehört, der sich in einem Gebäude befindet. Das gewährleistet dem Cloudanbieter einen stetigen Überblick über die im Rechenzentrum für den Betrieb vorhandenen und freien IP-Adressen und Co.

Insbesondere für das IT Service Management ist diese Art der Handhabung besonders hilfreich. Durch Monitoring werden die Geräte überwacht. Durch die Verknüpfung ist es möglich, eine Beeinträchtigung von CI-Klassen oder Services durch Betroffene unmittelbar zu erkennen.

Unabhängig davon, ob Sie eine CMDB auf herkömmliche Weise (wie im obigen Beispiel oder als Teil einer Software-Lösung für IT Service Management oder auf erweiterte Weise (z. B. für die Verfolgung der Flotten- oder Anlageninfrastruktur) verwenden, sollten Sie bedenken, dass eine CMDB im Grunde eine „unendliche Geschichte“ ist, die Ihrem Unternehmen hilft, die Daten zu finden, die es heute und in Zukunft zur Wertschöpfung benötigt.

Halten Sie sich stets vor Augen: Eine CMDB ist im Grunde eine „never ending story“.