Teste teorier og lage en plan

Hvis testen bekrefter teorien Deres, går De videre til planleggingen av løsningen. Hvis den ikke gjør det, må De ikke tvinge teorien gjennom; formuler en ny teori og test på nytt. Feilsøking går ofte flere ganger frem og tilbake mellom teori og testing. Hver teori som avkreftes, snevrer likevel inn mulighetene, så selv en «mislykket» test bringer Dem nærmere den virkelige årsaken.

Noen ganger ligger årsaken utenfor Deres tilgang, kompetanse eller myndighet, for eksempel ved et ISP-avbrudd eller en kjernesvitsj De ikke har tilgang til. I slike tilfeller bør De eskalere saken til en erfaren tekniker, et annet team eller leverandøren. Eskalering er ikke et nederlag; det er riktig fremgangsmåte når det å fortsette alene vil sløse med tiden eller innebære risiko for skade. Gi videre alt De har lært så langt.

Når årsaken er bekreftet, lager De en handlingsplan. Beskriv de nøyaktige trinnene, rekkefølgen og det forventede resultatet. En skriftlig plan holder en stressende reparasjon organisert og gjør det mulig for andre å gå gjennom den. For alt som påvirker produksjonen, er en tydelig plan forskjellen mellom en smidig reparasjon og en improvisert endring som skaper nye avbrudd.

En del av planleggingen er å spørre: «Hva kan denne endringen ødelegge?» Hvis De starter en svitsj på nytt, mister alle enhetene på den forbindelsen; hvis De endrer en nettmaske, kan verter bli isolert; hvis De oppdaterer fastvaren, kan innstillingene bli tilbakestilt. Ved å identifisere mulige konsekvenser på forhånd kan De varsle brukere, planlegge nedetid og forberede Dem på bivirkninger i stedet for å bli overrasket av dem.

Planlegg alltid en vei tilbake. Før De endrer en konfigurasjon, bør De lagre den nåværende, slik at De kan gjenopprette den hvis endringen mislykkes. En tilbakerullingsplan gjør en risikabel endring reversibel. Når De vet at De kan angre endringen, reduseres stresset, og De unngår at en mislykket retting utvikler seg til et langvarig driftsavbrudd mens De forsøker å gjenopprette systemet.

I administrerte miljøer følger endringer endringskontroll: De dokumenteres, godkjennes og planlegges ofte i et vedlikeholdsvindu når påvirkningen er minst. Denne formaliteten kan føles langsom, men den hindrer at én persons velmente retting forstyrrer virksomheten i de travleste timene. Selv små nettverk har nytte av en forenklet versjon av denne disiplinen.

Når De implementerer en endring, bør De endre én ting om gangen og teste etter hver endring. Hvis De endrer fem innstillinger samtidig og problemet forsvinner, vet De ikke hvilken endring som virket, eller om De samtidig introduserte et nytt problem. Enkeltstående, testede endringer gjør årsak og virkning tydelig, noe som er avgjørende både for korrekt feilsøking og dokumentasjon.

Fortell berørte brukere og kolleger hva De skal gjøre, og når det skal skje, særlig hvis det blir nedetid. Tydelig kommunikasjon skaper realistiske forventninger, reduserer frustrerte henvendelser og gir folk mulighet til å lagre arbeidet sitt. Et uventet driftsavbrudd, selv et planlagt, svekker tilliten. En kort forhåndsvarsling gjør en forstyrrende retting til en kontrollert og profesjonell hendelse.

Med en testet teori, en trinnvis plan, oversikt over bivirkninger, en klar tilbakerulling og informerte interessenter er De forberedt på å implementere endringen på en trygg måte. Denne grundige forberedelsen er det som skiller pålitelige teknikere fra dem som gjetter og håper. Den neste fasen, implementering og verifisering, blir dermed enkel og lite risikofylt.

De har lært å teste teorier og planlegge. Viktige punkter:

• Test en teori før De retter problemet; bekreft den eller formuler en ny teori.
• Eskalér når årsaken ligger utenfor det De kan håndtere.
• Lag en plan med trinn, mulige virkninger og en tilbakerulling.
• Bruk endringskontroll og vedlikeholdsvinduer i produksjonsmiljøer.
• Gjør én endring om gangen, og kommuniser planen.