Service Operation mit ITIL

Transkript

1 Service Operation mit ITIL Christian Habermüller chabermu.wordpress.com 5 tes AdminCamp, Sept. 2010, Gelsenkirchen 1/

2 Was ist ITIL? IT Infrastructure Library Internationaler de facto Standard im IT-Service Management Unabhängige Betrachtung von IT- Serviceleistungen Herstellerunabhängig nicht verbindlich aber genormt durch ISO/IEC /

3 Definition Service Ein Service erbringt für einen Kunden einen Mehrwert, indem er die Kundenziele unterstützt, verbessert oder überhaupt erst ermöglicht. Dabei muss der Kunden selbst keine Verantwortung für bestimmte Kosten und Risiken tragen! 3/

4 Ziele und Anliegen in Service Operation Lieferung von Service an den Kunden bzw. seine Anwender Verwalten der Bereitstellungsprozesse Verwalten der zugrunde liegenden Technologien Messen & Überwachen 4/

5 Aufgaben in Service Operation Notwendige Aktivitäten planen, Betrieb und Finanzierung sicherstellen Mit geeigneten Werkzeugen und Training Unvorhergesehenes mit ein rechnen Unvorhergesehene Störungen Unvorhergesehener Bedarf 5/

6 Service aus zwei Perspektiven betrachtet IT-Perspektive Versprechen, was geht Stabilität Qualität Reaktives Handeln Geschäfts-Perspekt' Liefern, was gebraucht wird Reaktionsfreudigkeit Kosten Proaktives Handeln 6/

7 Prozesse & Funktionen in Service Operation Prozesse Event Mngmt Incident Mngmt Problem Mngmt Request Fulfillment Access Mngmt Funktionen Service Desk Technical Mngmt IT Operations Mngmt Applications Mngmt 7/

8 Prozesse 8/

9 Definition Process Ein Process ist ein strukturierter Satz von Aktivitäten, der einen klar definierten Input zu einem oder mehreren klar definierten Outputs umwandelt. Er beinhaltet beliebig viele Rollen, Verantwortlichkeiten und Hilfsmittel und kann Richtlinien, Standards, Leitlinien, Aktivitäten und Arbeitsanweisungen definieren. 9/

10 Definition Rolle Eine Rolle wird in einem Process definiert und ist ein Satz von Verantwortlichkeiten, Aktivitäten und Kompetenzen, die einem Team oder einer Person zugewiesen sind. Einer Person oder einem Team können mehrere Rollen zugewiesen werden. 10/

11 Prozess Event Management 11/

12 Definition Event Ein Event ist eine Benachrichtigung aufgrund einer Statusänderung durch einen Service, einen Configuration Item oder einen Monitoring Tool. 12/

13 Ziele Event Management Informationen über Status der Infrastruktur Abweichungen von erwarteten Betrieb auf Basis von Service Level Agreements Event Management ist die Basis für Betriebsüberwachung & -steuerung! 13/

14 Arten von Events Information z.b. eine Aufgabe ist erledigt hat rein informative Zwecke Warning Der Service ist noch betriebsbereit aber erfordert ein Eingreifen Alert Der Service ist nicht mehr vollständig betriebsbereit 14/

15 Design für Event Management Wie können IT-Infrastruktur und IT- Services überwacht und beeinflusst werden? Wie wird überwacht? Wie werden Events erzeugt? Welche Schwellwerte sind notwendig? Welche Filter werden benötigt? 15/

16 Rollen in Event Management (1/2) Service Desk Üblicherweise nicht eingebunden lediglich Informationsstelle für Anwender IT Operations Management Wenn als separate Funktion vorhanden: Event Management ausführen 16/

17 Rollen in Event Management (2/2) Technical Management und Applications Management Während Design: Instrumentierung & Event- Klassifizierung Während Transition: Test der Event-Erzeugung Während Operation: Event Management ausführen 17/

18 Prozess Incident Management 18/

19 Definition Incident Ein Incident ist eine Qualitätsminderung oder eine ungeplante Unterbrechung eines Service. Auch ein Ausfall eines Configuration Item ohne bisherige Auswirkungen auf einen Service ist ein Incident. Beispiel: Der Ausfall einer einzelnen Festplatte in einem RAID5-Verbund. 19/

20 Definition Workaround Ein Workaround reduziert oder beseitigt die Auswirkungen von Incidents oder Problems, bevor noch eine vollständige Lösung vorhanden ist. Workarounds für Problems werden in Known Error Records dokumentiert, während Workarounds ohne Problem Records in Incident Records dokumentiert werden. 20/

21 Definition Problem Ein Problem ist die Ursache für einen oder mehrere Incidents. Zum Zeitpunkt der Erstellung eines Problem Record ist die Ursache in der Regel noch unbekannt. Für die weitere Untersuchung ist der Problem Management Prozess verantwortlich! 21/

22 Auswirkung Dringlichkeit Priorität angestrebte Lösungszeit Prio Lösungszeit Auswirkung / Schaden Hoch Mittel Niedrig Dringlichkeit Hoch 1 < 1h 2 < 8h 3 < 24h Mittel 2 < 8h 3 < 24h 4 < 48h Niedrig 3 < 24h 4 < 48h 5 Planung 22/

23 Definition Major Incident Ein Major Incident ist die höchste Kategorie eines Incident und führt zu einer erheblichen Unterbrechung des Business. Incidents dürfen nicht mit Problems verwechselt werden! 23/

24 Major Incident erfordert... eine Vereinbarung, was ein solcher ist! Separate Prozeduren Kürzere Zeiten Höhere Dringlichkeit evtl. Major Incident Team erforderlich 24/

25 Incident Management Messgrößen Gesamtzahl der Incidents Rückstand des Incidents Mittlere Zeit bis zur Lösung bzw. zum Workaround Prozentzahl der Incidents, die innerhalb der definierten Antwortzeit behandelt wurden Direktlösungsquote 25/

26 Prozess Problem Management 26/

27 Definition Known Error Ein Known Error ist ein Problem, für das die Ursache und ein Workaround dokumentiert wurde. Für die Erstellung und Verwaltung von Known Errors ist das Problem Management verantwortlich! 27/

28 Zwei Problem Management Prozesse Proaktiv Vorausschauend vor dem Auftreten Teil des Continual Service Improvment Initiiert in Service Operation Reaktiv Reaktion beim Auftreten Aufgabe des Problem Management Teil der Service Operation 28/

29 Rollen in Problem Management Problem Manager Prozessverantwortlicher und Verwalter der KEDB Schließt Problem Record Operative Problemlösungsgruppe Technischer Mitarbeiter Analyse, Diagnose kann bei speziellem Problem extra zusammengestellt werden 29/

30 Prozess Request Fulfillment 30/

31 Definition Service Request Ein Service Request ist eine Anfrage eines Anwenders nach Informationen, Beratung, einem Standard Change oder nach Zugriff auf einen Service. Service Requests werden in der Regel von einem Service Desk bearbeitet und erfordern üblicherweise nicht die Einreichung eines Request for Change. 31/

32 Ziele Request Fulfilment Information für Anwender Welche Services gibt es? Wie kann man diese nutzen? Anfragen nach Standard Services Beschaffung des Services & der dazugehörigen Komponenten 32/

33 Ein Service Request befasst sich nicht mit Incidents oder Changes! Vielmehr wird dabei ein vordefiniertes Vorgehen (Standard Change) durch den Anwender abgerufen, der mitunter vom Change Management vorab autorisiert wurde! 33/

34 Prozess Access Management 34/

35 Ziele Access Management Steuern der Rechte- & Zugriffe der Anwender Ausführen von Richtlinien & Aktionen Aus dem Security Management Aus dem Availability Management 35/

36 Begriffe im Access Management Access Umfang & Stufe des Service, zu deren Nutzung der Anwender berechtigt ist Identity Eindeutige Kennung zur Identifikation des Anwenders = Person oder Rolle Authority Berechtigungen, die einer Identity gegeben werden, um Access zu ermöglichen 36/

37 Funktionen 37/

38 Definition Function Eine Function ist ein Team oder eine Gruppe von Personen und deren Hilfsmittel, die eingesetzt werden, um einen oder mehrere Processes oder Aktivitäten durchzuführen. Eine Function ist also eine Einheit einer Organisation! 38/

39 Funktion Service Desk 39/

40 Ziele Service Desk Single Point of Contact Erste Informationsstelle für Anwender für Diagnosen & Nachforschungen Direkte Lösung, wenn möglich Wenn keine direkte Lösung in gegebener Zeit... dann Eskalation an entsprechendes Management Aufnahme & Abschließen von mit den dazugehörigen Records Incident und Problem Service Requests Access Requests 40/

41 Arten von Service Desks Lokaler Service Desk Ein Service Desk pro Firmenstandort Zentraler Service Desk Ein Service Desk für die gesamte Organisation Virtueller Service Desk Die Anfragen werden über ein System auf mehrere Service Desks verteilt Vor allem bei 24/7-Verfügbarkeit 41/

42 Messgrößen für Service Desk Erstlösungsrate Mittlere Lösungszeit (direkt) Mittlere Eskalationszeit Mittlere Service Desk Kosten pro Incident, pro Anruf, pro Minute etc. Kunden- und Anwenderzufriedenheitsumfragen 42/

43 Rollen in Service Desk Service Desk Analyst First Level Support Ansprechpartner für Anwender Service Desk Supervisor Schichtplanung Eskalationspunkt Service Desk Manager Generelle Verantwortung (nur bei großen Organisationen) 43/

44 Funktion Technical Management 44/

45 Ziele Technical Management Stabile technische Infrastruktur Planung, Implementierung & Aufrechterhaltung Gut gestaltete technische Infarstruktur Kosteneffizient Hoch belastbar unverwüstlich Optimaler Betriebszustand Rasche Fehlerdiagnose & -lösung 45/

46 Funktion Applications Management 46/

47 Ziele in Applications Management Funktionierende, stabile & verwaltbare Applikationen Anforderungen erkennen Design & Entwicklung unterstützen Fortlaufenden Support & Verbesserung liefern Rasche Fehlerdiagnose & -lösung Gut gestaltete Applikationen Kosteneffizient Features unterstützen Business Process 47/

48 Funktion IT Operations Management 48/

49 Ziele IT Operations Management Stabiler Betrieb des aktuellen Zustandes Betriebssteuerung & Anlagenwartung Überwachung der Ausführung von Betriebsaktivitäten & Events Verwaltung der physischen IT-Umgebung Regelmäßige Untersuchungen Stabilität aufrecht erhalten Kosten senken Service verbessern Schnelle Diagnose & Lösung bei Störungen 49/

50 Überlappende Zuständigkeiten 50/

51

52 Das ist IBM Lotus Notes Domino! (1/2) Teamfähige Kommunikations-Software Informationen werden nicht in Echtzeit ausgetauscht Intra-/Internet-Fähig Hochsicherheitssystem Für sensible Daten Dezentral in der Datenhaltung Daten können verteilt werden, auch Off-Line 52/

53 Das ist IBM Lotus Notes Domino! (2/2) Programmierbar IBM Lotus Notes Domino verfügt über 4 integrierte Programmierunterstützungen Formelsprache Lotus Script JavaScript Java Dokumentenorientiert Jeder Datensatz kann eine individuelle Datenstruktur haben 53/

54 Diese Präsentation ist urheberrechtlich geschützt Christian Habermüller Alle Rechte vorbehalten. Kein Teil dieser Präsentation darf ohne schriftliche Genehmigung des Autors in irgendeiner Form durch Fotokopie, Mikrofilm, Scannen, Download oder andere Verfahren reproduziert, gespeichert, wiedergegeben oder verbreitet werden. Insbesondere die Rechte der Wiedergabe durch Vortrag, Funk, Fernsehen und Internet sind dem Autor vorbehalten. Jede Zuwiderhandlung wird zivil- & strafrechtlich verfolgt. 54/

55 Diese Präsentation ist ausschließlich für den informativen Einsatzzweck gedacht und wird als diese ohne jegliche Garantie oder Gewährleistung bereitgestellt. Der Autor ist ausdrücklich nicht haftbar für mögliche Folgen oder mögliche Schäden, die durch die Verwendung des bereitgestellten Materials entstehen können oder könnten. Hinweise, Verweise oder Verknüpfungen bzw. Links in diesem Material unterliegen ebenfalls diesem Haftungsausschluß und sind Eigentum des jeweiligen Rechteinhabers. Die Rechte von geschützten Markennamen, Handelsmarken sowie alle weiteren Rechte unterliegen dem jeweiligen Rechteinhaber und bzw. oder des Eigentümers derselben. /