CMDB – Configuration Management Database

Eine CMDB – Configuration Management Database ist das Inventar deiner IT-Welt, aber mit Beziehungen: nicht nur „Server srv-web01 existiert", sondern auch „srv-web01 läuft auf ESXi-Host-7, ist Teil der Anwendung Shop-Frontend, wird von Switch core-3 versorgt und beherbergt die Datenbank kunden_db_prod". Solche Beziehungen sind entscheidend, sobald du Fragen beantworten musst wie: „Wenn wir Switch core-3 in der nächsten Nacht patchen – welche Services sind betroffen?" oder „Welche Server hängen am Vertrag mit Lieferant X, dessen Wartungsfenster nächstes Quartal endet?" In der Praxis ist die CMDB die Kartographie deiner IT – jedes Element ist ein Punkt, jede Abhängigkeit eine Linie. Diese Lektion zeigt, was Configuration Items (CIs) sind, welche Beziehungen es gibt, wie die CMDB als Werkzeug für Impact-Analysen genutzt wird, und warum die Hauptschwierigkeit nicht der Aufbau, sondern die Pflege ist.

1) Configuration Item (CI) – die kleinste Einheit

Ein CI – Configuration Item ist alles, was unter Configuration Management läuft: Hardware (Server, Switch, USV), Software (Anwendungen, Versionen), Services, Dokumente, Verträge, manchmal sogar Geschäftsprozesse. Jedes CI hat:

• Eindeutige Identifikation – z. B. CI-SRV-00428. Wird nie wiederverwendet, selbst wenn das Element ausgemustert ist.
• Typ / Klasse – Server, Netzwerkkomponente, Software, Service.
• Attribute – Hersteller, Modell, Seriennummer, IP, Standort, Garantie-Ende, Owner.
• Status – „In Betrieb", „in Test", „außer Betrieb", „in Reparatur".
• Beziehungen zu anderen CIs.
• Lifecycle-Historie – wann beschafft, eingebaut, letztes Update, ausgemustert.

Die Schwierigkeit: Granularität. Ist „Notebook" ein CI – oder sind „CPU", „RAM", „Display", „Akku" einzelne CIs? Faustregel: ein CI ist alles, was du einzeln verwalten, austauschen oder bewerten musst. Ein RAM-Riegel im internen Server ist nur dann ein eigenes CI, wenn dessen Garantie/Status separat erfasst werden muss.

2) Beziehungen – das Herzstück

Ohne Beziehungen ist die CMDB nur eine Liste – wie eine Excel-Tabelle. Erst die Beziehungen machen sie wertvoll. Klick die CIs an, um den Aufbau einer typischen kleinen Anwendungslandschaft zu sehen. Mit „Impact zeigen" siehst du, welche CIs betroffen wären, wenn das gewählte CI ausfällt:

3) Beziehungstypen – was steht zwischen den Knoten?

4) Wer braucht die CMDB? Die Anwendungsfälle

Eine CMDB ist Aufwand. Welche konkreten Praxisnutzen rechtfertigen ihn?

1. Impact-Analyse vor Changes. Bei jedem geplanten Change: „Was hängt an dem zu ändernden CI? Wer ist betroffen?" → CMDB liefert die Antwort in Sekunden statt in Tagen.
2. Wurzel-Analyse bei Incidents. „Drei Server sind down – haben sie etwas gemeinsam?" → CMDB zeigt: alle drei laufen auf dem gleichen Hypervisor.
3. Lizenzmanagement. Wo läuft welche Software in welcher Version? CMDB ist die Grundlage für saubere Lizenz-Compliance.
4. Compliance & Audits. Bei ISO-27001-Audit oder DSGVO-Anfragen: welche Systeme verarbeiten welche Daten? Welche Schutzmaßnahmen sind eingerichtet?
5. Kapazitäts- und Vertragsplanung. Welche Hardware läuft auf Wartung aus? Welche Server sind > 5 Jahre alt?
6. Onboarding/Übergabe. Neue Mitarbeiter sehen die Struktur. Bei Übergaben ist die CMDB die Brücke.

5) Wie wird die CMDB gefüllt – automatisch vs. manuell

Der Sündenfall vieler CMDB-Projekte: alles manuell pflegen wollen. Das funktioniert die ersten Wochen, danach veraltet die Datenbank schneller als man pflegen kann. Die heutigen CMDB-Produkte (ServiceNow CMDB, BMC Atrium, i-doit, Device42, ManageEngine) kombinieren mehrere Quellen:

• Discovery / Auto-Discovery – aktives Scannen des Netzwerks (per SNMP, WMI, SSH) findet Geräte und legt sie an.
• Agenten auf den Servern liefern Software-Inventar, Versionen, Patch-Stand. Häufig kombiniert mit Monitoring.
• Integrationen – CMDB zieht Informationen aus AD, vCenter, AWS/Azure-APIs, GitOps-Repos.
• Manuelle Eingabe – nur dort, wo automatisch nichts geht (Verträge, Geschäftsprozesse, Eigentümer-Zuordnungen).

Eine gute Faustregel: technische Attribute automatisch, organisatorische Attribute manuell. Eine IP-Adresse wird automatisch entdeckt; wer der Service-Owner ist, muss ein Mensch eintragen.

6) Federated CMDB – mehrere Quellen statt einer Mega-DB

Frühere CMDB-Ansätze wollten alle Daten in einer Datenbank. Das hat sich als unpraktisch erwiesen. Moderne Konzepte arbeiten federated: die CMDB selbst speichert nur das Wesentliche und referenziert externe „Authoritative Sources":

• Personaldaten → HR-System
• VMs → vCenter / Cloud-API
• Software-Versionen → Patch-Management-System
• Tickets → Ticket-System
• Verträge → Vertragsmanagement

Vorteil: keine Doppelpflege. Nachteil: viele Schnittstellen, jede ein potenzieller Synchronisations-Stolperstein.

7) Häufige Probleme

• Veraltete Daten. Die größte Sünde: CMDB-Einträge stimmen nicht mit Realität überein. Lösung: regelmäßige Discovery-Läufe, Verantwortlichkeit pro Datenfeld, Audits.
• Zu viel Detailtiefe. Wer jeden RAM-Riegel als CI erfasst, ertrinkt in Pflege. Auf den eigentlichen Zweck fokussieren.
• Keine Eigentümer. Wenn niemand für ein CI verantwortlich ist, verfault es. Pflicht: pro CI ein Owner, mindestens auf Kategorie-Ebene.
• CMDB als Selbstzweck. Die CMDB existiert für die Nutzung – Impact-Analyse, Change-Bewertung, Incident-Root-Cause. Wer eine baut, ohne dass sie aktiv genutzt wird, hat verloren.
• Datenschutz vergessen. CMDB enthält oft personenbezogene Daten (Owner, Nutzer, Mailadressen). Zugriffsrechte per RBAC, Aufbewahrungsfristen klären.

Zusammenfassung

Die CMDB (Configuration Management Database) ist das beziehungsreiche Inventar deiner IT. Atomare Einheit: das Configuration Item (CI) mit Identifikation, Klasse, Attributen, Status, Lifecycle-Historie und – am wichtigsten – Beziehungen zu anderen CIs (depends on, runs on, uses, ...). Hauptnutzen: Impact-Analyse vor Changes, Root-Cause bei Incidents, Lizenzmanagement, Compliance, Kapazitätsplanung. Gefüttert per Discovery (automatisch) + manuelle Pflege (für Organisatorisches wie Owner und Verträge). Modern federated – CMDB referenziert authoritative Sources statt selbst alles zu speichern. Tools: ServiceNow CMDB, BMC, i-doit, Device42. Größte Fehler: veraltete Daten, zu viel Detail, fehlende Eigentümer, CMDB als Selbstzweck. ITIL nennt die Practice Service Configuration Management; enge Beziehung zu Change Management und Problem Management.

Verwandte Lektionen: Change Management · Problem Management · Server-Dokumentation · und mehrWeitere relevante LektionenService Value SystemService Level ManagementMonitoring-KonzeptSPOFPatch-ManagementRBACKEDB