Trivadis

Die CMDB richtig planen, aber wie?

Uhr | Aktualisiert
von Christian Wischki

Ohne eine gute CMDB (Configuration Management Database) ist ein effizientes Configuration Management und somit auch ein erfolgreiches IT Service Management nicht möglich. Jedoch wird beim Design der CMDB meist übertrieben. Statt mit dedizierten IT Services und einfachen Strukturen zu beginnen sowie diese anschliessend gleichmässig zu verfeinern, wird oft der Big-Bang angestrebt. Die Lösung heisst hier: Think Big - Start Small.

Das Configuration Management

Das Configuration Management ist im Grunde der zentralste und auch wichtigste Prozess. 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 verantwortlich ist, da die CMDB das Herz und den Pulsschlag einer prozessorientieren beziehungsweise –gesteuerten IT ist. Das Service Management kann man im Grunde in zwei Bereiche aufteilen: Business Service Management (BSM) und IT Service Management (ITSM).

Einerseits müssen die Service-Beschreibungen für den Kunden (Service-Katalog) und andererseits diese auch für die IT als Service-Bäume beziehungsweise -Graphen innerhalb der Configuration Management Database (CMDB) abgebildet und hinterlegt werden. Dieses stellt den Kern und wichtigsten Bestandteil einer CMDB dar.

Um jedoch die Service-Bäume, welche den IT-Service im Grunde auf der technischen Seite beschreiben, in der CMDB vollständig abbilden zu können, muss die CMDB stets alle servicerelevanten Bestandteile (die Configuration Items) und deren Beziehungen untereinander beinhalten. Nur so lassen sich alle Services, wie beispielsweise auch in ITIL gefordert, zusammenhängend darstellen, verwalten und pflegen. Soweit die Theorie in Sachen CMDB und Configuration Management. In der Praxis stellt sich jedoch die Frage nach der sinnvollen Realisierung.

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

Eine Datenbank (DB) ist beispielsweise nach ITIL im Grunde nichts anderes als irgendein Wissensbehälter und 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 seitens ITIL definierten Bestandteile – sprich alle servicerelevanten CIs – inklusive deren 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:

  1. Eine Applikation
  2. Meist eine Vielzahl von Clients, auf denen diese Applikation auf irgendeine Art und Weise abläuft
  3. Ein oder mehrere Webserver, welche die entsprechenden GUIs sowie deren Applikationslogiken und Reports beinhalten
  4. Eine oder mehrere Datenbanken mit den entsprechenden Daten und Business-Logiken
  5. Ein oder mehrere Server, auf denen die Datenbanken ablaufen
  6. Entsprechende Storage-Systeme, auf denen die Daten physikalisch gespeichert sind
  7. Diverse Netzwerke, um alle physikalischen Komponenten des IT-Services miteinander zu verbinden
  8. Elektrischer Strom, um das Ganze überhaupt mit Energie versorgen zu können
  9. Gebäude und Einrichtungen, in denen sich unter anderem auch die physikalischen Elemente des IT-Services befinden

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

Die in der Praxis wirklich funktionierende CMDB ist im Grunde immer eine Art "Cloud-CMDB"

Eine in der Praxis gelebte und funktionierende CMDB stellt immer eine Art "Cloud" (Wolke) dar, in der verschiedene hierzu notwendige IT-Systeme untereinander verbunden sind und diese dann in der Summe die benötigte und von ITIL geforderte CMDB ergeben. Diese Cloud-CMDB setzt sich im Grunde immer aus zwei Hauptkomponenten zusammen: den logischen Teil und die physikalischen Teile.

  • Der logische Teil der CMDB stellt meist eine einzige Datenbank im herkömmlichen Sinne der IT dar, in der alle servicerelevanten CIs, deren Attribute und vor allem auch deren Beziehungen untereinander erfasst sind. Somit sind Service-Bäume bzw. Graphen existent, wobei den CIs aber noch keine realen Komponenten zugeordnet sind und somit nur ein logisches Modell vorhanden ist.
  • Die physikalischen Teile einer CMDB stellen dann die sogenannten Inventory-Systeme und -Datenbanken dar, welche in der Praxis auch schon oft dediziert vorhanden sind, wie z.B. 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, welcher dann in der Summe zu diesen beiden Hauptkomponenten die in der Praxis erfolgreiche und funktionierende CMDB ergibt, stellt die Entwicklung der Schnittstellen (das Mapping) zwischen den Inhalten der logischen CMDB und den Informationen der verschiedenen physikalischen CMDBs dar – diese Kommunikationsschicht sollte im Idealfall immer mittels einer SOA-basierten Architektur – realisert werden.

Die richtige Architektur einer CMDB ist zwar eine zwingende Voraussetzung für eine funktionierende CMDB, jedoch lange noch nicht das Ende der Fahnenstage. Ein weiterer wichtiger 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 leider keinen zusätzlichen Nutzen. Zu wenige CIs hingegen beschreiben den Service Baum in einem für die Praxis nicht ausreichendem Granularitätsgrad, was zur Folge hat, dass die beschreibenden Attribute der jeweiligen CIs – im Grunde deren 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 Service Bäume bzw. –Graphen und deren CIs immer Top-Down beschreiben und entwicklen, nie Buttom-Up. Eine CMDB dient dazu, den IT-Service mit seinen relevanten Bestandteilen aus Businesssicht zu beschreiben und diese Informationen dann mit den wirklich für den Betrieb notwendigen technischen Informationen anzureichern – und nicht um das gesamte vorhandene und vielleicht sogar auch gar nicht mehr notwendige Inventar der IT zu dokumentieren und diesem dann mittels ITIL eine weitere Lebensberechtigung zu erteilen.


Ist dieses alles nun 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-Tools und Inventory-Tools ist hierbei 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 dieses jedoch automatisiert erfolgen. Im Grunde 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.

Kostenoptimierung mittels einer CMDB im Datenbankbereich

Ein gutes Configuration Management im Datenbankbereich stellt die Grundlage für jeden Datenbankverantwortlichen dar, um die Supportkosten in Störungs- und Problemfällen so gering wie möglich zu halten oder diese gar proaktiv zu vermeiden.

Viele Störungen und Probleme in einer Oracle Datenbanklandschaft sind auf nicht optimale Einstellungen oder auf nicht autorisierte Veränderungen von Konfigurations- und Parametereinstellungen zurückzuführen. Diese verursachen in der Folge stets entsprechende Aufwände und Kosten - sowohl im Business, da dann die von den Datenbanken unterstützten IT-Services und somit auch deren zu unterstützende Geschäftsprozesse beeinträchtigt und gestört werden, als auch in der IT, da entsprechende Support-, Analyse- und Behebungsaufwände sowie -kosten anfallen.

Das Configuration Management im Datenbankbereich sollte somit bereits in der Projekt- beziehungsweise Architekturphase signifikant mitwirken. Eine Datenbank bietet eine Vielzahl von Konfigurationsmöglichkeiten, die stets auf die Applikationen, welche auf die Datenbank zugreifen, hin optimiert werden sollten. Während der anschliessenden Betriebsphase ist es im Datenbankbereich von essentieller Wichtigkeit, diese Parameter- und Konfigurationseinstellungen permanent zu überprüfen, um so nicht autorisierte Änderung schnellst möglichst zu identifizieren.

Konfigurations- und Parametereinstellungen sollten vor allem in diesem sensiblen Bereich der IT nur nach einer Autorisierung durch einen vorgeschalteten, qualitativ hochwertigen Change Management Prozess verändert werden, da eine Änderung eines Parameters oft einen signifikanten Einfluss auf die Wirkung anderer Parameter auf die Datenbank zur Folge hat. Werden diese Auswirkungen und Abhängigkeiten vorab im Detail nicht oder nur rudimentär analysiert und berücksichtigt, kann es durchaus passieren, dass man durch das Verändern des einen Parameters zwar das eine Problem löst, jedoch dadurch parallel mehrere weitere Probleme und Störungen wieder verursacht werden, welche dann wieder entsprechende – sogar dann auch meist x-fach höhere als die ursprünglichen - Aufwände und Kosten nach sich ziehen und somit eine Kostenspirale entsteht.

Fazit

Die Entwicklung einer für Ihr Unternehmen und Ihre IT-Services optimale und vor allem dann auch praxistaugliche CMDB sowie auch der darin befindlichen Servicegraphen stellt die Grundlage einer jeden erfolgreichen, prozessorienierten und –gesteuerten IT dar.

Der Weg zu dieser – und somit auch zu einem erfolgreichen Configuration Management – für Ihr Unternehmen und Ihre IT-Services optimalen CMDB ist immer eine gute und nicht überdimensionierten Basis- oder Initial-CMDB mit einer skalierbaren Architektur und einer diesbezüglich kontinuierlichen Optimierung und lässt sich im Grunde in 5 Abstrakten Schritten beschreiben:

  1. Definition & Identifikation der Servicebäume bzw. Servicegraphen sowie deren Bestandteile (Configuration Items)
  2. Planung und Strukturierung der CMDB
  3. Statusüberwachung des Lifecycle der entsprechenden CIs
  4. Verifizierung von Soll und Ist
  5. Reporting der für den Service relevanten KPIs & Optimierung des Configuration Managements

Christian Wischki ist Service Manager bei der Trivadis AG sowie Autor verschiedener Fachartikel und Bücher. Sowohl in den Bereichen des IT-, Business Service-, IT-Service- und Prozessmanagements, als auch in der Entwicklung und Architektur von Datenbanklandschaften und datenbankbasierten Applikationen, Lösungen und Services führte er in leitenden Funktionen bereits eine Vielzahl von nationalen und internationalen Projekten erfolgreich durch.