1 55/

Service Operation mit ITIL

Christian Habermüllerchabermu.wordpress.com

5tes AdminCamp, 20.-22. Sept. 2010, Gelsenkirchen

2 55/

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 20000

3 55/

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 !

4 55/

Ziele und Anliegen inService Operation

• Lieferung von Service an den Kunden bzw. seine Anwender

• Verwalten der Bereitstellungsprozesse• Verwalten der zugrunde liegenden

Technologien• Messen & Überwachen

5 55/

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

6 55/

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

7 55/

Prozesse & Funktionen inService Operation

• Prozesse– Event Mngmt– Incident Mngmt– Problem Mngmt– Request Fulfillment– Access Mngmt

• Funktionen– Service Desk– Technical Mngmt– IT Operations Mngmt– Applications Mngmt

8 55/

Prozesse

9 55/

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.

10 55/

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.

Definition Rolle

11 55/

Prozess Event Management

12 55/

Definition Event

Ein Event ist eine Benachrichtigung aufgrund einer Statusänderung durch einen Service,

einen Configuration Item oder einen Monitoring Tool.

13 55/

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 !

14 55/

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

15 55/

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 ?

16 55/

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

17 55/

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

18 55/

Prozess Incident Management

19 55/

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.

Definition Incident

20 55/

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.

21 55/

Definition Problem

Ein Problem ist die Ursache für einen oder mehrere Incidents.

Zum Zeitpunkt der Erstellung einesProblem Record ist die Ursache in der Regel

noch unbekannt.

Für die weitere Untersuchung ist der Problem Management Prozess verantwortlich !

22 55/

Auswirkung / Schaden

Hoch Mittel Niedrig

Dri

ng

lich

kei

t Hoch 1 < 1h 2 < 8h 3 < 24h

Mittel 2 < 8h 3 < 24h 4 < 48h

Niedrig 3 < 24h 4 < 48h 5 Planung

PrioLösungs-

zeit

Auswirkung

Dringlichkeit

PrioritätangestrebteLösungszeit

23 55/

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 !

24 55/

Major Incident erfordert ...

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

25 55/

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

26 55/

Prozess Problem Management

27 55/

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 !

28 55/

Zwei Problem Management Prozesse

• Reaktiv– Reaktion beim

Auftreten– Aufgabe des Problem

Management– Teil der Service

Operation

• Proaktiv– Vorausschauend vor

dem Auftreten– Teil des Continual

Service Improvment – Initiiert in Service

Operation

29 55/

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

30 55/

Prozess Request Fulfillment

31 55/

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.

Definition Service Request

32 55/

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

33 55/

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 !

34 55/

Prozess Access Management

35 55/

Ziele Access Management

• Steuern der Rechte- & Zugriffe der Anwender

• Ausführen von Richtlinien & Aktionen– Aus dem Security Management– Aus dem Availability Management

36 55/

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

37 55/

Funktionen

38 55/

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 !

Definition Function

39 55/

Funktion Service Desk

40 55/

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

41 55/

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

42 55/

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

43 55/

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)

44 55/

Funktion Technical Management

45 55/

Ziele Technical Management

• Stabile technische Infrastruktur– Planung, Implementierung & Aufrechterhaltung

• Gut gestaltete technische Infarstruktur– Kosteneffizient– Hoch belastbar– unverwüstlich

• Optimaler Betriebszustand– Rasche Fehlerdiagnose & -lösung

46 55/

Funktion Applications Management

47 55/

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

48 55/

Funktion IT Operations Management

49 55/

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

50 55/

Überlappende Zuständigkeiten

52 55/

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

53 55/

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

54 55/

Diese Präsentation ist urheberrechtlich geschützt.

© 2010 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.

55 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.