Optimiertes IT-Management (3)

Michael Santifaller


Service Management Architekturmodell (2)

Service Management Schicht

In dieser Schicht finden sich die operativen und taktischen ITSM-Kernprozesse, so wie sie vorher in den Service Management Referenzmodellen beschrieben wurden und hinreichend bekannt sind.

Systems Management Schicht

Während ITSM mit ITIL® konzeptionell und terminologisch aufgearbeitet wurde und damit nun eine Grundlage für Diskussion und Kommunikation besteht, hat sich für das Systems Management, also den Bereich der operativen Funktionen, noch kein Standard durchgesetzt.

Am nächsten kommt dieser Anforderung der Standard ISO/IEC 7498-4 (OSI Management Framework) der die Begriffe Fault, Accounting, Configuration, Performance und Security Management einführt. Allerdings grenzt sich dieser aus dem Jahr 1989 stammende Standard nicht klar genug von den ITIL®-Begriffen ab und überlappt sich anderseits teilweise beim Anwendungsbereich, so dass er als Grundlage für dieses Modell nicht Frage kam.

Da aber eine Terminologie zur Beschreibung von operativen Aufgaben dringend notwendig war, abstrahierte santix die Aktivitäten im Systems Management und identifizierte folgende Funktionskategorien:

  • Monitoring beinhalten die Funktionen zur auto-matischen Überwachung der Elemente in der IT-Infrastruktur und zur Alarmierung bei Zuständen ausserhalb eines definierten Normbereichs, z.B. Netzwerk-Management- und Server-Überwachungs-Systeme
  • Measuring-Funktionen werden eingesetzt um automatisch Messwerte zu ermitteln, u.a. für Diagnose, Trendanalysen und Verbrauchsberechnungen, z.B. Bandbreiten- und Storage-Messung
  • Operation bezeichnet alle Werkzeuge die zur manuellen Administration von Infrastrukturelementen eingesetzt werden, z.B. Remote Control und Scripting Tools, aber auch SAN Management-Werkzeuge usw.
  • Automation enthält alle Funktionen mit denen administrative Vorgänge automatisiert werden können, z.B. Job Scheduling, Run Book Automation usw.
  • Deployment umfasst alle Funktionen zur automatischen Veränderung der Konfiguration auf Infrastrukturelementen, z.B. Software-Installationen, Registrierungseinträge usw.
  • Discovery sind alle automatischen Funktionen die zur Ermittlung der aktuellen Konfiguration auf den Infrastrukturelementen eingesetzt werden, z.B. Software-Inventur, Hardware-Konfiguration, Netzwerkverbindungen usw.
  • Continuity-Funktionen erledigen Aufgaben zur Notfall-Vorsorge, z.B. Backup-Programme, High Availability Software usw.
  • Security schließt alle Funktionen ein, die für die Sicherheit auf den Infrastrukturelementen eingesetzt werden, z.B. Anti-Viren-Scanner, Firewalls usw.

Da diese Funktionen technologisch und konzeptionell eine Affinität miteinander haben, wurden sie in jeweils vier Paare gebündelt: Monitoring & Measuring, Deployment & Discovery, Operation & Automation sowie Continuity & Security.

Integration Layer

Der Integration Layer stellt eine Schicht dar, in der Daten aus den beiden umgebenden Schichten Service und Systems Management mit unterschiedlicher Dauer gehalten werden. Er dient so auch zum Austausch von Daten die zwischen Schichten übertragen werden müssen. Die Elemente in dieser Schicht sind altbekannt:

  • Die Configuration Management Database (CMDB) ist die zentrale Datenbasis der Service Management Prozesse, in ihr werden Informationen aus praktisch allen ITSM-Prozessen abgelegt. Gleichzeitig werden hier auch die Konfigurationsdaten für Systems Management Werkzeuge hinterlegt, z.B. das gescannte In-ventar aus Discovery-Funktionen oder die Jobdefinition aus dem Job Scheduling. Zu beachten ist, dass die CMDB ein logisches Konzept darstellt und keine einzelne physikalische Datenbank sein muss.
  • Beim Event und Impact Management handelt es sich um die Funktionen zur Verarbeitung von Events. Das Event Management filtert aus dem Strom von Events, der normalerweise vom Monitoring geliefert wird, die relevanten Ereignisse aus. Das Impact Management wertet Informationen aus der CMDB aus und reichert diese Events um andere Informationen aus der CMDB an, z.B. über Abhängigkeiten von IT Services von gestörten Infrastrukturelementen und die Priorität eines Events (in Abhängigkeit von der Bedeutung eines Services für das Business) für die Eröffnung eines Incidents. Event und Impact Management sind daher keine Datenhaltungsfunktionen im eigentlichen Sinne, sondern eher Real-Time-Datenverarbeitungsfunktionen. ITIL® V3 definiert einen Event Management Pro-zess, der sowohl die hier geschilderten Funktionen als auch das Monitoring beinhaltet, das santix Architekturmodell trennt diese Funktionen jedoch in zwei Schichten, um die technischen Schnittstellen zwischen den Funktionen im Intregration Layer und denen in der Systems Management Schicht sichtbar zu machen.
  • Als Management Data Warehouse werden alle Datenhaltungs- und Verarbeitungsfunktionen bezeichnet, die der Langzeitspeicherung von Messdaten und deren Auswertung im Berichtswesen dienen. Hier werden unter anderem Availability, Accounting oder Capacity Daten aus dem Measuring gehalten. Aber auch die Analytics-Produkte, die sich neuerdings großer Beliebtheit erfreuen zählen in diesen Bereich. In ITIL® V3 sind diese Daten Teil des Service Knowledge Management Systems.
  • Das Directory ist sicher ein überraschender Kandidat in dieser Schicht, aber da es die Konfigurationsdatenbank für alle benutzer- und zugriffsrelevanten Funktionen ist, hat es hier seinen Platz. Viele wichtige Managementfunktionen sind stark benutzerbezogen.

Die Verweildauer der Daten in dieser Integrationschicht reicht von einigen Sekundenbruchteilen für Events im Event und Impact Management bis hin zu Jahren für Daten im Management Data Warehouse. Der schreibende und lesende Zugriff auf die Funktionen dieser Schicht erfolgt über technische Schnittstellen, Beispiele sind proprietäre und genormte Nachrichtenprotokolle wie z.B. SNMP, Datenformate wie XML, Abfragesprachen wie SQL sowie APIs und CLIs. Diese Schnittstellen machen es überhaupt möglich, dass der Interface Layer zur Schaltstelle der Modularität in einer Management-Toolarchitektur wird, ansonsten wäre es nur möglich völlig homogene Architekturen aus dem Portfolio ein und desselben Softwareherstellers zu implementieren.

Keine Kommentare
Kommentar hinzufügen

* - Pflichtfeld

*




*
© 2012-2016   santix AG    Schwanthalerstraße 10     80336 München     info(@)santix.de