Service Operation mit ITIL

4.296 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
4.296
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
183
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Service Operation mit ITIL

  1. 1. Service Operation mit ITIL Christian Habermüller chabermu.wordpress.com 5tes AdminCamp, 20.-22. Sept. 2010, Gelsenkirchen 1 /55
  2. 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 20000 2 /55
  3. 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 /55
  4. 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 /55
  5. 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 /55
  6. 6. Service aus zwei Perspektiven betrachtet • IT-Perspektive • Geschäfts-Perspekt' • Versprechen, was • Liefern, was geht gebraucht wird – Stabilität – Reaktionsfreudigkeit – Qualität – Kosten – Reaktives Handeln – Proaktives Handeln 6 /55
  7. 7. Prozesse & Funktionen in Service Operation • Prozesse • Funktionen – Event Mngmt – Service Desk – Incident Mngmt – Technical Mngmt – Problem Mngmt – IT Operations Mngmt – Request Fulfillment – Applications Mngmt – Access Mngmt 7 /55
  8. 8. Prozesse 8 /55
  9. 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 /55
  10. 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 /55
  11. 11. Prozess Event Management 11 /55
  12. 12. Definition Event Ein Event ist eine Benachrichtigung aufgrund einer Statusänderung durch einen Service, einen Configuration Item oder einen Monitoring Tool. 12 /55
  13. 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 /55
  14. 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 /55
  15. 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 /55
  16. 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 /55
  17. 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 /55
  18. 18. Prozess Incident Management 18 /55
  19. 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 /55
  20. 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 /55
  21. 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 /55
  22. 22. Auswirkung angestrebte Priorität Lösungszeit Dringlichkeit Auswirkung / Schaden Lösungs- Prio Hoch Mittel Niedrig zeit Dringlichkeit Hoch 1 < 1h 2 < 8h 3 < 24h Mittel 2 < 8h 3 < 24h 4 < 48h Niedrig 3 < 24h 4 < 48h 5 Planung 22 /55
  23. 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 /55
  24. 24. Major Incident erfordert ... • … eine Vereinbarung, was ein solcher ist ! • Separate Prozeduren – Kürzere Zeiten – Höhere Dringlichkeit – evtl. Major Incident Team erforderlich 24 /55
  25. 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 /55
  26. 26. Prozess Problem Management 26 /55
  27. 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 /55
  28. 28. Zwei Problem Management Prozesse • Proaktiv • Reaktiv – Vorausschauend vor – Reaktion beim dem Auftreten Auftreten – Teil des Continual – Aufgabe des Problem Service Improvment Management – Initiiert in Service – Teil der Service Operation Operation 28 /55
  29. 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 /55
  30. 30. Prozess Request Fulfillment 30 /55
  31. 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 /55
  32. 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 /55
  33. 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 /55
  34. 34. Prozess Access Management 34 /55
  35. 35. Ziele Access Management • Steuern der Rechte- & Zugriffe der Anwender • Ausführen von Richtlinien & Aktionen – Aus dem Security Management – Aus dem Availability Management 35 /55
  36. 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 /55
  37. 37. Funktionen 37 /55
  38. 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 /55
  39. 39. Funktion Service Desk 39 /55
  40. 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 /55
  41. 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 /55
  42. 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 /55
  43. 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 /55
  44. 44. Funktion Technical Management 44 /55
  45. 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 /55
  46. 46. Funktion Applications Management 46 /55
  47. 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 /55
  48. 48. Funktion IT Operations Management 48 /55
  49. 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 /55
  50. 50. Überlappende Zuständigkeiten 50 /55
  51. 51. 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 /55
  52. 52. 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 /55
  53. 53. 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. 54 /55
  54. 54. 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. 55 /55

×