Ein Unternehmen der MEHLER AG

Transkript

1

2 Geschäftsprozess Monitoring Business Track Nagios Konferenz, 11.Oktober 2007 Michael Kienle Geschäftsführer it-novum GmbH

3 Agenda Notwendigkeit der Überwachung von Geschäftsprozessen Stabilität und Verfügbarkeit Anforderungen aus der Praxis ServiceLevelAgreements (SLA) Nagios unter dem Aspekt Geschäftsprozesse Defizite und Probleme Umsetzungen verschiedene Möglichkeiten Formale Beschreibung von Geschäftsprozessen End-2-End Monitoring Visualisierung Fazit: Genügt eine OpenSource Plattform den Anforderungen der Überwachung von Geschäftsprozessen?

4 IT-Kompetenz-Zentrum eines Konzerns IT-Lösungen für den gehobenen Mittelstand/Enterprise Sichere, zuverlässige und wirtschaftliche IT Komplette Wertschöpfungskette Beratung, Planung, Umsetzung, Betrieb Am externen Markt seit 1999 Ca. 50% externer Umsatz, Trend: steigend Synergieeffekte & Innovationen durch Konzernzugehörigkeit (>2 Mrd ) Partnerschaften und Zertifizierungen Schwerpunkte & Kompetenzen: Systemmanagement (itcockpit/nagios) ServerBasedComputing Outsourcing/Datacenter/SAP Konzepte, Analysen und Betrieb Storage- und Servervirtualisierung, Konsolidierung IT-Sicherheit, Datenschutz, Datensicherheit Dokumentenmanagement / Archivierung / ECM

5 Wandel der IT-Organisation Stabilität der IT: gering Tools: Keine Anforderungen: nicht definiert Phasenmodell zum Einordnen des Kunden Einführung IT Service Management

6 Wandel der IT-Organisation Stabilität: mittel aber nicht genau Phasenmodell zum Einordnen des Kunden vorhersehbar Tools: Insellösungen Anforderungen: unklar und ungenau Einführung IT Service Management

7 Wandel der IT-Organisation Stabilität: gut Tools: Einheitliches Phasenmodell zum Systemmanagement Einordnen des Kunden Anforderungen: gestiegen aber nicht genau definiert Einführung IT Service Management

8 Wandel der IT-Organisation Stabilität: Hoch Tools: Einheitliches und umfassendes Phasenmodell zum Einordnen des Kunden Systemmanagement, Serviceorientierung Anforderungen: qualitativ bekannt und hoch Einführung IT Service Management

9 Wandel der IT-Organisation Stabilität: Sehr hoch Tools: Einheitliches und umfassendes Phasenmodell IT-Service-Management zum Einordnen des Kunden Anforderungen: klar und quantitativ definierte Geschäftsprozesse Einführung IT Service Management

10 Notwendigkeit des BPM Monitorings Unternehmenskritische IT-Anwendungen IT-Abteilungen befinden sich in einem dramatischen Wandel (Trend zur Service-IT) Themen wie ITIL, ITSM, SOA, Agilität in der IT werden immer wichtiger Stabilität & Verfügbarkeit gefordert und zwar nicht bei einzelnen Hardware- Komponenten! Störung der Betriebsabläufe bedingen hohe Kosten Oftmals: Vereinbarung von SLAs (Service Level Agreements) für komplette Geschäftsprozesse (insb. Outsourcing) Einführung eines auf Geschäftsprozessen arbeitenden BPM-Monitoring zwingend notwendig sowohl für IT-Dienstleister (Reporting, proaktive Checks, schnelle Fehlerbehebung) als auch Leistungsnehmer/Kunden! (Transparenz & Kontrolle)

11 Anforderungen an BPM BPM-Monitoring sollte dementsprechend: die Wahrscheinlichkeit eines Ausfalles deutlich verringen im Fehlerfall schnellere Fehlerlokalisierung ermöglichen Proaktiv die Gefährdung von vereinbarten SLAs vermeiden Steigende Bedeutung durch Outsourcing bzw. Outtasking (Transparenz) Übergreifend eine angemessene (im Sinne der getroffenen Vereinbarungen) Nutzung sicherzustellen (dokumentieren/reporting) In der Praxis bedeutet dieses an Einsatzgebieten: Incident Management & Erkennen von Trends Performance Management: Sizing, proaktive Erweiterung SLA-Reporting (Verfügbarkeiten, Antwortzeiten) für beide (!) Seiten (Dienstleister & Kunde)

12 SLA ServiceLevelAgreements Notwendigkeit Quantifizierbare Kriteriendefinition BPM bedingt sinnvollerweise SLA Praxis Messkriterien: Nicht: Server x ist 95% per ping erreichbar Eher: Zu 99% lässt sich die SAP-Transaktion vom Standort A innerhalb von 10 Sekunden erfolgreich durchführen. Reporting: Hängt nicht an Diensten, Devices sondern am Kunden! Tipp aus der Realität: Definition nicht am grünen Tisch sondern mit Schwerpunkt auf einfach quantifizierbaren und einfach umsetzbaren Messpunkten!

13 Nagios Sichtweise I NAGIOS wurde als Überwachungswerkzeug für IT-Infrastruktur konzipiert. Orientierung an Servern (Hosts) als zentrales Objekt der Konfiguration und den darauf laufenden Diensten Trend in der Unternehmensorganisation hin zu einer Prozessorientierten Sichtweise. Nicht mehr die Verfügbarkeit eines einzelnen Systems steht im Vordergrund sondern die Verfügbarkeit eines gesamten Geschäftsprozesses (der unter Umständen aus vielen weltweit verteilten Systemen bestehen kann) Reporting, insb. SLA-Reporting ist wenig flexibel um notwendige Transparenz herzustellen. In großen Umgebungen geforderte Umsetzungen, z.b. komplexe kundenspezifische Anforderungen, können nur schwierig erreicht werden.

14 Nagios Sichtweise II Abbildung solcher komplexen Strukturen in NAGIOS ist schwierig. Möglichkeit über Host- und Service-Dependencies Strukturen und grundsätzlich Abhängigkeiten wiederzugeben. Allerdings reichen die Möglichkeiten nicht aus um die oft tiefe Verschachtelung eines Geschäftsprozesses wiederzugeben. Auch ist es nicht immer möglich den Zustand eines Geschäftsprozesses vollständig zu überwachen und klar in die Zustände (OK, Warning, und Critical) die NAGIOS bietet einzuordnen. Als Beispiel sei an dieser Stelle der Zustand Warning angeführt. Der Ausfall eines Dienstes kann den gesamten Prozess nur minimal verlangsamen, während der Ausfall eines anderen Dienstes zu einer erheblichen Beeinträchtigung führt, der Gesamtprozess ist aber nach vor funktionstüchtig. Für solche Fälle wäre eine feinere Abstufung erforderlich. Diese Schwächen von NAGIOS im Hinblick auf die Überwachung von Geschäftsprozessen machen die Entwicklung einer zusätzlichen Logik erforderlich welche die oben genannten Punkte ausgleichen kann und NAGIOS um die erforderliche Prozesssicht erweitert.

15 Nagios: Anforderungen/Erweiterungen Optimierung bei der Nutzung von SLAs Verbesserungen im Bereich Definition von (kundenspezifischen) SLAs Flexibilisierung beim SLA-Reporting Einfacheres Monitoring von komplexen Geschäftsprozessen, grundsätzlich verschiedene Vorgehensweisen: 1. Direkte Messung eines simulierten End-Nutzers (End-2- End; induktiver Ansatz) 2. Formale Beschreibung eines Geschäftsprozesses und Herleitung der notwendigen Überwachungen ( deduktiver Ansatz) 3. Herstellung von Relationen durch simple Visualisierung

16 Funktionen End-2-End Überwachung sämtlicher Komponenten der IT mit einer BPM Sichtweise (im Vergleich zur Infrastruktur-Perspektive) Definition der (quantifizierbaren) Kriterien ist entscheidend! Performance aus Anwendersicht eine Kombination aus Datenbank, Applikationsserver, Netzwerkanbindung, Workstation etc. Periodisches (natives) Simulieren von Benutzer-Interaktionen im LAN/WAN/VPN (Enduser-Experience: Simulieren von Tastatureingaben, Mausbewegungen und Reaktion auf Ereignisse wie z.b. Fenster, Eingabeaufforderungen etc.) ERP / SAP Transaktionen Terminalserver Login / CITRIX Bestellfunktion in Online Shops / Exchange Vollständige Integration in Nagios Grafische Darstellung der Zeiten Benachrichtigungen über alle Medien Verfügbarkeitsreporting SLA-Reporting (Schwellwerte wurden überschritten / nicht überschritten) Mandantenfähigkeit

17 hp procurve switch 5372xl J4848A Power Fault Console hp procurve 10/10 0TX xl Module J4 820A Status Re se t Cle ar 1 2 A B C D E F G H Self Fan Test Fault Power Modules J4820A 24 port 10/100TX Act FDx M a x LED Mode Select use xl m o du le s on ly J4820A 24 port 10/100TX hp procurve 10/10 0TX xl Module J4 820A J4820A 24 port 10/100TX hp procurve 10/10 0TX xl Module J4 820A Procurve Routing Switch 9308M HP J4138A Procurve Routing Switch 9308M HP J4138A hp procurve switch 5372xl J4848A Power Fault Console hp procurve 10/10 0TX xl Module J4 820A Status Re se t Cle ar 1 2 A B C D E F G H Self Fan Test Faul t Power Modules J4820A 24 port 10/100TX Act FDx M a x LED Mode Select use xl modules only J4820A 24 port 10/100TX hp procurve 10/10 0TX xl Module J4 820A J4820A 24 port 10/100TX hp procurve 10/10 0TX xl Module J4 820A End-2-End Monitoring, am Beispiel SAP SupplyChain Server (Partner) PC Applikations- Server Switch Switch Router z.b. MPLS Router Oracle Datenbank

18 Funktionsweise Scripting einer Anwendung aus Sicht eines Endnutzers, inkl. Messen der Einzelzeiten Regelmäßiges Ausführen (geplante Tasks) Melden ins Nagios Weiterverarbeiten im Nagios (Schwellwerte, Benachrichtigungen etc.)

19 E2E

20 Screenshot E2E-Messung Additive Darstellung (Login, Transaktion, Gesamt) Basis für SLA-Reporting

21 Umsetzung in Nagios

22 Formaler Ansatz Geschäftsprozessesmodellierung Nicht gerade neu; allerdings im Umfeld Monitoring wenig beschritten Viele formalen Modellierungen bekannt (ARIS ), z.b. im Umfeld SOA optimalerweise: Direkte Generierung des Monitorings OpenSource Tools: Together Workflow Editor (

23 Beispiel

24 Umsetzung in Nagios Zuordnung zwischen Services u. Geschäftsprozessen Synchronisierung der Status-Infos Einbindung in Nagios

25 Generiertes XPDL File <Activity Id="32" Name="Enter Order"> <Implementation> <Tool Id="enterOrder" Type="APPLICATION"> <ActualParameters> <ActualParameter>orderInfo</ActualParameter> <ActualParameter>orderNumber</ActualParameter> </ActualParameters> </Tool> </Implementation> <Performer>DBConnection</Performer> <TransitionRestrictions> <TransitionRestriction> <Join Type="XOR"/> </TransitionRestriction> </TransitionRestrictions> <ExtendedAttributes> <ExtendedAttribute Name="Coordinates"> <xyz:coordinates xpos="510" ypos="389"/> </ExtendedAttribute> <ExtendedAttribute Name="NagiosHost" Value="SAPA1"/> <ExtendedAttribute Name="NagiosHost" Value="SRVELO02"/> </ExtendedAttributes> </Activity>

26 Generierte Nagios Konfiguration define host { use generic-host name Enter_Order alias Workflow Activity address } define service { use generic-service host_name Enter_Order service_description SAPA1 checkcommand check_workflow!sapa1!1 } define service { use generic-service host_name Enter_Order service_description SRVELO02 checkcommand check_workflow!srvelo02!1 } Anm.: check_workflow == Nagios Plugin

27 Generierte Nagios-Konfiguration Work-in-Progress!!! Derzeitige Defizite: Abhängigkeiten flexibler zu gestalten (Logik der Relationen) Darstellung von Zwischenzustände (nicht nur schwarz oder weiß) besser verarbeiten zu können (SLA ) Bessere Einschätzbarkeit des Status Warning : Proaktive Sichtweise: Welche Konsequenzen bedingen derzeitige Situationen Generierte Visualisierung Weiterentwicklung in der nahen Zukunft: Derzeitige Projekte, Diplomarbeit Ergebnisse unter

28 Visualisierung von Prozessen Leistungskette inkl. der beteiligten Komponenten und Services Hierarchisch abbildbar

29 Genügt eine OpenSource Plattform den Anforderungen für ein BPM-Monitoring? Nagios kann als Monitoring-Plattform eine gute Unterstützung leisten; zumal die Verbreitung und die Flexibilität klare Vorteile bedingen. Durch die dargestellten Anforderungen und den notwendigen Wechseln in der Design-Philosophie werden jedoch wesentliche Erweiterungen notwendig. Letztendlich ist für eine erfolgreiche Umsetzung viel Know-How und immer noch viel Entwicklungsarbeit notwendig. Der Weg End- 2-End erscheint in der praktischen Umsetzung einfacher und schneller zu sein als der formalistische Ansatz. Die Zukunft liegt in einer umfassenderen Überwachung der kompletten IT (Framework Paradigma) und einer steigenden Service- (Geschäftsprozesse) und Kundenorientierung (SLA ). Die Bedeutung eines integrierten BPM wird deutlich steigen. Angrenzende Themen wie End-2-End Monitoring oder flexible Tools im Umfeld SLA werden wichtig.

30 Danke für Ihre Aufmerksamkeit! Interesse oder mehr Info? Michael Kienle Geschäftsführer Looking for a job? Please apply.