Her skal du avgrense én feil med en test, sammenligne forventet og faktisk resultat og velge neste handling. Metoden kan brukes på et program, en container eller en nettverkstjeneste. Du trenger en kjent brukerhandling som skulle ha virket, og tilgang til å undersøke den aktuelle løsningen.

Begynn med de syv trinnene og «Test forventet mot faktisk», og bruk dem i Oppgave 1. Nettverksrekkefølgen er støtte når feilen gjelder nettverk. Linux-/Proxmox-tabellen er ett eksempel, ikke kommandoer du må kjøre for alle feil. Selvtesten er valgfri øving.

Vil du se metoden brukt på en konkret feil, følg modellert feilsøking av en app. Der begrunner du neste test før du åpner svarforslaget.

De syv trinnene

1. Kartlegg omstendighetene. Hva skjedde, og når begynte det?
2. Reproduser feilen når det er trygt å gjøre det på nytt.
3. Lokaliser og avgrens mulige feilkilder – hvilket lag eller hvilken komponent kan det være?
4. Innhent informasjon – logger, feilmeldinger, kommandoresultater.
5. Bestem mulige løsninger ut fra det du nå vet.
6. Test én løsning eller hypotese om gangen. Endrer du flere ting samtidig, vet du ikke hva som faktisk løste det.
7. Dokumenter feilen og løsningen, slik at du (eller noen andre) kjenner den igjen neste gang.

Feilsøkingsrekkefølge for nettverk og tjenester

Når du ikke vet hvor en nettverksfeil ligger, gir denne rekkefølgen et startpunkt. Har du allerede et relevant testresultat, bruker du det til å velge hvor du undersøker videre. Du trenger ikke kjøre alle nettverkstestene for en kodefeil.

flowchart TD
    A[Fysisk forbindelse] --> B[Nettverksgrensesnitt]
    B --> C[IP-konfigurasjon]
    C --> D[Lokalt nett]
    D --> E[Gateway og ruting]
    E --> F[DNS]
    F --> G[Tjeneste]

Video: Slik tester du nettverkstilkobling med ping

Videoen viser hvordan ping kan brukes til å undersøke om en enhet er tilgjengelig over nettverket.

For hvert punkt bør du kunne:

• forklare hva kontrollpunktet faktisk undersøker
• finne relevante verdier med riktig kommando (se 🌐 Nettverksprotokoller for ping, nslookup med mer)
• skille en observasjon fra en antakelse
• velge neste kontroll ut fra resultatet av forrige kontroll, ikke ut fra magefølelse

Kommandoer per lag i en Linux-VM i Proxmox

Dette er en anvendelse av metoden når en Linux-VM ikke når en tjeneste. Kjør relevante kommandoer i VM-ens Console, ikke i Proxmox-vertens Shell. Se 🧭 Naviger i Proxmox VE ved behov. Velg test for det du undersøker; tabellen er ikke et forkrav til Oppgave 1.

Mangler standardruten, undersøk hvordan VM-en skal nå mål utenfor eget nett; enkelte mål kan ha egne ruter. Noen nett blokkerer ping, så manglende svar beviser ikke alene at forbindelsen er brutt. Fungerer navneoppslag og pakkekilder, har du konkrete resultater å bruke videre. 🌐 IP, subnett og standard gateway forklarer adresse, prefiks og rute.

Test forventet mot faktisk

En feilsøkingstest er bare nyttig hvis du vet hva du forventer før du kjører den. Skriv opp:

Behov:            Hva skal brukeren kunne gjøre?
Mål:               Hvilken adresse/tjeneste tester du?
Forventet:         Hva skal skje hvis alt fungerer?
Faktisk:           Hva skjedde?
Viser:             Hva beviser dette resultatet?
Viser ikke alene:  Hva beviser IKKE dette resultatet?

Oppgave 1 - Bruk metoden på et reelt problem

Ta et problem du har støtt på i et annet Driftsstøtte- eller Utvikling-emne (en container som ikke starter, en tjeneste du ikke får kontakt med, et script som feiler):

1. Gå gjennom de syv trinnene over, ett om gangen.
2. Skriv «forventet mot faktisk» for hver test du kjører.
3. Noter hvilken komponent eller hvilket lag testen avgrenser. Bruk nettverksrekkefølgen bare når den passer problemet.
4. Prøv én begrunnet retting i et testmiljø du har lov til å endre. Gjenta den opprinnelige brukerhandlingen og kontroller at rettingen faktisk virker. Behold en vei tilbake til forrige oppsett.

Har du ingen feil tilgjengelig, kan du analysere dette eksemplet: En app gir forventet side på /, men HTTP 404 på /status. Hva viser de to svarene, og hva ville du undersøkt først? Begge forespørslene fikk HTTP-svar; første kontroll er om /status faktisk finnes i appen og om klienten bruker riktig rute. Eksemplet er analyseøving, ikke belegg for at du har rettet en egen løsning.

Kontrollpunkt: Feilen er avgrenset og kontrollert

Vis testloggen og forklar hvilken observasjon som støttet neste test eller rettingen. Etter retting skal den opprinnelige handlingen gi forventet resultat. Du kan forklare muntlig eller skriftlig med kommandoer og resultater foran deg. Hvis feilen fortsatt står åpen, oppgir du hva som er testet, hva som fortsatt er usikkert og én presis neste test. Ikke skriv en antatt årsak som bekreftet.

Test deg selv

Valgfri selvtest med tilbakemelding. Svarene sendes ikke til læreren. Bruk egen testlogg til å vise faktisk feilsøking; selvtesten erstatter ikke den praktiske kontrollen.

Oppsummering

• Feilsøking er en metode, ikke gjetting – syv faste trinn fra kartlegging til dokumentasjon
• Halvdelingsmetoden kan avgrense en kjede når du kjenner leddene testen bruker
• For nettverk: bruk lagene til å velge en relevant neste test ut fra det du har observert
• Skriv alltid opp forventet mot faktisk før du tester, og husk at én test sjelden beviser alt