Configuration Management Database (CMDB)

Transcription

Configuration Management Database (CMDB)
Conguration Management Database (CMDB) Konzepte, Realisierung und Produkte
M.Sc. Seminararbeit im Schwerpunkt Telekommunikation
Fachhochschule Bonn-Rhein-Sieg
University of Applied Sciences
Fachbereich Informatik
Department of Computer Science
von:
Carsten Bochner
Köln
Germany
carsten <at> bochner.de
Sankt Augustin, Januar 2008
Inhaltsverzeichnis
1
Einleitung
3
2
IT Service Management, ITIL und die CMDB
5
2.1
IT Infrastructure Library (ITIL)
. . . . . . . . . . . . . . . . . . . . . .
5
2.2
Conguration- und Change-Management . . . . . . . . . . . . . . . . . .
5
2.3
Neuerungen durch ITIL Version 3 . . . . . . . . . . . . . . . . . . . . . .
7
3
4
5
Struktur, Funktionen und Konzepte einer CMDB
9
3.1
Conguration Items (CIs)
. . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.2
CI Typen und Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.3
Relationen der CIs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.4
Datenerfassung und Pege . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.5
Konkrete Leistungen und Vorteile einer CMDB
14
. . . . . . . . . . . . . .
Realisierung einer CMDB
17
4.1
Anforderungen an eine CMDB
. . . . . . . . . . . . . . . . . . . . . . .
17
4.2
Einführung einer CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.3
Produktübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Zusammenfassung und Fazit
21
Literaturverzeichnis
22
Abbildungsverzeichnis
23
2
Kapitel 1
Einleitung
Die Informationstechnologie durchschreitet derzeit einen Wandel von einer technologieorientierten und projektbezogenen Sichtweise hin zu einer kunden- und serviceorientierten Betrachtung. Während das IT-Management früher üblicherweise in die Phasen
Planung, Entwicklung und Produktion aufgeteilt war und somit reaktionär auf Kundenund Anwenderanforderungen reagiert hat, fordert das serviceorientierte IT-Management
eine Ergänzung durch proaktive Komponenten [ZHB05]. Dies ist nötig, da die Beziehung zwischen Dienstleister und Kunde viel ausgeprägter geworden ist und beide in
einem stetigen Dialog stehen müssen, um die zahlreichen Interessen im Kontext der
Leistungserbringung aufeinander abstimmen zu können. Aufgabe des IT Service Managements ist hierbei die Überwachung und Optimierung der Geschäftsprozess, die nötig
sind um IT-Dienstleistungen kundenfreundlich und ezient zu erbringen. Dies führt zu
einer ganzheitlichen Betrachtung des Unternehmens und seiner Strukturen, sowie organisatorischer Aspekte. Die Informationstechnologie, als Mittel zum Zweck, unterstützt
dabei das Management bei der Organisation, Steuerung, Analyse und Kontrolle der Geschäftsprozesse [Olb06].
Die enge Verknüpfung der Geschäftsprozesse und der Infrastruktur stellt Abbildung 1.1
grasch dar. Es wird deutlich, dass Ausfälle in der Infrastruktur erheblichen Einuss auf
die Services und Geschäftsprozesse haben können. Gleichzeitig können Veränderungen
der erbrachten Dienste und des Geschäftsmodells die Anpassung der IT Infrastruktur
notwendig machen. Dies lässt die gesteigerte Bedeutung des IT Service Managements
erkennen, welche auch die ITIL in ihren Best Practices hervorhebt. ITIL ist in Europa
die wichtigste Sammlung von Standards für die Einführung eines IT Service Managments und deniert hierfür umfangreiche Prozesse und Strukturen. Eine zentrale Datenquelle aller ITIL Service Management Prozesse ist die Conguration Management
Database (CMDB), welche den Ist-Zustand aller IT-Infrastrukturelemente und deren
Änderungen pegt. Darüber hinaus erfasst die CMDB die gegenseitigen Beziehungen
der Infrastrukturelemente, wodurch die gespeicherten Daten über denen eines typischen
Asset-Management Tools hinausgehen. Obwohl die engste Verknüpfung der CMDB zum
Conguration und Change Managment besteht, stellt diese die gespeicherten Informationen allen ITIL-Prozessen bereit und unterstützt hierdurch deren Einführung und
Optimierung [OSW07].
3
Abbildung 1.1: Verknüpfung von Geschäftsprozessen und Infrastruktur.
Die vorliegende Arbeit befasst sich im Folgenden mit der CMDB und somit mit einem
der zentralsten Elemente einer ITIL-konformen IT Service Management Architektur.
Diese Ausarbeitung ordnet daher im ersten Kapitel die CMDB in die ITIL Spezikation ein und stellt den Zusammenhang zwischen Change Management, Conguration
Management und ITIL vor.
Im zweiten Kapitel wird das konkrete Konzept einer CMDB beleuchtet und deren Funktionen vorgestellt. Hierbei werden zunächst Conguration Items eingeführt, welche die
wesentlichen, von der CMDB erfassten Elemente sind. Anschlieÿend werden die konkreten Leistungen und Vorteile einer CMDB aufgezeigt.
Das dritte Kapitel umfasst Informationen über die Einführung eines CMDB Produkts
in einer Organisation. Hierbei werden zunächst notwendige allgemeine Anforderungen
genannt, die ein CMDB Produkt erfüllen muss. Darauf folgend wird ein Ablaufplan,
mit notwendigen Aufgaben bei der Einführung einer CMDB, vorgestellt und eine Produktübersicht über CMDB Software gegeben. Abgeschlossen wird diese Ausarbeitung
durch eine Zusammenfassung der Erkenntnisse und einen Ausblick auf weitere Fragestellungen.
4
Kapitel 2
IT Service Management, ITIL und
die CMDB
2.1 IT Infrastructure Library (ITIL)
Die Information Technology Infrastructure Library (ITIL) ist eine herstellerunabhängige
Sammlung von Best Practices zur Umsetzung eines IT Service Managements. ITIL
wurde auf Initiative der Britischen Regierung entworfen und wird derzeit vom Oce of
Government Commerce (OGC) publiziert. Aktuell ist ITIL in der Version 3 verfügbar
und stellt einen De-facto-Standard bei der Einführung von IT Service Management
im Unternehmen dar [ZHB05]. Die ITIL deniert detailliert zahlreiche Prozess- und
Aufgabenbereiche, von besonderer Bedeutung im Zusammenhang mit einer CMDB sind:
• Service Support:
Beschäftigt sich mit dem störungsfreien und ezienten Betrieb
von IT Dienstleistungen. Besonders erwähnenswerte Unterbereiche sind das Conguration Management und das Change Management.
• Service Delivery:
Ziel ist es, eine bestmöglichen Kundenorientierung zu erreichen,
was durch die Identizierung, Planung und Überwachung der Anforderungen zwischen Kunden und Dienstleister erreicht werden soll.
Diese beiden Bereich gliedern sich wiederum in weitere Kernbereiche. Da der Umfang
der ITIL und der enthaltenen Prozesse und Aufgabenbereiche sehr groÿ ist, wird für
ausführlichere Erklärungen auf die weiterführende Literatur verwiesen, insbesondere
auf die oziellen Dokumente der OGC (bspw. [O06a] und [O06b]).
2.2 Conguration- und Change-Management
ITIL versteht das Conguration Management als Prozess der Planung, Identizierung,
Erfassung, Verwaltung und Kontrolle der IT-Infrastruktur. Nach Denition der ITIL
setzt sich diese Infrastruktur aus einzelnen Conguration Items (CI) zusammen. CIs
sind Infrastrukturkomponenten und gegebenenfalls mit diesen in Verbindung stehende
Informationselemente wie beispielsweise ein Änderungsantrag (siehe 3.1).
5
Das Ziel des Conguration Management ist laut ITIL die Erfassung aller IT-Vermögensgegenstände einer Organisation, deren Kongurationen und deren Beziehung untereinander. Somit geht das Conguration Management über die Aufgaben des IT-Asset Management hinaus, welches nur den Bestand erfasst. Durch die erfassten Informationen
soll ein logisches Modell der IT-Infrastruktur erzeugt werden, das dem Management die
für die Entscheidungsndung nötigen Analyse- und Überwachungsdaten zur Verfügung
stellt. Des Weiteren werden die Informationen direkt für das Incident Management, Problem Management, Change Management und Release Management verwendet, welche
zentrale Bestandteile des ITIL Service Management Prozesses sind.
ITIL empehlt die Umsetzung des Conguration Managements mit Unterstützung einer
Conguration Management Database (CMDB). Diese Empfehlung gilt für Organisationen jeder Gröÿe, mit Ausnahme von äuÿerst kleinen IT-Infrastrukturen [O06a]. Die
CMDB ist eine Datenbank, welche die identizierten CIs, deren Kongurationen, Abhängigkeiten und Historie enthält und idealerweise automatisierte Datenerfassung und
Datenabfrage ermöglicht. Die CMDB ist der zentralste Bestandteil in einer ITIL ITManagement Architektur, und stellt Funktionalität zur Verfügung, welche vom Service
Management und den Prozessen Service Support und Service Delivery benötigt wird.
Eine CMDB kann somit als Rückrat des Service Management Prozess der ITIL betrachtet werden, und ist die wichtigste Daten- und Informationsquellen, der sogenannte
Single Point of Truth. Objekte, die nicht in der CMDB erfasst sind, können nicht diese
Prozesse durchlaufen und es gibt für sie beispielsweise keine Incident- und Request for
Change-Anfragen [ZHB05]. Abbildung 2.1 veranschaulicht diese Abhängigkeit grasch.
Die Veränderungen der Infrastruktur wird durch das Change Management betreut, welches dafür sorgt, dass nur zugelassene Änderungen an der IT-Infrastruktur durchgeführt
werden [Els06]. Ziel ist die Minimierung beziehungsweise Vermeidung von änderungsbedingten Service-Unterbrechungen, anhand von standardisierten Prozessen zur Verarbeitung von Änderungsanträgen (Request for Change)[OSW07]. Jede durch das Change
Management vorgenommene Änderung muss in die CMDB eingepegt werden. Typischerweise wird jedoch vor jeder Änderung der aktuelle Ist-Zustand betrachtet, um
eine Orientierung und Risikoabschätzung bei der Durchführung dieser Änderungen zu
erhalten [Lie06]. Die hierzu nötigen Informationen werden wiederum von der CMDB
bereitgestellt. Somit sind das Conguration Management, die CMDB und das Change
Management eng miteinander verzahnt und benden sich in einem ständigen Wechselspiel und Informationsaustausch.
Obwohl die CMDB ein zentraler und gegebenfalls businesskritischer Punkt ist, stellt
deren Implementierung eine der gröÿten Herausforderungen bei der Einführung der
ITIL und des IT Service Managements dar. Dies ist insbesondere zurückzuführen auf
die weitreichenden Desingentscheidungen (Struktur und Umfang der CMDB, Detailreichtum der CIs), die getroen werden müssen und die zeitintensive Befüllung und
Wartung [BGSS06]. Problematisch ist auÿerdem, dass die ITIL nur beschreibt, was in
einer CMDB enthalten sein kann und sollte, es wird jedoch nicht explizit beschrieben,
6
Abbildung 2.1: Service Management und die CMDB nach ITIL Version 2.
wie diese Information erfasst, gepegt und verwaltet werden kann. Dies bleibt Aufgabe
konkreter technischer Lösungen und Produkte.
2.3 Neuerungen durch ITIL Version 3
Die Mitte 2007 erschienene Version 3 der ITIL fokusiert sich auf den Service-Life-Cycle
und verändert die Einordnung der CMDB in die Service Management Architektur. Auch
in dieser Version ist die CMDB weiterhin zentrale Informationsquelle des IT-Service Managements und eng mit dem Change- und Conguration-Management verzahnt. Neu
eingeführt wurde nun jedoch das Conguration Management System (CMS), welches
der CMDB übergeordnet ist und die Möglichkeit bereitstellt, mehrere CMDBs zu verwenden, welche zentral über das CMS angesprochen und gepegt werden können. Neu
eingeführt wurde die Vorgabe alle prozess- und organisationsorientierten Informationen
in der CMS abzulegen (vgl. 3.1).
Die CMS wiederum ist Teil des Service Asset und Conguration Management Prozesses (SACM), welcher in dem neu eingeführten Service Knowledge Management System
(SKMS) einzuordnen ist. Das SKMS bündelt Tools, Prozesse und Datenbanken, mit
dem Ziel die dort enthaltenen Informationen zentral zu verwalten und zu analysieren.
Die ITIL Version 3 ist recht neu und es sind bisher nur wenig Informationen und
Analysen über die Neuerungen verfügbar. Darüber hinaus sind kaum Tools und Im-
7
plementierungen vorhanden, welche die neue Version vollständig unterstützen. Daher
ist die Verbreitung in Organisationen derzeit noch gering und es ist zu erwarten, dass
auch ITIL Version 2 auf absehbare Zeit relevant bleiben wird. Der weitere Inhalt dieser
Ausarbeitung bezieht sich somit auf beide Versionen. Wird im weiteren Verlauf dieser
Arbeit von ITIL gesprochen, so bezieht sich diese Aussage immer auf Version 2 und
Version 3. Ist ein bestimmte ITIL Version gemeint, wird ITIL V2 oder ITIL V3 verwendet.
Nachdem bisher eine Einordnung der CMDB in das Konzept des Service-Managements
und der ITIL gegeben wurde, erläutert das nachfolgende Kapitel vertiefend die Struktur
und die Funktionen einer CMDB.
8
Kapitel 3
Struktur, Funktionen und Konzepte
einer CMDB
3.1 Conguration Items (CIs)
Eine CMDB bildet das IT-System einer Organisation anhand der erfassten CIs ab. Diese CIs sind Infrastrukturkomponenten des IT-Systems von beliebiger Granularität. Ein
Rechnersystem kann somit als eine ganze Einheit betrachtet werden oder jede Komponente einzeln erfasst werden, beispielsweise Prozessor, Mainboard, Grakkarte und so
fort. Die genaue Denition der als CI zu erfassenden Objekte stellt sich als schwierig
dar und wird auch in den Best Practices der ITIL V2 nicht klar dargelegt [BGSS06],
zudem führt ITIL V3 einige Denitionsänderungen im Bezug auf erweiterte Daten ein.
Gemeinsam ist allen CIs, die Zuordnung zu einem Datensatz, der dessen Eigenschaften
(Attribute) speichert.
Über die Fragestellung des Detailierungsgrads der zu erfassenden Komponenten hinaus,
gibt es in der Literatur widersprüchliche Auassungen darüber, ob auch mit Infrastrukturkomponeten in Verbindung stehende Informationselemente als CI bezeichnet und
dieser Form in die CMDB aufgenommen werden sollten. Die ITIL V2 [O06b] führt
auch diese Abgrenzung ein, gibt jedoch keine direkte Anweisung wie mit diesen Elementen umgegangen werden soll, so dass unterschiedliche Ansichten und Auslegungen
existieren.
Beispielsweise ist nach [BMC05] ein Conguration Item, ein Objekt einer Dateneinheit,
das Teil ihrer Umgebung ist. Hierbei ist es notwendige Bedingung, dass ein CI zumindest einige kongurierbare (beziehungsweise veränderliche) Attribute besitzt. Weiter
heiÿt es, dass Dateneinheiten physischer, logischer oder konzeptioneller Art sein können. Dateneinheit physischer Art seien beispielsweise Rechnersysteme, von logischer
Art installierte Instanzen einer Software und ein Geschäftsprozess beispielsweise von
konzeptioneller Art. Zudem wird gefordert, dass diese Dateneinheiten immer direkter
Teil ihrer Umgebung sein müssen und nicht nur eine Information über diese. Schluÿfolgernd wird gesagt, dass somit Verträge, Helpdesk-Tickets, Service Level Agreements
und Change-Ereignisse zwar kongurierbare Attribute besitzen, aber keine CIs sind, da
9
sie nicht direkter Teil Ihrer Umgebung sind. Diese Daten sollten auch in der CMDB
gespeichert und mit den CIs verknüpft werden, da sie wichtige Information über Ihre
Umgebung enthalten, jedoch nicht als CIs sondern separat als verwandte Daten. Die
Autoren argumentieren, dass dies den Vorteil bringt, dass die CMDB somit auf ihre
Hauptaufgabe, die Verwaltung von CIs, fokussiert bleibt, was insbesondere eine einfachere Informationsanalyse und bessere Datenbankperformanz ermöglicht.
Entgegengesetzter Meinung ist hierbei beispielsweise [Olb06], wo eindeutig darauf hingewiesen wird, dass alle verknüpften Dokumente gleichermaÿen wie Infrastrukturelemente
als CIs aufgefasst werden. Beispielhaft genannt werden hier Verträge, Betriebs- und Installationsanleitungen, Notfallpläne und Unternehmensrichtlinien.
Es herrscht somit Einigkeit, dass die mit CIs in Verbindung stehenden Informationen
in die CMDB aufgenommen und mit den CIs verknüpft werden sollten, die Form, also
ob selbst als CI oder nur als verwandte beziehungsweise erweiterte Daten, ist jedoch
strittig.
Weitere Diskussionen gibt es um die Annahme Mitarbeiter als CIs zu erfassen. Da
Mitarbeiter direkter Teil ihrer Umgebung sind und kongurierbare Attribute besitzen
(beispielsweise Kenntnisse, Arbeitsstunden und Abteilungen), müssten diese nach der
Deniton von [BMC05] in der CMDB erfasst werden. Gegner argumentieren hingegen,
dass die CMDB die Erfassung von technischen Komponenten zum Ziel hat und die
Mitarbeitererfassung Aufgabe des Human Resource Management. Ein Aufnahme in die
CMDB kann daher zu unerwünschten Redundanzen führen. Die ITIL V2 [O06b] sagt
hierzu nur vage, dass solche Informationen gespeichert werden können, verweist hierbei
aber auf mögliche rechtliche Probleme.
Mit der Einführung von ITIL V3 wurde versucht diesen Ungenauigkeiten zu begegnen und es wurde deniert, dass prozessorientierte und organisatorische Informationen
in einem Conguration Management System (CMS), welches den CMDBs übergeordnet ist (vgl. 2.3), gesammelt werden sollte. Als prozessorientierte Informationen werden
hier bekannte Probleme und Fehler, Incidents und geplante Changes und Releases aufgefasst. Unter organisatorischen Informationen sind Daten über Mitarbeiter, Kunden,
Benutzer, Lieferanten und Standorte zu verstehen.
Trotz den Änderungen in ITIL V3 verdeutlichen die oben genannten unterschiedlichen
Auassungen die Problematik der Auslegung, der in ITIL gegebenen Best Practices.
Bei der praktischen Einführung im Unternehmen erscheint es somit besonders wichtig
eine organisationsweite, eindeutige Denition der CIs zu erreichen und hierdurch eine
konsistente Erfassung der Komponenten zu gewährleisten. Bei mangelnden Erfahrungen innerhalb des eigenen Unternehmens könnte das Hinzuziehen von spezialisierten
externen Beratern somit durchaus sinnvoll sein. Auf Grund der derzeitig noch mangelnden Verbreitung von ITIL V3 und der fehlenden Unterstützung dieser Version durch
Software-Tools, wird die Problematik der Einteilung in CIs und mit diesen in Verbindung stehenden, erweiterten Aufzeichnungen noch einige Zeit aktuell bleiben. Daher
wird dieser Abschnitt, zum besseren Verständnis, mit einer Vorstellung der in ITIL V2
10
[O06b] genannten Conguration Item Beispiele, abgeschlossen.
Beispielhaft als CI genannt sind:
•
Services
•
Server
•
Environment (Umgebung)
•
Equipment (Ausstattung)
•
Netzwerkkomponenten
•
Schreibtische
•
Mobile Einheiten
•
Anwendungen
•
Lizenzen
•
Telekommunikationsdienste
•
Anlagen und Einrichtungen
Beispielhaft genannte, mit CIs in Verbindung stehende (erweiterte) Aufzeichnungen und
Daten sind:
•
Incidents (Ereignisse)
•
Bekannte Fehler
•
Probleme
•
Mitarbeiterdaten
•
Zulieferer
•
Lage
•
Geschäftsbereiche
•
Prozeduren
3.2 CI Typen und Attribute
Die ITIL sieht vor, dass alle CIs klassiziert werden, indem ihnen ein vordenierter
CI-Typ zugewiesen wird [O06a]. Die Bestimmung eines CI-Typs erleichtert die Suche
und die Bildung von Organisationsstrukturen. Viele CMDB-Implementation erlauben
es, für jeden CI-Typ unterschiedliche Attribute vorzudenieren. Allen CIs gemeinsam
ist die systemweit eindeutige Identizierungskennung. Attribute können theoretisch beliebig gewählt werden und alle bekannten und bestimmbaren Informationen umfassen.
11
Auch hierbei ist darauf zu achten, dass insbesondere die manuelle Erfassung und Pege
umfangreicher Datensätze sehr zeitintensiv und fehleranfällig sein kann. Der Umfang
der erfassten Daten muss wirtschaftlich sinnvoll sein. Typische Attribute für ein Rechnersystem sind beispielsweise:
•
eindeutige Identizierungskennung
•
CI-Typ
•
Seriennummer
•
Modellnummer
•
Garantiefrist
•
Installationsdatum
•
Administrator/Verantwortlicher
•
Hersteller
•
Status (aktiv, auÿer Betrieb, in Planung, im Test, im Lager, in Reparatur, ...)
3.3 Relationen der CIs
Im Gegensatz zu reinen IT Asset Management Tools enthält die CMDB auch weiter
gehende Informationen über die Beziehungen und Abhängigkeiten der CIs untereinander. Somit besteht der Datensatz einer CI aus seinen Attributen sowie den Verweisen
(Links) zu anderen CI-Datensätzen und verwandten Dokumenten. Hierdurch bilden die
Datensätze eine übersichtliche objekthierachische Struktur [Olb06].
Die Relationen der CIs können unterschiedlichster Art sein, für ein CI A und ein CI B
beispielsweise:
•
A ist Teil von B (z.B. ein Prozessor als Teil eines PCs)
•
A ist mit B verbunden (z.B. ein Drucker ist mit einem PC verbunden)
•
A löst B aus (z.B. startet ein Rechner einen Service auf einem Server)
•
A verwendet B (z.B. Softwareinstanz verwendet einen Rechner)
•
A ist abhängig von B (z.B. Prozessor ist abhängig von Netzteil)
Das Konzept der Verwendung von Attributen und Relationen ermöglicht zwei Optionen
bei der detaillierten Erfassung von Komponenten. Beispielsweise kann zur Erfassung
eines kompletten Desktop-PCs nur ein CI Objekt angelegt werden, das als Attribut den
Monitor und die Betriebssystem-Software zu gewiesen bekommt. Die andere Option ist
die zusätzliche Erzeugung von CIs für den Monitor und die Betriebssystem-Software
und die anschlieÿende Verknüpfung dieser durch Relationen. Diese Option bietet den
12
Abbildung 3.1: Übertragung der Netzwerkarchitektur in CIs und deren Beziehungen.
Vorteil, dass die Verknüpfungen unterschiedliche Typen besitzen und explizit die Art
der Relation angeben. Welche der beiden Optionen gewählt werden sollte, ist wiederum
ein Designentscheidung, die nicht generell beantwortet werden kann.
Die Verknüpfungen der Komponenten bilden die IT-Architektur einer Organisation ab
und sind der entscheidende Vorteil einer CMDB gegenüber IT-Asset Management Datenbanken, welche nur den zahlenmäÿigen Bestand erfassen. Anhand dieser Architekturkenntnis sind das Management und die IT-Verantwortlichen in der Lage Analysen
über die Auswirkungen von Änderungen (Change Management) zu erstellen, ein zügiges Incident-Management zu gewährleisten und Schwachstellen sowie Engpässe oder
Überschüsse zu erkennen.
Abbildung 3.1 zeigt die Übertragung einer Netzwerkarchitektur in CIs und deren Verbindungen. Bei einem Ausfall des zentralen Switchs könnte anhand der in der CMDB gespeicherten Verbindungen erkannt werden, welche Komponenten hiervon direkt (DesktopPC, Laptop, Server) und indirekt (Digitalkamera, Scanner, Drucker) betroen sind.
3.4 Datenerfassung und Pege
Sobald ein CI in die IT-Infrastruktur integriert wird, sollte es direkt unter die Kontrolle des Conguration Management gestellt und in der CMDB erfasst werden [O06b].
Äuÿerst erstrebenswert ist somit die Automatisierung der Prozesse zur Datenerfassung
und zum Datenabruf. Der automatische Import von Daten in die CMDB ermöglicht
eine erhebliche Verringerung des Zeitaufwands zur Pege der erfassten CIs, der erweiterte Daten und deren Relationen. Des Weiteren ist diese dynamische Synchronisation
bei Änderungen typischerweise zeitnäher als eine manuelle Pege und oftmals weniger
fehleranfällig. Verschiedene CMDB-Lösungen bieten bereits diese Funktionalität zum
automatischen Datenimport an. Hierbei ist es erforderlich, dass die Integrität, Reinheit
13
und Gültigkeit der Daten gewährleistet ist. Darüber hinaus muss das CMDB-System in
der Lage sein, die erhaltenen Informationen aufeinander abzustimmen und beispielsweise eine CI die, von zwei Datenquellen erfasst und mitgeteilt wurde, erkennen. Typische
Kongurationsquellen die einer CMDB für den Datenimport und die Datenpege zur
Verfügung stehen, sind Tools und Systeme für die Unterstützung folgender Aufgaben:
•
Incident-Management
•
Asset-Erkennung
•
Service Desk Management
•
Change Management
•
Security Management
•
Netzwerkmanagement
•
Lifecycle Asset Management
•
Vertragsmanagement
•
Service Level Management
•
Human Resource Management
•
Active Directory
3.5 Konkrete Leistungen und Vorteile einer CMDB
Die angebotenen Funktionen und unterstützten Prozesse einer CMDB sind stark abhängig von den gesammelten Daten und Informationen, der Einbindungen in den ITManagement Prozess und der internen Architektur der konkreten CMDB SoftwareLösung. Generell ist eine CMDB in der Lage durch ihre Informationen die Eektivität
aller ITIL-Prozesse zu erhöhen [OSW07]. Im Rahmen dieser Funktion als zentrale Informationsquelle, kann die CMDB selbst als Service Knowledge Management System
(SKMS) aufgefasst werden [SG07], beziehungsweise im Kontext von ITIL V3 als wichtigster Bestandteil des SKMS.
Wie in Kapitel 2 bereits angesprochen, ist die CMDB jedoch am engsten mit dem
Conguration- und Change-Management verbunden, welche sich in der in Abschnitt
2.2 beschriebenen Wechselwirkung benden. Durch Kenntnis der Beziehungen zwischen
CIs, kann eine CMDB insbesondere bei der Entdeckung von Abhängigkeiten zwischen
CIs helfen. Diese Informationen können bei der Planung von Infrastrukturänderungen verwendet werden, da beispielsweise identiziert werden kann welche CIs von einer Änderung oder einem Ausfall direkt oder indirekt betroen sind. Auf Grund des,
in der CMDB enthaltenen, logischen Infrastrukturmodells, kann eine CMDB auch als
Infrastruktur-Modellierung-System aufgefasst werden [SG07].
Über diese Funktionalität hinaus, kann eine CMDB auch die grundlegenden Leistungen
14
eines IT-Asset Management Tools erbringen und für die reine Verwaltung und Erfassung des aktuellen Infrastrukturinventars benutzt werden.
Nachfolgend werden zum weiteren Verständnis beispielhaft einige Informationen genannt, die aus einer vollständig integrierten CMDB abgerufen werden können. Mögliche
Leistungen und Funktionen einer CMDB sind beispielsweise:
•
Ausgabe aller CIs, inklusive der Attribute
•
Ausgabe aller CIs die abhängig sind von einer bestimmten CI
•
Visualisierung der CIs und deren Beziehung untereinander
•
Ausgabe von CIs unterschieden nach Test- und Live-Umgebungen
•
Alle Request for Changes einer CI
•
CIs, die von einem bestimmten Hersteller sind
•
CIs, die ein bestimmtes Alter erreicht haben
•
Die Historie der CIs
•
Alle CIs, die mit keinem anderen CI in Verbindung stehen
•
Ausstattung und Software an einem bestimmten Ort
•
CIs die verändert, ersetzt oder abgeschat werden sollen
•
Erfasste Probleme einer CI
•
CIs, die im Zusammenhang mit einem Incident stehen
•
CIs, die eine IP besitzen und deren Beziehung untereinander
Nach der Vorstellung einiger Beispiele von konkreten Leistungen einer CMDB, stellt die
folgenden Aufzählung nun eine Sammlung der wesentlichen ökonomischen Vorteile einer
CMDB im Zusammenspiel mit dem Conguration- und Change-Management dar. Diese
Sammlung orientiert sich an dem oziellen ITIL Service Support Handbuch [O06b]
und [OSW07].
Die wesentlichen ökonomischen und ezienzsteigernde Vorteile für eine Organisation
sind:
•
Bereitstellung genauer Informationen über alle CIs
•
Proaktives Management der IT-Komponenten zur Unterstützung der Serviceorientierung.
•
Informationen zur Kontrolle besonders wertvoller CIs
•
Unterstützung bei der Einhaltung vertraglicher Pichten
15
•
Unterstützung der Einhaltung gesetzlicher Bedingungen
•
Unterstützung bei der nanziellen Planung und bei Expansionsbestrebungen
•
Erkennen von Änderungen in der Softwarelandschaft
•
Unterstützung bei der Notfallplanung, durch besseres Verständnis der Zusammenhänge
•
Unterstützung des Release Managements
•
Verbesserung der Sicherheit durch die Überwachung der CI Versionen
•
Erkennen von nicht autorisierter Software
•
Nachweisbarkeit der IT gegenüber der Anwendergemeinde
•
Kontrolle der Assets durch Abgleich der vorhandenen CI-Datensätze mit der aktuell erkannten Infrastruktur
•
Minimiertes Betriebsrisiko durch die verbesserte Analyse der Auswirkung von Änderungen
•
Bereitstellen von Informationen für das Problem Management zur Erkennung von
Trends (bspw. welche Produkte erzeugen häug Probleme)
•
Bessere Einschätzung von Risiken, da die Beziehungen und Abhängigkeiten zwischen den CIs bekannt sind
16
Kapitel 4
Realisierung einer CMDB
4.1 Anforderungen an eine CMDB
Vor der Realisierung einer CMDB ist es erforderlich, die Anforderungen, die eine solche
Lösung erfüllen muss, zu erkennen. Daher werden die allgemein gültigen Anforderungen
an eine CMDB im folgenden Abschnitt beleuchtet.
Die Aktivitäten im Rahmen des Conguration Managements sind gemäÿ der ITIL die
Conguration Management Planung, die Kongurations-Identikation, die Kontrolle
der CIs, die Buchführung des Kongurations-Status und die Kongurations-Verikation
[O06b]. Um diese Aktivitäten zu unterstützen muss die CMDB, nach [SG07], die folgenden fünf funktionalen Anforderungen erfüllen.
Zunächst muss die CMDB in der Lage sein, die CI Erkennung zu unterstützen, was insbesondere die Einhaltung von Namenskonventionen, die Sicherstellung der Datenkonsistenz und die Aufzeichnung von Basiskongurationen der CI erfordert. Die Erfassung
und Aufzeichnung kann manuell erfolgen, wobei aber insbesondere bei umfangreichen
IT-Infrastrukturen der Einsatz automatischer Tools erstrebenswert ist.
Die zweite funktionale Anforderung ist die Fähigkeit zur Visualisierung des Datenbestandes der CMDB, so dass diese für Reviews und Audits verwendet werden können.
Dies erlaubt einen leichteren Überblick über die komplexen Zusammenhänge moderner
IT-Architekturen.
Die Component Failure Impact Analysis (CFIA) sollte von der CMDB angeboten werden. Diese Funktion erlaubt, bei einem akuten Ausfall einer CI oder bei der Planung
und Vorbereitung auf einen möglichen Ausfall, alle von einer CI abhängigen CIs zu entdecken (Bottom-up) beziehungsweise alle CIs zu ermitteln von denen eine CI abhängig
ist (Top-Down).
Die vierte notwendige Funktion ist die Unterstützung von Plausibilitäts-Prüfungen und
Audits. Hierbei sollten mindestens drei Arten von Audits unterstützt werden:
•
Das inhaltsbezogene Audit (Entdeckung unauthorisierter CIs und unbekannter
Instanzen)
•
Das strukturelle Audit (Entdeckung isolierter CIs)
17
•
Das technische-konistenz Audit (Entdeckung doppelter CIs oder ungültiger Beziehungen)
Die fünfte funktionale Anforderung an die CMDB ist die Fähigkeit zur Integration externer Informationsquellen, insbesondere von organisationsfremden Datenbanken und
CMDBs.
Über diese funktionalen Anforderungen hinaus, muss das interne Daten- bzw. Informationsmodell einer CMDB noch weiteren Anforderungen genügen, um eine langfristige
und optimale Umsetzung der ITIL zu gewährleisten.
Grundsätzlich muss das Datenmodell in der Lage sein, alle identizierten CIs, deren Attribute und Beziehungen in einer zweckmäÿigen und anpassbaren Form zu erfassen. Dies
bedeutet, dass die gespeicherten Daten in der gewünschten Form abgerufen und durchsucht (siehe 3.5), sowie gepegt und erweitert werden können. Darüber hinaus muss
das Datenmodell verschiedene Abfragefunktionen (selektive und relationale Abfragen)
und Suchschlüssel erlauben, um die erfassten Daten sinnvoll analysieren, managen und
bewerten zu können.
Eine hohe Anpassungsfähigkeit des Modells ist notwendig, da sich die IT-Infrastruktur
und der Service Management Prozess typischerweise in einem ständigen Wandel benden und sich diese Änderungen direkt auf die CMDB und dessen Datenmodell auswirken
können. Dies schlieÿt auch die Fähigkeit ein, den Detailierungsgrad der erfassten CIs zu
erhöhen oder zu verringern.
Alle Änderungen an den CIs müssen gemäÿ der ITIL verfolgt und dokumentiert werden
[O06b]. Eine weitere funktionale Forderung an das Datenmodell ist somit die Fähigkeit zur Speicherungen der Historie aller CIs [SG07]. Dies bedeutet, dass der komplette
Lebenszyklus (Planung, Anschaung, Betrieb, Deaktivierung etc.) der CIs im Datenmodell erfasst, gespeichert und abgerufen werden kann. Demnach ist es notwendig, dass
das Informationsmodell in der Lage ist auch diese Historie eines CIs zu speichern und
wiederzugeben.
[SG07] stellt abschlieÿend noch die Forderung, einen Katalog von vordenierte DatentypSchablonen für allgemeine, häug auftretende CI Typen (z.B. PC, Server, Hub) verwenden zu können. Dies verringert die nötige Implementierungszeit einer CMDB erheblich
[SG07]. Die Datentyp-Schablonen sollten sowohl sofort einsetzbar, als auch anpassbar
sein und auch typische Beziehungen zwischen CI Typen bereits vordeniert enthalten.
4.2 Einführung einer CMDB
Die Einführung einer CMDB in einer Organisation ist ein aufwendiger und komplexer
Prozess, da die Kontrolle der gesamten IT-Infrastruktur und der IT-Dienste, einer umfangreiche und gewissenhafte Planungen bedarf. Darüber hinaus stellt die anschlieÿende
Erfassung der Daten eine zeitintensive und gegebenenfalls fehleranfällige Aufgabenstellung dar. Der im Nachfolgenden beschriebene Prozess zur Einführung einer CMDB soll
als ein Leitfaden bei der Planung und Umsetzung dienen.
18
Der erste Schritt zur Einführung ist die Dention der Ziele, welche durch die CMDB
erreicht werden sollen und die Abschätzung des notwendigen Implementierungs- und
Pegeaufwandes. Soll die CMDB im Rahmen einer Umsetzung des ITIL Service Managements eingeführt werden, muss auch ein genaue Untersuchung der verbundenen Prozesse statt nden. Hierbei ist insbesondere eine Betrachtung der Change Management-,
Conguration Management- und Release Management-Prozesse und deren Anforderungen und Leistungen für die CMDB notwendig [O06b]. Auf Basis der Zielsetzung und
der Aufwandsabschätzung kann eine fundierte Entscheidung getroen werden, ob die
Einführung einer CMDB für die Organisation sinnvoll und erstrebenswert ist. Hier sei
angemerkt, dass ITIL für alle IT-Infrastrukturen, auÿer Kleinstsystemen, die Verwendung von CMDBs empehlt [O06b].
Der nächste Schritt sieht die Festlegung eines Projektteams vor, welches die Einführung
der CMDB betreut beziehungsweise durchführt und gegebenenfalls später die Pege und
Wartung des Systems übernimmt. Bei einer Einführung im Kontext der ITIL, sieht diese auch die Bestimmung eines Conguration Managers und eines Change Managers vor
[O06b]. Der Conguration Manager (und sein Team) ist im weiteren Prozessverlauf für
die detaillierte Erfassung der existierenden IT-Infrastruktur verantwortlich. Der Change
Manager wird sofort aktiv, sobald die ersten Daten in der CMDB erfasst sind und überwacht und pegt ab diesen Zeitpunkt alle Änderungen an der IT-Infrastruktur.
Als nächstes ist eine Planung des Designs und der Implementierung vorzunehmen. Hierbei muss zunächst das existierende System analysiert werden. Diese Aufgabe umfasst
sowohl die Bestimmung der Hauptinfrastrukturelemente, als auch die derzeitigen Conguration und Change Management Prozesse. Dabei werden auch die bereits vorhandenen Kongurationsdatenquellen (z.B. Exceltabellen, Datenbanken) erfasst und es wird
ermittelt wie diese Daten weiterverarbeitet werden können. Im Rahmen der ITIL müssen darüber hinaus die verschiedenen Schnittstellen der unternehmensweiten Service
Management Prozesse detailliert betrachtet werden und hieraus Anforderungen an die
CMDB abgeleitet werden. Anschlieÿend wird der Geltungsbereich der einzuführenden
CMDB deniert und es wird festgelegt in welchem Umfang Informationen über CIs
gesammelt werden sollen. Da diese Entscheidung weitreichende Folgen hat, sollte diese
äuÿerst gewissenhaft getroen werden, gegebenenfalls kann auch der Einsatz externer
Berater sinnvoll sein (siehe Abschnitt 3.1).
Ausgehend von diesen Kenntnissen kann nun eine detaillierte Anforderungsliste der notwendigen Funktionen der CMDB erstellt werden. Hierbei sind auch die in Abschnitt 4.1
dargelegten allgemeinen Anforderungen an eine CMDB zu beachten. Mit Hilfe dieser Anforderungen wird eine Evaluation verschiedener CMDBs durchgeführt und eine Auswahl
getroen. Die gewählte CMDB wird als nächstes erworben, installiert und konguriert.
Dies umfasst auch die Anbindung der nötigen Schnittstellen an andere Tools, die Denition von Benutzern, Rollen und Rechten, sowie die Datensicherung durch Backups.
Nun kann das allgemeine Datenmodell der CMDB erstellt werden, welches die CI-Typen,
die Attribute, die Beziehungstypen und die Hauptinfrastrukturelemente umfasst. Anschlieÿend kann die manuell oder automatische Befüllung der CMDB erfolgen. Dies kann
schrittweise jeweils für einen anderen Organisationsbereich durchgeführt werden.
19
Abschlieÿend ist die Schulung der Mitarbeiter sinnvoll, um das Verständnis für die
Ziele und die Konzepte des Change Managements und der CMDB zu erhöhen. Dieses Verständnis ist bei der Pege und Wartung der CMDB hilfreich, welche nach der
Einführung kontinuierlich durchgeführt werden muss, um ein konsistentes System mit
korrekten Daten zu gewährleisten.
4.3 Produktübersicht
Abgeschlossen wird dieses Kapitel mit einer kurzen Übersicht über die wichtigsten
CMDB Produkte. Dies ist keine vollständige Liste, da neben den genannten Produkten
zahlreiche Speziallösungen existieren, deren Aufzählung den inhaltlichen Rahmen dieser Arbeit übersteigen würde. Die Liste enthält neben Standardprodukten jedoch auch
Open Source Lösungen, da diese insbesondere für den Einsatz in kleinen Organisationen
interessant sind oder bei einer Evaluation oder Schulung des grundlegende Konzepts einer CMDB verwendet werden können.
20
Kapitel 5
Zusammenfassung und Fazit
Diese Arbeit ordnete die CMDB in die Gesamtarchitektur eines ITIL IT Services Managements ein. Hierbei wurde deutlich, dass die CMDB eine zentrale Datenquelle für
zahlreiche ITIL Prozesse darstellt und besonders eng mit dem Change Management und
Conguration Management verknüpft ist. Grundsätzlich empehlt ITIL die Einführung
einer CMDB zur Unterstützung dieser Prozesse.
Eine CMDB erfasst alle IT-Infrastrukturelemente und mit diesen in Verbindung stehende Informationen. Hierbei werden diese Elemente nicht nur einzeln gespeichert, sondern
es werden auch deren Beziehungen untereinander abgebildet. Dadurch geht der Informationsgehalt einer CMDB über den eines reinen IT Asset Management Tools hinaus,
welches nur den Bestand erfasst.
Im weiteren Verlauf dieser Arbeit wurden konkrete Funktionen und Leistungen einer
CMDB beleuchtet und es wurden allgemeine Anforderungen vorgestellt, welche eine
CMDB erfüllen sollte, um eine optimale Leistung zu erbringen. Generell ist eine CMDB
in der Lage alle ITIL Prozesse zu unterstützen, indem sie als Service Knowledge Management System fungiert und die zentrale Informationsquelle bildet. Darüber hinaus
kann ein CMDB als IT Infrastruktur Modellierungssystem verstanden werden, welches
beispielsweise die Planung von Änderungen, anhand der Kenntnis der CI-Beziehungen,
unterstützt. Zudem erbringt eine CMDB die Leistungen eines reinen IT Asset Management Tools.
Abschlieÿend wurde ein Leitfaden für die Einführung einer CMDB geboten und die
wichtigsten CMDB Tools vorgestellt.
In dieser Arbeit wurde die hohe Bedeutung und der groÿe Nutzen einer CMDB für das
ITIL IT Service Management deutlich. Daher erscheint die Einführung einer CMDB
in Organisationen, welche den Wandel zu kunden- und serviceorientierten Strukturen
vollziehen möchten, durchaus sinnvoll. Hierbei ist jedoch zu beachten, dass eine solche
Einführung mit erheblichen Aufwand verbunden ist und eine umfangreiche und gewissenhafte Planung erfordert.
21
Literaturverzeichnis
[BGSS06]
Brenner,
Garschhammer,
Michael ;
Sailer,
Markus ;
Thomas: CMDB - Yet Another MIB? In:
Martin ;
Schaaf,
Lecture Notes in Computer Science
(2006), Nr. Volume 4269: Large Scale Management of Distributed Systems
[BMC05]
BMC Software
;
BMC Software
Conguration Management Database (CMDB)?
[Els06]
Elsässer, Wolfgang:
What do you need from a
(Hrsg.):
2005. Whitepaper
ITIL einführen und umsetzen. München, Wien : Hanser,
2006
ITIL - Change Management.
[Lie06]
Lienemann,
[O06a]
Office of Government Commerce (OGC),
Gerhard:
Management.
[O06b]
Hannover : Heise, 2006
Hrg.:
ICT Infrastructure
Norwich, U.K. : The Stationary Oce, 2006
Office of Government Commerce (OGC),
Hrg.:
Service Support.
Nor-
wich, U.K. : The Stationary Oce, 2006
[Olb06]
Olbrich,
[OSW07]
Oldfield,
Alfred:
Adrian ;
ring Point
Sterbens,
(Hrsg.):
onsmanagement.
[SG07]
ITIL kompakt und verständlich.
Robert ;
Wiesbaden : Vieweg, 2006
Waschke,
Marv ;
CA und Bea-
Einsatz einer CMDB für das Change-und Kongurati-
2007. Whitepaper
Requirements and Recommendations
for the Realization of a Conguration Management Database (CMDB). MünSchaaf,
Thomas ;
Gögetap,
Boran:
chen, 2007. Poster presented on HPSUA 07
[ZHB05]
Zarnekow,
Rüdeiger ;
tiertes IT-Management.
Hochstein,
Axel ;
Brenner,
Heidelberg : Springer, 2005
22
Walter:
Serviceorien-
Abbildungsverzeichnis
1.1
Verknüpfung von Geschäftsprozessen und Infrastruktur.
. . . . . . . . .
4
2.1
Service Management und die CMDB nach ITIL Version 2. . . . . . . . .
7
3.1
Übertragung der Netzwerkarchitektur in CIs und deren Beziehungen. . .
13
23