En god fejlfindingsopgave begynder med at reducere usikkerhed. Hvad ser brugeren? Hvad forventede vi? Og hvor holder forklaringen op med at passe til det, systemet faktisk gør?
Min erfaring kommer fra mange generationer af teknologi. Som 14-årig sad jeg med maskinkode og undersøgte, hvordan programmer var lavet. Senere fulgte webudvikling, databaser, Linux, hosting, e-mail og integrationer. Nysgerrigheden er den samme: Jeg vil forstå, hvad der foregår.
Følg problemet gennem systemet
En fejl kan vise sig ét sted og opstå et andet. Derfor følger jeg den fra brugerens oplevelse gennem de relevante dele af systemet: browser, netværk, server, kode, konfiguration og data.
Den, der oplever fejlen, behøver ikke kunne forklare den teknisk. Min opgave er at stille de spørgsmål og finde de observationer, der gør det muligt at undersøge den.
- Beskriv symptomet og den forventede opførsel.
- Find ud af, hvornår fejlen opstår, og om den kan gentages.
- Undersøg logs, data og afhængigheder.
- Afprøv en forklaring med en afgrænset ændring.
- Kontrollér resultatet og de arbejdsgange, ændringen kan påvirke.
Brug erfaringen til at stille bedre spørgsmål
Erfaring hjælper mig med at vælge, hvor jeg begynder. Den erstatter ikke undersøgelsen. En fejl, der ligner noget velkendt, kan have en anden årsag denne gang.
Gamle systemer har lært mig at være opmærksom på kombinationer: en ændret konfiguration, en gammel afhængighed og data, der ikke længere passer til antagelserne i koden. Dokumentationen er et nyttigt udgangspunkt, som jeg holder op mod det, jeg kan observere.
Gør forklaringen brugbar for andre
Resultatet skal være mere end en ændring, der tilsyneladende virker. Jeg vil kunne forklare, hvad der skete, hvorfor ændringen hjælper, og hvad der stadig er usikkert.
Det giver et bedre grundlag for at vælge mellem en hurtig rettelse, en grundigere forbedring eller en plan for at udskifte en del af systemet. Og det gør det lettere for de mennesker, der skal passe løsningen bagefter.