ITILv3 führt Configuration-Management-System ein
Basis neu überdacht
Der zentrale Bestandteil für das IT-Service-Management gemäß ITIL (IT Infrastructure Library) ist eine umfassende CMDB (Configuration Management Database). Sie vereint alle zu verwaltenden Komponenten (Configuration Items, CIs) und deren Beziehungen. Das CMDB-Konzept von ITILv2 wurde oft missverstanden: Unternehmen haben die CMDB als eine einzige physikalische Datenbank aufgesetzt, die zudem keine Informationen zu den CI-Beziehungen umfasste. ITILv3 führt nun den Begriff des Configuration-Management-Systems (CMS) ein, um eine föderierte CMDB zu beschreiben.
Das CMS hält laut ITILv3 Daten bereit, die sonst nicht oder nur sehr schwierig erhältlich sind.
Aktuelle Konfigurationsdaten stellt das CMS durch Zugriff auf Systeme wie Discovery-Anwendungen,
Personal-, Incident-, Problem- oder Change-Management, Inventory- oder Audit-Systeme bereit. Ziel
ist es, in einer Metadatenbank Konfigurationsdaten über deren kompletten Lebenszyklus vorzuhalten.
Dabei handelt es sich nicht zwingend um nur eine Datenbank, die Konfigurationsattribute beschreibt,
sondern vielmehr um die Verknüpfung (Federation) mehrerer CMDBs. Dies ist erstmals in der
Spezifikation von ITILv3 explizit beschrieben.
Entdeckungsreise in die IT-Umgebung
Unternehmen sollten Daten aus den Bereichen der Netzwerke, Speicher, Server und Anwendungen mit
passenden Discovery-Lösungen zusammentragen. Hier ist es besonders wichtig, die erkannten
Informati-onen intelligent miteinander in Beziehung zu setzen. Gefragt ist eine Lösung zur
automatischen Erkennung verteilter Geschäftsanwendungen, die die Changes und die damit verbundenen
Beziehungsänderungen in einer dynamischen IT-Landschaft eines Unternehmens identifiziert. Sie
kombiniert dazu die Erkennung von Applikationen mit einem modellbasierten Ansatz für das
Ressourcenmanagement. Anhand bestimmter Erkennungsmerkmale gilt es, gängige Anwendungen zu
erkennen, mit zusammenhängenden Applikationen zu gruppieren und deren Abhängigkeiten untereinander
automatisch abzubilden. Zudem müssen Anwender ihre CMDB-Datenbestände über verschiedene Quellen
hinweg synchronisieren können. So bleiben alle Konfigurationsinformationen stets auf dem neuesten
Stand.
Die Discovery-Software sollte Änderungen in einer dynamischen Umgebung mit den Elementen und
Abhängigkeiten sofort erkennen. Eine Monitoring- und Root- Cause-Analysis-Software untersucht dann
aufgrund dieser Daten, wann und wie stark die Verfügbarkeit von Geschäftsprozessen beeinträchtigt
ist. Dashboards verdichten die komplexen Informationen grafisch und geben permanent einen schnellen
Überblick über den Status der Services, Grafiken und Tabellen fassen Informationen zu erkannten
Applikationen sowie Veränderungen zusammen. High-Definition-Erkennung identifiziert
J2EE-Anwendungen und bildet sie inklusive Module, Komponenten und Zusammenhängen ab. Es gibt
inzwischen Software auf dem Markt, die zusätzlich Einzelkomponenten innerhalb zusammenhängender
Geschäftsanwendungen, dokumentierte und aktive Abhängigkeiten sowie Zusammenhänge zwischen
einzelnen Servern und verschiedenen Instanzen installierter Applikationsserver und Datenbanken
erkennt. So entsteht ein hoch aufgelöstes Gesamtbild der Applikationslandschaft mit den zugehörigen
Beziehungen.
Wer seine Konfigurationsdaten in ein einheitliches System integrieren möchte, sollte auf die
Skalierbarkeit des Discovery Tools achten: Nur wenn die Lösung über mehrere Rechenzentren hinweg
einsetzbar ist, erhalten Unternehmen einen einheitlichen, standortübergreifenden Einblick in
sämtliche CMDB-Daten. Anstatt alle System- und Komponenteninformationen in ein einziges Repository
aufzunehmen, können Unternehmen eine moderne Lösung sowohl in eigene CMDB-Installationen als auch
in die Software anderer Anbieter in-tegrieren. So entsteht ein CMS, das Informationen über
Ereignisse, Probleme, Lösungen, Veränderungen, Software-Releases, aber auch über Mitarbeiter,
Lieferanten, Standorte, Geschäftseinheiten, Kunden und Anwender vereint. Die Wartung dieses
Informations-Pools über das komplette IT-Inventar übernimmt das Configuration-Management. Da die
Prozesse des Configuration-Managements selten allumfassend sind und die einmal erfassten Daten über
die Zeit von der Realität abweichen können, sollten die Konfigurationen periodisch
nachsynchronisiert werden.
Unternehmen, die sich mit dem Gedanken tragen, ITILv3 in ihrer IT-Organisation schrittweise
umzusetzen, stellen sich, wie schon zu Zeiten der Version 2, die Frage: "Wo sollen wir anfangen?"
Hier gibt es keine allgemeingültige Antwort, doch für die meisten Unternehmen ist und bleibt der
Incident-Managementprozess der praktikabelste Ausgangspunkt für eine ITIL-Einführung. Hier ist die
Zahl der organisatorischen Schnittstellen besser überschaubar als beim zentralen
Configuration-Management, das alle Unternehmensbereiche berührt. Die meisten IT-Abteilungen sind
außerdem erfahren im Umgang mit ihrem Event-Management, sodass man ITIL von hier aus angehen
sollte.
Irgendeine Form des Incident-Managements existiert in praktisch jedem Unternehmen. Der
Service-Desk, der als Funktion im ITIL-basierten Service-Management Störungen aufnimmt und die
Aktivitäten koordiniert, kann in manchen Fällen im Rahmen vom Incident-Managements bereits
Störungen beheben. Wie bei einer "IT-Feuerwehr" gilt es, mangelhafte Dienste so schnell wie möglich
wiederherzustellen. Dies soll negative Auswirkungen auf die Geschäftsprozesse des betroffenen
Unternehmens minimieren. Viele Anwender haben die grundlegenden Funktionen und die zugehörigen
Automatisierungstechniken des Incident-Managements bereits implementiert. Oft genügt es, die
bestehenden Elemente neu zusammenzusetzen und einige Abläufe zu verfeinern, um so den Prozess zu
optimieren und besser in die gesamte IT-Servicelandschaft zu integrieren.
Automation kann insbesondere die Zeit verkürzen, die für die Suche nach den Ursachen eines
Vorfalls oder einer Störung anfällt. Mithilfe eines eingebauten Objektmodells und einer
Korrelationstechnik kalkulieren aktuelle Managementlösungen mögliche Problemursachen und deren
Symptome vorab. Das Objektmodell beschreibt die physischen und logischen Komponenten der
Infrastruktur, ihr Verhalten und ihre Topologie. Dabei analysiert eine solche Lösung die Topologie
der gesamten IT-Infrastruktur. Ändert sich diese, so erneuert sich die Korrelationsmatrix
automatisch. Probleme lassen sich so automatisch identifizieren, und die Auswirkungen
beispielsweise von Netzwerkproblemen auf die Geschäftsprozesse und Applikationen sichtbar machen.
Die IT-Abteilung profitiert dann von sofort umsetzbaren Informationen und kann die Probleme
frühzeitig lösen, sodass die Geschäftsprozesse oft ohne Unterbrechung weiterlaufen.
Anders als in ITILv2 tritt mit der neuen ITIL-Version das Thema ROI (Return on Investment)
stärker auf den Plan. Daher sollte jede Veränderung eines Prozesses einen Vorher-/Nachher-Vergleich
durchlaufen. Kennzahlen wie MTTR (Mean Time to Repair, durchschnittliche Reparaturzeit) oder die
durchschnittlichen Kosten eines Ereignisses sind hilfreich, um Verbesserungen objektiv messen zu
können. Unternehmen, die in ITIL-Projekten Kennzahlen nutzen, schaffen eine Argumentationsgrundlage
für Budgetverhandlungen und sichern so die Optimierung des ITIL-Prozesses. Überzeugend wirkt eine
Verknüpfung technischer Messwerte mit Kennzahlen aus dem Finanzwesen wie dem ROI: Entscheider, die
technische Diskussionen scheuen, können mit finanziellen Ergebnissen durchaus etwas anfangen. Echte
Kostensenkungen und potenzielle Erträge sind die besten Argumente für Folgeprojekte.
Basis jeder ITSM-Initiative in einer komplexen, heterogenen IT-Umgebung ist die
Prozessautomation. Bevor jedoch Software eingekauft wird, gilt es, sich mit der eigenen Umgebung
auseinanderzusetzen. Diese Analyse liefert die Rahmenbedingungen für eine durchdachte Architektur,
deren Design und Implementierung. Eine flexible Strategie ist der Aufbau einer modularen
Automationsarchitektur. Wie diese für das Incident-Management aussehen sollte, zeigt das Bild auf
Seite 34. Meist ist eine Vielzahl von Management-Tools zu konsolidieren. Die Werkzeuge im unteren
Bereich verwalten immer nur eine spezifische Domain (Netzwerk oder Applikationen) oder einen
Datensilo (Speicher, Datenbanken, Mainframe oder Server). Diese Insellösungen koppelt man an ein
zentrales Konsolidierungssystem, das alle Ereignisse sammelt. Idealerweise setzt diese Software die
Daten dann über die Ursprungsdomänen hinweg in Beziehung. Auf diesen "Konsolidator" setzen Anzeige-
und Analysesysteme auf, die qualifizierte Ereignisinformationen akzeptieren, übersichtlich
aufbereiten und den Mitarbeitern des Service-Desks so die Arbeit erleichtern.
Das Problem-Management ist eng an das Incident-Management gekoppelt. Handelt es sich um ein
bekanntes Problem, lässt sich die Störung durch Beseitigung des ursächlichen Fehlers relativ
schnell beheben und zwischenzeitlich der Service per Workaround wiederherstellen. Je genauer dabei
die Ereignisdaten sind, desto besser wird auch das Problem-Management funktionieren. In vielen
Fällen sind die Ereigniseinträge durch falsche Meldungen unbrauchbar, oder unechte Events
verhindern die Ableitung wiederkehrender Problemmuster. Ein Incident-Management, das diese
Irrläufer vorfiltert und nur echte Incidents speichert, ist eine Voraussetzung für fundierte
Entscheidungen des Problem-Managements. Die erste Frage beim Ausfall eines Dienstes lautet meist: "
Was hat sich verändert?" Eine Veränderung kann immer auch die Ursache für ein weiteres Problem mit
einem bestimmten Service sein. Studien zeigen, dass typische Global-2000-Unternehmen rund 1000
einzelne Applikationen im Einsatz haben und täglich bis zu 30.000 Veränderungen an den Anwendungen
und der Applikationsinfrastruktur durchführen. Auf solche Changes sind dabei 70 Prozent der
Ausfälle zurückzuführen. Diese Zahl macht deutlich, dass Automation unumgänglich ist.
Software, die in Echtzeit genaue Details über CIs sammelt, identifiziert auch Veränderungen der
IT-Umgebung und generiert aus diesen Daten entsprechende Ereignisse. Im Umkehrschluss kann ein
Unternehmen nur auf der Basis fundierter, akkurater Ereignis- und Konfigurationsdaten
Entscheidungen über die Veränderung einer Umgebung treffen. Automatisierte Tests über die
Auswirkungen bestimmter Veränderungen vor deren Umsetzung sind deshalb zwingend notwendig. In einem
umfassenden Modell aller CIs und deren Beziehung zueinander sind die Auswirkungen jeglicher
Veränderung auf den Abstraktionsebenen der Konfigurationselemente, Applikationen, Business-Services
und Anwender simulierbar. So lassen sich kostspielige Überraschungen vermeiden.
Bei Automationsvorhaben gerät das Thema Integration oft ins Hintertreffen. Dabei ist diese für
die Prozessautomation immer ein Kernpunkt, denn selbst alle Standards zusammen werden nie den
Anforderungen der Integrationsexperten gerecht. Auch wenn sich viele Hersteller permanent um neue
Standards bemühen, ist diese Schere so etwas wie das ungeschriebene Gesetz des Service-Managements.
Wo Standards noch fehlen, sind Adapter gefragt. Automationsexperten sollten also
Programmierkenntnisse in Java, XML, Dotnet etc. mitbringen, um eigene Adapter zu konzipieren.
Obwohl es bereits eine Reihe leistungsfähiger und intelligenter Managementlösungen für die
ITIL-Umsetzung gibt, steckt der Markt für die Automation von IT-Prozessen noch in einem relativ
frühen Entwicklungsstadium.
Lesen Sie mehr zum Thema
