3.6 Erstdiagnose, Lösung und funktionale Eskalation (Teil 2/2) 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 der Incident mit den vorhandenen Kenntnissen, Werkzeugen oder Berechtigungen nicht gelöst werden, erfolgt eine funktionale Eskalation an eine geeignete Fachgruppe. Ziele der Erstdiagnose Die Erstdiagnose soll möglichst schnell klären: Was funktioniert nicht? Was funktioniert weiterhin? Wer oder was ist betroffen? Seit wann besteht die Beeinträchtigung? Welche Auswirkungen entstehen? Gab es kurz zuvor einen Change? Ist bereits ein ähnlicher Incident bekannt? Existiert ein dokumentierter Workaround? Kann der Service Desk den Incident direkt lösen? Welche Fachkenntnisse werden andernfalls benötigt? Eine gute Erstdiagnose reduziert: unnötige Rückfragen, doppelte Prüfungen, falsche Eskalationen, lange Bearbeitungszeiten, und vermeidbare Serviceunterbrechungen. Erstdiagnose und Ursachenanalyse unterscheiden Die Erstdiagnose gehört in 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 Dienst kontrolliert neu starten Funktion testen Benutzer informieren Service wiederherstellen Problem Management Ursache des Absturzes untersuchen Speicherverbrauch analysieren Softwarefehler prüfen dauerhafte Korrektur planen Merke Ein Incident kann gelöst sein, obwohl die eigentliche Ursache noch nicht bekannt oder beseitigt ist. Symptom, 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 Zu Beginn eines Incidents ist häufig 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: beobachten Informationen sammeln Umfang bestimmen Hypothesen bilden Hypothesen testen Ergebnisse bewerten Service wiederherstellen 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 alle Geräte oder nur ein 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: Nach Eingabe der Zugangsdaten sollte innerhalb weniger Sekunden die Startseite 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 Viele Incidents treten 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 aufwendigen 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 den betroffenen Service? Ist es ein Fehler, eine Warnung oder nur eine Information? Tritt die Meldung auch im Normalbetrieb auf? Gibt es zeitlich 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 erwartetes Verhalten tatsächliches Verhalten Fehlermeldung Beispiel: Anwendung öffnen Auftrag auswählen „PDF exportieren“ anklicken Anwendung beendet sich ohne Meldung Zusatz: tritt bei drei getesteten Aufträgen auf nur Desktop-Version betroffen Webversion funktioniert Vom Einfachen zum Komplexen Eine sinnvolle Praxisreihenfolge kann sein: Meldung und Auswirkungen verstehen bekannte Störungen prüfen offensichtliche Voraussetzungen prüfen Änderungen vergleichen Monitoring und Logs auswerten Fehlerbereich eingrenzen Hypothesen testen Spezialisten einbinden Dies ist keine feste ITIL-Vorgabe. Es verhindert jedoch, dass sofort mit besonders aufwendigen oder riskanten Maßnahmen begonnen wird. Ausschlussverfahren Beim Ausschlussverfahren werden mögliche Fehlerbereiche systematisch geprüft. Beispiel: VPN-Verbindung funktioniert nicht. Prüfung Ergebnis Internetverbindung vorhanden ja DNS-Auflösung funktioniert ja VPN-Gateway erreichbar ja Benutzerkonto aktiv ja MFA erfolgreich ja Client-Zertifikat gültig nein Damit wurde der Fehler auf das Zertifikat eingegrenzt. Merke Jeder Test sollte eine konkrete Hypothese bestätigen oder verwerfen. Hypothesen dokumentieren 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: DNS ändern Firewall-Regel anpassen Dienst neu starten Zertifikat erneuern Server neu starten Wenn der Service anschließend funktioniert, ist nicht erkennbar, welche Maßnahme wirksam war. Besser: Maßnahme planen Risiko bewerten Maßnahme durchführen Ergebnis prüfen dokumentieren erst danach nächsten Schritt festlegen Produktive Änderungen müssen entsprechend den Regeln des Change Enablement durchgeführt werden. Neustarts bewusst einsetzen Ein Neustart kann ein sinnvoller Workaround sein. Er darf jedoch nicht reflexartig verwendet werden. Vorher sollte geprüft werden: Gehen flüchtige Diagnoseinformationen verloren? Werden Benutzer oder andere Services unterbrochen? Besteht Datenverlustrisiko? Ist eine Genehmigung erforderlich? Gibt es eine weniger eingreifende Maßnahme? Kann der Fehler nach dem Neustart weiterhin analysiert werden? ... (Fortsetzung wegen Nachrichtenlängenlimit erforderlich)