Was ist eine CMDB (Configuration Management Database)?

Eine CMDB (Configuration Management Database) ist eine Datenbank, die Informationen über die IT-Assets einer Organisation speichert - Server, Anwendungen, Netzwerktechnik, Desktop-Computer - und vor allem die Beziehungen zwischen ihnen. Jeder Eintrag ist ein Configuration Item (CI) mit eigenen Attributen, und jedes CI ist mit dem verknüpft, worauf es läuft, wovon es abhängt oder womit es verbunden ist. Die Beziehungsdaten trennen eine CMDB von einem einfachen Asset-Register: Sie beantworten nicht nur „was besitzen wir”, sondern „was fällt aus, wenn dies ausfällt”.

Wofür CMDB steht und woher der Begriff kommt

CMDB steht für Configuration Management Database. Der Begriff stammt aus Frameworks für IT Service Management (ITSM) wie ITIL, wo die CMDB der zentrale Speicher ist, der den Configuration-Management-Prozess trägt. In der Praxis wirkt sie als Data-Warehouse für Ihre IT-Umgebung: Jede verwaltete Komponente wird als Configuration Item erfasst, und die Datenbank hält sowohl die Attribute des Elements als auch seine Verknüpfungen zu allem ringsum. Die zweite Hälfte - die Beziehungen - macht sie zur CMDB und nicht zu einer Tabelle voller Geräte. Es ist derselbe Unterschied, der eine CMDB vom umfassenderen IT-Asset-Management (ITAM) trennt, worauf wir unten zurückkommen.

Was als Configuration Item zählt

Ein Configuration Item (CI) ist jede Komponente, die sich eigenständig lohnt zu verfolgen. Typische Beispiele:

• Hardware-CIs - Server, Switches, Firewalls, Storage-Arrays, Endgeräte
• Software-CIs - Anwendungen, Datenbanken, Betriebssysteme, Middleware
• Virtuelle und Cloud-CIs - virtuelle Maschinen, Container, Cloud-Instanzen und -Services
• Service-CIs - die Geschäftsservices, die die Komponenten ergeben, z. B. „E-Mail” oder „Rechnungsstellung”

Jedes CI trägt Attribute (Name, Version, Umgebung, Verantwortlicher, Standort) und Beziehungen („läuft auf”, „hängt ab von”, „ist Teil von”). Der Detailgrad ist die erste Grundsatzentscheidung: Erfasst man jedes Kabel, erstickt die CMDB im Pflegeaufwand; erfasst man nur Server, beantwortet sie keine nützlichen Fragen. Eine gute Faustregel: nach Anwendungsfall abgrenzen, nicht nach Asset - taucht eine CI-Klasse nie in einem Incident, einer Änderung oder einem Audit auf, lassen Sie sie weg.

Wie ein CMDB-Eintrag aussieht: ein Beispiel

Ein CMDB-Eintrag ist strukturierter als eine Zeile in einer Tabelle. Ein einzelner CI-Datensatz trägt in der Regel einen Namen oder eine ID, einen CI-Typ (Server, Anwendung, Datenbank, Netzwerkgerät, Cloud-Ressource), einen Status, die Umgebung, in der er läuft (Produktion, Staging, Entwicklung), einen Verantwortlichen und technische Felder wie IP-Adresse oder Version - und obendrein seine Beziehungen.

Ein konkretes Beispiel macht es greifbar. Ein CI namens app-prod-01 ist vom Typ Anwendung, liegt in der Produktion, gehört dem Zahlungsteam und trägt drei Beziehungen: Es läuft auf einer virtuellen Maschine, hängt ab von einer Zahlungsdatenbank und ist Teil von dem Checkout-Service. Rufen Sie diesen einen Datensatz auf, sehen Sie in einer einzigen Ansicht alles, worauf der Checkout-Service beruht. Multiplizieren Sie das über Hunderte von CIs, entsteht eine Service-Map - der Abhängigkeitsbaum hinter jedem Geschäftsservice, den die meisten CMDB-Werkzeuge für Sie zeichnen.

Beziehungen sind der Punkt

Nehmen Sie eine Kette: Die Rechnungsanwendung läuft auf einer virtuellen Maschine, die auf einem Host im Serverraum läuft, der über einen Switch angebunden ist. Muss dieser Switch ersetzt werden, sagt Ihnen die CMDB - noch bevor Sie etwas anfassen -, dass die Rechnungsstellung mit ausfällt. Das ist die Auswirkungsanalyse (Impact-Analyse), und sie ist der Hauptanwendungsfall der CMDB. Dieselben Daten helfen bei der Fehlersuche: Ist die Rechnungsstellung langsam, zeigt die CMDB jede darunterliegende Komponente, die sich zu prüfen lohnt - die Grundlage der Ursachenanalyse. Deshalb sind CMDBs in größeren IT-Organisationen fester Bestandteil von Change- und Incident-Management.

Warum CMDBs veralten - und wie Teams sie aktuell halten

Eine CMDB ist nur so gut wie ihre Aktualität, und der klassische Fehler ist bekannt: Sie wird einmal während eines Projekts befüllt und veraltet dann, während sich die Landschaft ringsum verändert. Praktiker sagen es gern offen - eine CMDB scheitert nicht beim Start, sie scheitert einige Monate später, wenn niemand sagen kann, wem ein bestimmter Datensatz gehört. Zwei Dinge halten sie ehrlich. Das Erste ist die automatische Discovery: Werkzeuge, die Netzwerk und Cloud-Konten scannen und CIs bei Änderungen der Infrastruktur aktualisieren, damit die Datenbank nicht von Hand gepflegt wird. Das Zweite ist klare Verantwortlichkeit: Jedes CI braucht einen benannten Verantwortlichen für seine Richtigkeit, und die kritischsten CIs werden nach einem Plan erneut geprüft. Ohne einen speisenden Change-Prozess veraltet eine CMDB schnell - genau deshalb passt sie zu Teams mit ausgereiften ITSM-Praktiken und selten zu Teams ohne solche.

CMDB vs. Asset-Register vs. ITAM

Die Grenze verläuft beim Zweck. Ein Asset-Register dient Eigentum und Geld: wer welches Gerät hat, was es gekostet hat, wann die Garantie endet, was bei der Disposition geschieht. Eine CMDB dient dem Betrieb: technische Konfiguration und Abhängigkeiten, zur Unterstützung von Änderungen und Störungen. ITAM ist die übergeordnete Disziplin; eine CMDB ist ein Werkzeug, das vor allem stark an ITSM ausgerichtete Teams nutzen. Kurz gesagt: ITAM sagt Ihnen, was Sie besitzen und was es kostet, während eine CMDB Ihnen sagt, wie es verdrahtet ist und was ausfällt, wenn Sie es anfassen. Beide überschneiden sich bei der Hardware selbst - derselbe Server taucht in beiden auf -, doch sie erfassen unterschiedliche Fakten. Lizenzansprüche und Verlängerungen gehören etwa in die Datensätze des Software-Lizenzmanagements, nicht in eine Abhängigkeitskarte.

Wann ein kleines Team wirklich eine braucht

Eine CMDB zahlt sich aus, wenn Sie Infrastruktur betreiben, von der andere Systeme abhängen, und Änderungen vornehmen, die eine Auswirkungsbewertung erfordern - eigene Server, eine Produktionsumgebung, alles mit Ausfallkosten. Sie zahlt sich nicht aus als erstes führendes System für ein Team, dessen Bestand aus Laptops, Smartphones und SaaS-Lizenzen besteht; dort geht es um Eigentum und Verlängerungen, und die größte Schwachstelle der CMDB - einmal befüllt und nie aktualisiert - trifft gerade Teams ohne Change-Prozess am härtesten. Für diesen Mehrheitsfall schlägt ein aktuelles Asset-Register eine veraltete CMDB, und ein Tool wie AMPthilly führt eines mit Eigentümern, Ausgaben, Dokumenten und Audit-Historie je Asset - ganz ohne Abhängigkeitskarte.

Verwandte Begriffe

• Software Asset Management - Verwaltung der Software-Seite der IT-Landschaft
• Software-Lizenzmanagement - wo Berechtigungen und Verlängerungen geführt werden
• Lizenz-Compliance - innerhalb der gehaltenen Lizenzbedingungen bleiben
• IT-Asset-Disposition - Hardware am Lebensende sicher ausmustern
• True-Up - die Lizenzabstimmung, die ein Vendor-Audit auslöst