# Systematische Fehlersuche: vom Symptom zur Ursache > 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. **Autor:** Mr. Benjamin · **Beruf:** IT-Grundlagen **Veröffentlicht:** 2026-07-24 · **Aktualisiert:** 2026-07-24 **Quelle:** https://yellowbluetech.de/blog/systematische-fehlersuche --- 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. > **Merksatz** > > Der Kern der Methode: **erst verstehen, dann eingrenzen, dann handeln.** Jede Änderung ist ein Test einer konkreten Vermutung – kein Versuch aufs Geratewohl. ## Das Vorgehen in sechs Schritten ```text 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 Ticket ``` Schritt 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](/blog/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](/blog/ip-adresse-erklaert), Gateway, Ping | 3 – Vermittlung | Stimmt die Adressierung, ist das Ziel erreichbar? | | Port erreichbar, Firewall-Regel | 4 – Transport | Wird der Dienst durchgelassen? | | Anmeldung, Berechtigung, [DNS](/blog/was-ist-dns) | 5–7 | Antwortet die Anwendung korrekt? | > **Prüfungstipp** > > „Ein Rechner hat keinen Netzwerkzugriff – wie gehen Sie vor?" ist eine Standardaufgabe. Antworte **strukturiert von unten nach oben**: erst die physische Verbindung, dann die IP-Konfiguration, dann Namensauflösung und Anwendung. Nenne dabei konkrete Werkzeuge: `ping` auf das Gateway prüft Schicht 3, ein erfolgreicher Ping auf die IP bei fehlgeschlagenem Ping auf den Namen zeigt ein **DNS-Problem**. ## Zwei Regeln, die dich schützen > **Hinweis** > > **Immer nur eine Änderung auf einmal.** Änderst du drei Dinge gleichzeitig und es funktioniert, weißt du nicht, welche geholfen hat – und die anderen beiden bleiben als unbemerktes Risiko im System. Mach jede erfolglose Änderung wieder rückgängig, bevor du die nächste testest. > > **Dokumentiere im Ticket, nicht im Kopf.** Was du geprüft und ausgeschlossen hast, ist für die nächste Ebene bei einer Eskalation genauso wertvoll wie die Lösung selbst. Wie das organisatorisch eingebettet ist, steht im Beitrag zu [Ticketsystem und Support-Level](/blog/ticketsystem-support-level). ## Selbstkontrolle **Frage:** 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? - [ ] Am Netzwerkkabel - [ ] An der IP-Konfiguration des Rechners - [x] An der Namensauflösung durch DNS - [ ] Der Server ist ausgefallen **Erklärung:** Wenn die IP erreichbar ist, funktionieren die Schichten 1 bis 3. Scheitert nur der Zugriff über den Namen, kann der Name nicht in eine IP-Adresse aufgelöst werden – das ist Aufgabe des DNS. Der Fehler liegt also in der Namensauflösung, nicht in der Verkabelung oder Adressierung. ## 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](/blog/itil-servicemanagement) · [MAC-Adresse und ARP: Adressierung im lokalen Netz](/blog/mac-adresse-und-arp) · [DHCP erklärt: automatische IP-Vergabe](/blog/dhcp-erklaert) ## 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.