Anwendungsmetriken im IT Service Management

Transkript

1 Anwendungsmetriken im IT Service Management Juergen Moors, Senior Sales Consultant Copyright 2006 Quest Software Ich Jürgen Moors Jahrgang 1965 Mit der IT befasst seit 1983 Senior Presales Consultant bei Quest Software Stationiert in Köln, aber nur selten im Büro Spezialisiert auf Anwendungstuning und IT-Anwendermonitoring Zertifiziert auf ITIL V3

2 Zielübung Copyright 2006 Quest Software Metriken sollen die ITSM-Prozesse unterstützen verständlich sein ohne große Kosten / Overhead erhoben werden Nachvollziehbarkeit gewährleisten die Grundlage für Planung darstellen die Grundlage für Berechnung und Verrechnung bilden vorbeugend warnen aussagekräftige Berichte ermöglichen: Status der Anwendung / Services darstellen Einhaltung von SLA und OLA aufzeigen Änderungen in den Anwendungen sichtbar machen Abfallprodukt: Die Metriken sollen im Fehlerfall die Diagnose und Analyse vereinfachen

3 Ansatz Copyright 2006 Quest Software Metrik-Stack Monitoring Diagnose, Analyse Daten Regeln Andere Metriken Berichtswesen SKMS Metriken

4 Welche Metriken sollen erfasst werden? Service-Messung (ungefähr = Anwendungsmonitoring) Technische Bestandteile des Services (Methoden, SQL) Infrastruktur des Services (DB, App. Srv.) Hardware (CPU, RAM, Netzwerk) Eindruck der Anwender (HTTP-Verkehr) OLA (Antwortzeit im Vergleich zum OLA) SLA (Antwortzeit im Vergleich zum SLA) Zu beachten: Das Tool, welches das Monitoring durchführt, soll die Daten direkt in Informationen umwandeln! Quest Software: Foglight 5 Metriken - Grundsätzliches Jeder Bereich hat seine individuellen Metriken Metriken müssen auf den Empfänger abgestimmt sein sonst droht Daten-Spamming Nur die Metriken erheben, die wirklich notwendig sind Messen kostet Overhead und das Lesen der Metriken ihre Zeit! Wenn Metriken nur im Kontext sinnvoll sind, dann den Kontext herstellen Alle 6 Monate die Notwendigkeit der Metriken in Frage stellen (CSIP!) Metrik- und Berichtgenerierung muss automatisiert sein

5 Benötigte Granularität Bis auf Objektebene? Es kann nur eine Antwort geben: Bis auf Methoden-/SQL-Ebene? Je nach Bedarf! Bis auf Serviceebene? Bilder von oben nach unten: Quest Software JProbe PerformaSure Foglight Benötigte Granularität Service- / Anwendungsmonitoring Kompromiss: Messen auf Methoden-/SQL-Ebene Tiefer messen kostet zuviel Overhead Grobere Messungen sind nicht detailliert genug zur Erfassung von Services, zur Diagnose, usw. Lösungsvorschlag: In der Produktion bis auf Methoden-/SQL-Ebene messen, in der Entwicklungsumgebung kann bei Bedarf tiefer gemessen werden.

6 Benötigte Abstraktion Natürlich: Auf Serviceebene Auf Anwendungsebene Auf Kundenebene Auf Zeitebenen (Jahr, Quartal, Monat, Woche, Tag) Auf Lieferantenebene Lösungsvorschlag (1) Ein Monitoring-Werkzeug, in das sich externe Quellen über standardisierte Schnittstellen einfach einbinden lassen, Sie haben ein Monitoring-Tool? welches über eine eigene Reporting-Engine verfügt und Aber das hat keine brauchbaren Schnittstellen und keine Reporting-Engine? ein ausgefeiltes Nutzer- und Rollenkonzept beinhaltet. Quest Software: Foglight 5

7 Lösungsvorschlag (2) Es gibt diverse Hersteller, die einen an ITSM ausgerichteten Reporting-Aufsatz auf bestehende Systeme anbieten. Q to be: QBoard Lösungsvorschlag (3) Welchen Ansatz Sie auch immer wählen Wichtig ist, dass eine Alarmierungskomponente enthalten ist Mit Berichte der automatisch Akzeptanz generiert der werden Anwender jeder Nutzer steht die Informationen und fällt so präsentiert der bekommt, dass er sie versteht Erfolg des Systems jeder Nutzer die Informationen so präsentiert bekommt, wie er sie braucht jeder Nutzer NUR die Informationen bekommt, die er braucht

8 Problemfälle (1) Virtualisierung: LPars, Zones, VM-Ware Falsche OS-Werte Kein Zugriff in die virtualisierte Zone Kein Support durch Dritthersteller (Monitoring-Tools, etc.) Sicherheitsleck Quest Software: Foglight 5 Problemfälle (2) Präsentation der Metriken Dem Nutzer angepasst: So viel, so oft, so genau und so ungenau wie nötig Metriken immer gehirngerecht präsentieren Quest Software: Foglight 5

9 Problemfälle (3) Manuelle Berichtgenerierung ITSM verlangt viele Berichte, die automatisch erstellt werden sollten. Manuelle Interaktion erlaubt vermeidbare Fehler und erhöht den Arbeitsaufwand Automatische Berichtsgenerierung ist ein Muss! Berichte sind organisch. Sie sollen sich den wechselnden Anforderungen anpassen Problemfälle (4) Daten aus unterschiedlichen Systemen Eine Metrik eindeutig definieren und nur einmal aus einem (Monitoring-) System in die Datenbank einspeisen Quest Software: Foglight 5

10 Metriken Copyright 2006 Quest Software Buchtip (1) Metrics for IT Service Management 202 Seiten, davon ca. 50% Metriken mit Beschreibung für IT Service Management Van Haren Publishing ISBN:

11 Buchtip (2) Die ITIL-Bücher In den Büchern finden sich immer wieder kleine Abschnitte mit KPIs Datenquellen Anwendungen (Siebel, SAP, etc.) Infrastruktur-Software (DB, AppSrv, WebSrv, etc.) Infrastruktur-Hardware (CPU, RAM, Netzwerk, etc.) Organisationen (Betrieb, CAB, Service Desk, etc.) Verwaltungsprozesse (i. d. R. Daten aus der Anwendung, die ITILProzesse IT-technisch abbildet) Funktionen (Feedback von Service Managern, Change Managern, etc.)

12 Welche Metriken sollen erfasst werden? Service Strategy Prozentsatz der IT-Kosten für bestimmte Aggregate (Service, Kunde, Anwendung, ) [!] TCO der IT [!] Beantragte Änderungen bez. auf bestehende Services [n] Return of Investment für bestimmte Aggregate (Service, Kunde, Anwendung, ) [!] Verhältnis definierte / analysierte / genehmigte / genutzte (im Portfolio befindliche) Services [n] Anzahl erfüllter Anforderungen pro Service [n / Servicename] Servicekosten / vorrausichtliche Lebensdauer [! / Monat] Anzahl Geschäftsprozesse / Service [n] Wichtigkeit eines Services für den Besteller [n] ROI des Services erreicht [Boolean] Welche Metriken sollen erfasst werden? Service Design Sämtliche Kapazitäten der Service-Infrastruktur mit historischer Entwicklung (CPU-Last, Festplattenkapazität, Netzwerklast, ) [%] Verfügbarkeiten der Services und relevanter CIs [%] Verhältnis der Services im Portfolio / im Katalog / in Nutzung [%] Anzahl gelöster Sicherheitsprobleme [n] Realisierungszeit sicherheitsrelevanter Änderungen [Minuten] Zeit vom Auftreten bis zur Erkennung von Zwischenfällen [Minuten] Antwortzeit auf sicherheitsrelevanter Zwischenfälle [Minuten] Erfüllung der Anforderungen pro Supplier [n / Suppliername] Zwischenfälle pro Supplier [n / Suppliername] Übererfüllung der Anforderungen und Kapazitäten von CIs [%] Risikofaktor eines Services [%] Wirksamkeit der Maßnahmen zur Verhinderung des Serviceausfalls [%]

13 Welche Metriken sollen erfasst werden? Service Transition Anteil umgesetzter Services zur Anzahl umzusetzender Services [%] Anteil Services im geplanten Rahmen zur Anzahl Services außerhalb des geplanten Rahmens [%] Historische Entwicklung der Zwischenfälle bezogen auf Planung und Verzögerung bei der Serviceeinführung im Verhältnis zu allen Zwischenfällen [%] Anzahl Änderungen im Monat für überführte Services [n / Monat] Verhältnis fehlgeschlagener Änderungen zu allen Änderungen [%] Anzahl zurückgewiesener Änderungen [n] Verhältnis Notfall-Änderungen zu allen Änderungen [%] Verhältnis ungetesteter Releases zu allen Releases [%] Anzahl Zwischenfälle je Release [n / Releasebezeichnung] Dauer Service-Bestellung bis Service-Verfügbarkeit [Tage] Welche Metriken sollen erfasst werden? Service Operation Anzahl Events, Incidents, Service Requests pro Monat [n / Monat] Zeit zur Klärung der Zuständigkeit für Events, Incidents, Service Requests [Minuten] Zeit bis zur Lösung von Events, Incidents, Service Requests [Minuten] Anzahl definierter Probleme Anzahl verschiedener Nutzer, die einen Events, Incidents, Service Requests melden [n / Monat] Verhältnis Events, Incidents, Service Requests zu Änderungen pro Monat [%] Anzahl Events, Incidents, Service Requests pro Service im Jahr [n] Anzahl gelöster Events, Incidents, Service Requests mit Hilfe der Wissensdatenbank Anzahl Lösungen in der Wissensdatenbank [n]

14 Welche Metriken sollen erfasst werden? Continual Service Improvement Zufriedene Kunden in verschiedenen Aggregaten (je Service, Lösungszeit Helpdesk, etc.) im Verhältnis zu allen Kunden je Monat [% / Monat] Kosteneinsparung durch SIP [%] Verhältnis der genehmigten Änderungen im Service Management zu den beantragten Änderungen im Service Management [%] Verhältnis aller Verbesserungsvorschläge zu den Vorschlägen eingereicht von Personen außerhalb des SIP [%] Weitergeleitete Änderungsvorschläge pro Monat [n / Monat] Verhältnis im Vorjahr verwendete Berichte zu in diesem Jahr unverändert weiter verwendeten Berichten [%] Anzahl verbesserter Metriken herbeigeführt durch das CSIP [n] Verhältnis erreichte Ziele zu gesetzten Zielen des CSIP [%] Verhältnis aller Änderungen zur Anzahl Änderungen, die nicht umgesetzt werden konnten [%] Anwendungsmetriken im IT Service Management Juergen Moors, Senior Sales Consultant juergen.moors@quest.com Copyright 2006 Quest Software