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

Kurz erklärt

Ziel der Erstdiagnose ist nicht, sofort die eigentliche Ursache zu kennen, sondern möglichst schnell die Situation zu verstehen, Auswirkungen zu begrenzen und den Service wiederherzustellen.

Gute Diagnosen beruhen auf:

Beobachtungen,

überprüfbaren Fakten,

strukturierten Tests,

technischem Wissen,

vorhandenen Erfahrungen,

und nachvollziehbaren Entscheidungen.

ITIL empfiehlt, vorhandenes Wissen systematisch zu nutzen und Incidents möglichst früh dort zu lösen, wo die erforderlichen Fähigkeiten vorhanden sind.

Ziele der Erstdiagnose

Nach der Ticketaufnahme beginnt die eigentliche Analyse.

Dabei sollten zunächst folgende Fragen beantwortet werden:

Was funktioniert nicht?

Was funktioniert noch?

Seit wann besteht die Störung?

Wer ist betroffen?

Welche Änderungen gab es kurz zuvor?

Welche Systeme hängen zusammen?

Gibt es bereits bekannte Incidents?

Existiert ein Workaround?

Die Erstdiagnose soll möglichst schnell klären,

ob der Service wiederhergestellt werden kann,

ob Spezialisten benötigt werden,

oder ob eine funktionale Eskalation notwendig ist.

Erstdiagnose ist keine Ursachenanalyse

Ein häufiger Fehler besteht darin, bereits in den ersten Minuten die eigentliche Ursache finden zu wollen.

Die Erstdiagnose verfolgt jedoch ein anderes Ziel.

Erstdiagnose	Ursachenanalyse
Service möglichst schnell wiederherstellen	eigentliche Ursache dauerhaft finden
Minuten bis Stunden	Stunden bis Tage
Incident Management	Problem Management
Fokus auf Wiederherstellung	Fokus auf Prävention

Beispiel:

Ein Webserver antwortet nicht.

Während der Erstdiagnose genügt möglicherweise:

Dienst neu starten,

Funktion prüfen,

Benutzer informieren.

Warum der Dienst abgestürzt ist, wird später im Problem Management untersucht.

Merke

Ein gelöster Incident bedeutet nicht automatisch, dass die Ursache beseitigt wurde.

Beobachtung vor Interpretation

Techniker neigen häufig dazu, sehr früh Vermutungen aufzustellen.

Besser ist folgende Reihenfolge:

Beobachten

Informationen sammeln

Hypothesen bilden

Hypothesen testen

Ursache bestätigen

Beispiel:

❌ "Die Firewall blockiert den Zugriff."

Besser:

✅ "HTTPS-Verbindungen schlagen fehl. Andere Protokolle funktionieren. Firewall ist eine mögliche Ursache."

Symptome richtig erfassen

Ein Symptom beschreibt das beobachtete Verhalten.

Beispiele:

Anmeldung schlägt fehl

Druckauftrag bleibt hängen

Anwendung reagiert nicht

Datei lässt sich nicht öffnen

VPN verbindet nicht

Ein Symptom ist noch keine Ursache.

Mögliche Ursachen

Für dasselbe Symptom können völlig unterschiedliche Ursachen verantwortlich sein.

Symptom

Anmeldung nicht möglich

Mögliche Ursachen:

Passwort falsch

Konto gesperrt

Active Directory nicht erreichbar

DNS-Problem

Netzwerkfehler

Zertifikat abgelaufen

MFA-Dienst gestört

Cloud-Ausfall

Deshalb sollten Vermutungen immer überprüft werden.

Strukturierte Diagnose

Eine bewährte Reihenfolge lautet:

Problem verstehen

Umfang bestimmen

Änderungen prüfen

Logs prüfen

Monitoring prüfen

Verbindung testen

Komponenten eingrenzen

Hypothese testen

Ergebnis dokumentieren

Umfang bestimmen

Nicht jede Störung betrifft alle Benutzer.

Zu klären ist:

Ein Benutzer?

Mehrere Benutzer?

Ein Standort?

Alle Standorte?

Nur Windows?

Auch macOS?

Nur VPN?

Auch intern?

Je genauer der Umfang bekannt ist, desto einfacher lässt sich die Ursache eingrenzen.

Änderungen berücksichtigen

Viele Incidents entstehen kurz nach Änderungen.

Zu prüfen sind beispielsweise:

Software-Updates

neue Firewall-Regeln

Zertifikatswechsel

DNS-Änderungen

neue Switch-Konfiguration

Benutzeränderungen

Gruppenrichtlinien

Cloud-Änderungen

Frage:

Was hat sich kurz vor dem Fehler geändert?

Diese Frage spart häufig sehr viel Diagnosezeit.

Reproduzierbarkeit prüfen

Ein Fehler sollte möglichst reproduziert werden.

Beispiel:

Anwendung starten

Benutzer anmelden

Auftrag öffnen

Speichern

Tritt der Fehler jedes Mal auf?

Oder nur gelegentlich?

Auch diese Information grenzt Ursachen erheblich ein.

Bekannte Fehler nutzen

Vor aufwendigen Analysen sollte geprüft werden:

Gibt es einen bekannten Incident?

Existiert ein Knowledge-Artikel?

Hat der Hersteller bereits einen Hinweis veröffentlicht?

Gab es ähnliche Tickets?

Viele Incidents lassen sich dadurch deutlich schneller lösen.

Monitoring verwenden

Monitoring liefert häufig frühere Hinweise als Benutzer.

Beispiele:

CPU-Auslastung

Festplattenspeicher

Netzwerk

Dienste

Zertifikate

Backup

Hardware

Monitoring ersetzt jedoch keine Diagnose.

Es zeigt häufig nur Symptome.

Logs richtig einsetzen

Logs beantworten häufig Fragen wie:

Wann trat der Fehler auf?

Welche Komponente war beteiligt?

Welche Fehlermeldung wurde erzeugt?

Welche Benutzer waren betroffen?

Dabei gilt:

Nicht jede Warnung ist automatisch relevant.

Logs müssen immer im Zusammenhang betrachtet werden.

Ausschlussverfahren

Eine sehr effektive Methode ist das Ausschlussprinzip.

Beispiel:

VPN funktioniert nicht.

Prüfung:

Internet vorhanden ✔️

DNS funktioniert ✔️

Anmeldung funktioniert ✔️

VPN-Server erreichbar ✔️

Zertifikat gültig ❌

Die Ursache lässt sich dadurch systematisch eingrenzen.

Von einfach nach komplex

ITIL empfiehlt keine feste Reihenfolge.

In der Praxis hat sich jedoch bewährt:

Offensichtliches prüfen

Bekannte Fehler prüfen

Änderungen prüfen

Monitoring prüfen

Logs prüfen

Detailanalyse

Nicht sofort mit der kompliziertesten Hypothese beginnen.

Keine unnötigen Änderungen

Während der Diagnose sollte möglichst nicht gleichzeitig an mehreren Komponenten gearbeitet werden.

Schlecht:

Firewall ändern

DNS ändern

Server neu starten

Zertifikat erneuern

Danach ist kaum nachvollziehbar, welche Maßnahme tatsächlich geholfen hat.

Besser:

Eine Änderung durchführen.

Ergebnis prüfen.

Dokumentieren.

Erst danach die nächste Maßnahme.

Hypothesen dokumentieren

Eine gute Arbeitsnotiz enthält:

Hypothese

DNS-Auflösung fehlerhaft.

Test

Namensauflösung gegen internen DNS geprüft.

Ergebnis

DNS funktioniert.

Schlussfolgerung

Hypothese verworfen.

Dadurch vermeiden andere Bearbeiter dieselben Tests.

Wissen systematisch nutzen

Erfahrungen sollten nicht ausschließlich im Kopf einzelner Administratoren bleiben.

Hilfreich sind:

Knowledge-Artikel

Standardlösungen

Runbooks

Checklisten

bekannte Fehler

Herstellerdokumentation

Dadurch steigt die First Contact Resolution deutlich.

First Contact Resolution (FCR)

FCR beschreibt den Anteil der Incidents,

die bereits beim ersten Kontakt vollständig gelöst werden.

Vorteile:

kürzere Wartezeit

zufriedenere Benutzer

weniger Eskalationen

geringere Kosten

FCR darf jedoch nicht künstlich erhöht werden, indem Tickets vorschnell geschlossen werden.

Shift Left

Shift Left bedeutet,

Wissen möglichst früh im Support bereitzustellen.

Beispiele:

bessere Wissensdatenbank

Self-Service

Standardlösungen

Automatisierung

KI-Unterstützung

Schulungen

Dadurch können mehr Incidents bereits im Service Desk gelöst werden.

Dokumentation während der Diagnose

Nicht erst am Ende dokumentieren.

Nach jeder wichtigen Maßnahme sollte festgehalten werden:

Zeitpunkt

Maßnahme

Ergebnis

nächster Schritt

Dadurch bleiben Übergaben nachvollziehbar.

Merksätze

Symptome sind keine Ursachen.

Beobachtungen sind wichtiger als Vermutungen.

Erst den Service wiederherstellen, anschließend die eigentliche Ursache untersuchen.

Jede Diagnose sollte nachvollziehbar dokumentiert werden.

Bekannte Lösungen sind schneller als neue Vermutungen.