Setze einen Ablauf für CMDB-Änderungen. So bleiben Servicefolgen sichtbar

Eine CMDB klingt nach Datenbankarbeit. Im Betrieb entscheidet sie aber oft darüber, ob eine Änderung nur ein System verändert oder einen ganzen Service trifft. Wenn diese Folge nicht sichtbar ist, wirken Freigaben sauberer, als sie wirklich sind.

CMDB steht für Configuration Management Database. Gemeint ist eine Datenbasis, in der wichtige IT-Bausteine und ihre Beziehungen abgebildet werden. Dazu gehören zum Beispiel Server, Anwendungen, Datenbanken, Schnittstellen, Netzkomponenten, Cloud-Ressourcen und die Services, die darauf aufbauen. Für ITSM-Generalisten ist die CMDB deshalb kein reines Inventar. Sie soll zeigen, welche Änderung welche Servicewirkung haben kann.

Eine Änderung braucht mehr als ein technisches Objekt

Ein einzelner Servername sagt wenig darüber aus, wer betroffen ist. Auch eine Datenbank, ein Zertifikat oder ein Netzwerksegment wirkt im Change-Ticket oft kleiner, als es im Alltag ist. Erst die Verbindung zum Service macht sichtbar, ob ein interner Hilfsdienst, ein Kundenportal, eine Schnittstelle zum Provider oder ein Meldeweg im Service Desk berührt wird.

Genau hier scheitert die CMDB häufig nicht an der Technik, sondern am Ablauf. Ein Team aktualisiert die technische Komponente, ein anderes pflegt den Servicekatalog, ein drittes bewertet Betriebsrisiken. Wenn niemand festlegt, wann eine Änderung die Beziehungen in der CMDB prüft, entstehen stille Lücken. Beim nächsten Ausfall sucht der Betrieb dann nicht nur die Ursache, sondern auch den Zusammenhang.

Der Ablauf muss vor der Freigabe greifen

Atlassian beschreibt eine CMDB als Werkzeug, um IT-Assets, Konfigurationselemente und deren Beziehungen zu verwalten. IBM ordnet die Configuration Management Database ebenfalls als Grundlage ein, um Abhängigkeiten und Auswirkungen im IT-Betrieb besser zu verstehen. Freshworks stellt den Nutzen ähnlich dar: Eine CMDB soll nicht nur Objekte sammeln, sondern Beziehungen, Eigentümer und Servicekontext sichtbar machen. Für den Change-Prozess folgt daraus eine einfache Regel. Die Beziehungsprüfung gehört vor die Freigabe, nicht erst nach dem Go-live.

Praktisch heißt das: Jedes Change-Ticket braucht einen kurzen Kontrollpunkt zur CMDB-Wirkung. Der Antragsteller benennt, welches Objekt verändert wird. Der Service Owner oder eine klar definierte Betriebsrolle prüft, welche Services, Schnittstellen und Betriebszeiten daran hängen. Wenn die Beziehung fehlt, wird sie ergänzt oder als bewusst unbekannt markiert. Nur dann ist später nachvollziehbar, ob ein Risiko übersehen wurde oder ob eine bekannte Lücke akzeptiert war.

So sieht ein brauchbarer CMDB-Änderungsablauf aus

• Lege fest, welche Change-Arten immer eine CMDB-Prüfung auslösen, zum Beispiel Serverwechsel, Datenbankumzug, Zertifikatswechsel, Firewall-Regel, Cloud-Ressource oder Schnittstellenänderung.
• Trenne Objektpflege und Servicewirkung. Ein technischer Owner kennt das System, der Service Owner kennt die Auswirkung auf Nutzer und Kunden.
• Nutze im Ticket ein Pflichtfeld für den betroffenen Service, aber kein langes Formular mit unklaren Spezialwerten.
• Dokumentiere fehlende Beziehungen offen. Eine bekannte Lücke ist besser als eine scheinbar vollständige CMDB.
• Prüfe nach größeren Änderungen stichprobenartig, ob Servicekatalog, Bereitschaftsplan und Eskalationsweg noch zur CMDB passen.

Der wichtigste Punkt ist die Reihenfolge. Wer die CMDB erst nach der Umsetzung bereinigt, macht sie zur Nachdokumentation. Wer sie vor der Freigabe nutzt, macht sie zum Steuerungsinstrument. Das ist besonders wichtig bei hybriden Umgebungen, in denen Cloud-Dienste, Providerleistungen, lokale Systeme und SaaS-Anwendungen gemeinsam einen Service tragen.

Servicefolgen müssen für den Betrieb lesbar bleiben

Eine gute CMDB-Frage lautet nicht: Ist das Objekt vorhanden? Besser ist: Sieht der Betrieb, welcher Service leidet, wenn dieses Objekt ausfällt oder geändert wird? Diese Frage zwingt zu einem anderen Blick. Es geht nicht um Vollständigkeit als Selbstzweck, sondern um verwertbare Zusammenhänge für Priorisierung, Kommunikation und Wiederanlauf.

Wenn ein Zertifikat ausläuft, muss der Service Desk wissen, welches Portal betroffen ist. Wenn eine Firewall-Regel geändert wird, muss sichtbar sein, welche Schnittstelle danach getestet werden muss. Wenn ein Cloud-Speicher verschoben wird, muss klar sein, welcher Bericht, welche Anwendung oder welcher Kunde davon abhängt. Ohne diese Servicefolie bleibt die CMDB eine technische Liste. Mit ihr wird sie zu einem praktischen Frühwarnsystem.

Der kleine Prozess schützt vor großen Suchzeiten

Der Ablauf muss nicht schwer sein. Ein kurzer CMDB-Kontrollpunkt im Change-Ticket, eine klare Zuständigkeit und eine sichtbare Markierung für ungeklärte Beziehungen reichen oft für den Anfang. Wichtig ist, dass die Prüfung regelmäßig passiert und nicht nur nach Audits oder großen Störungen.

So bleibt die CMDB nah am Betrieb. Änderungen zeigen früher, welche Services betroffen sind. Freigaben bekommen eine bessere Grundlage. Und im Störfall verliert das Team weniger Zeit mit der Frage, welche technische Änderung plötzlich beim Kunden ankommt.

Quellen und Einordnung: Atlassian zur CMDB im ITSM-Kontext, IBM zur Configuration Management Database, Freshworks zur CMDB und Servicebeziehungen. Stand der Quellenprüfung: 24.07.2026. Bildquelle: Pexels / Foto-ID 270404 / C00 Lizenz.