Hier grenzen Sie mit einem Test einen einzelnen Fehler ein, vergleichen das erwartete und das tatsächliche Ergebnis und wählen die nächste Aktion aus. Die Methode kann auf eine Anwendung, einen Container oder einen Netzwerkdienst angewendet werden. Sie benötigen eine bekannte Benutzeraktion, die hätte funktionieren sollen, sowie Zugriff zur Untersuchung der betreffenden Lösung.

Beginnen Sie mit den sieben Schritten und „Erwartetes gegen Tatsächliches testen“ und wenden Sie diese in Aufgabe 1 an. Die Netzwerkreihenfolge dient als Unterstützung, wenn der Fehler das Netzwerk betrifft. Die Tabelle für Linux/Proxmox ist ein Beispiel und keine Befehle, die Sie bei jedem Fehler ausführen müssen. Der Selbsttest ist eine optionale Übung.

Möchten Sie sehen, wie die Methode auf einen konkreten Fehler angewendet wird, folgen Sie dem Link [[Feilsokingsmetode Level 2 - Modellert feilsiking av en app|modellierte Fehlersuche einer App]]. Dort begründen Sie den nächsten Test, bevor Sie den Vorschlag für die Antwort öffnen.

Die sieben Schritte

1. Umstände kartieren. Was geschah und wann begann es?
2. Fehler reproduzieren, wenn es sicher ist, ihn erneut auszulösen.
3. Mögliche Fehlerquellen lokalisieren und eingrenzen – welche Schicht oder Komponente könnte betroffen sein?
4. Informationen sammeln – Logs, Fehlermeldungen, Befehlsausgaben.
5. Mögliche Lösungen bestimmen auf Basis dessen, was Sie jetzt wissen.
6. Eine Lösung oder Hypothese nach der anderen testen. Wenn Sie mehrere Dinge gleichzeitig ändern, wissen Sie nicht, was das Problem tatsächlich gelöst hat.
7. Den Fehler und die Lösung dokumentieren, damit Sie (oder andere) sie beim nächsten Mal wiedererkennen können.

Fehlerbehebung-Reihenfolge für Netzwerke und Dienste

Wenn Sie nicht wissen, wo ein Netzwerkfehler liegt, bietet diese Reihenfolge einen Ausgangspunkt. Wenn Sie bereits relevante Testergebnisse haben, verwenden Sie diese, um zu wählen, wo Sie weiter untersuchen müssen. Es ist nicht erforderlich, alle Netzwerktests für einen Codefehler auszuführen.

flowchart TD
    A[Physische Verbindung] --> B[Netzwerkinterface]
    B --> C[IP-Konfiguration]
    C --> D[Lokales Netzwerk]
    D --> E[Gateway und Routing]
    E --> F[DNS]
    F --> G[Dienst]

Video: So testen Sie die Netzwerkverbindung mit Ping

Das Video zeigt, wie ping verwendet werden kann, um zu überprüfen, ob ein Gerät im Netz erreichbar ist.

Für jeden Punkt sollten Sie in der Lage sein:

• zu erklären, was der Kontrollpunkt tatsächlich überprüft
• die relevanten Werte mit dem richtigen Befehl abzurufen (siehe [[Protokolle Ebene 1 - Netzwerkprotokolle|🌐 Netzwerkprotokolle]] für ping, nslookup usw.)
• eine Beobachtung von einer Annahme zu unterscheiden
• den nächsten Prüfschritt basierend auf dem Ergebnis des vorherigen Schritts auszuwählen und nicht anhand eines Bauchgefühls

Befehle pro Ebene in einer Linux-VM in Proxmox

Dies ist eine Anwendung der Methode, wenn sich eine Linux-VM nicht mit einem Dienst verbindet. Führe die relevanten Befehle im Konsolen-Fenster der VM aus und nicht in der Shell des Proxmox-Gastgebers. Siehe bei Bedarf 🧭 In Proxmox VE navigieren. Wähle den Test für das, was du untersuchst; die Tabelle ist keine Voraussetzung für Aufgabe 1.

Fehlt der Standardroute, untersuche, wie sich die VM an Ziele außerhalb des eigenen Netzes wenden soll; einzelne Ziele können eigene Routen haben. Einige Netze blockieren ping, daher beweist ein fehlendes Echo allein nicht, dass die Verbindung unterbrochen ist. Wenn Namensauflösung und Paketquellen funktionieren, hast du konkrete Ergebnisse für weitere Schritte zur Verfügung. 🌐 IP, Subnetz und Standard-Gateway erklärt Adresse, Präfix und Route.

Erwarteter vs. tatsächlicher Wert

Ein Fehlersuchtest ist nur nützlich, wenn Sie wissen, was Sie erwarten, bevor Sie ihn ausführen. Notieren Sie:

Anforderung:       Was soll der Benutzer tun können?
Ziel:              Welche Adresse/Dienst testen Sie?
Erwartet:          Was soll passieren, wenn alles funktioniert?
Tatsächlich:       Was ist passiert?
Zeigt:             Was beweist dieses Ergebnis?
Beweist nicht allein: Was beweist dieses Ergebnis NICHT?

Aufgabe 1 - Anwendung der Methode auf ein reales Problem

Nehmen Sie ein Problem aus einem anderen Betrieb- oder Entwicklungsthema (ein Container startet nicht, ein Dienst ist nicht erreichbar, ein Skript schlägt fehl):

1. Gehen Sie die sieben obigen Schritte nacheinander durch.
2. Notieren Sie für jeden Test, den Sie durchführen, „erwartetes Ergebnis vs. tatsächliches Ergebnis“.
3. Halten Sie fest, welche Komponente oder welcher Layer durch den Test eingegrenzt wird. Verwenden Sie die Netzwerk-Reihenfolge nur dann, wenn sie zum Problem passt.
4. Versuchen Sie eine begründete Korrektur in einer Testumgebung, die Sie ändern dürfen. Wiederholen Sie die ursprüngliche Benutzeraktion und stellen Sie sicher, dass die Korrektur tatsächlich wirkt. Bewahren Sie einen Weg zurück zur vorherigen Konfiguration auf.

Falls keine Fehler verfügbar sind, können Sie dieses Beispiel analysieren: Eine App liefert unter / die erwartete Seite, gibt aber HTTP 404 unter /status. Was zeigen die beiden Antworten an, und was würden Sie zuerst untersuchen? Beide Anfragen erhielten eine HTTP-Antwort; die erste Überprüfung besteht darin zu klären, ob /status tatsächlich in der App existiert und ob der Client die richtige Route verwendet. Das Beispiel dient als Analyseaufgabe und belegt nicht, dass Sie eine eigene Lösung korrigiert haben.

Prüfpunkt: Der Fehler ist eingegrenzt und kontrolliert

Zeigen Sie das Testprotokoll an und erklären Sie, welche Beobachtung die nächste Tests oder die Korrektur gestützt hat. Nach der Korrektur muss die ursprüngliche Aktion das erwartete Ergebnis liefern. Sie können dies mündlich oder schriftlich mit Befehlen und Ergebnissen vor Ihnen erläutern. Wenn der Fehler weiterhin offen ist, geben Sie an, was getestet wurde, was noch unsicher ist und einen präzisen nächsten Test. Schreiben Sie keine vermutete Ursache als bestätigt nieder.

Selbsttest

Optionale Selbsttests mit Feedback. Die Antworten werden nicht an die Lehrkraft gesendet. Verwenden Sie Ihr eigenes Protokoll, um das tatsächliche Debugging zu dokumentieren; der Selbsttest ersetzt nicht die praktische Überprüfung.

Zusammenfassung

• Fehlersuche ist eine Methode, kein Raten – sieben feste Schritte von der Erfassung bis zur Dokumentation
• Die Halbierungsverfahren kann eine Kette eingrenzen, wenn Sie die Glieder kennen, die der Test verwendet
• Für Netzwerke: Verwenden Sie die Schichten, um aus dem Beobachteten einen passenden nächsten Test zu wählen
• Notieren Sie immer das Erwartete im Vergleich zum Tatsächlichen, bevor Sie testen, und denken Sie daran, dass ein einzelner Test selten alles beweist