Die CMDB, der niemand traut

Es ist zwei Uhr morgens und eine kundenorientierte Anwendung ist ausgefallen. Der Bereitschaftsingenieur öffnet die CMDB, findet den Server und sieht einen Besitzer, der das Unternehmen vor einem Jahr verlassen hat. Die Datenbank, von der die Anwendung abhängt, ist überhaupt nicht erfasst. Was folgt, ist eine Runde von Telefonanrufen, eine Suche in gemeinsamen Tabellen und eine Debatte darüber, wer für was verantwortlich ist. Der Incident zieht sich hin, und am nächsten Morgen sagt jemand wieder: "Man kann sich sowieso nicht auf die CMDB verlassen."

Wir sehen oft das gleiche Muster. Die Konfigurationsdatenbank existiert, sie kostet wirklichen Aufwand, um sie zu pflegen, und trotzdem traut ihr niemand. Deshalb führen die Leute ihre eigenen Aufzeichnungen in Tabellen, Wikis oder in ihren Köpfen. Das schließt den Kreis: Je weniger die CMDB verwendet wird, desto weniger wird sie aktualisiert, und desto weniger verdient sie, vertraut zu werden. Dahinter stehen müde Menschen, die jedes Mal ein Bild der Infrastruktur von Grund auf neu aufbauen, wenn etwas kaputt geht.

Warum die üblichen Lösungen nicht anhalten

Die typische Reaktion ist ein Bereinigungprojekt. Ein Team verbringt Wochen damit, Aufzeichnungen zu überprüfen, die Daten sehen für eine Weile gut aus, und sechs Monate später ist alles wieder beim Alten. Das Problem ist nicht ein schlechter Import. Es ist die Art und Weise, wie Daten erstellt werden und wie sie altern.

• Manuelle Eingabe ohne Überprüfung. Mehrere Personen erstellen Elemente auf unterschiedliche Weise, und niemand überprüft, ob das Ergebnis sinnvoll ist.
• Keine Historie. Wenn ein Wert falsch ist, gibt es keine Möglichkeit, herauszufinden, wer ihn geändert hat, wann oder woher er stammt.
• Mehr als eine Wahrheit. Die Organisation hält eine primäre CMDB in einem Tool und operative Daten in einem anderen. Ohne eine zuverlässige Verbindung driften die Aufzeichnungen auseinander.
• Kein Feedback-Schleife. Inkonsistenzen treten zum ungünstigsten Zeitpunkt auf: während eines Incidents.

Eine bessere Art, über Datenqualität nachzudenken

Vertrauen in eine CMDB kommt nicht von der Perfektion. Es kommt von Transparenz. Die Leute werden auf Daten vertrauen, wenn sie sehen können, woher sie kommen, wann sie zuletzt bestätigt wurden und was falsch mit ihnen ist. Wir empfehlen, auf vier Prinzipien aufzubauen:

1. Automatisieren Sie, wo immer möglich. Discovery und Importe schlagen manuelle Kopien.
2. Jede Änderung hat einen Autor und eine Quelle. Versionshistorie ist die Grundlage für die Nachverfolgung von Fehlern und für Audits.
3. Überprüfen Sie die Qualität kontinuierlich. Es ist weit besser, eine Inkonsistenz an einem ruhigen Dienstagmittag zu finden als während eines nächtlichen Ausfalls.
4. Seien Sie klar über die primäre Aufzeichnung. Wenn eine andere CMDB das System der Aufzeichnung ist, muss es unmissverständlich sein, welches Element welchem entspricht.

Wie Eywo Stratum damit umgeht

Eywo Stratum arbeitet mit 34 Elementklassen, von Business-Services und Anwendungen über Datenbanken, virtuelle und physische Server, IBM Power, Container und Speicher bis hin zu Netzwerk- und OT-Geräten. Sie können es auf verschiedene Weise bevölkern und kombinieren:

• durch die Discovery-API, die von Scan- und Inventarwerkzeugen gespeist wird,
• durch Importieren von CSV- oder Excel-Dateien, typischerweise während der Einführung oder Migration,
• durch manuelles Erstellen von Elementen, wo nichts anderes sie erfassen kann,
• durch Synchronisierung mit einer primären CMDB wie ServiceNow oder SMAX über externe IDs, sodass immer klar ist, welche Aufzeichnung welcher entspricht.

Jede Änderung an einem Element erstellt eine neue Version. Die Historie zeigt, wer die Änderung vorgenommen hat, wann, genau was geändert wurde und woher die Daten stammen: Discovery, Import, Synchronisierung oder eine Person. Wenn ein Wert falsch ist, kann sein Ursprung in Momenten nachverfolgt werden.

Darüber hinaus befinden sich Datenqualitätsüberprüfungen. Stratum kennzeichnet Inkonsistenzen und unvollständige Aufzeichnungen, damit das Team sie als Teil der normalen Arbeit und nicht unter dem Druck eines Incidents beheben kann. Im Laufe der Zeit wird die CMDB zum ersten Ort, an dem die Leute suchen, weil sie wissen, was sie dort finden werden.

Fazit

Eine CMDB, der niemand vertraut, ist kein technisches Problem. Es ist ein Problem des Vertrauens, und Vertrauen kann nicht vorgeschrieben werden. Es kann nur verdient werden: durch automatisierte Bevölkerung, transparente Historie, kontinuierliche Überprüfungen und eine klare Verbindung zur primären Aufzeichnung. Der Lohn ist ein Betrieb, in dem der Bereitschaftsingenieur die Antwort in den Daten in der Nacht findet, nicht auf dem Telefon eines Kollegen.

CMDB-Management, Versionshistorie, Importe und Datenqualitätsüberprüfungen sind Teil der Standard-Edition; Synchronisierung mit einer primären CMDB über externe IDs ist in der Enterprise-Edition verfügbar.