End User Experience Monitoring Eine Frage des Blickwinkels

Transkript

1 End User Experience Monitoring Eine Frage des Blickwinkels Heutige Geschäftsprozesse sind eingebettet in einen globalen Markt mit Teilnehmern auf der ganzen Welt die Forderung nach höchster Verfügbarkeit und Performance von jedem Ort der Welt is längst nicht nur mehr eine Herausforderung für große Unternehmen. SAP End-User Experience Monitoring (EEM) ist ein effizientes Werkzeug, um dieser Aufgabe gewachsen zu sein. Inhalt Einleitung... 1 Zuverlässige automatisierte Messung... 2 E2E Trace Analyse... 2 Echtzeit Monitoring... 3 Alerting Infrastruktur... 4 Reporting... 4 Weiterführende Informationen... 5 EINLEITUNG Der Begriff End User Experience Monitoring ist im IT-bezogenen Kontext fest belegt für Verfahren, die eine Aussage über die wirkliche Benutzbarkeit von Datenverarbeitungssystemen aus Anwendersicht zurückmelden. Benutzbarkeit wird in diesem Zusammenhang meist über die Begriffe Verfügbarkeit und Leistungsfähigkeit definiert und meint nichts anderes als die Möglichkeit, eine gestellte Aufgabe inhaltlich korrekt und in hinreichend kurzer Zeit erledigen zu können. Dem Anspruch, die wirkliche Benutzbarkeit widerzuspiegeln, werden diese Verfahren gerecht, indem sie Daten möglichst dicht auf Seite der Systembenutzer erheben, also fernab der Serverräume. Diese Vorgehensweise mutet zunächst ungewohnt an und man entfernt sich damit als IT Verantwortlicher scheinbar allzu schnell von vertrautem Terrain: Schließlich war man ja in der Vergangenheit stets bemüht, durch das Sammeln tausender technischer Messwerte den guten Zustand eines Datenverabeitungssystems lückenlos zu dokumentieren. Mit Blick auf Laplace galt die Maxime, immer mehr Daten in immer kürzeren Messintervallen zu erheben, um das System immer vollständiger zu beschreiben. Leider drängt bereits eine flüchtige Durchsicht der Supportkomponente den auch in der Physik längst überholten Determinismus in den Bereich der Bedeutungslosigkeit. Ungerührt von der Vielfalt verfügbarer Messwerte urteilen die Endanwender über ihr Datenverarbeitungssystem schlicht in den Kategorien Geht nicht! und Ist langsam Begrifflichkeiten also, die sich exakt mit den beim End User Experience Monitoring betrachteten Aspekten Verfügbarkeit und Leistungsfähigkeit zur Deckung bringen lassen. Der Gedanke, direkt das zu messen und zu belegen, was vom Anwender bzw. Kunden nachgefragt und verstanden wird, ist also nicht abwegig. Für technische Umsetzungen gibt es im Wesentlichen zwei unterschiedliche Ansatzpunkte: Die naheliegende Methode versucht, vereinfacht gesprochen den Anwendern über die Schulter zu schauen und Messdaten über die beobachteten Transaktionen an einen zentralen Auswertungsserver zu senden. Je nach Konfiguration und Hersteller kann dies permanent (Monitoring-Fall) oder nur im Fehlerfall zur Analyse geschehen. Um dem Verdacht der Mitarbeiterkontrolle entgegen zu wirken, bieten diese Lösungen diverse ausgeklügelte Anonymisierungs- und Sicherheitseinstellungen. Wenn bei Ihnen der bittere Nachgeschmack trotzdem nicht weichen will oder sie um

2 die breite Akzeptanz einer solchen Messinfrastruktur in ihrer Firma fürchten müssen, gibt es einen alternativen Ansatz, der darüber hinaus entscheidende technische Vorteile mit sich bringt. ZUVERLÄSSIGE AUTOMATISIERTE MESSUNG Der von SAP End User Experience Monitoring (EEM) gewählte Weg verzichtet auf menschliche Nutzer als Datenquelle und stützt sich stattdessen auf ein Netzwerk künstlicher Helfer, die in den jeweiligen Regionen vor Ort Transaktionen ausführen und dabei Verfügbarkeit und Leistungsfähigkeit der genutzten Datenverarbeitungssysteme zum SAP Solution Manager melden. Diese EEM Robots genannten Helfer werden auf preiswerte Desktoprechner installiert und agieren in der Systemlandschaft wie echte Mitarbeiter oder Kunden. Sie rufen Portalseiten auf, prüfen Warenkörbe, durchsuchen Datenbanken und füllen SAPGUI Formulare, denn die dazu ausgeführten Skripte wurden durch das Aufzeichnen eben dieser eigentlich menschlichen Nutzern vorbehaltenen Tätigkeiten aufgezeichnet. Auf Systemseite sind die Aktivitäten der EEM Robots daher völlig unauffällig und kaum von denen normaler Benutzer zu unterscheiden. Sie werden gleichberechtigt ausgeführt, sind also eine repräsentative Messgröße. Wie die Namensgebung EEM Robots nahelegt, sind es die Vorteile, die eine automatische Lasterzeugung mit sich bringt, die den nicht zu verschweigenden initialen Aufwand der Skriptaufzeichnung mehr als aufwiegen. Einem Industrieroboter gleich führen die EEM Robots unbeirrt ihre Tätigkeit aus ohne je zu ermüden, ohne Flüchtigkeitsfehler, ohne Freizeit. Statt auf ein zukünftiges Problem zu warten, können sie als Verantwortlicher Transaktionen lückenlos proaktiv beobachten, selbst wenn in der entsprechenden Region gerade kein realer Anwender die Funktionalität nutzt. Sei es nun wegen der fortgeschrittenen lokalen Tageszeit oder weil die Transaktion nur selten, dann aber sehr dringend gebraucht wird. So sparen Sie im Ernstfall wertvolle Zeit und abhängig vom Fehler ist die Anwendung wieder produktiv, bevor die Kollegen aus Übersee aufstehen und das Frühstück beginnen. Ein wesentlicher Vorteil der Robotstrategie ist die Reproduzierbarkeit der Skriptausführungen und die daraus entstehende Vergleichbarkeit einzelner Ausführungen lokal untereinander oder überregional ausgehend von verschiedenen Robots als Datenquelle. Damit lässt sich vergleichsweise einfach einschätzen, ob ein Problem lokal begrenzt, also nur aus einer Lokation beobachtbar ist oder ob der Geschäftsablauf global bei allen EEM Robots und daher eher auf Seite des zentralen Datenverarbeitungssystems gestört ist. Sie betrachten also das Verhalten eines bestimmten Skripts für eine Vielzahl von EEM Robots. Der umgekehrte Ansatz mit dem Blick auf einen bestimmten Robot und die dort ausgeführten verschiedenartigen Skripte, macht es einfach, ein generisches Netzwerkproblem von spezifischeren Ursachen zu unterscheiden. Sind gleich mehrere von einander inhaltlich disjunkte Skripte von Ausfällen betroffen, braucht es keine prophetischen Fähigkeiten, eine gemeinsame und eher technische Ursache in der Filiale zu vermuten. Wie Sie sehen liefert SAP End User Experience Monitoring also schon allein durch die verteilte Messanordnung und einfache Statusvergleiche wichtige Hinweise zur Fehlerursache, ohne dass dazu eine tiefere Kenntnis der Skriptabläufe genutzt wurde. Im EEM RealTime Monitoring werden darüber hinaus natürlich Einzelschritte zu Skripten und detaillierte Fehlermeldungen zu jedem Schritt angezeigt. So lässt sich nicht nur der ausgeführte Geschäftsprozess als Ganzes, sondern auch Teilschritte gesondert nach den Kriterien Verfügbarkeit und Leistungsfähigkeit bewerten und analysieren. Vereinfacht gesprochen repräsentiert das Skript also eine Geschäfts-Transaktion und der Skriptschritt eine Benutzerinteraktion wie etwas das Drücken eines Buttons oder das Füllen einer Anfragemaske durch den Benutzer bzw. Robot. Das Wissen, bei welchem Schritt ein Skript mit welchen Fehlerstatus ausgeführt wurde, grenzt die Vielfalt der möglichen Ursachen erheblich ein. Quittiert das System den ersten Schritt mit Wrong Password or Username gibt es wahrscheinlich Naheliegenderes als eine intensive Prüfung von Sperrtabellen oder Heapdumps zur Fehlersuche. E2E TRACE ANALYSE Leider sind die Erwartungen an eine ideale Geschäftstransaktion für den produktiven menschlichen Benutzer und End User Experience Monitoring diametral verschieden. Um eine optimale Auswertbarkeit zu realisieren, ist es aus EEM-Sicht wünschenswert, möglichst kleinschrittig und linear voranzuschreiten. Je besser sie Teilaufgaben in separaten Schritten voneinander abgrenzen können, desto leichter lässt sich mit dem Finger auf eine bestimmte Komponente deuten, die für eine Störung verantwortlich zeichnet. Eine anwenderfreundliche Applikation hingegen wird in der Bestrebung Komplexität vom Benutzer fernzuhalten aufgebaut sein und möglichst viele Aktivitäten im Sinne des Anwenders im Hintergrund ausführen. Diese digitale Entsprechung zu Aladins Wunderlampe ist für das reine End User Experience Monitoring ein Alptraum: Ein Mouseklick und alles geschieht wie von Geisterhand im Hintergrund. Ein einziger Tastendruck löst eine Kaskade von Aktivität und hektischer

3 Betriebsamkeit im Hintergrund aus: Dutzende RFC-Verbindungen zu diversen Datenbanken und Systemen werden benutzt, Daten werden konsolidiert, Vorgänge warten auf Workprozesse, Sperreinträge werden geschrieben und gelöscht. Aus Sicht des Benutzers und damit leider auch aus der Perspektive des EEM Robots dreht sich nur monoton die Sanduhr, bis das Ergebnis angezeigt wird. oder auch nicht. Die Messwerte, die der EEM Robot in dieser Situation an den SAP Solution Manager schicken kann, sind also wahrscheinlich wenig hilfreich, um das Problem weiter einzukreisen. Es mag Sie an dieser Stelle trösten, dass die Messung eine lokalisierte, objektive Quantifizierung des Engpasses ermöglicht und diese Information proaktiv bereitstellt wird, noch bevor ein realer Anwender das Problem melden musste. Eine wirklich befriedigende Lösung muss jedoch einen Schritt weiter gehen, hinter den Vorhang schauen und die verborgenen Vorgänge hinter den Kulissen beleuchten. SAP End User Experience Monitoring nutzt dazu die SAP-Passport- Technologie, die auch von der End-to-End-Trace- Analyse verwendet wird. Jeder Nachricht, die vom EEM Robot zum Datenverarbeitungssystem geschickt wird, wird ein sogenannter SAP-Passport angefügt. Der SAP- Passport enthält eine eindeutige Identifikationsnummer und Angaben darüber, welche Informationen die Gegenstelle während der Verarbeitung der eigentlichen Anfrage für Analysezwecke aufbewahren soll. Muss die Verarbeitung auf einer anderen Komponente im Hintergrund fortgesetzt werden, so wird der SAP-Passport zusammen mit der Anfrage weitergereicht und die dortigen Systeme werden angewiesen, ebenfalls Informationen über die Abarbeitung aufzubewahren. Um im Bild zu bleiben: Der Robot vermag zwar noch immer nicht selbst hinter den Vorhang zu blicken, ist nun aber in die Lage versetzt, eine Visitenkarte darunter hindurchschieben zu können. Darauf die Bitte, über Tätigkeiten hinter den Kulissen Buch zu führen und alle Beteiligten durch Mund-zu-Mund-Propaganda von diesem Vorgehen zu unterrichten. Im RealTime Monitoring wird daher zunächst die Ausführung eines Skripts samt zugeordneten Schritten durch einen EEM Robot gemeldet und wie zuvor schlicht nach Verfügbarkeit und Leistungsfähigkeit bewertet. In einem nachgelagerten Vorgang werden von Seiten des SAP Solution Managers die beteiligten Einzelkomponenten des Datenverarbeitungssystems angesprochen und die dort abgelegten Informationen passend zur jeweiligen SAP-Passport- Identifikationsnummer abgefragt. Das RealTime Monitoring UI zeigt nun mehr Details zu den einzelnen Skriptschritten und listet zum Beispiel beteiligte SAP-Systeme, RFC-, Client- und HTTP- Zeiten auf. Spätestens mit dem Absprung in die End-to-End-Trace-Analyse per Mausklick hebt sich der Vorhang zur Gänze und ein Engpass lässt sich abhängig von der konfigurierten Detailstufe z. B. durch ABAP-, Wily- oder SQL-Traces genauestens analysieren. Um sich nicht zwischen minimaler Beeinflussung des Datenverarbeitungssystems durch das Tracen und tiefgehender Analysemöglichkeit entscheiden zu müssen, bietet SAP End User Experience Monitoring ihnen drei Möglichkeiten, die Detailstufe im Bedarfsfall anzuheben. Sie können jederzeit ein Skript einmalig mit frei konfigurierter Detailstufe erneut manuell ausführen, ohne dabei die reguläre Ausführungskonfiguration dauerhaft zu verändern. Es ist aber auch möglich, die Detailstufe für eine festgelegte Zeit zu erhöhen, bevor das Skript automatisch wieder auf die Normaleinstellungen zurückkehrt. Die dritte Variante sorgt im Falle einer gemessenen Laufzeitüberschreitung automatisch für eine sofortige Wiederholung der Messung mit frei konfigurierbarer Detailstufe. Die beiden letztgenannten Methoden sind besonders gut geeignet, sporadisch auftretenden Phänomenen auf den Grund zu gehen, die sich selten gezielt reproduzieren lassen und gewöhnlich auf Anwender- wie Supportseite Frustration auslösen. Wer kennt das nicht? Der berühmte Vorführeffekt sorgt zunächst dafür, dass Anwender Überzeugungsarbeit leisten müssen, bis ein Problem glaubhaft gemacht werden kann. Der mühsam bekehrte Verantwortliche führt die Transaktion dann wieder und wieder erfolgreich und performant aus, während zeitgleich mehr und mehr gleichartige Beschwerden auflaufen. Mit SAP End User Experience Monitoring übernimmt der EEM Robot die mühsame Detektivarbeit und meldet seine Erkenntnisse ins RealTime Monitoring. ECHTZEIT MONITORING Das RealTime Monitoring UI ist die zentrale Analyseplattform für End-User Experience-Monitoring- Daten. Die Adobe-Flash-basierte Applikation ist über das Technical Monitoring Workcenter erreichbar und besteht im wesentlichen aus Registerkarten, die eine ausgewählte Gruppe von Skriptausführungen in bestimmten Lokationen über einen gewissen Zeitraum vom Solution Manager abfragen. Einfacher ausgedrückt: Sie legen jeweils fest, welche Skripte sie interessieren, für welche Robots im Fokus sind und wie weit sie in die Vergangenheit schauen möchten. Im nächsten Schritt entscheiden sie über die Darstellung der angeforderten Daten, indem sie eine oder mehrere Ansichten (Neudeutsch: Apps) für die Registerkarte auswählen. Es stehen diverse Varianten zur Auswahl, darunter Baumstrukturen, Tortendiagramme, Kurven und Kachelansichten. Abhängig von der Aufgabenstellung sind diese unterschiedlich gut geeignet, einen Überblick zu

4 vermitteln oder verschiedene Ausführungen im Detail zu vergleichen. Allen gemeinsam ist jedoch, dass sie stets auf den in der Registerkarte angeforderten Daten operieren. Sie zeigen also stets dasselbe, aber bringen es andersartig zur Anzeige. Liegt der angeforderte Datenbestand nicht mehr im lokalen Datenpuffer, fordert das RealTime Monitoring UI verdichtete Daten aus dem Business Warehouse an. Ein schneller Blick auf die Daten des letzten Jahres zwingt daher nicht direkt zum Wechsel in eine ungewohnte BW- Webtemplate-Umgebung. Die Möglichkeiten und Arbeitsabläufe im RealTime Monitoring UI sind vielfältig, aber meist intuitiv zu erlernen. Einen ersten Eindruck vermittelt die lauffähige Demoversion unter: ALERTING INFRASTRUKTUR Die Benutzbarkeit von Geschäftsvorgängen in Echtzeit global zu beobachten und im Bedarfsfall eine tiefgreifende technische Analyse durchführen zu können, ist eine faszinierende Möglichkeit. Wer sich jetzt allerdings in den Kontrollraum der Mondmissionen versetzt fühlt, der wird schnell enttäuscht sein, denn auch wenn das RealTime Monitoring ansprechend und funktional ist, wird es nicht rund um die Uhr im Fokus der Aufmerksamkeit stehen und nur selten der initiale Zugang zum End User Experience Monitoring sein. Im Regelfall wird man die EEM Robots im Hintergrund ihre Aufgabe verrichten lassen, während man sich wichtigeren Themen widmet. Dabei können sie sich auf die Alerting-Infrastruktur des Solution Manager 7.1 verlassen. Sollte ein EEM Robot unerwartet hohe Antwortzeiten messen oder funktionale Defizite aufdecken, wird ein Alertereignis in der Unified Alert Inbox hinterlegt, der Verantwortliche per SMS oder informiert und je nach Konfiguration optional ein Incident erzeugt. Ein direkter Absprung ins RealTime Monitoring erleichtert dann eine umgehende Untersuchung. Nebenbei verhindert ein durchdachter Algorithmus, dass ein bereits gemeldetes Problem, dessen Lösung noch etwas Zeit benötigt, mit einem konstanten Strom an Alertereignissen und SMS zu viel Aufmerksamkeit auf sich zieht und andere Ereignisse schlicht überdeckt. REPORTING Die finale Datensenke im SAP Solution Manager 7.1 ist das Business Warehouse und so werden auch EEM-Daten aus dem lokalen Datenpuffer früher oder später in verdichteter Form im BW abgelegt. Über das RealTime Monitoring und diverse BW-Webtemplates im Interactive Reporting bekommen Sie Zugriff auf diese Übersichtsdaten. Die Bewertungskriterien, ob es sich bei gemessenen Antwortzeiten um Erwartungswerte oder kritische Schwellwertüberschreitungen handelt, wird dabei streng aus der Konfiguration für das Alerting übernommen. So entspricht das Berichtswesen exakt den angezeigten Daten der Monitoring- Applikation. Soll das BW allerdings für die Nachweisführung im Rahmen einer Dienstgütevereinbarung (engl. Service Level Agreement, kurz: SLA) herangezogen werden, kommt man mit dieser Schwellwertphilosophie schnell in einen Interessenkonflikt. Auf der einen Seite sind die Schwellwerte und die damit verbundenen Alerts wichtige Indikatoren, um einen Schiefstand frühzeitig zu erkennen und diesen womöglich noch vor einer wirklich kritischen Marke zu beheben. Auf der anderen Seite legt die Dienstgütevereinbarung die Schwellwerte exakt fest und reduziert die Vorwarnzeit damit auf nahe Null. Den Ausweg bietet hier ein unabhängiger Satz Schwellwerte für Dienstgütevereinbarungen im SAP End User Experience Monitoring und ein zusätzliches vom Interactive Reporting disjunktes Berichtswesen. Dies ermöglicht eine angemessene Vorwarnzeit durch sinnvolles Alerting bei gleichzeitig exaktem Berichtswesen für die Dienstgütevereinbarung. Exakt meint in diesem Zusammenhang auch, dass eine Vereinbarung entweder eingehalten oder gebrochen wurde und daher nur ein Schwellwert definiert werden muss, der diese Grenze eindeutig definiert.

5 Zur Anzeige der erhobenen SLA-Daten wird eine SAP-Excelsius basierte Applikation genutzt, die sich auf die Darstellung relevanter Kerndaten beschränkt. Mit einem Blick lässt sich so jeweils für die Kategorien Verfügbarkeit und Leistungsfähigkeit ablesen in wie viel Prozent der Fälle die definierten Schwellwerte eingehalten wurden. Anhand der Farbgebung grün oder rot ist ersichtlich, ob diese Prozentwerte den Vorgaben der Gütevereinbarung entsprechen. Zusätzlich werden die Daten der Vormonate grafisch zur Anzeige gebracht. Eine detaillierte Kenntnis der zugrundeliegeden Schwellwertsätze und Mechanismen ist zur Interpretation nicht mehr notwendig. Ursachenforschung und die Suche nach administrativen Gegenmaßnahmen bleiben alleine dem Bereich RealTime Monitoring und End-to- End Trace vorbehalten. Das Berichtswesen im Bereich Dienstgütevereinbarung richtet sich damit primär an externe bzw. interne Kunden einer IT- Lösung, die technischen Hintergründen nur bedingt Interesse entgegen bringen, solange die Benutzbarkeit gewährleistet und belegt werden kann. WEITERFÜHRENDE INFORMATIONEN Wenn Sie neugierig geworden sind, finden Sie hier weitere Informationen: End User Experience Monitorin im SDN: Technical Operations im SDN Application Lifecycle Management allgemein