11
82 HMD 264 Frank Steinbeck Stabiler IT-Betrieb durch Geschäftsprozess- überwachung Der IT-Betrieb muss sich in der heutigen Zeit großen Veränderungen unterwerfen, um von der Unternehmensführung nicht nur als reiner Kos- tenfaktor, sondern primär als ein wesentlicher Bestandteil des Unternehmenserfolgs wahrge- nommen werden zu können. Die Komplexität und Heterogenität der IT-Systemlandschaften werden in Zukunft aufgrund zunehmender Kun- denanforderungen weiterhin steigen. Es kann hier von einem Wachstum auf 50.000-100.000 IT-Komponenten pro internationalem Konzern (Größenordnung 10.000 Mitarbeiter) in den nächsten Jahren ausgegangen werden. Die IT-Or- ganisation wird in Zukunft keine reale Möglich- keit mehr haben, Auswirkungen von Störungen auf andere IT-Komponenten und auf die Ge- schäftsprozesse der Kunden zu erkennen. Es wird zu Kommunikationsschwierigkeiten innerhalb des IT-Betriebs, zu den Mitarbeitern des Konzerns und zu den Kunden kommen. Die Entstörungs- dauer und entsprechend die Nichtverfügbarkeit der IT-Services werden ansteigen. Die Kundenun- zufriedenheit wird sich drastisch erhöhen. Das Unternehmen verliert Geld und Kunden! Inhaltsübersicht 1 Geschäftsprozessüberwachung – allgemein 2 Geschäftsprozessüberwachung – Voraussetzungen 3 Geschäftsprozessüberwachung – Referenzmodell 3.1 Referenzmodell zur Einführung einer Geschäftsprozessüberwachung 3.2 Schichtenmodell 3.3 Servicebaum der IT-Organisation 3.4 Vorgehensmodell zur Identifizierung der IT-Serviceelemente 4 Geschäftsprozessüberwachung – Implementierung 1 Geschäftsprozessüberwachung – allgemein Der IT-Betrieb unterliegt heutzutage enormen Anforderungen, die es auf Basis einer Ge- schäftsprozessüberwachung zu lösen gilt: Große Datenmengen sind zu bewältigen, zu identifizieren, zu konsolidieren und zu korre- lieren. Die Alarmierung bei IT-Störungen ist intelli- gent zu steuern, die Alarme sind hoch zu ver- dichten, zentral zu verarbeiten und zu stan- dardisieren. Die IT-Umgebung und deren Status müssen dokumentiert sein, um die vom Auftragge- ber geforderte Nachweispflicht zu erbrin- gen, die unternehmensinternen Normen/ Vorschriften einzuhalten und die Transparenz und dadurch den Wissenstransfer sicherzu- stellen. Einheitliche Sicht und vernetzte Informatio- nen über Störungsursachen sind erforderlich. Um diesen hohen Anforderungen gerecht zu werden, bedarf es einer Geschäftsprozessüber- wachung und eines standardisierten Referenz- modells zur Einführung der Überwachung. Nur so kann der IT-Betrieb die notwendige Sorgfalts- pflicht als interner IT-Dienstleister sicherstellen und damit eine gleichbleibende Kundenzufrie- denheit erreichen. Eine zentrale Bedeutung innerhalb der Ge- schäftsprozessüberwachung kommt der kor- rekten Alarmierung im Störfall zu. Die Alarmie- rung an die richtige Abteilung oder Person und der korrekte Detaillierungsgrad der Störungs- information sind hierbei ausschlaggebend. Da- durch wird der IT-Organisation die Möglichkeit gegeben, die Entstörungsdauer bzw. die Nicht-

Stabiler IT-Betrieb durch Geschäftsprozess-überwachung

Embed Size (px)

Citation preview

82 HMD 264

Frank Steinbeck

Stabiler IT-Betrieb durch Geschäftsprozess-überwachung

Der IT-Betrieb muss sich in der heutigen Zeitgroßen Veränderungen unterwerfen, um von derUnternehmensführung nicht nur als reiner Kos-tenfaktor, sondern primär als ein wesentlicherBestandteil des Unternehmenserfolgs wahrge-nommen werden zu können. Die Komplexitätund Heterogenität der IT-Systemlandschaftenwerden in Zukunft aufgrund zunehmender Kun-denanforderungen weiterhin steigen. Es kannhier von einem Wachstum auf 50.000-100.000IT-Komponenten pro internationalem Konzern(Größenordnung 10.000 Mitarbeiter) in dennächsten Jahren ausgegangen werden. Die IT-Or-ganisation wird in Zukunft keine reale Möglich-keit mehr haben, Auswirkungen von Störungenauf andere IT-Komponenten und auf die Ge-schäftsprozesse der Kunden zu erkennen. Es wirdzu Kommunikationsschwierigkeiten innerhalbdes IT-Betriebs, zu den Mitarbeitern des Konzernsund zu den Kunden kommen. Die Entstörungs-dauer und entsprechend die Nichtverfügbarkeitder IT-Services werden ansteigen. Die Kundenun-zufriedenheit wird sich drastisch erhöhen. DasUnternehmen verliert Geld und Kunden!

Inhaltsübersicht1 Geschäftsprozessüberwachung – allgemein2 Geschäftsprozessüberwachung –

Voraussetzungen3 Geschäftsprozessüberwachung –

Referenzmodell3.1 Referenzmodell zur Einführung einer

Geschäftsprozessüberwachung3.2 Schichtenmodell3.3 Servicebaum der IT-Organisation3.4 Vorgehensmodell zur Identifizierung der

IT-Serviceelemente4 Geschäftsprozessüberwachung –

Implementierung

1 Geschäftsprozessüberwachung – allgemein

Der IT-Betrieb unterliegt heutzutage enormenAnforderungen, die es auf Basis einer Ge-schäftsprozessüberwachung zu lösen gilt:

! Große Datenmengen sind zu bewältigen, zuidentifizieren, zu konsolidieren und zu korre-lieren.

! Die Alarmierung bei IT-Störungen ist intelli-gent zu steuern, die Alarme sind hoch zu ver-dichten, zentral zu verarbeiten und zu stan-dardisieren.

! Die IT-Umgebung und deren Status müssendokumentiert sein, um die vom Auftragge-ber geforderte Nachweispflicht zu erbrin-gen, die unternehmensinternen Normen/Vorschriften einzuhalten und die Transparenzund dadurch den Wissenstransfer sicherzu-stellen.

! Einheitliche Sicht und vernetzte Informatio-nen über Störungsursachen sind erforderlich.

Um diesen hohen Anforderungen gerecht zuwerden, bedarf es einer Geschäftsprozessüber-wachung und eines standardisierten Referenz-modells zur Einführung der Überwachung. Nurso kann der IT-Betrieb die notwendige Sorgfalts-pflicht als interner IT-Dienstleister sicherstellenund damit eine gleichbleibende Kundenzufrie-denheit erreichen.

Eine zentrale Bedeutung innerhalb der Ge-schäftsprozessüberwachung kommt der kor-rekten Alarmierung im Störfall zu. Die Alarmie-rung an die richtige Abteilung oder Person undder korrekte Detaillierungsgrad der Störungs-information sind hierbei ausschlaggebend. Da-durch wird der IT-Organisation die Möglichkeitgegeben, die Entstörungsdauer bzw. die Nicht-

Geschäftsprozessüberwachung

HMD 264 83

verfügbarkeit der IT-Services steuern zu kön-nen.

Um eine Geschäftsprozessüberwachungeinzuführen, sind klare und verständliche Zielezu formulieren. Tabelle 1 stellt den Querschnitteiner Betrachtung dar, bestehend aus mehrerenZieldefinitionen unterschiedlicher internatio-naler Konzerne aus den Branchen Telekommu-nikation und Logistik.

Daraus ergeben sich die folgenden Vorteilefür die IT-Organisation:

! Die IT besitzt eine zentrale Stammdatenhal-tung (Configuration Management Database(CMDB)).Es wird eine einheitliche und zentrale Sichtfür alle beteiligten Projekt- und Betriebsein-heiten ermöglicht.

! Es sind die Beziehungen und Abhängigkeitendargestellt.Das Management der IT-Organisation kannzielgerichtet Maßnahmen einleiten, da dieAuswirkungen der Störung bekannt sind.

Tab. 1: Ziele der Geschäftsprozessüberwachung

Ziele Geschäftsprozessüberwachung Beschreibung

Proaktive Überwachung Der IT-Betrieb kann den Einfluss einer Störung auf die Geschäftsprozesse und andere IT-Komponenten proaktiv erkennen.

Planung und Priorisierung von Störungen

Es kann eine Planung und Priorisierung der Entstörung stattfinden. Incident-Management-Maßnahmen können standardisiert werden.

Einplanung rechtzeitiger Gegenmaßnahmen bei Störungen

Der IT-Betrieb kann rechtzeitig Gegenmaßnahmen (Planung zusätzlicher Ressourcen, externer Support, zusätzliche Hardware, Kosten, …) einplanen.

Gleiche Sichtweise auf die Störung Jede beteiligte Einheit hat die gleiche Sichtweise auf den Servicebaum und somit die gleiche Sicht auf sämtliche IT-Services, IT-Komponenten und Geschäftssichten. Eine Störung wird von allen Beteiligten in ihrer Priorisierung und Auswirkung gleich wahrgenommen.

Abhängigkeiten und Zusammenhänge Die Abhängigkeiten und Zusammenhänge zwischen den IT-Komponenten und IT-Services sind dargestellt, die Kommunikation zur Entstörung wird effizienter, die Entstörungsdauer kürzer.

Darstellung der Auswirkung der Störung Die Auswirkungen einer Störung auf die Geschäftssichten/Geschäftsprozesse sind dargestellt, die Unternehmensführung bekommt die notwendige Transparenz im Blick auf die Störungen und ihre Auswirkungen bzw. kann darstellen, welche Einheit (z.B. ein Vorlieferant) Grund der Störung gewesen ist (=> Reporting).

Erkennen der Tragweite einer Störung Der IT-Betrieb kann historisch und aktuell erkennen, welche Tragweite eine IT-Störung auf die Geschäftsprozesse besitzt oder besessen hat.

Bessere Absicherung gegen Ausfall Die Auswirkungen auf die Geschäftsprozesse sind transparent, die wichtigen IT-Services können besser gegen Ausfall abgesichert werden (z.B. Redundanz, Cluster, QoS, …), es können die notwendigen Ressourcen (Hardware, Mitarbeiter, Software, …) ohne größeren zeitlichen Druck bestellt und beschafft werden.

Geschäftsprozessüberwachung

84 HMD 264

! Die Dokumentation der IT-Dienste ist vorhan-den.Eine tagesaktuelle Dokumentation der IT-Umgebung kann erstellt werden.

! Es wird die Grundlage zur schnelleren Entstö-rung geschaffen, da die Abhängigkeiten vonanderen Störungen bekannt sind.Dadurch wird die Nichtverfügbarkeit derIT-Services reduziert, und die Mitarbeiter-kapazitäten können optimiert eingesetztwerden.

! Die Alarmierung erfolgt hochverdichtet.Die Ursache und deren Auswirkungen auf an-dere IT-Komponenten, IT-Services und Kun-den können auf einen Blick dargestellt wer-den.

Um eine Geschäftsprozessüberwachung einzu-führen, sind aus unserer Sicht ein Referenzmo-dell und ein Schichtenmodell empfehlenswert.Das Referenzmodell IBPM© liefert praxiserprob-te »Best Practices« zur Einführung einer Ge-schäftsprozessüberwachung mit folgenden In-halten:

1 Identifizierung komplexer IT-Bestände:Schnelle und sichere Erfassung der Configu-ration Items (CIs), Abhängigkeiten und Zu-sammenhänge über IBPM©-Templates undPraxiserfahrungen zur halbautomatischenBefüllung der zentralen CMDB

2 Grafischer Servicebaum mit visualisiertenAlarmen:Grafische Darstellung der Abhängigkeiten/Zusammenhänge der Komponenten im Stö-rungsfall

3) Proaktive Alarmierung:Es wird nicht erst alarmiert, wenn der IT-Ser-vice bereits gestört ist.

4) Dynamische CMDB-View:Dynamische Anpassung von Abhängig-keiten und Zusammenhängen der CIs

5) Dynamisches Event-Korrelationsregelwerk:Dynamische Anpassung der Event-Korrela-tionsregeln, Anpassungen im Format, derStruktur und der Formel von Event-Korrela-

tionsregeln innerhalb des ITSM-Toolsets,dynamische Verarbeitung (d. h. u. a. keinHardcoding) von Event-Status und Event-Vererbung

6) Servicealarmierung:Hochverdichtete Servicealarme, Zusammen-führung von Schnittstellen, Produkt- und Lö-sungsanteile, hoher Alarmdetaillierungs-grad für den Betrieb, hohe Detaillierung derRelationen u. Abhängigkeiten

7) Basisalarmierung unterschiedlicher SMS-Soft-ware:Alarmierung von Betriebszuständen von CIs,Integration von z.B. BMC Patrol, HP-OV,SNMP-Traps, Nagios, SiteScope usw.

2 Geschäftsprozessüberwachung – Voraussetzungen

Um eine Geschäftsprozessüberwachung einzu-führen und langfristig betreiben zu können, istdie Schaffung verschiedener Voraussetzungennotwendig.

! Technische Voraussetzungen:– Definition eines Referenzmodells zur Ein-

führung– Abstimmung und Befüllung des Schich-

tenmodells (CIs, Abhängigkeiten, Zusam-menhänge, Event-Views, Alarmierungusw.)

! Organisatorische Voraussetzungen:– Es muss ein Change-Management-Pro-

zess eingeführt sein.– Es muss einen Executive Sponsor, einen

Projektbesitzer, einen Auftraggeber, einenProjektleiter, ein Projektkonzeptteam undein Umsetzungsteam geben.

– Es muss eine Beachtung und Unterstüt-zung durch die oberste Führungsebene»Executive Management Attention« ge-geben sein.

– Es muss ein Strategiewechsel in den Köp-fen der Mitarbeiter stattfinden, dassIT-Leistungen transparent gemacht wer-den.

Geschäftsprozessüberwachung

HMD 264 85

Assessment Monitoring-Software u. Parametersatz

Vereinheitlichung Parametersatz + Monitoring-Software

Aufstellen Struktur Schichtenmodell

Assessment bestehende Monitoring-Schichten und Service-Maps

Aufstellen Struktur Servicetree

Erstellung Checklisten zur Befüllung Schichtenmodell + Servicetree

Assessment IT-Betriebsmittel

Aufstellen Format Konzeptpapiere

Schulung Schichtenmodell + Servicetree für MA

Befüllung Schichtenmodell + Servicetree durch MA

Assessment Abhängigkeiten/Zusammenhänge, Relationen, Event-Views, CIs, ...

Erstellung Checklisten zur Befüllung Schichtenmodell + Servicetree

Erstellung Checklisten zur Befüllung Schichtenmodell + Servicetree

Assessment IT-BetriebsmittelAssessment IT-Betriebsmittel

Aufstellen Format KonzeptpapiereAufstellen Format Konzeptpapiere

Servicetree für MASchulung Schichtenmodell + Schulung Schichtenmodell +

Servicetree für MABefüllung Schichtenmodell +

Servicetree durch MA Befüllung Schichtenmodell +

Servicetree durch MA

Assessment Abhängigkeiten/Zusammenhänge,Relationen, Event-Views, CIs, ...

Assessment Abhängigkeiten/Zusammenhänge, Relationen, Event-Views, CIs, ...

Kick-off

Erstellung Anforderungskonzeptpapiere

Erstellung Umsetzungskonzeptpapiere

Umsetzung + Installation Toolset

Daten-integration

Erstellung Anforderungskonzeptpapiere

Erstellung Anforderungskonzeptpapiere

ErstellungUmsetzungskonzeptpapiere

Erstellung Umsetzungskonzeptpapiere

Umsetzung + Installation Toolset

Umsetzung + Installation Toolset

Daten-integration

Daten-integration

– Ein Multiprojektmanagement muss in-stalliert werden, um parallel die IT-Ser-vices in der Überwachung abzubilden.

– Vertrauen in neue Methoden und Vorge-hensweisen

– Bereitstellung von Ressourcen und Bud-get, klare Einhaltung der Projektplanungund des Projektauftrags

3 Geschäftsprozessüberwachung – Referenzmodell

3.1 Referenzmodell zur Einführung einer Geschäftsprozessüberwachung

Bei IBPM© handelt es sich um ein Referenzmo-dell zur Konzepterstellung und Implementie-rung von Geschäftsprozessüberwachung, d. h.Gewährleistung der Wiederverwendbarkeit vonbestehenden Verfahren, und bedeutet somiteine Kostenreduktion. Weiterhin ist die ein-fache Modifizierbarkeit von Vorteil, da sie zurErfüllung neuer bzw. geänderter Anforde-rungen oder zur Anpassung der Modelle an spe-zifische Anforderungen und unterschiedlicheBenutzergruppen beitragen kann. Außerdemwerden basierend auf dem Referenzmodell die

Konzepte zur Geschäftsprozessüberwachung,d. h. die Beschreibung des Servicebaums/derServicemodelle, erstellt.

Das Referenzmodell baut auf einem Multi-projektmanagement auf, das notwendig ist, umeine parallele Identifizierung von IT-Services zuermöglichen. Die zukünftig anstehenden Da-tenmengen (mind. 100.000 IT-Komponenten,mind. 1.000.000 Checks) zu bewältigen und da-durch alle IT-Komponenten, deren Abhängig-keiten und die Überwachungen, d. h. Checks derIT-Komponenten, identifizieren zu können, istein weiterer Vorteil des Referenzmodells. DasReferenzmodell ist das Kernstück der Einfüh-rung einer Geschäftsprozessüberwachung.

Das Referenzmodell (vgl. Abb. 1) wird aufden Kunden abgestimmt und als »Stahlrah-men« während des Projektes mitgeführt. DasReferenzmodell beinhaltet generell folgendePunkte:

! Multiprojektmanagementplanung, Projekt-phasenplan, Ziele, Aufwand, Kosten

! Servicebaum-Schichtenmodell zur CI-Erfas-sung und Alarmierung

! Vordefinierte Arbeitspapiere zur Identifizie-rung der IT-Services

Abb. 1: Referenzmodell

Geschäftsprozessüberwachung

86 HMD 264

! Projektorganisation (Executive Sponsor, Pro-jektbesitzer, Auftraggeber, Projektleiter, Pro-jektkonzeptteam, Implementierungsteam)

! Change-Management-Prozess

3.2 Schichtenmodell Das Schichtenmodell ist das Framework, aufdem die Geschäftsprozessüberwachung auf-setzt. Das Schichtenmodell bildet den Rahmen,

in dem die Geschäftsprozessüberwachung kon-zeptioniert und aufgebaut wird. Im Schichten-modell wird festgelegt, welche Elemente inwelcher Detailtiefe für eine Geschäftsprozess-überwachung speziell für den Kunden notwen-dig werden. Unter anderem sind es standard-mäßig die folgenden Rahmenelemente (vgl.Tab. 2), die nach Bedarf erweitert werden kön-nen.

Elemente BeschreibungSysteme • Anzahl der Systeme

• Klassifizierung der Systeme• Liste der Systemnamen (Hostname, IP-Adresse, Standort, AP, weitere

Attribute)• Parametersatz zur Überwachung

Cluster • Anzahl der Cluster• Klassifizierung der Cluster• Liste der Clusternamen• Zuordnung von Systemen zu Clustern• Parametersatz zur Überwachung

Applikationen • Anzahl der Applikationen• Klassifizierung der Applikationen• Liste der Applikationen• Zuordnung der Applikationen zu Systemen• Parametersatz zur Überwachung

Schnittstellen • Anzahl der Schnittstellen• Benennung der Schnittstellen• Parametersatz

Geschäftsparameter • Anzahl der Geschäftsparameter• Benennung der Geschäftsparameter• Parametersatz

Vertikaler u. horizontaler Servicebaum

• CIs, Abhängigkeiten und Zusammenhänge IT-Komponenten und IT-Services• Korrelationsregelwerk• CMDB• CI-Attribute• Alarmierung und Notifizierung, Eskalation

Diagonaler Servicebaum • Abhängigkeiten und Zusammenhänge Geschäftssicht, Kundensicht• Korrelationsregeln• Alarmierung und Notifizierung, Eskalation

Event-Views, Konsolen • IT-Benutzersichten, Geschäftssichten u. Kundensichten• Leitstand-, ITSM-Konsolen

Event-Status-Types (siehe nächsten Abschnitt)

• Mögliche Status der IT-Serviceelemente

Monitoring-Software • Auswahl der Systemmanagement-Software (z.B. BMC Performance Manager, Tivoli NetAgent, HP-OV Agent, SNMP-Agent)

• Auswahl der IT-Servicemanagement-Software• Auswahl der Korrelation-Engine• Auswahl der Notifizierungs- und Eskalations-Engine• Schnittstellen an die Incident-Mgmt.- und Change-Mgmt.-Toolsets

Name und Anzahl der Schichten

• Siehe unterer Abschnitt

Tab. 2: Rahmenelemente im Schichtenmodell

Geschäftsprozessüberwachung

HMD 264 87

Physical IT- View

Logical IT- View

IT-Service- View (IT-Services)

Customer- Business-Service- View (IT-Services)

Clusteralarme

Clusterstatus, Applikationsstatus, Systemstatus (z.B. ‚geclusterte‘ Filesysteme)

Basisalarme

System-Erreichbarkeit, Systemzustand, Applikationszustand, EtE-Zustand

1st, 2nd, 3rd Support-Level

IT-Mid.-Mgmt.-Level

IT-Mgmt.-Level

CTO-Level

Keine Event-Korrelation

1. Servicealarm-Event-Korrelation

Servicealarme

Komponentenstatus, Funktionenstatus, intern IT-

Service-Status, ...

2.-n-te Servicealarm-Event-Korrelation

Servicealarme

IT-Servicesn-te Servicealarm-Event-

Korrelation

Kunde A Kunde B Kunde C

Systeme, Applikationen, Cluster

Komponenten, Funktionen, interne IT-

Services, ...

IT-Services

Systeme, Applikationen, Cluster

Komponenten, Funktionen, interne IT-

Services, ...

IT-Services

Diagonale Servicealarm-Event-Korrelation

Ein IT-Serviceelement ist eine Einheit in einemServicebaum. Dieses kann ein System, eine Ap-plikation, eine Funktion oder auch ein IT-Servicesein.

Das Schichtenmodell (vgl. Abb. 2) stellt dieStruktur und die Grundlage zur Erstellung desServicebaums dar. Es unterteilt sich in die physi-kalische IT-View und in die logische IT-View. In-nerhalb der physikalischen IT-View wird diephysikalische IT-Infrastruktur, innerhalb der lo-gischen IT-View werden die logisch zusammen-gefassten IT-Dienste abgebildet.

Die Analyse der Anzahl und Benennung derSchichten im Servicebaum-Schichtenmodell istein wesentlicher Bestandteil für eine erfolg-reiche Geschäftsprozessüberwachung. Über dieAnzahl der Schichten wird die Detailtiefe imServicebaum und dadurch in der Korrelationund Alarmierung gesteuert. Hier wird in Ab-stimmung mit dem Service Level Manager fest-gelegt, welche Qualität die IT-Services basie-rend auf ihrer Verfügbarkeit und Performancebesitzen müssen. Eine korrekt gewählte Detail-tiefe kann die Qualität der IT-Services erhöhen,da die IT-Organisation durch die starke Detail-

lierung proaktiv Gegenmaßnahmen ergreifenbzw. die zugrunde liegenden Störungen schnel-ler bearbeiten und abschließen kann.

Die Benennung der Schichten ist abhängigvon der Anzahl der Schichten, d. h. der Detailtie-fe. Das Referenzmodell sieht standardmäßig diefolgende Aufstellung vor, die bei Bedarf erwei-tert werden kann. Erfahrungsgemäß solltenmind. 5 Schichten bis max. 10 Schichten vorhan-den sein.

Erfahrungsgemäß sind die folgendenSchichten notwendig (vgl. Tab. 3).

Basisalarme und ServicealarmeBasisalarme sind unverdichtete Alarme einesgestörten Serviceelements, sie werden von derMonitoring-Software erkannt und gemeldetund stellen den Status einer IT-Komponente(z.B. System, Applikation) in der physikalischenIT-View dar. Servicealarme sind verdichtete Ba-sisalarme und stellen den Status einer logischzusammengefassten IT-Komponente (z.B. IT-Service) in der logischen IT-View dar.

Der Status wird in Form des Event-Status-Types dargestellt.

Abb. 2: Darstellung Schichtenmodell

Geschäftsprozessüberwachung

88 HMD 264

Schichtname Beschreibung Weitergabe an die nächsthöhere Schicht

System u. Applikation, Netzwerk

Es wird jedes System und jede Applikation mit einem ausgewählten Standard-parametersatz überwacht. Es werden Basisalarme erzeugt. Leitstandkonsolen zeigen die Basisalarme an.

Basisalarme, die eine Servicerelevanz besitzen.

Cluster Es wird die Verfügbarkeit der Dienste (z.B. Filesystem, Prozesse) und der Applikationen überwacht. Die Systemfunktionen und Applikationen sind zum größten Teil hochverfügbar ausgelegt. Das bedeutet, wenn der Primary-Node im Cluster ausfällt, übernimmt der Backup-Node die Dienste und Applikationen, die der Cluster dem IT-Service zur Verfügung stellt.Die Basisalarme werden korreliert, und dadurch werden verdichtete Servicealarme erzeugt, die den Status der Clusterdienste bzw. der Clusterapplikationen darstellen.Die physikalische Infrastruktur ist in den beiden ersten Schichten abgedeckt.

Servicealarme mit Verdichtungs- und Korrelationsstufe I

Komponenten Innerhalb eines IT-Service existieren 1-n Komponenten, die von 1-n Clusterdiensten und Applikationen zur Verfügung gestellt werden. Die Cluster-Servicealarme werden korreliert, und es werden verdichtete Servicealarme, die den Status der Komponenten darstellen, erzeugt.

Servicealarme mit Verdichtungs- und Korrelationsstufe II

Funktionen Innerhalb eines IT-Service existieren 1-n Funktionen, die von 1-n Komponenten zur Verfügung gestellt werden. Die Komponenten-Servicealarme werden korreliert, und es werden verdichtete Servicealarme, die den Status der Funktionen darstellen, erzeugt.

Servicealarme mit Verdichtungs- und Korrelationsstufe III

Interne IT-Services Innerhalb eines IT-Service existieren 1-n interne IT-Services, die von 1-n Funktionen zur Verfügung gestellt werden. Die Funktionen-Servicealarme werden korreliert, es werden verdichtete Servicealarme, die den Status der internen IT-Services darstellen, erzeugt.

Servicealarme mit Verdichtungs- und Korrelationsstufe IV

IT-Services Innerhalb eines IT-Service existieren 1-n interne IT-Services. Die unterliegenden Servicealarme werden korreliert, es werden verdichtete Servicealarme, die den Status der IT-Services darstellen, erzeugt.

Servicealarme mit Verdichtungs- und Korrelationsstufe V

Geschäftssicht Diese Schicht ist eine diagonale Schicht, die sich der Basisalarme und Servicealarme aus den unterliegenden Schichten bedient.

Business-Service-Korrelation

Tab. 3: Exemplarische Darstellung der Schichten

Geschäftsprozessüberwachung

HMD 264 89

Dynamisches KorrelationsregelwerkDie Korrelationsregeln beinhalten die Verer-bungsrichtlinien und Verknüpfungen der Ser-viceelemente und besitzen als Ergebnis den Sta-tus des Serviceelements. Der Status ist derEvent-Status-Type. Die Korrelationsregeln unter-liegen der Hierarchie des Service-Trees und desSchichtenmodells. Eine Störung bzw. ein Eventwird von der Monitoring-Software gemeldet,dann von der ersten Schicht verarbeitet und ver-dichtet, die Verarbeitungsergebnisse werden je-weils in die zweite Schicht gemeldet und in dernächsthöheren Schicht weiterverarbeitet undverdichtet usw. Die höchste Schicht ist gleichzei-tig die höchste Verdichtungsstufe und stellt dasErgebnis der Event-Korrelation dar. Die Verarbei-tung, d. h. die Event-Korrelation, erfolgt auf Ba-sis der Abhängigkeiten und Zusammenhängezwischen den IT-Komponenten und IT-Services.

Innerhalb des Servicebaum-Schichtenmo-dells werden Basisalarme zu Servicealarmenkorreliert. Die Grundlage zur Korrelation sinddie Configuration Items (CI), deren Abhängig-keiten und Korrelationsregeln. Ziel des »dyna-mischen Korrelationsregelwerks« ist die Pflegeund die Wartbarkeit der Configuration Items(CI), deren Abhängigkeiten und Zusammenhän-ge und Korrelationsregeln innerhalb der CMDBauf dynamischer Basis. Die detaillierte Beschrei-

bung der Methode »dynamisches Korrelations-regelwerk« sieht folgendermaßen aus:! Die Möglichkeit zur dynamischen Anpas-

sung ...– bei Hinzufügen, Änderung oder Löschung

von CIs– bei Hinzufügen, Änderung oder Löschung

der Abhängigkeiten/Zusammenhängeder CIs

– bei Hinzufügen, Änderung oder Löschungder Korrelationsregeln

– bei Hinzufügen, Änderung oder Löschungder Überwachung eines CIs

! Kein »Hardcoding« der Zusammenhänge/Ab-hängigkeiten und Korrelationsregeln zwi-schen den einzelnen CIs

! Für jeden CI/Event kann eine eigene unab-hängige Event-Tool-View erstellt werden.

! Integration der Event-Tool-Views und Event-Tool-Procs, Event-Status-Type-Vererbungen

! Die Event-Status-Types können auf jedem CIAnwendung finden.

Event-Status-TypesAuf Basis der Abhängigkeiten/Zusammenhän-ge und der Korrelationsregeln kann der Statusjedes Serviceelements bestimmt werden. Erfah-rungsgemäß existieren mehrere Event-Status-Types (vgl. Tab. 4).

Event-Status-Type Beschreibung

Serviceelement Down Alarm

Serviceelement steht nicht mehr zur Verfügung. Kritikalität wird z.B. auf »Rot« und die Severity z.B. auf »5« gesetzt.

Serviceelement Endangered Alarm

Das Serviceelement steht zur Verfügung, ist aber gefährdet. Kritikalität wird z.B. auf »Gelb« und die Severity z.B. auf »4« gesetzt.

Serviceelement Redundancy Lost Alarm

Die Hochverfügbarkeit bzw. Redundanz des Serviceelements (z.B. Ausfall einer Cluster-Site/Cluster-Node im Clusterverbund) ist nicht mehr gegeben. Kritikalität wird z.B. auf »Rot« und die Severity z.B. auf »3« gesetzt.

Serviceelement Degrated Alarm

Serviceelement steht nur noch eingeschränkt bzw. beeinträchtigt zur Verfügung. Kritikalität wird z.B. auf »Gelb« und die Severity z.B. auf »2« gesetzt.

OK Serviceelement ist o.k. Kritikalität wird z.B. auf »Grün« und die Severity z.B. auf »0« bzw. »1« gesetzt.

Tab. 4: Event-Status-Type im Schichtenmodell

Geschäftsprozessüberwachung

90 HMD 264

Basierend auf den Event-Status-Types der Ser-viceelemente ist die Maßnahme und derenPriorisierung abzuleiten (vgl. Tab. 5).

ServicebaumDas Schichtenmodell bildet die Grundlage zumServicebaum. Auf Basis des Schichtenmodellswird der Servicebaum aufgebaut. Im Schichten-modell sind das Format und die Struktur unddadurch der Detaillierungsgrad des Service-baums verankert.

Event-ViewJede der Schichten im Schichtenmodell kanneine eigene Event-View beinhalten, d. h. eineKonsolenansicht der jeweiligen Basis- oder Ser-vicealarme. Somit ist es möglich, dass alle betei-ligten Projekt- und Betriebseinheiten eine ein-heitliche Sicht und zugleich eine auf ihre Auf-gabe spezifisch angepasste Ansicht auf denZustand der IT-Services erhalten.

3.3 Servicebaum der IT-OrganisationDas Schichtenmodell definiert die Struktur unddie Detailtiefe des Servicebaums. Nach derIdentifizierung der IT-Services basierend auf derStruktur des Schichtenmodells kann der IT-Ser-vicebaum erstellt werden: Das Aufstellen desServicebaums beinhaltet die vollständige Befül-lung des Servicebaum-Schichtenmodells. Diese

Befüllung erfolgt parallel a) über die Identifizie-rung der IT-Serviceelemente und b) über stan-dardisierte Arbeitspapiere.

a) Die Identifizierung der IT-Serviceelementeist im nächsten Abschnitt beschrieben.

b) Die Arbeitspapiere sind standardisiert undbeinhalten in Format und Struktur dasSchichtenmodell. Es sind der Parametersatzzur Überwachung der CIs, die Zusammen-hänge und Abhängigkeiten der CIs, die je-weiligen Event-Korrelationsregeln, die Noti-fizierung/Eskalation und die Event-Status-Types enthalten. Das Konzeptpapier beinhal-tet den Servicebaum in Form einer hochde-taillierten Matrix. Um der Komplexität derIT-Umgebung (ca. 100.000 IT-Komponenten)gerecht zu werden, ist es ratsam, beispiel-haft das unten genannte Vorgehensmodellzur Identifizierung der IT-Serviceelementeanzuwenden.

3.4 Vorgehensmodell zur Identifizierung der IT-Serviceelemente

Das Vorgehensmodell zur Identifizierung derIT-Serviceelemente (vgl. Abb. 3) ist von wesent-licher Bedeutung für die Geschäftsprozessüber-wachung. Hierdurch wird das Konzeptpapierund die CMDB mit unten stehenden Elementenbefüllt:

Tab. 5: Event-Status-Type im Schichtenmodell und Maßnahmen

Event-Status-Type Beschreibung

Serviceelement Down Alarm

Priorität 1, sofortiges Handeln zur Wiederherstellung, Kunde kann nicht mehr arbeiten.

Serviceelement Endangered Alarm

Priorität 2, schnelles Handeln zur Wiederherstellung der notwendigen Performance und Kapazität, Kunden können nur noch stark eingeschränkt arbeiten.

Serviceelement Redundancy Lost Alarm

Priorität 3, zeitnahes Handeln zur Wiederherstellung der Redundanz, kein Kunden-Impact.

Serviceelement Degrated Alarm

Priorität 4, Handeln, wenn keine anderen Störungen existieren, Kunden bemerken keine bzw. nur leichte Verzögerungen in der Bearbeitung.

OK Keine

Geschäftsprozessüberwachung

HMD 264 91

! CIs bzw. IT-Serviceelemente– Physikalische IT-Serviceelemente

– Systeme, Cluster, Applikationen,Schnittstellen u. Parametersatz zurÜberwachung

– Alle Serviceelemente, die basierend aufder Definition in den physikalischen IT-View-Schichten des Schichtenmodellsenthalten sein sollten.

– Logische IT-Serviceelemente– Alle Serviceelemente, die basierend auf

der Definition in den logischen IT-View-Schichten des Schichtenmodells ent-halten sein sollten.

– Geschäftsparameter u. Parametersatz zurÜberwachung

! Abhängigkeiten, Zusammenhänge undEvent-Korrelationsregeln IT-Serviceelementeund IT-Services

! Abhängigkeiten, Zusammenhänge und Kor-relationsregeln IT-Services, Geschäftssicht,Kundensicht

Zur vollständigen Identifizierung der IT-Servicesfehlen bestimmte Elemente im Konzeptpapierund im ITSM-Toolset. Diese sind manuell imKonzeptpapier und im ITSM-Toolset einzutra-

gen bzw. zu konfigurieren. Ein Teil des Konzept-papiers ist in der CMDB enthalten, der andereTeil befindet sich im ITSM-Toolset (z.B. Korrela-tion-Engine, Konsolen-Frontends, Agenten). ! IT-Benutzersichten, Geschäftssichten u. Kun-

densichten! Leitstand-, ITSM-Konsolen! Evtl. Alarmierung und Notifizierung, Eskala-

tion! Evtl. Event-Status-Types! Evtl. Korrelationsregeln, wenn diese von den

Standardabhängigkeiten/Zusammenhän-gen der CIs abweichen

Durch die genannte Vorgehensweise könnenbasierend auf den IT-Service-Component-Temp-lates vorkonfigurierte Standarddatensätze (z.B.Event-Korrelationsregeln, Event-Status-Types)benutzt werden. Hierdurch werden die restli-chen Eintragungen deutlich vereinfacht. DieEvent-Views sind manuell zu pflegen (Konzept-papier und Tool). Der Change-Manager über-prüft die Korrektheit der neuen Eintragungenim Konzeptpapier und ändert diese bzw. fügtweitere Elemente hinzu.

Das Konzeptpapier beinhaltet somit alleElemente, die für eine Geschäftsprozessüber-

Abb. 3: Vorgehensmodell zur Identifizierung der IT-Serviceelemente

Geschäftsprozessüberwachung

92 HMD 264

wachung notwendig sind, und stellt gleicher-maßen die tagesaktuelle Dokumentation derGeschäftsprozesse des Konzerns dar.

4 Geschäftsprozessüberwachung – Implementierung

Innerhalb der Monitoring- und ITSM-Softwarewerden die Konzeptpapiere abgebildet und dieCMDB befüllt. Die Konfiguration der Monito-ring- und ITSM-Software ist in den Konzept-papieren enthalten.

Die Implementierung der Monitoring- undITSM-Software ist abhängig vom Softwareher-steller und kann aus diesem Grund nicht stan-dardisiert und als Methode beschrieben wer-den.

Frank SteinbeckSteiCon Solution GmbHUbierstr. 6953173 Bonn [email protected]