Close

Mindville Insight ist jetzt Teil von Jira Service Management Premium, Enterprise und Data Center. Mehr erfahren.

Ready for ITSM at high velocity?

Leitfaden zu Datenbanken für das Konfigurationsmanagement (CMDBs)

Laut ITIL 4 wird eine Configuration Management Database (CMDB) "verwendet, um Configuration Records während ihres gesamten Lebenszyklus zu speichern [....] und die Beziehungen zwischen ihnen zu pflegen."

Anders ausgedrückt speichert deine CMDB Informationen über die Konfiguration von Elementen innerhalb eines Unternehmens, einschließlich Hardware, Software, Systemen, Einrichtungen und manchmal auch Personal. Es ist Aufgabe der IT-Organisation festzulegen, welche Elemente nachverfolgt werden sollen und wie. Diese Konfigurationsdaten können für jedes Element Beziehungen und Abhängigkeiten zwischen Elementen, den Verlauf von Änderungen an jedem Element sowie Klassen und Attribute wie Typ, Besitzer und Wichtigkeit beinhalten.

Innerhalb einer CMDB werden diese nachverfolgten Elemente als Configuration Items (CIs) bezeichnet. Wie in ITIL 4 definiert, sind CIs "alle Komponenten, die gemanagt werden müssen, um einen IT Service bereitstellen zu können".

Das Ziel einer CMDB ist es, einem Unternehmen die Informationen bereitzustellen, die erforderlich sind, um bessere Geschäftsentscheidungen zu treffen und ITSM-Prozesse effizient auszuführen. Durch die Zentralisierung aller Konfigurationsinformationen können Führungskräfte kritische CIs und ihre Beziehungen besser verstehen. CMDBs sind wichtig für die Analyse der Auswirkungen und der Ursachen, für die Einhaltung gesetzlicher Vorschriften sowie für das Vorfallmanagement und Änderungsmanagement.

IT-Asset-Management (ITAM) und Konfigurationsmanagement

Wenn wir von Assets und CIs, dem IT-Asset-Management (ITAM) und dem Konfigurationsmanagement sprechen, kann das ziemlich verwirrend werden. Auf den ersten Blick scheinen die Begriffe austauschbar zu sein. Tatsächlich können sie sich mit denselben Komponenten eines Unternehmens befassen, jedoch mit verschiedenen Aspekten.

Worin unterscheiden sich diese Praktiken? Nehmen wir als Beispiel ein Auto, das sowohl ein Vermögenswert (etwas von finanziellem Wert für ein Unternehmen) als auch ein CI (eine dynamische Komponente, die für die Services eines Unternehmens wichtig ist) sein könnte.

Innerhalb der verschiedenen Praktiken gibt es unterschiedliche Überlegungen bezüglich des Autos:

ITAM-Überlegungen

Überlegungen beim Konfigurationsmanagement

  • Wann hast du das Auto gekauft?
  • Von welchem Händler?
  • Zu welchem Preis?
  • Um welche Marke, welches Modell, welche Ausstattung handelt es sich?
  • Wie hoch ist die Wertminderung?
  • Was wird von der Garantie abgedeckt?
  • Welches Öl wird verwendet?
  • Wie oft wird das Öl kontrolliert?
  • In wie vielen Kilometern ist der nächste Ölwechsel fällig?
  • Wie lautet die Motorkonfiguration?
    • Wurde sie geändert?

Nicht jedes Asset ist auch ein CI. Für einige Unternehmen kann es sinnvoll sein, Assets nachzuverfolgen, die nicht über die Konfiguration und Abhängigkeiten verfügen, die sie bei der Nachverfolgung als CIs wertvoll machen. Ein Energieunternehmen kann zum Beispiel einzelne Strommasten als Assets nachverfolgen. Sie haben einen finanziellen Wert für das Unternehmen, deshalb kann es sich lohnen, sie im Rahmen des Asset-Managements nachzuverfolgen, um zu wissen, wann sie beschädigt wurden oder ersetzt werden müssen.

Die Einordnung als CI ist für den Strommast wahrscheinlich nicht sinnvoll. Bei ihm gibt es keine verflochtenen Abhängigkeiten nachzuverfolgen. Bei einem langen Stück Holz kann man auch kaum von einer Konfiguration sprechen. Und der Versuch, Strommasten als CIs in deine CMDB einzugeben, wird dem System möglicherweise keinen ausreichenden Nutzen bringen, um den Zeit- und Arbeitsaufwand zu rechtfertigen.

Eigenschaften einer CMDB

Wir wissen also, wofür eine CMDB da ist, welche Rolle sie beim Konfigurationsmanagement spielt, welchen Bezug sie zum Asset-Management hat und wie sie sich davon unterscheidet. Doch wie sieht die CMDB-Funktion in der Praxis aus?

Die wesentlichen funktionalen Merkmale einer CMDB sind:

Nahtlose Dashboards mit CI-Metriken und Analysen, die es einfach machen, den Zustand von CIs, deren Beziehungen, die Auswirkungen von Änderungen, Muster, die zu Vorfällen oder Problemen führen, sowie den Aufwand (Geld und Ressourcen) für den Aufbau und die Verwaltung jedes Service innerhalb eines Unternehmens zu verfolgen.

Compliance-Funktionen, mit denen du und Prüfer detaillierte Aufzeichnungen und transparente Einblicke nicht nur in den aktuellen Zustand von CIs, sondern auch in deren bisherige Änderungen, Prüfungen, gegenseitige Kontrollen, Vorfälle usw. erhalten.

Erstellung von CIs und die rechtzeitige Aktualisierung ihrer Daten, die über drei verschiedene Methoden unterstützt wird: manuelle Eingabe, Integrationen (API-gesteuert, SCCM) und Erkennungstools, die automatisierte Scans aller IP-Adressen im Netzwerk eines Unternehmens durchführen, um Software- und Hardwareinformationen zu sammeln und den Bestand jedes physischen und virtuellen Geräts im Unternehmen effektiv erfassen.

Unterstützung für föderierte Datensätze, einschließlich Normalisierung und Abstimmung von CIs und deren Daten.

IT-Servicezuordnung (in der Regel eine grafische Darstellung von Beziehungen und Abhängigkeiten).

Zugriffskontrollen, mit denen du bei Bedarf verschiedenen Personen oder Teams unterschiedliche Zugriffsebenen zuteilen und Änderungen bei auftretenden Fragen oder Vorfällen zu ihrem Ursprung zurückverfolgen kannst.

Die Vorteile einer CMDB

Die Hauptprobleme, die mit einer CMDB angegangen werden, sind isolierte Daten und veraltete Informationen. Vor der Implementierung einer CMDB sind die Daten der meisten Unternehmen in verschiedenen Systemen mit verschiedenen Besitzern verstreut. Das macht es schwierig, einen Überblick über alle CIs und ihre Abhängigkeiten zu erhalten, und noch schwieriger zu verstehen, welche Informationen aktuell sind und welche nicht.

Dadurch wird verhindert, dass Teams bei Entscheidungen wichtigen Kontext einbeziehen können. Und dies wiederum wirkt sich auf die Risikobewertung und Berichterstellung aus, beeinträchtigt die Entscheidungsfindung, verlangsamt die Problemlösung und bedeutet letztendlich finanzielle Verluste und Imageschäden für das Unternehmen.

Nehmen wir einmal an, dass die Daten von CI A in einer Abteilung untergebracht sind und die von CI B in einer anderen. CI B ist von CI A abhängig, damit es richtig funktioniert. Wenn aber die Abteilung von CI A beschließt, die Konfigurationselemente aus Wartungsgründen offline zu nehmen, hat sie keinen Einblick in die Auswirkungen auf CI B.

Im besten Fall kann dies bei mehreren Teams für Verwirrung sorgen. Im schlimmsten Fall kann es zu einem größeren Vorfall kommen. Um dieses Szenario zu vermeiden, ist lediglich eine gut funktionierende CMDB erforderlich.

Forrester identifiziert drei Anwendungsfälle, in denen eine CMDB heutzutage eine wichtige Rolle spielt:

Planung

Technologiemanager benötigen CMDB-Daten, um allgemein auf der Ebene der Unternehmensarchitektur und des Portfoliomanagements als auch detailliert auf der Ebene des Asset- und Kapazitätsmanagements zu planen.

Buchhaltung

Die IT-Finanzabteilung muss auf Aufzeichnungen zu Anwendungen oder Servicecodes zugreifen können, um Abrechnungen zuzuweisen und die Unternehmensfinanzen ordnungsgemäß zu verwalten.

Betrieb

Eine CMDB verbessert eine Reihe von wichtigen ITSM-Praktiken, darunter das Änderungs-, Vorfall- und Problemmanagement.

Beim Änderungsmanagement kann eine CMDB die Risikobewertung verbessern, indem sie voraussieht, welche Benutzer, Systeme und andere CIs betroffen sein könnten. In regulierten Branchen kann sie auch die Einhaltung von Vorschriften unterstützen, Teams bei der Verwaltung von Kontrollen helfen und einen klaren Audit-Trail vorgeben.

Beim Vorfallmanagement kann eine CMDB beim Identifizieren von Änderungen helfen, die zu einem Vorfall geführt haben, und zu einer schnelleren Lösung beitragen. Aufzeichnungen zu Vorfällen lassen sich mit den relevanten CIs verknüpfen. Teams können so Vorfälle im Zeitverlauf zusammen mit den Assets, auf die sie sich auswirken, verfolgen.

Beim Problemmanagement kann eine CMDB bei der Ursachenanalyse helfen und Teams schneller zum Kern eines Problems führen. Sie kann auch ein proaktives Problemmanagement unterstützen und Teams dabei helfen, Assets zu identifizieren, die ein Upgrade benötigen, um Servicekosten zu senken und ungeplante Ausfälle zu reduzieren.

Letztendlich sollte eine CMDB die Komplexität reduzieren, Fehler verhindern, die Sicherheit erhöhen und dafür sorgen, dass ITSM-Praktiken wie das Änderungs- und Vorfallmanagement reibungslos ablaufen.

Die Herausforderungen von CMDBs

Branchenstatistiken zeigen, dass nur 25 % der Unternehmen einen bedeutsamen Nutzen aus ihren CMDB-Investitionen ziehen. Aufgrund dieser derart niedrigen Erfolgsquote hat die Technologie einen ziemlich zweifelhaften Ruf.

Die gute Nachricht ist, dass die Ursachen für das Scheitern vermeidbar sind und sich in der Regel in sechs vorhersehbare Kategorien einteilen lassen:

Unternehmenskultur

In jedem Unternehmen lässt sich anhand der Kultur und dem Engagement der Teams am besten ermitteln, ob neue Technologien und Prozesse erfolgreich sind. In einer aktuellen Studie des Harvard Business Review gaben 93 % der Führungskräfte an, dass die größte Herausforderung bei der datengesteuerten digitalen Transformation Menschen und Prozesse sind. Dasselbe gilt für CMDB-Projekte.

Relevanz

CMDBs werden oft als zentrale Informationsquelle bezeichnet. Das führt manchmal dazu, dass Unternehmen versuchen, alle ihre Daten in eine Datenbank zu zwängen, ohne über die Anwendungsfälle nachzudenken, die für ihre Anforderungen relevant sind.

Wie bei jedem Daten-Repository sollte eine CMDB fokussierte, nützliche Daten enthalten, die interne Prozesse wie das Änderungsmanagement unterstützen. Sorge dafür, dass deine CMDB einen klar definierten Nutzen und einen Besitzer hat. Sie sollte zudem die Möglichkeit bieten, Daten zu aktualisieren, um alle Änderungen abzubilden.

Zentralisierung

Wenn wir eine CMDB als einen zentralen Ort zur Anzeige von Asset-Daten bezeichnen, bedeutet das nicht, dass sich alle Asset-Daten ausschließlich in der CMDB befinden müssen. Dieser verbreitete Irrglaube kann für Teams einen hohen Aufwand verursachen, wenn sie versuchen, alle ihre Daten in diese zentrale Informationsquelle zu verschieben. Die Best Practice besteht darin, aus Daten von anderen Tools einen Verbund zu erstellen, damit zur Bearbeitung jedes Anwendungsfalls das am besten geeignete Tool verwendet wird.

Es ist beispielsweise sinnvoller, Finanzdaten in einem ITFM-Tool (IT Financial Management) und Softwarelizenzinformationen in einem SAM-Tool (Software Asset Management) zu speichern. Die Daten können dann in deine CMDB importiert und gespiegelt werden, auch wenn dies nicht der primäre Speicherplatz ist.

Genauigkeit

Viele Unternehmen haben Schwierigkeiten, eine korrekte CMDB zu erstellen und zu pflegen. Die häufigsten Probleme bestehen darin, dass Erkennungstools zu selten ausgeführt werden, Automatisierungsregeln fehlen oder nicht auf manuelle Eingaben verzichtet werden kann. Eine geeignete Lösung für diese Herausforderungen ist eine ereignisgesteuerte Erkennung, die die traditionelle Bottom-Up-Erkennung ergänzt.

Für alle diejenigen, die mit diesen Begriffen nicht vertraut sind: Bei einer Bottom-Up-Erkennung werden Assets von der Infrastruktur bis hin zu kundenorientierten CIs zugeordnet. Eine ereignisgesteuerte Erkennung findet statt, wenn z. B. ein Ereignis innerhalb eines Systems oder ein Problem eintritt, das zur Kommunikation zwischen den Systemen führt. Basierend auf diesem Ereignis ordnet das System dann die zugehörigen CIs und deren Verbindungen zu.

Übrigens ist nicht jedes CI auffindbar. Vielleicht möchte dein Team ja Monitore in der CMDB zuordnen. Weil Monitore von automatisierten Systemen nicht erkannt werden, müssen sie manuell über eine Kalkulationstabelle (oder eine ähnliche Methode) eingegeben werden.

Um eine hohe Genauigkeit zu erzielen und ein anschauliches Bild von deinen Assets und ihren Verbindungen zu erhalten, musst du das Potenzial der Bottom-Up-Erkennung und der ereignisgesteuerten Erkennung nutzen.

Prozess

In einigen Unternehmen ist man der Auffassung, dass CMDBs zur Modellierung älterer Infrastrukturen und Software dienen und nicht für den neuen Stack an Cloud- und softwaredefinierten Infrastrukturen sowie die darauf gehosteten modernen Workflows geeignet sind.

Tatsächlich sollten wir uns hier nicht mit der Wortbedeutung aufhalten, sondern uns mit dem Nutzen befassen, den die Nachverfolgung unserer CIs (alte wie neue) in einem Tool bringt, das uns einen guten Überblick über unsere technischen Ökosysteme liefert.

Tools

Die Auswahl des richtigen Tools ist enorm wichtig, wenn du die oben genannten traurigen Fehlerstatistiken vermeiden möchtest. Einige CMDB-Tools sind nichts weiter als Asset-Repositorys, also Datenstrukturen, die auf ältere physische Infrastruktur- und Erkennungstools festgelegt sind, die langsam auf Änderungen reagieren. Um erfolgreich mit einer CMDB zu arbeiten, brauchst du eine, die neue Arten von Assets berücksichtigt und sich schnell an Änderungen anpassen kann.

Wähle aus, was in deiner CMDB verwaltet werden soll

Es gibt keine allgemeingültige Vorgehensweise, wie du CIs in deiner CMDB verwalten solltest. In welchem Maß und Umfang die CMDB eingerichtet werden soll, sollte sich nach den Anwendungsfällen und Zielen des jeweiligen Unternehmens richten. Normalerweise ist es sinnvoll, auf oberster Ebene zu beginnen und die Services korrekt einzurichten, und dann bei Bedarf breiter oder tiefer zu gehen, damit du deine Unternehmensziele erreichen kannst.

CIs können im Übrigen grob als technische oder nichttechnische Einheiten gruppiert werden.

Zu den technischen Einheiten gehören Unternehmensservices, technische Services, Anwendungen, Software, Datenbanken, Container, virtuelle Maschinen, Betriebssysteme, Hardware, Netzwerke, Ports usw.

Nichttechnische Einheiten können auch in deiner CMDB modelliert werden, wenn du sie von anderen Assets in deiner IT-Servicezuordnung entweder als abhängig oder als betroffen darstellen möchtest. Zu den nichttechnischen Einheiten können Benutzer, Kunden, Unternehmen, Standorte, Serviceverträge, Dokumente usw. gehören.

Zu guter Letzt sollten bei der Entwicklung eines CMDB-Modells Cloud-Services berücksichtigt werden. Die SaaS-Angebote (z. B. Google Apps, Dropbox, Salesforce usw.) und IaaS-Angebote (z. B. DigitalOcean, Linode, Rackspace, Amazon Web Services usw.) können beide bei Bedarf als CIs dargestellt werden.

Im Gegensatz zu herkömmlichen CMDBs bietet Insight for Jira Service Management eine flexible und offene Datenstruktur, mit der du all deine Ressourcen verwalten kannst.