De strukturerede fejlsøgningstrin

Identificér problemet ved at indsamle oplysninger fra brugere, logfiler og dine egne test. Spørg, hvad der blev ændret, hvornår problemet begyndte, og hvem der er berørt. Stil spørgsmål ved det indlysende, og genskab problemet, hvis du kan. En klar og specifik problemformulering som "intet internet fra det trådløse netværk på anden sal" hjælper med at styre alt det efterfølgende. En vag formulering fører til en vag løsning.

Opstil en teori om den sandsynlige årsag. Form ud fra symptomerne et kvalificeret gæt på, hvad der er galt. Begynd med de mest sandsynlige og enkleste årsager, de såkaldte "lavthængende frugter", før du undersøger sjældne årsager. Hvis en enkelt pc ikke har netværk, er et defekt kabel mere sandsynligt end en fejl i en routingprotokol. Du kan have flere mulige teorier.

Test teorien for at fastslå årsagen. Udfør en kontrol, der bekræfter eller afkræfter dit gæt. Gå videre, hvis teorien bekræftes. Hvis ikke, skal du opstille en ny teori og teste igen eller eskalere problemet til en person med større ekspertise eller adgang. Begynd aldrig at reparere, før du faktisk har bekræftet årsagen, ellers kan du ødelægge dele, der fungerer.

Læg en handlingsplan, og identificér mulige konsekvenser. Beslut præcis, hvad du vil gøre, i hvilken rækkefølge, og hvad der kan gå galt. Overvej nedetid, berørte brugere og en vej til at rulle ændringen tilbage, hvis løsningen mislykkes. Planlægning forhindrer, at en hurtig løsning på én enhed ved et uheld forstyrrer et helt netværkssted. Større ændringer kræver større og mere omhyggelige planer.

Implementer løsningen i overensstemmelse med din plan, eller eskaler problemet, hvis det ligger uden for din beføjelse eller kunnen. Foretag om muligt én ændring ad gangen, så du kan se, hvad der faktisk løste problemet. Under implementeringen skal du overholde reglerne for ændringsstyring og vedligeholdelsesvinduer, så trafikken i driftsmiljøet forstyrres mindst muligt.

Kontrollér, at hele systemet fungerer, og implementer om nødvendigt forebyggende foranstaltninger. Bekræft ikke kun, at det oprindelige symptom er væk, men også at intet andet er gået i stykker. Bed brugeren om at teste, og kontrollér relaterede tjenester igen. Hvis et defekt kabel forårsagede udfaldet, kan du også mærke kabeltrækket eller udskifte det slidte kabel ved siden af for at forhindre en gentagelse.

Dokumentér resultater, handlinger og udfald. Notér symptomet, årsagen, hvad du gjorde, og resultatet. God dokumentation gør den næste lignende hændelse hurtigere at løse, understøtter videndeling og skaber et revisionsspor. Dette sidste trin er let at springe over under pres, men det er det, der forvandler en enkeltstående løsning til varig organisatorisk viden.

Som en del af metoden vælger teknikere ofte en retning ved hjælp af OSI-modellen. Nedefra og op begynder ved det fysiske lag (kabler, forbindelser) og arbejder opad. Det er nyttigt, når der er mistanke om et totalt nedbrud. Oppefra og ned begynder ved applikationen og arbejder nedad. Det er nyttigt, når en applikation opfører sig forkert, men forbindelsen ser ud til at fungere. Metoden del og hersk begynder i midten for at opdele problemområdet.

Vær opmærksom på vaner, der ødelægger metoden: at ændre flere ting på én gang, så du ikke kan se, hvad der virkede, at springe kontrollen over eller at glemme at dokumentere. Modstå også bekræftelsesbias, altså trangen til at blive ved med at tro på en teori, efter at beviserne modsiger den. Det er disciplinen i at følge hvert trin i den rigtige rækkefølge, der gør metoden pålidelig under pres.

Du har lært den strukturerede metode. Vigtige punkter:

• Syv trin: identificér, opstille en teori, test, planlæg, implementér, kontrollér, dokumentér.
• Begynd med de enkleste sandsynlige årsager.
• Bekræft årsagen, før du reparerer; eskalér efter behov.
• Metoder: nedefra og op, oppefra og ned samt del og hersk.
• Kontrollér og dokumentér altid, også under pres.