Warum Automated Discovery allein keine gute CMDB sicherstellt

Der erste Teil der Beitragsreihe hat den Fokus auf ein typisches Muster in CMDB-Projekten gelegt: Die Tool-Frage wird häufig zu früh gestellt. Der zweite Teil knüpft daran an und betrachtet einen angrenzenden Aspekt. Wenn Datenmodell, Prozesse und Anbindungen einer CMDB definiert sind, stellt sich die praktische Folgefrage: Wie werden Configuration Items und ihre Beziehungen aktuell gehalten?

In vielen Fällen fällt die Antwort auf Automated Discovery. Die zugrunde liegende Annahme ist nachvollziehbar: Wenn Systeme automatisiert erkannt und ausgelesen werden, müsste sich die Datenpflege in der CMDB deutlich vereinfachen. In der Praxis zeigt sich jedoch, dass automatisierte Discovery zwar relevant ist, die Qualität und Nutzbarkeit einer CMDB aber nicht allein daraus folgt.

Ein Automated-Discovery-Tool besteht vereinfacht aus vier funktionalen Bausteinen.

Hinzu kommt, dass viele Enterprise-Discovery-Tools bereits Unterstützung für verbreitete Technologien über verschiedene Ebenen der Infrastruktur hinweg mitbringen und sich in vielen Fällen erweitern lassen.

Die Wirksamkeit automatisierter Discovery hängt davon ab, wie stark die zu erfassenden Elemente standardisiert sind. In der Praxis tritt häufig das Problem ein, dass Unternehmensinfrastrukturen in der Regel nicht vollständig standardisiert sind. Anpassungen und Abweichungen finden sich oft auf mehreren Ebenen, beispielsweise im Betriebssystem, in Middleware-Komponenten oder Schnittstellen sowie in betriebsspezifischen Konfigurationen.

Dementsprechend stößt die Standardlogik eines Discovery-Tools schnell an ihre Grenzen. Dabei zeigen sich typischerweise zwei Muster. Entweder die vorhandene Logik liefert nicht die tatsächlich benötigten Informationen oder sie erzeugt Datenmengen, die für die CMDB keinen ausreichenden Mehrwert haben.

Beides erzeugt zusätzlichen, teils erheblichen Aufwand, da die Discovery-Mechanismen angepasst, erweitert oder durch andere Quellen ergänzt werden müssen. Weiterhin können Updates des Discovery-Tools Auswirkungen auf individuell angepasste Bereiche haben, sodass sich ein fortlaufender Pflegeaufwand ergibt.

Unsere Erfahrung aus CMDB-Projekten zeigt; wenn die Standardmechanismen eines Discovery-Tools an ihre Grenzen stoßen, ist es in der Regel nicht zielführend, das Werkzeug immer weiter an die Gegebenheiten der eigenen Infrastruktur anzupassen. Sinnvoller ist es, mit dem Tool zu arbeiten und fehlende Informationen aus anderen verlässlichen Quellen zu ergänzen.

Anstatt sich auf ein einzelnes Discovery-Tool zu verlassen, ist es häufig zielführender, in Kategorien eines CMDB-Discovery-Frameworks zu denken. Für den Aufbau eines solchen Frameworks sind mehrere Aspekte relevant.

Zu Beginn steht die Frage nach den relevanten Datenquellen. Nicht jede Information muss neu erhoben werden, wenn sie in anderen Systemen bereits belastbar vorliegt. Aus diesem Grund ist es hilfreich, bestehende Tools oder Plattformen zu prüfen.

Je nach Umgebung kann ein agentenbasierter, agentenloser oder kombinierter Ansatz sinnvoll sein. Maßgeblich ist, die jeweils geeignetste Quelle für die benötigten Informationen zu nutzen.

Security-Vorgaben beeinflussen Discovery-Vorhaben häufig stärker als die Logik des Tools. Deshalb sollten frühzeitig die zu verwendenden Protokolle sowie die verfügbaren Zugriffe inklusive Berechtigungen technischer Abfragen geklärt werden.

Bei Einschränkungen an dieser Stelle ist es sinnvoll, zur Quellenansicht und Architektur zurückzukehren. Oft müssen dann andere Datenquellen oder alternative Erhebungswege eingeplant werden.

In Discovery-Vorhaben gilt oft das Pareto-Prinzip. So betreffen rund 80 % der benötigten Informationen nur etwa 20 % der relevanten CI-Typen. Gerade deshalb lohnt es sich, früh festzulegen, welche Attribute tatsächlich gepflegt werden müssen.

Ohne diese Eingrenzung steigt der Aufwand schnell, während der fachliche Nutzen nicht im gleichen Maß zunimmt.

Ein Discovery-Framework ist eine fortlaufende Aufgabe, da alle gepflegten Daten regelmäßig überprüft werden müssen, damit sie für nachgelagerte Prozesse verwendbar bleiben.

Zur Datenqualität gehören neben der Vollständigkeit auch Aktualität, Konsistenz sowie Nachvollziehbarkeit der Informationen.

Die verarbeiteten Daten müssen technisch übertragen und nachvollziehbar konsumiert werden können. Zu diesem Zwecke empfiehlt sich ein Mechanismus, der veranschaulicht, ob die Übergabe erfolgreich war und die Informationen in der Zielstruktur wie vorgesehen eingetroffen sind.

Erst wenn diese letzte Strecke stabil funktioniert, kann die Datenerhebung einen belastbaren Beitrag zur Pflege der CMDB leisten.

In diesem Zusammenhang ist die Entscheidung für ein bestimmtes Tool relevant, aber nicht allein ausschlaggebend. Grundsätzlich können verschiedene Lösungen vergleichbare Ergebnisse liefern, wenn sie passend zum Bedarf eingesetzt werden.

Ob eine kommerzielle Lösung oder ein Open-Source-Ansatz besser geeignet ist, hängt weniger von der Qualität des Tools selbst als von den Anforderungen der jeweiligen CMDB, der vorhandenen Infrastruktur und den organisatorischen Rahmenbedingungen ab.

Automatisierte Discovery erleichtert die Erfassung und Aktualisierung von CI-Daten. Eine belastbare und nutzbare CMDB ergibt sich daraus jedoch nicht automatisch. Standardmechanismen stoßen insbesondere dort an ihre Grenzen, wo Infrastrukturen von individuellen Anpassungen geprägt sind.

Es ist daher sinnvoll, den Blick über das einzelne Tool hinaus zu richten. Wenn Discovery als eigenständige Aufgabe mit klaren Datenquellen, definiertem Scope, abgestimmten Sicherheitsvorgaben, laufender Qualitätskontrolle und verlässlicher Integration betrachtet wird, lässt sich die Datenpflege in der CMDB deutlich zielgerichteter organisieren.

Im dritten Teil dieser Beitragsreihe erfolgt die begriffliche und konzeptionelle Einordnung zentraler Strukturen im CMDB-Umfeld. Dazu gehören unter anderem CMDB, CMS und SKMS.