ITIL Definition
- best Practice Ansatz (Strategie/Planung, Entwicklung/Implementierung, Betrieb) von IT-Services
- ITIL = Information Technology Infrastructure Library
- ITIL definiert Prozesse, Funktionen, Rollen die in Organisation vorkommen (>10MA)
- kein offizieller Standard für Compliance
- Zertifizierung nur durch ISO 20000 oder BS 15000
Service Desk
- SPOC (Single Point of Contact)
- Zuständig für die Bearbeitung von Incidents und Service
Requests - Triggert weitere ITIL-Prozesse
- Zusammensetzung
- Call Center
- Unskilled (Aufnahme & Weiterleitung)
- Skilled
- Expert (kostet 100% mehr als unskilled)
Helpdesk vs Servicedesk
- Helpdesk
- Fokus auf break-fix (incident management)
- 1st, 2nd Level
- ServiceDesk
- Incident Management und Service Requests (new stuff)
- einhalten von SLA
ITILv3 Lifecycle Phasen
- Jede Phase besitzt ITILv3-Prozesse (Rollen und Aufgaben)
- Service Design
- Service Transition
- Service Operation
ITIL-Prozess
- Merkmale
- Steuerbar, messbar
- Eingabe, Ausgabe
- bewertbar, nachvollziehbar
- Rollen und Eigenschaften:
- Process Manager: Verantwortlicher für den Prozess
- Process Owner: Ausführende des Prozesses
- KPI: Key Performance Indicators
Incident Management Prozess
- Ziel: Schnellstmögliche Wiederherstellung eines Services
- massgebend für Qualität und Reputation der IT-Organisation
- Incident und Known-Error (Ursache der Störung bekannt)
- für Known-Error besteht in der Regel ein Workaround
- triggert
- Problem Management: Untersuchung von Problemursachen mit dem Ziel eine Lösung zu finden
- Change Management: Durchführung von Konfigurationsänderungen zur Behebung von Incidents
- Configuration Management: Dokumentation von Änderungen (Nachvollziehbarkeit)
Problem Management Prozess
- Suchen nach Ursachen von möglichen Störungen (Incidents)
- Erarbeitung eines Workarounds oder ein finalen Lösung
- Erstellung von Request for Change (RFC)
- Dokumentation der Vorgehensweise zur Problemlösung
- eng mit den folgenden Prozessen verbunden:
- Incident Management: Erstellung von Workarounds
- Change Management: Verbesserungsvorschläge
- Availability/Capacity Management: proaktive Untersuchungen
- Service Level Management: Priorisierung von Problemen
Configuration Management
- Inventarisierung und Pflege aller Betriebsmittel (Hardware, Software, Lizenzen, Lieferanten, usw.)
- Configuration Item (CI) – inklusive Modellierung der Abhängigkeiten zwischen den CI
- CMDB (Configuration Management Database)
- Die CMDB bildet die Basis für alle ITIL-Prozesse
- Incident Management: Abschätzung der Auswirkung von Incidents
- Problem Management: Erkennen von Abhängigkeiten
- Fragestellung
- Festlegung eines geeigneten Detaillierungsgrades
- Pflege der gespeicherten Daten in der CMDB
Change Management Prozess
Ziel: Changes wirtschaftlich, termingerecht und mit minimalen Risiken umsetzen.
Einsatz von standardisierten Methoden und Verfahren
Nutzen:
- Weniger Incidents
- Risiken sind bekannt
- Nachvollziehbarkeit
- Keine nicht autorisierten Changes
- Bewusstes Hinterfragen von Changes
- Höhere Qualität durch systematische Tests
- Bessere Planbarkeit von Zeit und Budgets für Changes
- Einhaltung von Compliance Richtlinien
Change Management Aufgaben
- Abwickeln von Changes
- Erstellung der Aufzeichnung von RFC‘s (Request for Change)
- Überprüfen von RFC‘s
- Beurteilung & Bewertung der Risiken
- Formelle Autorisierung
- Planung (Change Schedule)
- Koordination und Freigabe
- Review & Abschluss
- Führen des Change Advisory Board (CAB)
- Handhabung von Notfall-Changes
Change Management: Typen von Changes
- Normal Change
- geplant, getestet, autorisiert
- Standard Change
- Normal Change mit Vorautorisierung
- Emergency Change
- Umgeht den Normalfall, Einführung mit nachträglicher Autorisierung oder durch das eCAB
Die 7 „R“ des Change Managements
- who raised it
- for what reason
- what is the return (i.e. why are we doing this?)
- what are the perceived risks
- what resources do we need / have
- who is responsible für building, testing, etc.
- what relationship exists to other changes
Fallback / Backoff Strategien
Szenario: signifikantes Fehlverhalten der installierten Komponente
- Ausserbetriebnahme der Software
- De-Installation / Neu-Installation der Software
- Rückgängigmachen der Veränderung
- Nicht immer möglich (z.B. Firmware)
- Nicht immer unterstützt (z.B. Microsoft Windows Servicepacks)
- Anpassung der Nutzung an neues Verhalten
- Muss bereits im Releaseplan berücksichtigt werden (Funktionalität und Zeitaufwand)
Change Advisory Board (CAB)
Mitglieder:
- Change Manager (Zuständig für die Durchführung des Changes)
- Anwender auf Managementebene & Kunden
- IT-Linienvorgesetzten
- Technische Fachspezialisten
Ziele: Fachliche Beurteilung eines Changes inklusive Risikobeurteilung und Abstimmung der einzelnen Changes
untereinander.
Unterschiede zwischen ITILv3 und ITILv4
- ITILv4 ist eine Weiterentwicklung von ITILv3, die oft kritisiert worden ist.
- Das ITILv4-Framework berücksichtig neu auch Trends wie Cloud, Agile und DevOps.
- ITILv4 besitzt neu 34 verschiedene Prozesse (ITILv3 nur 23) – Dadurch ist es möglich die ITIL-
Prozesse besser an die Bedürfnisse des Business (Business Alignment) auszurichten. - Die Phasen Service Design, und Service Transition und Service Operation von ITILv3 entfallen.
- Die Zertifizierungsprüfungen für MA wurden entsprechend angepasst.
ITILv3 Service Lifecycle:
Fokus auf kontinuierliche
Weiterentwicklung des Services.
ITILv4 Service Value Chain:
Fokus auf Business Alignment der IT-Services
Service Guiding Principles (ITILv3 vs ITILv4)
ITIL V3 Guiding Principles
1. Focus on Value
2. Design for Experience
3. Start where you are
4. Work Holistically
5. Progress Iteratively
6. Observe Directly
7. Be Transparent
8. Collaborate
9. Keep it Simple
ITIL V4 Guiding Principles
1. Focus on Value
2. Start where you are
3. Progress Iteratively with Feedback
4. Collaborate and Promote Visibility
5. Think and Work Holistically
6. Keep it Simple and Practical
7. Optimize and Automate
Erfolgsfaktoren (ITILv3 vs ITILv4)
ITIL V3 Four P’s
1. People
2. Process
3. Product
4. Partners
ITIL V4 Four Dimensions
1. Organizations and people
2. Information and technology
3. Partners and suppliers
4. Value streams and processes
DevOps
Zusammenarbeit zwischen Entwicklungs- und Betriebsteam ausbauen / stärken
* Automatisierung bei der Bereitstellung von neuen
SW-Releases durch automatisierten Build-, Test- und Deployment-Prozesse
* Kontinuierliche Verbesserung des Codes durch kurze Release Zyklen (2 bis 3 Wochen)
* Kurze Feedback Prozess zwischen Entwicklung
und Business, mit dem Ziel in kleinen Releases die Funktionalität kontinuierlich weiter-
zuentwickeln und zu verbessern.
DevOps und ITIL
Die grossen Irrtürmer bezüglich ITIL und DevOps:
* DevOps kann ITIL ersetzen
* DevOps = kontinuierliche Entwicklung, Integration und automatisierte Bereitstellung
* ITIL / ITSM ist immer dokumentationslastig und umfasst schwerfällige Prozesse,
die Teams verlangsamen
* ITIL / ITSM ist nur für grosse Unternehmen geeignet
- DevOps kann ITIL nicht ersetzen!
- Bei der erfolgreichen Einführung von DevOps im Unternehmen muss geprüft werden, wie der
DevOps Prozess in die bestehenden ITIL-Prozesse Change-Management, Config-Management
und Release-Management integriert werden kann. - DevOps birgt die Gefahr, dass neue SW-Release oder Changes ohne das Einhalten der
bestehenden ITIL-Prozesse eingeführt werden. Dies kann zu Konflikten und die Service
Qualität verringern.
ITIL KPI
- Key Performance Indicator
Die ITIL-Prozesse besitzen KPI‘s. Mit Hilfe von diesen KPI‘s kann die Effizienz und die Effektivität der einzelnen Prozesse überwacht werden. Oft werden diese KPI‘s auch zur Diskussion des Budgets und zur Rechtfertigung von mehr Ressourcen benutzt.
