Zen und die Kunst, IT Konfigurationsmanagement .indd

Zen und die Kunst, IT Konfigurationsmanagement .indd
WENDIA
ITSM
EXPERT TALK
Zen und die Kunst, IT
Konfigurationsmanagement umzusetzen:
Praktische Anleitung für eine
ingenieurmäßige Vorgehensweise
ACHIM GRINDLER
Praktische Anleitung für
eine ingenieurmäßige
Vorgehensweise
Zen und die Kunst, IT Konfigurationsmanagement umzusetzen
Configuration und Service Asset Management gehört
im IT Service Management nach ITIL zu den Kern- und
Komplexität eines Configuration
Management Systems
Königsdisziplinen. Die Komplexität des Themas mit seinen
umfangreichen Ausbau- und Erweiterungsmöglichkeiten
Service Asset and Configuration Management (SACM) hat
stellt IT-Organisationen häufig vor große Herausforderungen.
das Ziel gesicherte und aktuelle Informationen über die zur
Wie packt man den Aufbau der CMDB und die Umsetzung
Leistungserstellung verwendeten Konfigurationselemente zur
von Prozessen am Besten an? Wie können IT Manager beim
Verfügung zu stellen [1]. Eine Configuration Management
Thema Configuration Management von den klassischen
Database
Ingenieursdisziplinen profitieren? Und was hat die Kunst ein
Manangement System (CMS) ist für diese Aufgabe essentiell.
Motorrad zu warten mit IT Service Management zu tun?
ITIL
V3
(CMDB)
oder
entwickelt
für
neuerdings
das
ein
CMS
Configuration
eine
komplexe
Softwarearchitektur, aufgeteilt in vier Ebenen (Daten- und
Achim Grindler, stv. Abteilungsleiter am Steinbuch Centre
Informationsquellen und Werkzeuge, Informationsintegrations
for Computing des Karlsruher Instituts für Technologie
schicht, Wissensverarbeitungsschicht und Präsentationsschicht).
(KIT), zeigt im Wendia ITSM Expert Talk Paper eine neue
Im Herzen dieser Architektur steht die „integrierte CMDB“ mit
Perspektive auf, die bei der Einführung von Configuration
dem darin abgebildeten Service Modell [2].
und Service Asset Management wertvolle Unterstützung
Diese Architekturgrafik zeigt, wie umfangreich das Thema SACM
bietet. Dabei wird deutlich, wie ein ingenieursmässiges
gestaltet und ausgebaut werden kann, um alle ITIL-Verfahren
Vorgehen den Umgang mit den großen Herausforderungen
zu adressieren. Je nach Anforderung der IT-Organisationen
des Themas wesentlich vereinfacht.
werden zur Umsetzung Projekte von zwei bis drei Jahren
Laufzeit aufgesetzt – Ausgang ungewiss, da meist mitten in
der Umsetzungsphase das Datenmodell oder Werkzeuge und
Schnittstellen neu bewertet und diskutiert werden.
Herausforderungen bei der Umsetzung
Die großen Herausforderungen bei der Umsetzung von
Konfigurationsmanagement im IT Service Management werden
deutlich, wenn man versucht folgende Fragen zu beantworten:
• und wie wird einen Configuration Management Prozess
gestaltet, der im Zusammenspiel mit den anderen IT-Verfahren
auch gelebt werden kann – also effektiv und effizient ist.
• Welche IT-Prozesse sollen durch das Configuration und Asset
Management unterstützt werden?
• Welche Daten (Stamm- und Detaildaten) müssen von wem in
welcher Form gespeichert und kontrolliert werden, um diese ITProzesse zu unterstützen?
Dafür gibt es leider kein Patentrezept. Im Gegenteil, mit komplexer
werdenden IT-Landschaften (verteilte, heterogene Systeme und
Anwendungen, virtualisierte Hardware, Software, Speicher und
Netzwerke) wird auch das klassische Konfigurationsmanagement
aufwändiger und auch anfälliger dafür sein Ziel (s. o.) nicht zu
erreichen.
Von der „Produktdokumentation“ her denken
Wie kann hier ein ingenieurmäßiges Vorgehen weiterhelfen? Bei
der Entwicklung, Bau, Test, Vertrieb und beim Kundendienst
eines Produktes fließen in aller Regel wichtige Dokumen¬tationen
in einem Service-Handbuch (Service-Manual) zusammen (das ist
die Sicht des Dienstleisters auf die Konfiguration). Der Käufer
des Produkts bekommt eine ausführliche und verständliche
Bedienungsanleitung zur Hand (entspricht der Kundensicht auf
die Konfiguration).
Ich wage die Behauptung: „Gute“ Konfigurationsbeschreibungen
unterstützten bestmöglich die Produkt- und Service-Prozesse.
Sie sind essentiell für das Erbringen der Leistungen im gesamten
Produkt-/Service-Life-Cycle.“
Mit anderen Worten: „Schlechte“, d.h. unvollständige und nicht
aktuelle Konfigurationsbeschreibungen sind häufig die Ursache
für eine verminderte Servicequalität innerhalb der verschiedenen
Produkt-/Service-Life-Cycle Phasen.
Ein praktisches Beispiel: Das Service-Handbuch zum HiFi-Verstärker
Vor mir liegt das Service-Handbuch für einen HiFi-Verstärker.
Die Informationen sind unterteilt in die Abschnitte:
Funktionsbeschreibung, Demontage und Austausch, Elektrischer
Abgleich, Verpacken, Schaltungs- und Print-Diagramme,
Explosionszeichnungen, Teilelisten / Hersteller, Technische
Abschnitt
Daten, etc.
Jeder Abschnitt dieser Konfigurationsbeschreibung ermöglicht
die Abwicklung eines internen Service-Prozesses:
Service-Prozess
Technische Beschreibung,
Funktionsdiagramme
Wissen über Gesamtprodukt / Service
und Zusammenhänge der Komponenten
Demontage und Austausch
Reparatur / Änderung
Elektrischer Abgleich
Technische Daten
Geräte Wartung
Endabnahme
Verpacken
sicherer Versand und Inbetriebnahme
Schaltungs- und Print-Diagramme
Fehlersuche, Reparatur
Explosionszeichnungen
Produktion, Reparatur
Teileliste / Hersteller
Produktion, Beschaffung, Reparatur
Der Mehrwert dieser Konfigurationsbeschreibung kann im Service-/Prozesskontext so formuliert werden:
Diese Konfigurationsbeschreibung ermöglicht es, u.a. dass:
• Fehler in akzeptabler Zeit gefunden und behoben,
• Wartungsarbeiten korrekt und nachhaltig durchgeführt,
• und die richtigen Ersatzteile bei den Herstellern bestellt
werden können.
Abb. 1: Auszug aus dem Service Manual eines HiFi-Verstärkers
Einfache Zusammenstellung von Konfigurationsbeschreibungen für die IT
Wenn eine IT-Organisation die Dokumente (Papier, Excel-Listen,
Datenbanken, Web, Wiki, ...), die für die Leistungserstellung
benötigt werden, sichtet, aktualisiert, fehlende ergänzt und dann
in Beziehung zueinander stellt, entsteht daraus auch ohne neue,
komplexe Tools eine „gute“ Konfigurationsbeschreibung von ITServiceleistungen.
Die Beziehungen und Verweise sollten später in einem
recherchierbaren Tool auf Basis einer Datenbank gehalten werden.
Zu jedem Objekt in der Datenbank sollten Stammdaten definiert
werden, ohne die die gelebten oder zu noch etablierenden Prozesse
nicht effizient funktionieren. Eine Präsentationsschicht kann z.B.
auch in einem schon vorhandenen Content Management oder
Wiki System abgebildet werden.
Prozesse, Dokumentation, Service-Modell
Will ein IT-Servicebetreiber sein Produkt (seinen IT-Service)
nach diesem Beispiel beschreiben, ist es zunächst wichtig
zu beantworten, mit welcher Beschreibung welcher Prozess
unterstützt wird oder werden soll. Dies führt dazu, dass der von
ITIL V3 propagierte Service Life Cycle an Bedeutung gewinnt
und zu jeder Life Cycle Phase dedizierte Dokumente und Daten
erstellt bzw. in Beziehung gesetzt werden.
• Wie wird ein neuer IT-Service in der Organisation eingeführt?
• Wie wird ein IT-Service gewartet und betrieben?
• aus welchen Komponenten und Services besteht der IT-Service
und wie stehen diese in Beziehung untereinander?
• Wie werden Komponenten für einen IT-Service bestellt und
konfiguriert?
• Wie wird der IT-Service vertrieben?
• Wie werden Anwender bei der Nutzung des IT-Services
unterstützt?
Dies sind nur einige Fragen, die, wenn Sie beantwortet werden,
zu einem generischen Betriebs- und Servicekonzept führen, das
dann in den Betriebs- und Service-Handbüchern konkretisiert
werden kann.
Aufbau einer CMDB
Und wie kann nun eine Integrierte CMDB aufgebaut werden?
Alle zur Leistungserstellung genutzten Komponenten werden
mit ihren Stammdaten über einen Configuration Management
Prozess in die Datenbank gebracht (korrespondierend mit
der Teileliste des Gerätes) und danach mit dem aus den
verschiedenen Dokumenten gebundenen Service-Handbuch in
Beziehung gesetzt. Das Service-Handbuch selbst wird wiederum
mit den Service-Anleitungen und den Service-Spezifika (Service
Level) in Beziehung gesetzt und die Service Spezifika (ggf.
unterschiedlichster Ausprägung) werden schließlich mit den
Kunden in Beziehung gesetzt. Die Instanzen eines angeforderten
IT-Service werden mit den Anwendern, die Betriebs-Handbücher
mit den produktiven Komponenten und Systemen verknüpft.
Blaupausen für Servicemodelle, die diesen Anforderungen
genügen liegen vor und können an die jeweiligen Bedürfnisse
angepasst werden (z.B. [3]). Eine Herausforderung, gerade
auch für die Toolhersteller, ist die Implementierung von Regeln
(Policies) zur Pflege und zum Aufbau einer strukturierten CMDB
[4]. Ein praktikables Service-Datenmodell ist auch in der Service
Management Toolsuite POB G6 von Wendia umgesetzt.
CMDB als Wissensdatenbank – Service Knowledge
Beim Bau eines HiFi-Gerätes ist z.B. die Teileliste essentiell. Beim
Aufbau eines IT-Services, die zum Betrieb notwendigen Server
und Systeme. Wie müssen die Teile auf der Platine bestückt
werden? Korrespondiert mit der Frage: Welche Software wird wie
auf welchem System installiert und konfiguriert? Wie wird das
Gerät elektrisch abgeglichen? Bedeutet im IT-Kontext: Wie wird
das Gesamtsystem in Betrieb genommen und überprüft, ob die
Lösung den Kundenanforderungen entspricht?
Hat man am Ende des Projekts „gute“ Konfigurationsbeschreibungen im vorgeschlagenen Sinn zusammengestellt,
entsteht eine Service Knowledge Datenbank durch geschicktes
„Zusammenklicken“ der verwendeten Elemente (Software,
Hardware, Zuständigkeiten, Services, Servicebausteine) und
verlinken mit dem jeweiligen Service-Handbuch.
Wissen veraltet im Sekundentakt
Eine Installation (oder eine Service-Konfiguration) kann nur
bewirtschaftet werden, wenn man genau weiß, aus welchen
Einzelteilen sie besteht. Besonders wichtig ist dieses Wissen,
wenn einige dieser Einzelteile für das korrekte Funktionieren
des Systems und damit für den täglichen Geschäftsablauf
lebenswichtig sind [1]“. Das gilt für ein Motorrad oder ein HiFiGerät genauso wie für einen IT-Service. Wenn wir komplexe
Systeme in kleinere weniger komplizierte Teile und Funktionen
zerlegen erschließt sich das notwendige Wissen über das
Gesamtsystem. Abb. 2 zeigt eine Struktur, die auf technische
Systeme anwendbar ist [6].
Abb. 2: Strukturierung eines Systems in Funktionen und Teile
Für viele IT-Prozesse ist es wichtig die Funktion(en) eines Services
aus Anwendersicht zu kennen und im Fehler- oder Änderungsfall
E-Mail
genau benennen zu können. Nachfolgende Tabelle macht dies
deutlich.
HiFi-Verstärker
IMAP-Zugang
Rechter Kanal / Linker Kanal
Web-Zugang
Leistungsanzeige rechts, links
E-Mail senden
Leistungsbegrenzer
E-Mail empfangen
Klangregelung
Mobile Synchronisation
Lautstärkeregelung
Verschlüsselung / Signatur
Balanceregelung
SPAM-Filter
zusätzlicher Lautsprecherausgang
Nutzen und Vorteil des durch die CMDB generierten Wissens
Wenn in der CMDB die Services zusätzlich mit Funktionsblöcken
abgebildet werden und diesen Funktionsblöcken dann dafür
benötigte Teile (Sub-Services, Komponenten) zugeordnet werden
(wie in dem Blockdiagramm im Service-Manual des HiFi-Gerätes),
erreicht man eine detaillierte Anwendersicht. Wenn Funktionen
Wichtigkeiten oder Service-Level zugeordnet bekommen,
kann man Incidents besser priorisieren, Verfügbarkeiten besser
auswerten und Auswirkungen bei Änderungen besser abschätzen.
Wissen, das aus den zusammengestellten Daten und
Informationen resultiert, nutzt allen Beteiligten: Anwender
greifen auf die richtige Anleitung zu, Administratoren nutzen die
offiziellen Wartungsfenster, Entwickler die aktuellen SoftwareBibliotheken, Change Manager erstellen Impact-Analysen und
kontaktieren Betreiber, Serviceverantwortliche definieren ServiceKlassen und Kundenbeziehungen, das Service Desk recherchiert
zu den häufig gestellten Fragen...
Prozesse aus den Ingenieursdisziplinen und ihr gewinnbringender
Einsatz im ITSM
Fazit: „Gute“ Konfigurationsbeschreibungen sind auch
diejenigen, aus denen man etwas „genau wissen“ kann. Deshalb
sollte unbedingt ein Änderungsmanagement betrieben werden.
Sehr schnell veränderliche Daten an einer Vielzahl von Objekten,
sollten automatisiert eingesammelt werden. Während ServiceBeziehungen nur bedingt automatisiert gepflegt werden können.
Hier ist oftmals ein redaktioneller Prozess sinnvoll und
notwendig. In der industriellen Entwicklung und Fertigung steht
am Ende einer Phase (Entwicklung, Test, Prototyp, Produktreife,
Vermarktung) ein Qualitätsmanagementprozess und sammelt
über Checklisten gesteuert, für die Abnahme wichtige Dokumente
ein. Vielleicht ist es ein gewinnbringender Ansatz, auch für das
IT Service Management von den Ingenieursdisziplinen und der
„Kunst der Motorradwartung“ [5] zu lernen?
&
BUCHTIPP
Zen und die Kunst, ein Motorrad zu warten
1974 hat Robert M. Pirsig ein wunderbares „Service-Management Buch geschrieben“.
Ich empfehle es jedem IT-Manager! Nachstehend ein kleiner Auszug:
• Erfolg entsteht, wenn man Sinn für Qualität hat [S. 294]
• Verständnis / Wissen über das Gesamtsystem wichtig [S. 102]
• eine Strukturierung dieses Systems ist enorm hilfreich [S. 100]
• für erfolgreiche Wartungen benötigt man Mut und Begeisterung [S. 313, 314]
• durch welche Arten von Entmutigungen Wartungsaktionen scheitern [S. 316 - 321]
• Der Wert guter Werkzeuge [S. 335]
In meinem Musikregal steht heute noch der HiFi-Verstärker, dessen Service-Manual
mich inspirierte einen anderen Ansatz für die IT-Dokumentation zu denken. Das
Gerät wurde 1974 gebaut und betreibt immer noch die Lautsprecher in unserem
Wohnzimmer. Ob sich noch eine Werkstatt finden lässt, die das Gerät bei einem
Defekt reparieren kann?
Nicht nötig! Ich habe ja das Service-Manual.
Am Steinbuch Center for Computing wurde eine entsprechende CMDB-Lösung
bereits entwickelt und eingeführt. Alle wesentlichen im vorliegenden Whitepaper
geschilderte Ansätze sind umgesetzt. Für eine umfangreichere Prozessintegration
und –automation wäre ein aufwändiges Redesign und Fortentwicklungen oder
eine kundenspezifisch angepasste Standard-Lösung erforderlich.
ÜBER
DEN AUTOR
Achim Grindler ist stellvertretender Abteilungsleiter der Abteilung
IT-Security und Service-Management (ISM) am Steinbuch Centre
for Computing des KIT. Dort betreut und koordiniert er den
Bereich IT-Servicemanagement. Die Schwerpunkte seines Teams
sind
Kundenorientierung,
Verbesserung
und
Standardisierung
bestehender Arbeitsabläufe sowie die konsequente Unterstützung der
SCC-Abteilungen bei den geplanten Veränderungsprozessen und die
Konzeption, Bereitstellung und Schulung von ITSM-Werkzeugen.
Er
diplomierte
an
der
Hochschule
Karlsruhe
im
Fach
Nachrichtentechnik und ist seit 1994 am KIT angestellt. Bis 2001 war
er im In- und Ausland als Elektronik- und Softwareentwickler sowie
als Inbetriebnahme-Ingenieur an Großforschungsprojekten beteiligt.
Von 2002 bis 2007 leitete er für die zentralen Bürokommunikationsund
Desktopdienste
des
Großforschungsbereichs,
das
Team
"Systemsoftware und -hardware".
Quellenangaben:
[1] Walter Vogt, fIT for benefit – IT Services kundenorientiert planen und steuern, 2002, S. 56
[2] OGC, ITIL - Service Transition, 2007, S. 68
[3]
Simone Rudolph et al, Struktur von IT-Servicekatalogen: Ein praxisorientierter
Gestaltungsvorschlag für die Dokumentation des IT-Leistungsangebots, MKWI‘08
[4] Lothar Buhl, FCS Consulting, Abbildung von Services in der CMDB, Vortrag auf der PUG 2014
[5]
Robert M. Pirsig, Zen und die Kunst ein Motorrad zu warten, 1974, S. 100 - 102
MAKING SERVICE
MANAGEMENT HAPPEN
WENDIA GMBH DEUTSCHLAND
Garmischerstraße 4
80339 München
Phone +49 89 54052 214
Email: [email protected]
Web: www.wendia.de
WENDIA GMBH DEUTSCHLAND
Königstraße 26
70173 Stuttgart
Phone +49 711 18567 412
Email: [email protected]
Web: www.wendia.de
WENDIA AG SCHWEIZ
Baarerstraße 94
6300 Zug
Phone +41 41 560 77 04
Email: [email protected]
Web: www.wendia.ch
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement