3.6 Erstdiagnose, Lösung und funktionale Eskalation (Teil 2/2)

Funktionale

Eskalation

Kurz erklärt

Die Erstdiagnose soll einen Incident schnell verstehen, eingrenzen und möglichst früh beheben.

Dabei geht es zunächst nicht darum, die endgültige Ursache vollständig zu ermitteln. Das wichtigste Ziel des Incident Managements ist die schnelle Wiederherstellung des vereinbarten Servicebetriebs.

Kann einder Incident mit den vorhandenen KenntnissenKenntnissen, Werkzeugen oder Berechtigungen nicht gelöst werden, wirderfolgt ereine funktionale Eskalation an eine geeignete FachgruppeFachgruppe.

weitergegeben.

---

Ziele der Erstdiagnose

DiesDie bezeichnetErstdiagnose ITILsoll alsmöglichst funktionaleschnell Eskalation.

Gründe können sein:klären:

• fehlendesWas Fachwissenfunktioniert nicht?
• fehlendeWas Zugriffsrechtefunktioniert weiterhin?
• notwendigeWer Herstellerunterstützungoder was ist betroffen?
• SpezialwerkzeugeSeit erforderlichwann besteht die Beeinträchtigung?
• komplexeWelche InfrastrukturAuswirkungen entstehen?
• sicherheitsrelevanteGab Vorfällees kurz zuvor einen Change?
• mehrereIst betroffenebereits Systemeein ähnlicher Incident bekannt?
• Existiert ein dokumentierter Workaround?
• Kann der Service Desk den Incident direkt lösen?
• Welche Fachkenntnisse werden andernfalls benötigt?

Eine Eskalationgute bedeutetErstdiagnose nicht, dass jemand einen Fehler gemacht hat.

Sie dient dazu, den Incident möglichst effizient dort bearbeiten zu lassen, wo die passende Kompetenz vorhanden ist.

---

Typischer Eskalationsweg

Benutzer
      │
      ▼
Service Desk
      │
      ▼
2nd Level Support
      │
      ▼
3rd Level / Spezialisten
      │
      ▼
Hersteller oder Lieferant

Nicht jeder Incident durchläuft alle Ebenen.

Je besser Wissen dokumentiert wird, desto häufiger kann bereits der Service Desk helfen.

---

Warme und kalte Übergabe

Eine funktionale Eskalation sollte möglichst vollständig vorbereitet sein.

Kalte Übergabe

Das Ticket wird lediglich weitergeleitet.

Beispiel:

"Bitte prüfen."

Nachteile:reduziert:

• erneuteunnötige Rückfragenckfragen,
• doppelte ArbeitPrüfungen,
• längerefalsche BearbeitungszeitEskalationen,
• lange Bearbeitungszeiten,
• und vermeidbare Serviceunterbrechungen.

---

Warme

Erstdiagnose Übergabe

und Ursachenanalyse unterscheiden

Die SituationErstdiagnose wirdgehört vollständigin beschrieben.erster Linie zum Incident Management.

Die tiefergehende Ursachenanalyse gehört häufig zum Problem Management.

Erstdiagnose	Ursachenanalyse
Service möglichst schnell wiederherstellen	zugrunde liegende Ursache untersuchen
kurzfristiger Fokus	langfristiger Fokus
Workaround oder schnelle Lösung möglich	dauerhafte Lösung vorbereiten
Incident Management	Problem Management
Minuten bis Stunden	abhängig von Komplexität auch deutlich länger

Beispiel:

Ein Anwendungsdienst reagiert nicht mehr.

Incident Management

• bereitsDienst geprüftekontrolliert Schritteneu starten
• MessergebnisseFunktion testen
• LogauszügeBenutzer informieren
• bisherigeService Vermutungen
• aktuelle Auswirkungen
• gewünschte Unterstützungwiederherstellen

DadurchProblem kannManagement

das

nächste
• Ursache Teamdes unmittelbarAbsturzes weiterarbeiten.
  untersuchen
• Speicherverbrauch analysieren
• Softwarefehler prüfen
• dauerhafte Korrektur planen

Merke

EineEin guteIncident Eskalationkann spartgelöst oftsein, mehrobwohl Zeitdie alseigentliche eineUrsache schnellenoch Eskalation.nicht bekannt oder beseitigt ist.

---

Ticket-Pingpong

Symptom, vermeiden

Ursache und Auswirkung unterscheiden

Begriff	Bedeutung	Beispiel
Symptom	beobachtetes Fehlverhalten	Anmeldung schlägt fehl
unmittelbare Ursache	direkter technischer Auslöser	Zertifikat abgelaufen
Grundursache	tiefer liegende Ursache	Zertifikatsüberwachung fehlte
Auswirkung	Folge für Benutzer oder Geschäftsprozess	Benutzer können nicht arbeiten

EinZu Beginn eines Incidents ist häufigerufig nur das Symptom bekannt.

Die Ursache darf deshalb nicht vorschnell als bestätigt dokumentiert werden.

Ungeeignet:

Die Firewall blockiert die Anwendung.

Besser:

HTTPS-Verbindungen zur Anwendung schlagen fehl. Eine Blockierung durch die Firewall ist eine mögliche, noch nicht bestätigte Ursache.

---

Beobachtung und Vermutung trennen

Eine strukturierte Diagnose folgt möglichst dieser Reihenfolge:

1. beobachten
2. Informationen sammeln
3. Umfang bestimmen
4. Hypothesen bilden
5. Hypothesen testen
6. Ergebnisse bewerten
7. Service wiederherstellen
8. Maßnahmen dokumentieren

Beobachtungen sollten möglichst messbar sein.

Ungeeignet:

Das Netzwerk ist langsam.

Besser:

Die Antwortzeit zum Gateway liegt normalerweise unter 5 ms. Aktuell werden zwischen 80 und 150 ms sowie Paketverluste von etwa 12 Prozent gemessen.

---

Den Umfang bestimmen

Der Umfang hilft bei der Eingrenzung.

Zu prüfen ist beispielsweise:

• Ist nur ein Benutzer betroffen?
• Sind mehrere Benutzer betroffen?
• Ist ein gesamter Standort betroffen?
• Betrifft der Fehler istalle dasGeräte ständigeoder Weiterreichennur zwischenein Teams.bestimmtes?
• Ist nur eine Anwendung betroffen?
• Funktioniert der Service intern, aber nicht über VPN?
• Sind nur neue Anmeldungen betroffen?
• Funktionieren bestehende Sitzungen weiterhin?
• Sind bestimmte Betriebssysteme oder Versionen betroffen?

Beispiel:

Eine Anwendung startet bei einem Benutzer nicht.

Prüfung:

• anderer Benutzer am selben Gerät: funktioniert
• derselbe Benutzer an anderem Gerät: funktioniert nicht
• andere Anwendungen: funktionieren

Damit liegt die Ursache wahrscheinlich eher im Benutzerkonto oder Benutzerprofil als im Gerät.

---

Den Normalzustand kennen

Für die Diagnose muss bekannt sein, was normalerweise geschehen sollte.

Beispiel:

ServiceNach DeskEingabe →der NetzwerkZugangsdaten →sollte Serverinnerhalb →weniger DatenbankSekunden →die NetzwerkStartseite erscheinen. Stattdessen bleibt der Ladebildschirm dauerhaft sichtbar.

Diese Beschreibung ist aussagekräftiger als:

Anmeldung funktioniert nicht.

Hilfreiche Fragen:

• Was wollten Sie durchführen?
• Was sollte normalerweise geschehen?
• Was geschieht stattdessen?
• Wird eine Fehlermeldung angezeigt?
• Wann hat es zuletzt funktioniert?

---

Änderungen berücksichtigen

JedeViele WeiterleitungIncidents kostettreten Zeit.nach Änderungen auf.

Zu prüfen sind beispielsweise:

• Softwareupdates
• neue Firewall-Regeln
• DNS-Änderungen
• Zertifikatswechsel
• Gruppenrichtlinien
• Benutzer- oder Berechtigungsänderungen
• Firmwareupdates
• Netzwerkumbauten
• Cloud-Konfigurationsänderungen
• Änderungen durch Lieferanten

Eine wichtige Diagnosefrage lautet:

Was hat sich kurz vor Beginn des Fehlers verändert?

Ein zeitlicher Zusammenhang beweist jedoch noch keine Ursache.

Der Change muss fachlich überprüft werden.

---

Bekannte Incidents und Fehler prüfen

Vor einer Eskalationaufwendigen Analyse sollte geprüft werden:

• Gibt es bereits einen aktiven Incident?
• Ist eine allgemeine Störung bekannt?
• Existiert ein Problem Record?
• Gibt es einen Known Error?
• Ist ein geeigneter Knowledge-Artikel vorhanden?
• Hat der Hersteller eine Störung oder ein bekanntes Problem gemeldet?
• Wurde dieselbe Kombination aus Symptom und Service bereits dokumentiert?

Dadurch lassen sich doppelte Analysen vermeiden.

---

Monitoring verwenden

Monitoring kann wichtige Hinweise liefern.

Typische Messwerte:

• CPU-Auslastung
• Arbeitsspeicher
• Speicherplatz
• Dienststatus
• Netzwerkverbindungen
• Antwortzeiten
• Fehlerraten
• Zertifikatsgültigkeit
• Backup-Status
• Hardwarezustand
• Cloud-Service-Status

Monitoring zeigt jedoch häufig nur ein Symptom.

Beispiel:

CPU-Auslastung 100 Prozent

Dies beweist noch nicht, welcher Prozess oder welche Ursache verantwortlich ist.

---

Logs gezielt auswerten

Logs können zeigen:

• wann ein Fehler begann,
• welche Komponente beteiligt war,
• welche Meldung erzeugt wurde,
• welches Konto verwendet wurde,
• und welche Aktion fehlgeschlagen ist.

Bei der Auswertung sollte geprüft werden:

• Passt der Zeitstempel zum Incident?
• Betrifft die Meldung wirklich dasden richtigebetroffenen Team ausgewählt?Service?
• WurdenIst genügendes Informationenein gesammelt?Fehler, eine Warnung oder nur eine Information?
• WurdenTritt bekanntedie LösungenMeldung geprüft?auch im Normalbetrieb auf?
• SindGibt allees notwendigenzeitlich passende Changes oder Events?

Nicht jede rote Fehlermeldung ist für den aktuellen Incident relevant.

---

Reproduzierbarkeit prüfen

Ein reproduzierbarer Fehler lässt sich leichter eingrenzen.

Zu dokumentieren sind:

• genaue Arbeitsschritte
• verwendete Anwendung
• Version
• Gerät oder Betriebssystem
• Benutzerkonto
• verwendete Daten
vorhanden?
• erwartetes Verhalten
• tatsächliches Verhalten
• Fehlermeldung

Beispiel:

1. Anwendung öffnen
2. Auftrag auswählen
3. „PDF exportieren“ anklicken
4. Anwendung beendet sich ohne Meldung

Zusatz:

• tritt bei drei getesteten Aufträgen auf
• nur Desktop-Version betroffen
• Webversion funktioniert

---

Swarming

Vom Einfachen zum Komplexen

ModerneEine IT-Organisationensinnvolle arbeitenPraxisreihenfolge häufigkann sein:

1. Meldung und Auswirkungen verstehen
2. bekannte Störungen prüfen
3. offensichtliche Voraussetzungen prüfen
4. Änderungen vergleichen
5. Monitoring und Logs auswerten
6. Fehlerbereich eingrenzen
7. Hypothesen testen
8. Spezialisten einbinden

Dies ist keine feste ITIL-Vorgabe.

Es verhindert jedoch, dass sofort mit Swarming.

Dabei arbeiten mehrere Spezialisten gleichzeitig an einem Incident.

Vorteile:

• weniger Wartezeit
• kein Ticket-Pingpong
• schneller Wissensaustausch
• bessere Zusammenarbeit

Dieses Vorgehen eignet sich besonders für:

aufwendigen

oder
• Majorriskanten Incidents
Maßnahmen
• komplexebegonnen Cloud-Infrastrukturen
• kritische Produktionssysteme

---

Workaround

Ein Workaround stellt den Service vorübergehend wieder her, ohne die eigentliche Ursache dauerhaft zu beseitigen.

Beispiele:

• alternativer Drucker
• Webversion statt Desktop-App
• Ersatzserver
• Neustart eines Dienstes
• manuelle Verarbeitung

Der Benutzer kann weiterarbeiten.

Die Ursache kann später untersucht werden.wird.

---

Dauerhafte Lösung

Eine dauerhafte Lösung beseitigt die eigentliche Ursache.Ausschlussverfahren

Beispiele:Beim Ausschlussverfahren werden mögliche Fehlerbereiche systematisch geprüft.

Beispiel:

• Softwarefehler

  VPN-Verbindung behoben

funktioniert
• fehlerhafte Firewall-Regel korrigiert
• Zertifikat erneuert
• Speicher erweitert
• Hardware ersetzt

---

Workaround oder Lösung?

nicht.

StundenoderTage

WorkaroundPrüfung	Dauerhafte LösungErgebnis
schnellInternetverbindung vorhanden	nachhaltigja
UrsacheDNS-Auflösung bleibt bestehenfunktioniert	Ursache beseitigtja
reduziertVPN-Gateway Auswirkungenerreichbar	verhindert Wiederholungja
oftBenutzerkonto Minutenaktiv	häufigja
MFA erfolgreich	ja
Client-Zertifikat gültig	nein

---

Damit

Wann endet ein Incident?

Der Incident endet, wennwurde der vereinbarte Service wieder verfügbar ist.

Nicht erforderlich ist:

• vollständige Ursachenanalyse
• Softwarekorrektur
• Herstellerupdate

Diese Arbeiten gehören häufig bereits zum Problem Management oder Change Management.

---

Dokumentation der Lösung

Eine gute Abschlussdokumentation enthält:

• tatsächliche Ursache (falls bekannt)
• durchgeführte Maßnahmen
• verwendeten Workaround
• endgültige Lösung
• betroffene Systeme
• notwendige Folgearbeiten

Dadurch können ähnliche Incidents später schneller gelöst werden.

---

Wissen zurückführen

Jeder gelöste Incident kann neues Wissen erzeugen.

Geeignete Ergebnisse:

• neuer Knowledge-Artikel
• aktualisierte Checkliste
• neue Automatisierung
• Anpassung eines Runbooks
• Verbesserung einer Monitoring-Regel

Dadurch profitieren zukünftige Bearbeiter.

---

KI-Unterstützung

KI kann unterstützen bei:

• ähnlichen Tickets
• Knowledge-Artikeln
• Loganalyse
• Fehlermeldungen
• Lösungsvorschlägen
• Zusammenfassungen

Die Verantwortung bleibt jedoch beim Menschen.

KI ersetzt keine technische Bewertung.

---

Typische Diagnosefehler

Fehler 1

Zu früh auf einedas UrsacheZertifikat festlegen.

---

Fehler 2

Mehrere Änderungen gleichzeitig durchführen.

---

Fehler 3

Logs nicht prüfen.

---

Fehler 4

Monitoring ignorieren.

---

Fehler 5

Keine Dokumentation.

---

Fehler 6

Ticket ohne ausreichende Informationen eskalieren.

---

Fehler 7

Workaround als endgültige Lösung betrachten.

---

Fehler 8

Bekannte Lösungen nicht verwenden.

---

Fehler 9

Symptom und Ursache verwechseln.

---

Fehler 10

Benutzer nicht über den aktuellen Stand informieren.

---

Praxisbeispiel

Meldungeingegrenzt.

Benutzer können sich nicht anmelden.

Erstdiagnose:

• mehrere Benutzer betroffen
• Active Directory erreichbar
• DNS funktioniert
• Zertifikat abgelaufen

WorkaroundMerke

AnmeldungJeder überTest Ersatzdienstsollte möglich.

eine

Dauerhafte Lösung

Neues Zertifikat installiert.

Folgearbeit

Monitoring erweitert, damit Zertifikatsabläufe künftig frühzeitig erkannt werden.

---

Checkliste Erstdiagnose

•  Symptom verstanden
•  Umfang bestimmt
•  Änderungen geprüft
•  Monitoring geprüft
•  Logs geprüft
•  bekannte Lösungen geprüft
• konkrete Hypothese getestet
•  Maßnahmen dokumentiert
•  Benutzer informiert

---

Checkliste funktionale Eskalation

•  richtige Fachgruppe
•  vollständige Ticketinformationen
•  bisherige Maßnahmen dokumentiert
•  Messergebnisse beigefügt
•  aktueller Status beschrieben
•  nächster Schritt definiert

---

Checkliste Abschluss

•  Service wiederhergestellt
•  Benutzer informiert
•  Lösung dokumentiert
•  Ursache dokumentiert (falls bekannt)
•  Knowledge-Artikel prüfen
•  Problem Management erforderlich?
•  Change erforderlich?
•  Monitoring verbessern?
•  Automatisierung möglich?

---

Bedeutung für Fachinformatiker für Systemintegration

Im Berufsalltag besteht die wichtigste Aufgabe häufig nicht darin, möglichst viele Systeme zu kennen.

Entscheidend ist vielmehr eine strukturierte Vorgehensweise.

Ein guter Fachinformatiker:

• beobachtet zuerst,
• dokumentiert sauber,
• prüft systematisch,
• nutzt vorhandenes Wissen,
• eskaliert zielgerichtet,
• kommuniziert verständlich,
• und sorgt dafür, dass gewonnene Erkenntnisse dauerhaft dokumentiert werden.

Dadurch werden Incidents schneller gelöst und wiederkehrende Fehler langfristig reduziert.

---

Zusammenfassung

Ticket übernehmen

↓

Symptom verstehen

↓

Umfang bestimmen

↓

Änderungen, Monitoring und Logs prüfen

↓

Hypothesen testen

↓

Workaroundbestätigen oder Lösung durchführen

↓

Falls nötig funktional eskalieren

↓

Service wiederherstellen

↓

Lösung dokumentieren

↓

Wissen in Knowledge Base übernehmenverwerfen.

---

VerwandteHypothesen Seitendokumentieren

Eine gute Arbeitsnotiz kann folgendermaßen aufgebaut sein:

Hypothese

DNS-Auflösung ist fehlerhaft.

Test

Interne und externe Namensauflösung mit dem vorgesehenen DNS-Server geprüft.

Ergebnis

Name wird korrekt aufgelöst.

Schlussfolgerung

Hypothese verworfen.

Dadurch muss die nächste bearbeitende Person denselben Test nicht wiederholen.

---

Nur kontrollierte Maßnahmen durchführen

Während der Diagnose sollten nicht mehrere Änderungen gleichzeitig vorgenommen werden.

Ungeeignet:

• 3.4DNS Tickets vollständig erfassen und kategorisierenändern
• 3.5Firewall-Regel Auswirkungen, Dringlichkeit und Prioritätanpassen
• 3.7Dienst Ownership,neu hierarchische Eskalation und Major Incidentsstarten
• ProblemZertifikat Managementerneuern
• KnowledgeServer Managementneu starten

Wenn der Service anschließend funktioniert, ist nicht erkennbar, welche Maßnahme wirksam war.

Besser:

1. Maßnahme planen
2. ContinualRisiko Improvementbewerten
3. Maßnahme durchführen
4. Ergebnis prüfen
5. dokumentieren
6. erst danach nächsten Schritt festlegen

Produktive Änderungen müssen entsprechend den Regeln des Change Enablement durchgeführt werden.

---

QuellenNeustarts bewusst einsetzen

Ein Neustart kann ein sinnvoller Workaround sein.

Er darf jedoch nicht reflexartig verwendet werden.

Vorher sollte geprüft werden:

• PeopleCertGehen –flüchtige ITILDiagnoseinformationen 4 / ITIL 5 Incident Managementverloren?
• PeopleCertWerden –Benutzer ITILoder 4andere /Services ITIL 5 Service Deskunterbrochen?
• ITILBesteht PracticeDatenverlustrisiko?
Guides
• Ist (Incidenteine Management,Genehmigung Knowledgeerforderlich?
Management)
• Gibt es eine weniger eingreifende Maßnahme?
• Kann der Fehler nach dem Neustart weiterhin analysiert werden?

Framework-Stand:... ITIL(Fortsetzung Versionwegen 5
Nachrichtenlängenlimit Fachlicher Stand: August 2026erforderlich)