View
248
Download
2
Category
Preview:
Citation preview
Dipl.-Inform. Johannes Plötner
ITIL in der Praxis4. Secure Linux Administration Conference, 10.12.2009
Johannes Plötner
• Diplom Informatiker, Uni Karlsruhe (TH)Schwerpunkte Telematik, Kryptographie und Sicherheit
• Fachautor (Linux, IT-Sicherheit)
• Wichtige Stationen
• 2001 - 2003 Programmiererxebec mediafactory GmbH
• 2003 - 2008 IT-Berater, Administrator, Programmierer (freiberufl.)b.i.g. netzwerk management GmbH, Claranet GmbH, u.a.
• seit 2008 Leitung der SystemadministrationClaranet GmbH
Claranet GmbH
International vernetzt mit starkem lokalen Fokus (3 Niederlassungen in D)
Inhabergeführtes Mittelstandsunternehmen mit ca. 700 Mitarbeitern
Organisches und kontinuierliches Wachstum aus eigener Kraft seit Gründung
Umsatz in 2007/2008: 109 Millionen €, ca. 36.000 Business Kunden
Managed Services Provider gegründet 1996, in Deutschland seit 2000
Unser Netzwerk
• 500+ Peers
• 16 Rechenzentren
• Datendurchsatz 6 GB/s
• 700 Mitarbeiter
• Eigener Backbone
• 24/7 Support
Ziel des Vortrags
• Herangehensweise an eine ITIL-Einführung
• …aber keine Einführung in ITIL selbst.
• Prozessmanagement: Erfahrungen, Einsichten, Empfehlungen
• …ohne die ultimative Weisheit zu verkünden.
Agenda
• Einführung
• Grundlagen des Prozessmanagements
• Reifegrade
• ITIL & Co.
• ITIL Service Desk
• Prozesse des User Supports
• Lessons learned
Kennen Sie das?
• Bei einem Systemausfall…
• Auf der Suche nach der Ursache des Problems…
• Bei Änderungen an technischen Systemen…
Konsequenzen…
• Was bedeutet das aus Sicht der IT für…
• … die Beauftragung von technischen Änderungen?
• … die Schnittstelle zum „Kunden“?
• … die Stabilität des IT-Betriebes?
Weitere Gründe für Prozesse
• Sicherstellung eines stabilen IT-Betriebs
• Definierbare, klare Abläufe mit und gegenüber dem Kunden
• Unabhängigkeit von einzelnen Personen
• Ordnung statt Chaos durch Priorisierung
• Messbarkeit von Aktivitäten
• Ermöglichung von SLAs
• …
Lösungen…
• Prozesse, ja, aber…
• Welche Prozesse brauche ich?
• Wie könnten die Prozesse aussehen?
• Wie viel „Prozessoverhead“ brauche ich?
Lösungen…
• Prozesse, ja, aber…
• Welche Prozesse brauche ich?
• Wie könnten die Prozesse aussehen?
• Wie viel „Prozessoverhead“ brauche ich?
Reifegradmodell für Prozesse
• Reifegradmodelle (CMMI, SPICE, …)
• … bewerten die Reife (Institutionalisierung) der Prozesse.
• … sind erstmal abstrakt von den Prozessen selbst.
• … unterstützen bei Zieldefinition und Bestandsaufnahme.
• … sind ein Werkzeug zur Prozessverbesserung.
Reifegrade
• Level 1: Initial
• Arbeit wird „ad hoc“ erledigt, es gibt keinen Prozess
• Qualität und Zeitpunkt des Ergebnisses nicht vorhersagbar
• Erfolg abhängig von einzelnen Mitarbeitern („Helden“)
Le
ve
l 1
Initial
Le
ve
l 2
Repeatable
Le
ve
l 3
Defined
Le
ve
l 4
Managed
Le
ve
l 5
Optimized
Reifegrade
• Level 2: Repeatable
• informeller, ggf. unvollständiger Prozess
• Erfolge aus der Vergangenheit können wiederholt werden
Le
ve
l 1
Initial
Le
ve
l 2
Repeatable
Le
ve
l 3
Defined
Le
ve
l 4
Managed
Le
ve
l 5
Optimized
Reifegrade
• Level 3: Defined
• Prozess vollständig dokumentiert und eingeführt
• Einhaltung des Prozesses wird sichergestellt
• Überblick und Kontrolle über geführte Aktivitäten
Le
ve
l 1
Initial
Le
ve
l 2
Repeatable
Le
ve
l 3
Defined
Le
ve
l 4
Managed
Le
ve
l 5
Optimized
Reifegrade
• Level 4: Managed
• Messung von Effizienz und Effektivität
• teilw. reaktive Prozessverbesserungen
Le
ve
l 1
Initial
Le
ve
l 2
Repeatable
Le
ve
l 3
Defined
Le
ve
l 4
Managed
Le
ve
l 5
Optimized
Reifegrade
• Level 5: Optimized
• kontinuierliche, proaktive Verbesserung der Prozesse
Le
ve
l 1
Initial
Le
ve
l 2
Repeatable
Le
ve
l 3
Defined
Le
ve
l 4
Managed
Le
ve
l 5
Optimized
Der optimale Reifegrad…L
eve
l 1
Initial
Le
ve
l 2
Repeatable
Le
ve
l 3
Defined
Le
ve
l 4
Managed
Le
ve
l 5
Optimized
Reifegrad Risiko
hoch hoch
niedrig niedrig
Lösungen…
• Prozesse, ja, aber…
• Welche Prozesse brauche ich?
• Wie könnten die Prozesse aussehen?
• Wie viel „Prozessoverhead“ brauche ich?
IT Infrastructure Library
• IT Infrastructure Library
• „Sammlung von Büchern“
• enthält „best practises“ führender IT-Dienstleister
• beschreibt Prozesse, Rollen und Werkzeuge
• gibt den „Rahmen“ vor – individuelle Ausgestaltung notwendig
Service-Lebenszyklus nach ITIL
Service Strategie
Service Design
Service Transition
Service Operation
ContinualService
Improvement
ITIL vs. ISO
• ITIL …
• … ist kein Standard, sondern enthält „best practices“
• … zertifiziert keine Organisationen, sondern Personen
ITIL vs. ISO
• ITIL …
• … ist kein Standard, sondern enthält „best practices“
• … zertifiziert keine Organisationen, sondern Personen
• ISO 20000 …
• … legt Anforderungen an ein ITSM fest
• … ist eine Zertifizierung für Unternehmen
• … umfasst und ergänzt ITIL
ITIL vs. ISO
• ITIL …
• … ist kein Standard, sondern enthält „best practices“
• … zertifiziert keine Organisationen, sondern Personen
• ISO 20000 …
• … legt Anforderungen an ein ITSM fest
• … ist eine Zertifizierung für Unternehmen
• … umfasst und ergänzt ITIL
• ISO 9001 …
• … legt Anforderungen an ein „Qualitätsmanagementsystem“ fest
• … beschreibt, welche Prozesse wie offengelegt werden müssen
• … sagt nichts über die tatsächliche Qualität der Prozesse aus
Lösungen…
• Prozesse, ja, aber…
• Welche Prozesse brauche ich?
• Wie könnten die Prozesse aussehen?
• Wie viel „Prozessoverhead“ brauche ich?
ITIL Service Desk
Der ITIL Service Desk ist kein Prozess, sondern eine Funktion
• Aufgaben des Service Desks
• Single Point of Contact für Kunden
• Annahme, Akzeptanz, Kategorisierung und Abwicklung von
Störungen, Anfragen und Änderungswünschen
• Support-Level
• 1st Level: Annahme, Klassifikation, Lösungsversuch, ggf.
Eskalation
• 2nd Level: Fachabteilung
• 3rd Level: ggf. Hersteller
Incident Management
Incident: Ungeplante Unterbrechung oder Qualitätsminderung
eines IT-Services
• Ziel des Incident Managements
• zeitnahe Wiederherstellung der Servicequalität (Workaround)
• Umsetzung nach ITIL
• Priorisierung
• Ticketsystem
• Wissensdatenbank
• proaktive Kundeninformation / SLA
Incident Management in der Praxis
• 1st Level – nicht 100%-ig ITIL-konform
• Erreichbarkeit wichtiger als Lösung
• „Routing“ der Anfrage– Klassifikation, Priorisierung, SLAs, Zuständigkeitsmatrix usw
• anfänglich oft fehlende Infos: Checklisten erstellt
• 2nd Level – Lösung mit Wissensdatenbank
• Vorzeitige Eskalation oder „Rumprobieren“
• Proaktivität durch Monitoring
• 3rd Level – Kunden- oder Technologieexperten
• SPOC ist kein Redeverbot
• „Ticket-Ping-Pong“
• keine Aktion ohne Ticketupdate
Problem Management
Problem: Ursache eines (oder mehrerer) Incidents
• Ziel des Problem Managements
• nachhaltige Vermeidung von Störungen
• Umsetzung nach ITIL
• Reaktiv:– Finden der (unbekannten) Ursache eines Incidents
– Schnelle und wirksame Behebung
• Proaktiv:– Analyse des Performancemonitorings, Logfiles, …
Problem Management in der Praxis
• „Betreuungsmodell“
• Rolle Delivery Lead: Verantwortung für die Lieferqualität eines
bestimmten technischen Bereichs bzw. für einen Kunden
• u.a. 3rd Level und Problem Management
• wichtig: Loslösung vom Tagesgeschäft
• zu viel vs. zu wenig Problem Management
• ggf. Problem Management SLAs
• genaue Dokumentation
• … der Incidents im Ticketsystem
• … der „Known Errors“ samt Workarounds in der
Wissensdatenbank
Change Management
Ziel: wirtschaftliche, termintreue und risikoarme Umsetzung von
Changes
• Change-Kategorien
• Routine bzw. Standard Change
• Normal Change
• Emergency Change
• Request for Change (RfC): Antrag auf Change-Durchführung
• (E)CAB: Gremium, beraten hinsichtlich Change-Requests
• Bewertung, Priorisierung, Planung
• Freigabe oder Zurückweisung
Change Management in der Praxis
• Vorsicht bei (E)CAB
• Haben Sie viele Changes?
• Integration in Rollenmodell
• Vorsicht bei RfC – KISS!
• Inhalt/Ergebnis, Planung, Risiko, Fallbackplan, Aufwand
• Genehmigung per E-Mail Ok
Recommended