Ein Incident (deutsch: Störung oder Vorfall) bezeichnet im IT-Kontext jede ungeplante Unterbrechung oder Qualitätsminderung eines IT-Services. Der Begriff stammt aus dem ITIL-Framework und ist ein zentrales Konzept im IT-Service-Management. Incidents können von kleinen Beeinträchtigungen bis hin zu vollständigen Systemausfällen reichen.
Im Gegensatz zu einem Problem, das die zugrundeliegende Ursache beschreibt, ist ein Incident das Symptom – also das, was der Anwender direkt wahrnimmt. Das Ziel des Incident Managements ist es, den normalen Servicebetrieb so schnell wie möglich wiederherzustellen und die Auswirkungen auf das Geschäft zu minimieren.
Was genau ist ein Incident?
Die offizielle ITIL-Definition beschreibt einen Incident als:
“Eine ungeplante Unterbrechung eines IT-Services oder eine Verringerung der Qualität eines IT-Services.”
Diese Definition umfasst auch Ausfälle von Konfigurationselementen (Configuration Items), die den Service noch nicht beeinträchtigt haben, aber potenziell könnten.
Wichtig ist die Abgrenzung zu verwandten Begriffen:
| Begriff | Beschreibung | Beispiel |
|---|---|---|
| Incident | Symptom, das den Service beeinträchtigt | E-Mail-Server antwortet nicht |
| Problem | Zugrundeliegende Ursache eines oder mehrerer Incidents | Defekte Festplatte im Server |
| Event | Jedes erkennbare Ereignis in der IT-Infrastruktur | CPU-Auslastung über 80% |
| Service Request | Anfrage eines Nutzers (kein Fehler) | Passwort zurücksetzen |
Typische Beispiele für Incidents
In der Praxis begegnen IT-Fachkräften täglich verschiedene Arten von Incidents. Hier einige typische Beispiele aus dem Unternehmensalltag:
- Anwendungsausfall: Eine Geschäftsanwendung stürzt ab oder reagiert nicht mehr
- Netzwerkstörung: Benutzer können nicht auf das Internet oder interne Ressourcen zugreifen
- Hardware-Defekt: Ein Drucker, Monitor oder anderes Peripheriegerät funktioniert nicht
- Performanceprobleme: Systeme reagieren extrem langsam
- Anmeldeprobleme: Benutzer können sich nicht am System anmelden
- Datenverlust: Dateien sind plötzlich nicht mehr verfügbar
- E-Mail-Störung: E-Mails werden nicht gesendet oder empfangen
- Sicherheitsvorfall: Verdacht auf Malware oder unbefugten Zugriff
Incident Management im ITIL-Framework
Das Incident Management ist eine der 34 Practices in ITIL 4 und gehört zu den Service Management Practices. Es ist eng mit dem Service Desk verbunden, der als zentrale Anlaufstelle für alle Incidents dient.
Ziele des Incident Managements
Das Incident Management verfolgt mehrere zentrale Ziele:
- Schnelle Wiederherstellung: Den normalen Servicebetrieb so schnell wie möglich wiederherstellen
- Minimierung der Auswirkungen: Negative Auswirkungen auf Geschäftsprozesse begrenzen
- Einhaltung von SLAs: Vereinbarte Service Level Agreements einhalten
- Dokumentation: Alle Incidents für spätere Analyse erfassen
- Kommunikation: Betroffene Anwender über Status und Fortschritt informieren
Der Incident-Lebenszyklus
Jeder Incident durchläuft einen definierten Lebenszyklus mit mehreren Phasen:
┌─────────────────────────────────────────────────────────────┐
│ INCIDENT-LEBENSZYKLUS │
├─────────────────────────────────────────────────────────────┤
│ 1. Identifikation → Incident wird erkannt/gemeldet │
│ 2. Erfassung → Ticket wird erstellt │
│ 3. Kategorisierung → Art des Incidents bestimmen │
│ 4. Priorisierung → Dringlichkeit festlegen │
│ 5. Diagnose → Ursache untersuchen │
│ 6. Eskalation → Bei Bedarf weiterleiten │
│ 7. Lösung → Workaround oder Fix anwenden │
│ 8. Abschluss → Dokumentation und Bestätigung │
└─────────────────────────────────────────────────────────────┘
Kategorisierung von Incidents
Die Kategorisierung hilft dabei, Incidents systematisch zu erfassen und später auszuwerten. Typische Kategorien sind:
- Hardware: Physische Geräte wie Server, PCs, Drucker
- Software: Anwendungen, Betriebssysteme, Updates
- Netzwerk: Verbindungsprobleme, Router, Switches
- Sicherheit: Malware, Phishing, unbefugte Zugriffe
- Datenbank: Datenbankfehler, Verbindungsprobleme
- Benutzer: Zugangsprobleme, Berechtigungen
Eine durchdachte Kategorisierung ermöglicht es, Trends zu erkennen und wiederkehrende Probleme zu identifizieren. Wenn beispielsweise viele Incidents in der Kategorie “Netzwerk” auftreten, könnte dies auf ein grundlegendes Problem Management hinweisen.
Priorisierung: Dringlichkeit und Auswirkung
Die Priorisierung bestimmt, in welcher Reihenfolge Incidents bearbeitet werden. Sie basiert auf zwei Faktoren:
- Impact (Auswirkung): Wie stark ist der Geschäftsbetrieb betroffen? Wie viele Benutzer sind betroffen?
- Urgency (Dringlichkeit): Wie schnell muss der Incident gelöst werden?
Aus diesen beiden Faktoren ergibt sich die Priorität:
| Hohe Dringlichkeit | Mittlere Dringlichkeit | Niedrige Dringlichkeit | |
|---|---|---|---|
| Hoher Impact | Kritisch (P1) | Hoch (P2) | Mittel (P3) |
| Mittlerer Impact | Hoch (P2) | Mittel (P3) | Niedrig (P4) |
| Niedriger Impact | Mittel (P3) | Niedrig (P4) | Geplant (P5) |
Prioritätsstufen in der Praxis
| Priorität | Bezeichnung | Reaktionszeit | Lösungszeit | Beispiel |
|---|---|---|---|---|
| P1 | Kritisch | 15 Minuten | 4 Stunden | Kompletter Systemausfall |
| P2 | Hoch | 1 Stunde | 8 Stunden | Wichtige Anwendung nicht verfügbar |
| P3 | Mittel | 4 Stunden | 24 Stunden | Einzelner Arbeitsplatz betroffen |
| P4 | Niedrig | 8 Stunden | 48 Stunden | Kosmetischer Fehler |
| P5 | Geplant | Nächster Arbeitstag | Nach Vereinbarung | Optimierungswunsch |
Eskalation bei Incidents
Wenn ein Incident nicht innerhalb der vereinbarten Zeit gelöst werden kann oder besondere Expertise erfordert, erfolgt eine Eskalation. Es gibt zwei Arten:
Funktionale Eskalation (horizontal)
Der Incident wird an eine Gruppe mit mehr Fachwissen weitergegeben. Typische Support-Level sind:
- 1st Level Support (Service Desk): Erste Anlaufstelle, löst einfache Incidents
- 2nd Level Support: Spezialisten für bestimmte Technologien
- 3rd Level Support: Experten, oft Entwickler oder Hersteller
- 4th Level Support: Externe Partner oder Hersteller-Support
Hierarchische Eskalation (vertikal)
Bei kritischen Incidents oder wenn zusätzliche Ressourcen benötigt werden, wird das Management einbezogen. Dies ist besonders wichtig bei:
- Überschreitung von SLA-Zeiten
- Major Incidents mit großem Geschäftsimpact
- Ressourcenkonflikten
- Entscheidungen außerhalb der Befugnis des Support-Teams
Major Incidents
Ein Major Incident ist ein Incident mit erheblichen Auswirkungen auf das Geschäft. Er erfordert besondere Behandlung und hat eigene Prozesse:
- Schnellere Reaktionszeiten: Sofortige Eskalation und Zusammenstellung eines Incident-Teams
- Separate Kommunikation: Regelmäßige Updates an Management und betroffene Stakeholder
- Incident Commander: Eine Person koordiniert alle Aktivitäten
- Post-Incident-Review: Nachbereitung zur Verbesserung der Prozesse
Beispiele für Major Incidents sind der Ausfall eines zentralen ERP-Systems, eine Ransomware-Attacke oder der Ausfall des gesamten Netzwerks.
Incident vs. Problem: Der Unterschied
Ein häufiger Fehler ist die Verwechslung von Incident und Problem. Der Unterschied ist fundamental:
| Aspekt | Incident | Problem |
|---|---|---|
| Definition | Symptom, Service-Unterbrechung | Zugrundeliegende Ursache |
| Ziel | Schnelle Wiederherstellung | Dauerhafte Beseitigung der Ursache |
| Zeitrahmen | Kurzfristig (Minuten bis Stunden) | Längerfristig (Tage bis Wochen) |
| Lösung | Workaround akzeptabel | Root Cause Analysis erforderlich |
| Beispiel | Server antwortet nicht | Defekte RAM-Module |
In der Praxis wird oft zuerst der Incident behoben (z.B. Server-Neustart), und anschließend untersucht das Problem Management die Ursache, um zukünftige Incidents zu verhindern.
Tools für das Incident Management
Für professionelles Incident Management werden spezialisierte Tools eingesetzt. Diese ITSM-Tools (IT Service Management Tools) bieten Funktionen wie:
- Ticket-Erstellung und -Verwaltung
- Automatische Kategorisierung und Priorisierung
- Eskalationsworkflows
- SLA-Überwachung
- Reporting und Dashboards
- Knowledge Base Integration
- Self-Service-Portal für Endanwender
Bekannte ITSM-Tools sind:
- ServiceNow: Enterprise-Lösung für große Unternehmen
- Jira Service Management: Von Atlassian, gut integriert mit Entwicklungstools
- Freshservice: Cloud-basierte Lösung für KMU
- OTRS: Open-Source-Alternative
- Zendesk: Bekannt für Kundenservice, auch für IT-Support geeignet
- ManageEngine ServiceDesk Plus: Umfangreiche Features für mittlere Unternehmen
Kennzahlen im Incident Management
Um die Qualität des Incident Managements zu messen und zu verbessern, werden verschiedene KPIs (Key Performance Indicators) verwendet:
| KPI | Beschreibung | Typischer Zielwert |
|---|---|---|
| MTTR (Mean Time To Resolve) | Durchschnittliche Lösungszeit | < 4 Stunden |
| MTTA (Mean Time To Acknowledge) | Zeit bis zur ersten Reaktion | < 15 Minuten |
| First Contact Resolution Rate | Anteil beim ersten Kontakt gelöster Incidents | > 70% |
| SLA Compliance | Einhaltung der vereinbarten Zeiten | > 95% |
| Incident Volume | Anzahl der Incidents pro Zeitraum | Trend: sinkend |
| Reopen Rate | Anteil erneut geöffneter Incidents | < 5% |
Incident Management in der Praxis
Als IT-Fachkraft wirst du regelmäßig mit Incidents konfrontiert. Hier einige praktische Tipps:
Für den 1st Level Support
- Aktives Zuhören: Lasse den Anwender das Problem vollständig beschreiben
- Strukturierte Fragen: Wann trat das Problem auf? Was wurde zuvor gemacht?
- Dokumentation: Erfasse alle relevanten Informationen im Ticket
- Known Errors prüfen: Gibt es bereits dokumentierte Lösungen?
- Kommunikation: Halte den Anwender über den Fortschritt informiert
Für das Management
- Trends analysieren: Welche Incidents treten häufig auf?
- Root Cause fördern: Incidents sind Symptome – investiere in Problem Management
- Automatisierung: Wiederkehrende Lösungen automatisieren
- Schulung: Das Team kontinuierlich weiterbilden
- Feedback-Kultur: Aus Incidents lernen, nicht Schuldige suchen
Incident Management in der IT-Ausbildung
Das Thema Incident Management ist besonders relevant für angehende Fachinformatiker für Systemintegration, da sie häufig im IT-Support oder Service Desk arbeiten. Aber auch Fachinformatiker für Anwendungsentwicklung sollten verstehen, wie ihre Anwendungen im Betrieb unterstützt werden.
In der IHK-Prüfung können folgende Themen relevant sein:
- Definition und Abgrenzung von Incident, Problem und Service Request
- Der Incident-Lebenszyklus
- Priorisierung nach Impact und Urgency
- Eskalationsstufen im Support
- Zusammenhang mit ITIL und IT-Service-Management
Quellen und weiterführende Links
- AXELOS ITIL Incident Management - Offizielle ITIL-Ressourcen
- BMC - What is Incident Management? - Detaillierte Erklärung
- Atlassian - Incident Management - Praktischer Leitfaden
- ServiceNow - Incident Management - Enterprise-Perspektive