So planen Sie eine praxistaugliche CMDB

28
Produkte & Praxis
31-32/10
So planen Sie eine
praxistaugliche CMDB
Ohne Configuration-Management-Database kein effizientes IT-Service-Management.
Doch beim Design einer CMDB wird meist übertrieben. Statt auf einfache Strukturen
setzen Anwender auf komplexe Systeme und Big-Bang-Inbetriebnahme.
Von Christian Wischki und Daniel Liebhart*
D
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, zusammen-
hä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.
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 uni-
Foto: Fotolia.com/Robert Mizerek
as 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: BusinessService-Management (BSM) und IT-ServiceManagement (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
cw31-s28 28
28.07.2010 13:50:03 Uhr
Produkte & Praxis
31-32/10
verselle und für alle Fälle passende CMDB
– am liebsten noch als „Rundum-sorglosPaket“, 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 ihrer eigenen 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.
Die CMDB-Cloud
In der Praxis hat sich die Unterscheidung in eine logische CMDB als Integrationsebene
und physikalische CMDBs als Datenquellen bewährt.
Präsentationsund Wissensintegrationsebene
Informationsintegrationsebene
Change-, Releaseund AssetManagement-Sicht
Abfragen, Analysen
und Reportings
Serviceportfolio &
Servicekatalog
Technische
Konfiguration und
Lifecycle-Sicht
Datenquellen
(physikalische
CMDBs)
ServiceKnowledgeInformationen
Integrierte
CMDB/CMS
cw31-s29 29
Service-Desk-Sicht
Monitoring, Reviews,
Scorecards, Dashboards
Service- Availability- & CapacityManagementRelease &
Informationen
-Changes
Platform-ConfigurationTools
Discovery-Tools
Asset-Tools
Speicher, Projekt,
Dokumente
Platform-ConfigurationTools
physische CIs
CRM-, SCMSysteme
Audit-Tools
Quelle: Trivadis
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
CI-Lifecycle
Fünf Schritte zu einer praxistauglichen
CMDB. Eine detaillierte Beschreibung
lesen Sie auf der nächsten Seite.
Identifikation der
relevanten CIs
Planung und Strukturierung der CMDB
Reporting der KPIs
(Prozess & CMDB)
Kaum darstellbare Komplexität
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.
QualitätsManagementSicht
Availability-, Capacity-, PerformanceManagement (Forecasting & Planung)
Gleich einem Wissensbehälter
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-ManagementDatenbank 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.
29
Statusüberwachung
der CIs (LifecycleManagement)
Verifizierung und Audit
(Soll Ist)
Quelle: Trivadis
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,
sondern 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.
Mapping auf SOA-Basis
Der essenzielle 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.
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:
u
28.07.2010 13:50:10 Uhr
30
Produkte & Praxis
31-32/10
u1. So viel CIs wie für den Service not-
wendig, jedoch so wenige wie möglich:
Zu viele oder nicht notwendige CIs und
Attribute verursachen Aufwand, bringen
aber keinen zusätzlichen Nutzen. Zu wenige CIs hingegen beschreiben den Servicebaum in einem für die Praxis nicht ausreichenden 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 Bottomup:
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
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.
Fazit
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 Erfolgsfaktor hinzu: der Automatisierungsgrad. Ein hoher Automatisierungsgrad bei der Datengewinnung und
Verifizierung durch entsprechende SystemManagement- und Inventory-Tools ist unerlässlich. CIs wie beispielsweise Gebäude,
die sich selten ändern und quantitativ den
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 Basisoder Initial-CMDB mit einer skalierbaren
Architektur und einer diesbezüglich kontinuierlichen Optimierung.
(ue)
*Christian Wischki ist Service Manager,
Daniel Liebhart Solution Manager bei der
Trivadis AG.
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.
eDie Definition und Identifikation der Configuration Items:
Der erste Schritt im Configuration-Management ist immer die
Definition einer Policy, die klärt, 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.
rPlanung 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 Aktenordner aus Pappe sein, in dem
alle CIs manuell geführt und aktualisiert werden, oder ein Tool im
Millionen-Euro-Bereich, für das man spezialisierte Administratoren
benötigt, um es am Laufen zu halten. Innerhalb des ConfigurationManagements 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.
cw31-s30 30
tStatusü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.
uVerifizierung 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 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 IncidentTickets qualitätsgesichert richtiggestellt werden.
iReporting 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).
28.07.2010 13:50:20 Uhr