Die CMDB richtig planen

Das Configuration-Management ist der zentrale und auch wichtigste Prozess innerhalb von Itil. Das liegt jedoch nicht am Configuration-Management-Prozess selbst, sondern daran, dass dieser für die Pflege, Richtigkeit, Nachvollziehbarkeit und Vollständigkeit der Configuration-Management-Database (CMDB) verantwortlich ist und diese Datenbank das Herz und den Pulsschlag von Itil repräsentiert.

Man kann das Service-Management nach Itil in zwei Bereiche aufteilen: Business-Service-Management (BSM) und IT-Service-Management (ITSM). Die Servicebeschreibungen müssen einerseits für den Kunden (Servicekatalog) und andererseits für die IT als Servicebäume beziehungsweise -graphen innerhalb der CMDB abgebildet und hinterlegt werden. Dieses stellt den Kern und wichtigsten Bestandteil einer CMDB beziehungsweise von Itil dar. Um jedoch die Servicebäume, die einen IT-Service auf der technischen Seite beschreiben, in der CMDB vollständig abbilden zu können, muss die CMDB stets alle servicerelevanten Bestandteile (Configuration Items = CIs) und deren Beziehungen untereinander beinhalten. Nur so lassen sich alle Services, wie in Itil gefordert, zusammenhängend darstellen, verwalten und pflegen. So weit die Theorie in Sachen CMDB und Configuration-Management nach Itil. In der Praxis stellt sich jedoch die Frage nach der sinnvollen Realisierung.

Zwischen Theorie und Praxis

Hier werden immer noch die meisten und auch größten Fehler im gesamten Itil-Kontext gemacht, die sich in der Folge auch auf die gesamte Itil-Einführung negativ auswirken. Die IT favorisiert sehr gerne eine universelle und für alle Fälle passende CMDB - am liebsten noch als "Rundum-sorglos-Paket", mit dem man auch alle potenziellen zukünftigen Anforderungen abdecken kann. Viele Tool-Hersteller vermitteln hier leider oft den Eindruck, dass dies möglich ist - vor allem mit der hauseigenen Lösung, und zwar auf Knopfdruck. Das reale Ergebnis schaut derzeit jedoch in den meisten Fällen völlig anders aus, und nicht selten entpuppt sich die eingekaufte Super-CMDB-Lösung bis zu ihrer Verwendbarkeit hinsichtlich Kosten und Aufwand als Fass ohne Boden.

Was den IT-Service komplex macht

Eine Datenbank ist nach Itil im Grunde nichts anderes als irgendein Wissensbehälter. Sie ist nicht, wie man vermuten würde, zwingend eine Datenbank im Sinne der IT. Itil besagt an dieser Stelle lediglich, dass man für eine Configuration-Management-Datenbank einen Wissensbehälter benötigt, um darin alle durch Itil definierten Bestandteile, sprich alle servicerelevanten CIs inklusive ihrer Eigenschaften (als beschreibende Attribute) und ihrer Verbindungen untereinander abzulegen.

In der Praxis jedoch ist das Ganze etwas komplexer. Ein IT-Service gegenüber dem Business besteht in der Praxis beispielsweise aus folgenden Bestandteilen:

• Eine Applikation,

• meist eine Vielzahl von Clients, auf denen diese Applikation abläuft,

• ein oder mehrere Web-Server, welche die entsprechenden GUIs sowie deren Applikationslogiken und Reports beinhalten,

• eine oder mehrere Datenbanken mit den entsprechenden Daten und Business-Logiken,

• ein oder mehrere Server, auf denen die Datenbanken ablaufen,

• entsprechende Storage-Systeme, auf denen die Daten physikalisch gespeichert sind,

• diverse Netzwerke, um alle physikalischen Komponenten des IT-Service miteinander zu verbinden,

• elektrischer Strom, um das Ganze überhaupt mit Energie versorgen zu können, und nicht zuletzt

• Gebäude und Einrichtungen, in denen sich unter anderem auch die physikalischen Elemente des IT-Service befinden.

Ausgehend von diesen Punkten reift relativ schnell die Erkenntnis, dass es sich in der Praxis fast nie um Servicebäume handeln kann, sondern vielmehr um Servicegraphen, da die gelebten IT-Services um ein Vielfaches komplexer und mehrdimensionaler sind, als es in einem Baum darstellbar ist. Offensichtlich scheint auch, dass es eigentlich unmöglich ist, eine universelle, für alle in der IT vorkommenden Komponenten und Schnittstellen passende CMDB zu finden oder zu entwickeln.

Bewährtes aus der Praxis

Eine in der Praxis gelebte und funktionierende CMDB stellt immer eine Art "Cloud" (Wolke) dar, in der verschiedene IT-Systeme untereinander verbunden sind, die dann in der Summe die benötigte und von Itil geforderte CMDB ergeben. Diese Cloud-CMDB setzt sich immer aus zwei Hauptkomponenten zusammen: dem logischen Teil und den physikalischen Teilen. Den logischen Teil der CMDB bildet meist eine einzige Datenbank im herkömmlichen Sinn der IT, in der alle servicerelevanten CIs, deren Attribute und vor allem auch deren Beziehungen untereinander erfasst sind. Somit sind Servicebäume beziehungsweise -graphen existent, wobei den CIs aber noch keine realen Komponenten zugeordnet sind, somit also nur ein logisches Modell vorhanden ist.

Die physikalischen Teile einer CMDB stellen dann die so genannten Inventory-Systeme und -Datenbanken dar, die in der Praxis oft schon dediziert vorhanden sind, so zum Beispiel ein Datenbank-Inventory-System, ein Server- und Client-Inventory-System sowie ein CVS-System für diverse Quellcodes und vieles mehr.

Der essentielle Baustein jedoch, der dann in der Summe zu diesen beiden Hauptkomponenten die in der Praxis erfolgreiche und funktionierende CMDB ergibt, stellt die Entwicklung der Schnittstellen (Mapping) zwischen den Inhalten der logischen CMDB und den Informationen der verschiedenen physikalischen CMDBs dar. Diese Kommunikationsschicht sollte im Idealfall immer mittels einer SOA-basierenden Architektur realisiert werden.

Goldene Regeln für die Granularität

Die richtige Architektur ist zwar eine zwingende Voraussetzung für eine funktionierende CMDB, jedoch lange noch nicht das Ende der Fahnenstange. Einen weiteren wichtigen Bestandteil stellt der Granularitätsgrad der in der CMDB zu erfassenden CIs dar. Dieser sollte den jeweiligen Anforderungen aus Business und Controlling sowie dem kritischen Punkt beim Service und dem Ausfallsrisiko angemessen sein. Die zwei goldenen Regeln hierbei lauten:

1. So viel CIs wie für den Service notwendig, jedoch so wenige wie möglich:

Zu viele oder nicht notwendige CIs und Attribute verursachen Aufwand, aber keinen zusätzlichen Nutzen. Zu wenige CIs hingegen beschreiben den Servicebaum in einem für die Praxis nicht ausreichendem Granularitätsgrad, was zur Folge hat, dass die beschreibenden Attribute der jeweiligen CIs, das sind die servicerelevanten Konfigurations- und Parametereinstellungen, für die anderen Itil-Prozesse nicht ausreichend dokumentiert sind und somit auch der Nutzen der CMDB nicht mehr gegeben ist.

2. Die Servicebäume beziehungsweise -graphen und deren CIs immer Top-down beschreiben und entwickeln, nie Bottom-up:

Eine CMDB dient dazu, den IT-Service mit seinen relevanten Bestandteilen aus Business-Sicht zu beschreiben und diese Informationen dann mit den für den Betrieb notwendigen technischen Informationen anzureichern. Er dient nicht dazu, das gesamte vorhandene und vielleicht sogar gar nicht mehr notwendige Inventar der IT zu dokumentieren und diesem dann mittels Itil eine weitere Lebensberechtigung zu erteilen.

Ist dies alles gegeben, kommt für den laufenden Betrieb einer CMDB ein weiterer entscheidender Erfolgfaktor hinzu: der Automatisierungsgrad. Ein hoher Automatisierungsgrad bei der Datengewinnung und Verifizierung durch entsprechende System-Management- und Inventory-Tools ist unerlässlich. CIs wie beispielsweise Gebäude, die sich selten ändern und quantitativ den kleineren Anteil darstellen, kann man in der Praxis durchaus manuell pflegen - bei allen anderen CIs sollte dies jedoch automatisiert erfolgen. Im Prinzip lässt sich dafür die ABC-Analyse aus der Lagerwirtschaft anwenden: A-Teile (wenige, aber teure) können manuell erfasst und verifiziert werden, C-Teile (viele und im Verhältnis zu den A-Teilen billige) sollten unbedingt automatisiert inventarisiert, verwaltet und gepflegt werden.

Fünf Schritte zum Erfolg

Der Weg zu einer praxistauglichen CMDB, die auf die Bedürfnisse der jeweiligen IT-Services und vor allem auch auf die des jeweiligen Unternehmens zugeschnitten ist, lässt sich in fünf Schritten beschreiben.

1. Die Definition und Identifikation der Configuration Items:

Der erste Schritt im Configuration-Management ist immer die Definition einer Policy dazu, was ein Configuration Item und seine konstituierenden Komponenten darstellt und was nicht. Dazu gehören auch die Informationen und Beziehungen, die für jedes einzelne CI aufgezeichnet und definiert werden, sowie die entsprechenden Dokumentationen.

2. Planung und Strukturierung der CMDB:

Planung und Strukturierung sind neben der Überwachung der CIs die wichtigsten Aufgaben des Configuration-Managements. Wie bereits erwähnt, existiert nicht die eine, alles abdeckende und auch immer passende CMDB für jeden IT-Service und jedes Unternehmen. Eine CMDB muss, wie die Servicebäume und -graphen, stets auf die entsprechenden Bedürfnisse der IT-Services hin entwickelt werden. Eine CMDB kann im Extremfall ein physikalischer Aktenordner sein, in dem alle CIs manuell geführt und aktualisiert werden, oder ein Tool im Millionen-Euro-Bereich, für das man dedizierte Administratoren benötigt, um es am Laufen zu halten. Innerhalb des Configuration-Managements muss die CMDB jedoch stets so strukturiert sein, dass sie einerseits für die entsprechenden Services vollständig ist und sich andererseits für das Configuration-Management auch handhaben lässt. Eine der wichtigsten Grundlagen für den Erfolg von Itil innerhalb eines Unternehmens ist eine CMDB, die man leicht benutzen, verwalten und pflegen kann. Sie muss deshalb immer auf die jeweiligen Anforderungen der IT und des Business hin abgestimmt, entwickelt und optimiert werden.

3. Statusüberwachung des CI-Lifecycle:

Das Configuration-Management hat unter anderem auch die Aufgabe, den Lifecycle-Status der CIs zu überwachen. Auf den ersten Blick stellt dies aus Sicht der physikalischen CIs eines Service keine große Herausforderung dar. Da jedoch innerhalb der CMDB unter anderem auch die Servicekataloge, die Servicebeschreibungen und deren Dokumentationen sowie SLAs (Service-Level-Agreements), OLAs (Operation-Level- Agreements) und UCs (Underpinning Contracts) gepflegt werden müssen, stellen Lifecycle-Betrachtung und Statusüberwachung für das Configuration-Management auch entsprechende Aufwände und Qualitätsanforderungen dar.

4. Verifizierung von Soll und Ist:

Die Verifizierung der realen Ist-Konfigurationen von verschiedenen, in der CMDB hinterlegten CIs in Bezug auf ihre Soll-Konfigurationen bildet eine weitere sehr wichtige Aufgabe des Configuration-Managements. Jede Differenz sollte unverzüglich einen automatischen Incident erzeugen (Incidents können beziehungsweise sollten nicht nur vom User gemeldet werden können, sondern vor allem auch von entsprechenden Monitoring-Systemen). Anschließend wird untersucht, ob die Ist-Konfiguration des CI wirklich falsch ist oder ob in der CMDB falsche Werte hinterlegt sind. In beiden Fällen sollte dies dann mittels eines Incident-Tickets qualitätsgesichert wieder richtiggestellt werden.

5. Reporting der für den Service relevanten KPIs und Optimierung des Configuration-Managements:

Alle servicerelevanten Key-Performance-Indikatoren (KPIs) sollten in für die jeweiligen IT-Services passenden, regelmäßigen Abständen analysiert und dokumentiert werden. Auf Basis der Ergebnisse des Reportings können dann einerseits entsprechend kontinuierliche Verbesserungsprozesse (KVPs) für das Configuration-Management selbst initiiert werden. Andererseits dienen diese auch als Input für das gesamte prozessübergreifende Service-Improvement-Programm (SIP).

Fazit

Die Entwicklung einer für ein Unternehmen und die dort vorhandenen IT-Services optimalen CMDB sowie auch der darin befindlichen Servicegraphen stellt die Grundlage einer jeden erfolgreichen Itil-Einführung dar. Der Weg zu dieser CMDB ist immer eine gute und nicht überdimensionierte Basis- oder Initial-CMDB mit einer skalierbaren Architektur und einer diesbezüglich kontinuierlichen Optimierung. (ue)

Bilder: Fotolia (R. Mizerek) und Trivadis