Ver-ITIL-t


20. März 2009

Prozess: Service Asset & Configuration Management

Zielstellung des Asset & Configuration Management

Ziel des Configuration & Asset Managements ist die allumfängliche Information anderer Prozesse und des Managements mit Informationen zur Infrastruktur. Die Bestrebung nach Real-Time-Daten und die Komplexität der Infrastrukturen machen den Einsatz von Tools unumgänglich. Das zentrale Repository ist das CMS, in dem CIs abgelegt werden.


Begrifflichkeiten im Asset & Configuration Management

Das CMS (Configuration Management System) ist die zentrale Ablage aller CIs.

Unter CIs (Configuration Items) versteht man alle Komponenten, die während der Bereitstellung von Services Benutzung finden. Neben dem Bereich Hardware gehören beispielsweise auch Software, Gebäude, Netzwerkkomponenten und virtuelle Umgebungen dazu. Die Auflösung eines Service in seine Bestandteile (CIs) ist eine der Aufgaben, die in Echtzeit möglich sein sollte.

Unter dem Begriff CMDB (Configuration Management Database) versteht ITILv3 eine physikalische Ablage. Das CMS kann unter bestimmten Anforderungen auch mehrere CMDBs enthalten.

Neben den CMDBs sind im CMS noch weitere Repositories enthalten, die beispielsweise funktions- oder unternehmensbezogen befüllt werden. Auch die DML (Definitive Media Library) gehört zum CMS und damit in die Zuständigkeit des Asset & Configuration Managements.

Grundsätze des Asset & Configuration Management

Ein wesentlicher Grundsatz ist die Automatisierung. Kaum eine Infrastrukturlandschaft kann heute noch händisch dokumentiert werden. Die Ursachen dafür sind vielschichtig – an der Stelle sei nur der Trend zur Virtualisierung genannt, der zu einer vorher nicht gekannten Dynamik geführt hat.

Eine wesentliche Herausforderung für die Modellierung und Befüllung des CMS ist die Abstraktionstiefe. Je mehr Details abgebildet werden müssen, desto höher wird der Aufwand für die Pflege – je geringer der Datenbestand, desto eingeschränkter ist die Nutzung des CMS möglich. Es gilt, einen praktikablen Kompromiss zu finden, was sich in der Praxis vor allem beim Start eines solchen Vorhabens als schwierig herausstellen kann.

Die Bildung eines hierarchichen Bildes der Infrastruktur wird ausdrücklich empfohlen. Für das Reporting anderer Prozesse (zum Beispiel Uptimes von Services, …) ist das Etablieren von Parent-Child-Beziehungen obligatorisch. Die “Trivialform” sieht folgende Hierarchie vor:

Business Service -> Technical Service -> Komponenten CIs

Für die Pflege des Status könnte folgende Systematik zum Einsatz kommen:

planned -> ordered ->tested -> implemented -> working ->archieved

Auch für die Stati kann nur eine Hilfestellung gegeben werden – in Abhängigkeit der Anforderungen zur Information können mitunter noch mehr oder auch deutlich weniger Stati notwendig sein.

Weitere interessante Inhalte

Category: Service Asset and Configuration Management – Stefan – 13:30

Keine Kommentare »

Noch keine Kommentare

RSS-Feed für Kommentare zu diesem Beitrag. | TrackBack URI

Hinterlasse einen Kommentar

XHTML ( You can use these tags): <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> .

!-- Piwik -->