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