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.