Systematische Fehlersuche: vom Symptom zur Ursache
Kurzantwort
Systematische Fehlersuche bedeutet, das Problem erst genau zu beschreiben, dann den Bereich einzugrenzen und Hypothesen einzeln zu prüfen – statt auf Verdacht Dinge zu verändern. Bei Netzwerkstörungen dient das OSI-Modell als Raster: von unten nach oben prüfen. Wichtigste Regel: immer nur eine Änderung auf einmal und alles dokumentieren.
Teil des Lernpfads IT-Service und Projekte · Schritt 4 von 7
Der klassische Fehler bei einer Störung: sofort etwas verändern. Treiber neu installieren, Kabel tauschen, neu starten. Manchmal klappt es – und niemand weiß, warum. Meistens dauert es länger als ein geordnetes Vorgehen, und am Ende sind drei Dinge verändert, von denen zwei neue Probleme machen.
Warum systematisch vorgehen?
Weil Raten unbezahlte Zeit kostet und Änderungen auf Verdacht neue Fehler erzeugen. Ein methodisches Vorgehen ist reproduzierbar, nachvollziehbar und funktioniert auch bei Systemen, die du noch nicht kennst.
Das Vorgehen in sechs Schritten
1. Symptom genau erfassen Was funktioniert nicht – und was funktioniert noch?
2. Umfang eingrenzen Ein Nutzer oder alle? Ein Gerät oder alle?
3. Veränderungen prüfen Was wurde zuletzt geändert?
4. Hypothese bilden Eine konkrete, prüfbare Vermutung
5. Hypothese testen Genau eine Änderung – dann messen
6. Lösung dokumentieren Ursache, Maßnahme, Ergebnis ins TicketSchritt 2 ist der wirksamste. Die Frage „Wer ist nicht betroffen?" halbiert den Suchraum oft sofort: Wenn nur ein Arbeitsplatz betroffen ist, liegt es nicht am Server.
Schritt 3 ist der meistübersprungene. Systeme, die jahrelang liefen, fallen selten grundlos aus – meist gab es ein Update, eine Konfigurationsänderung oder einen Umbau.
Das OSI-Modell als Suchraster
Bei Netzwerkstörungen liefert das OSI-Schichtenmodell eine fertige Reihenfolge. Man prüft von unten nach oben – denn eine defekte untere Schicht lässt jede darüberliegende scheitern:
| Prüfschritt | Schicht | Frage |
|---|---|---|
| Kabel, Link-LED, WLAN-Verbindung | 1 – Bitübertragung | Besteht überhaupt eine Verbindung? |
| Switch-Port, MAC-Adresse | 2 – Sicherung | Kommt das Gerät ins lokale Netz? |
| IP-Adresse, Gateway, Ping | 3 – Vermittlung | Stimmt die Adressierung, ist das Ziel erreichbar? |
| Port erreichbar, Firewall-Regel | 4 – Transport | Wird der Dienst durchgelassen? |
| Anmeldung, Berechtigung, DNS | 5–7 | Antwortet die Anwendung korrekt? |
Zwei Regeln, die dich schützen
Selbstkontrolle
Selbstkontrolle
Ein Nutzer erreicht eine Webseite nicht. Der Ping auf die IP-Adresse des Servers klappt, der Ping auf den Namen schlägt fehl. Wo liegt der Fehler?
Häufige Fragen
Warum prüft man beim OSI-Modell von unten nach oben?
Weil jede Schicht auf der darunterliegenden aufbaut. Ohne physische Verbindung nützt die beste IP-Konfiguration nichts, und ohne funktionierende Adressierung erreicht keine Anwendung ihr Ziel. Prüfst du von unten, schließt du mit jedem Schritt einen ganzen Block möglicher Ursachen aus, statt weiter oben im Nebel zu suchen.
Was, wenn der Fehler nicht reproduzierbar ist?
Dann geht es zunächst darum, ein Muster zu finden: Tritt er zu bestimmten Zeiten auf, bei bestimmten Nutzern, unter Last, nach einem Neustart? Hilfreich sind Protokolldateien und Monitoring-Daten aus dem Zeitraum des Auftretens. Sporadische Fehler deuten oft auf Ressourcenengpässe, Wackelkontakte oder Timing-Probleme hin.
Darf ich einfach neu starten?
Ein Neustart behebt viele Störungen, aber er vernichtet auch den Zustand, in dem der Fehler analysierbar wäre. Sichere deshalb vorher relevante Informationen wie Fehlermeldungen und Protokolle. Und behalte im Hinterkopf: Ein Neustart, der hilft, ist eine Behelfslösung und keine Ursachenklärung – tritt der Fehler wieder auf, ist die Ursache noch da.
Wie erkenne ich, wann ich eskalieren sollte?
Wenn du innerhalb der vereinbarten Frist keine belastbare Hypothese mehr hast oder die nächste Prüfung Rechte und Kenntnisse erfordert, die du nicht hast. Zu lange allein weiterzusuchen gefährdet die zugesagte Lösungszeit. Wichtig ist, bei der Eskalation vollständig zu dokumentieren, was du bereits ausgeschlossen hast.
Weiterlesen: IT-Servicemanagement und ITIL: Grundlagen · MAC-Adresse und ARP: Adressierung im lokalen Netz · DHCP erklärt: automatische IP-Vergabe
Das Wichtigste in Kürze
- Erst verstehen, dann eingrenzen, dann handeln – nicht auf Verdacht ändern.
- Die stärkste Frage: Wer ist nicht betroffen?
- Immer prüfen, was zuletzt geändert wurde.
- Netzwerkfehler mit dem OSI-Modell von unten nach oben eingrenzen.
- Nur eine Änderung auf einmal – und alles im Ticket dokumentieren.