Configuration Management Database

Ein Configuration Item (CI) ist jede Komponente, die verwaltet werden muss, um einen Dienst bereitzustellen. Dazu gehören ein Server, eine Workstation, ein Netzwerk-Switch, eine Anwendung, ein Datenbankschema, eine Lizenz, ein Vertrag oder die Dokumentation, die beschreibt, wie all das zusammenhängt. Jedes CI hat Attribute wie Eigentümer, Standort, Version, Seriennummer und Lifecycle-Status. In den meisten Konzepten wird außerdem eine Historie seiner Zustände geführt.

Das entscheidende Merkmal einer CMDB ist, dass Beziehungen genauso wichtig sind wie die Elemente selbst. Ein CI-Datensatz sagt, was eine Komponente ist. Eine Beziehung sagt, dass die Gehaltsabrechnung auf einem bestimmten Cluster läuft, dieser Cluster von einem Storage-Array abhängt und eine Filiale über einen bestimmten Router angebunden ist. Zusammen bilden diese Verknüpfungen einen Abhängigkeitsgraphen. Er beantwortet Fragen, die eine einfache Liste nicht beantworten kann: Wenn dieses Gerät ausfällt, welche Dienste stehen dann still und wer ist betroffen?

Im IT-Service-Management ist die CMDB der Bezugspunkt, in den andere Prozesse schreiben und aus dem sie lesen. Das Incident-Management verknüpft jeden Incident mit den betroffenen CIs. Das beschleunigt die Triage und macht wiederkehrende Störungen an derselben Komponente sichtbar. Das Problem-Management analysiert diese Häufungen, um Ursachen zu finden. Das Change-Management ist der wichtigste Schreibprozess: Ein genehmigter Change hält fest, welche CIs er betrifft, und die CMDB soll den neuen Zustand nach Abschluss des Changes abbilden.

Der Abhängigkeitsgraph macht aus Datensätzen Entscheidungen. Vor der Genehmigung eines Changes lässt sich sein Wirkungsradius abschätzen, indem man den Beziehungen von den betroffenen CIs nach außen folgt. Nach einem Incident zeigt derselbe Weg, was auf Folgeschäden zu prüfen ist. Eine CMDB, die nur bei Audits genutzt wird, liefert nur einen Bruchteil dieses Nutzens.

Beide hängen zusammen, beantworten aber unterschiedliche Fragen. Eine Asset-Inventarisierung, ein Kernbestandteil des IT-Asset-Managements (ITAM), zeigt, was die Organisation besitzt, wo sich ein Asset befindet und wer dafür verantwortlich ist. Ihre Hauptnutzer sind Finanzen, Einkauf und Facility-Management. Eine CMDB zeigt, wie Komponenten zusammenhängen und was eine Änderung an einer davon bewirkt. Ihre Nutzer sind die Incident-, Problem- und Change-Teams.

In der Praxis ist die Grenze fließend. Viele Organisationen beginnen mit einem einfachen Inventar und ergänzen Beziehungen, sobald ihre Service-Management-Prozesse reifen. Ein einfacher Test gilt: Ein Repository, in dem nichts mit etwas anderem verknüpft ist, ist eine Inventarisierung mit zusätzlichen Feldern, egal wie man es nennt.

Die meisten CMDBs kombinieren automatisierte Discovery mit manueller Pflege der Datensätze. Discovery nutzt agentenbasierte Erfassung, Netzwerk-Scans und Integrationen mit Cloud- und Verzeichnisplattformen. Sie findet, was tatsächlich existiert, und erkennt Abweichungen zwischen erfasstem und realem Zustand. Verträge, Servicedefinitionen und andere Elemente, die sich nicht scannen lassen, werden manuell erfasst und gepflegt.

Wenn mehrere Tools jeweils einen Teil der Wahrheit halten, führt die CMDB sie zusammen oder gleicht sie ab. Für jeden Attributtyp wird eine Quelle als maßgeblich festgelegt. Konflikte werden nach Regel gelöst, nicht durch Diskussion. Genauigkeit ist das Ergebnis eines laufenden Prozesses, keine einmalige Datenübernahme. Ohne benannten Eigentümer verfällt sie schnell.

In Anexet Inventory listet die Workstation-Karte die Geräte und installierten Anwendungen mit Gerätetyp, Hersteller, Version und Installationsdatum auf. Solche Datensätze sind das Rohmaterial, aus dem eine CMDB ihre Konfigurationselemente bildet.

1 / 2

• 
• 

Das Fehlermuster ist ein bekannter Verlauf. Der anfängliche Umfang deckt alles auf einmal ab, sodass das Projekt in Datenqualitätsarbeit versinkt, bevor etwas geliefert wird. Datensätze werden nur aktualisiert, wenn jemand daran denkt. Mit der Zeit stimmt die Datenbank nicht mehr mit der Realität überein, und die Mitarbeiter vertrauen ihr nicht mehr. Dann ist sie technisch am Leben und praktisch tot. Die folgenden Praktiken trennen die Umsetzungen, die überleben, von den anderen.

Eine CMDB sind Referenzdaten, kein Sammler. Sie beobachtet die Umgebung selten selbst, sondern bündelt, was Discovery-, Monitoring- und Management-Tools melden. Im Gegenzug bereichert sie diese Tools. Monitoring-Alarme erhalten Kontext darüber, was ein Host ist und welchem Dienst er dient. Sicherheitsuntersuchungen beginnen mit einer bekannten Karte dessen, was existieren sollte. Die Wiederherstellungsplanung weiß, welche Komponenten in welcher Reihenfolge zurückzuholen sind.

Ihre Grenzen ergeben sich aus demselben Konzept. Eine CMDB erkennt keine Eindringlinge, steuert keine Geräte und ersetzt nicht die Sichtbarkeit der Endpoints. Sie zeigt der Organisation, wie ihre Umgebung aussehen sollte, damit andere Kontrollen interpretieren können, was sie sehen. Kontrollen wie Data Loss Prevention setzen dort an, wo Daten tatsächlich bewegt werden, wie die Tabelle zeigt.

Man beginnt mit den Diensten, deren Ausfall das meiste kosten würde, und modelliert die Komponenten, von denen sie abhängen. Die Nähe des Modells zur Realität ist die eigentliche Disziplin des Configuration Managements, deshalb sollte man erst erweitern, wenn ein Genauigkeitsaudit bestanden ist.