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.
Top Related