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
- RAM
- 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.