Afprøvning af teorier og udarbejdelse af en plan

Hvis testen bekræfter din teori, skal du gå videre til planlægningen af løsningen. Hvis den ikke gør, må du ikke tvinge teorien igennem; opstil en ny teori, og test igen. Fejlfinding bevæger sig ofte flere gange frem og tilbage mellem teoriopstilling og test. Hver afkræftet teori indsnævrer stadig mulighederne, så selv en "mislykket" test bringer dig tættere på den egentlige årsag.

Nogle gange ligger årsagen uden for din adgang, ekspertise eller beføjelse, for eksempel ved et udfald hos internetudbyderen eller en central router, du ikke må røre. I sådanne tilfælde skal du eskalere problemet til en erfaren tekniker, et andet team eller leverandøren. At eskalere er ikke et nederlag; det er det rigtige valg, når det vil spilde tid eller medføre risiko for skader at fortsætte alene. Videregiv alt, hvad du har fundet ud af indtil videre.

Når du har bekræftet årsagen, skal du udarbejde en handlingsplan. Beskriv de præcise trin, rækkefølgen og det forventede resultat. En skriftlig plan holder en stressende løsning organiseret og giver andre mulighed for at gennemgå den. For alt, der berører driftsmiljøet, er en klar plan forskellen på en problemfri reparation og en improviseret ændring, der skaber nye udfald.

En del af planlægningen er at spørge: "Hvad kan denne ændring ødelægge?" En genstart af en switch afbryder alle enheder på den; en ændring af en undernetmaske kan isolere værter; en firmwareopdatering kan nulstille indstillinger. Hvis du identificerer mulige konsekvenser på forhånd, kan du advare brugere, planlægge nedetid og forberede dig på bivirkninger i stedet for at blive overrasket over dem.

Planlæg altid en vej tilbage. Før du ændrer en konfiguration, skal du gemme den aktuelle, så du kan gendanne den, hvis rettelsen mislykkes. En plan for tilbagerulning gør en risikabel ændring reversibel. Når du ved, at du kan fortryde ændringen, mindskes stress, og du undgår, at en mislykket rettelse udvikler sig til et langvarigt driftsstop, mens du forsøger at genoprette systemet.

I administrerede miljøer følger ændringer ændringsstyring: De dokumenteres, godkendes og planlægges ofte i et vedligeholdelsesvindue, hvor påvirkningen er mindst. Denne formalisme kan føles langsom, men den forhindrer, at én persons velmenende rettelse forstyrrer en virksomhed i spidsbelastningsperioder. Selv små netværk kan drage fordel af en enkel version af denne disciplin.

Når du implementerer en ændring, skal du ændre én ting ad gangen og teste efter hver ændring. Hvis du ændrer fem indstillinger på én gang, og problemet forsvinder, ved du ikke, hvilken ændring der virkede, eller om du har introduceret et nyt problem. Enkeltstående, testede ændringer gør årsag og virkning tydelig, hvilket er afgørende for både fejlfinding og nøjagtig dokumentation.

Fortæl berørte brugere og teammedlemmer, hvad du vil gøre, og hvornår du vil gøre det, især hvis der opstår nedetid. Tydelig kommunikation afstemmer forventninger, reducerer frustrerede opkald og giver folk mulighed for at gemme deres arbejde. Et overraskende driftsstop, selv et planlagt, skader tilliden. En kort orientering gør en forstyrrende rettelse til en kontrolleret og professionel hændelse.

Med en testet teori, en trinvis plan, opmærksomhed på bivirkninger, en klar tilbagerulning og informerede interessenter er du klar til at implementere sikkert. Denne omhyggelige forberedelse er det, der adskiller pålidelige teknikere fra dem, der gætter og håber. Den næste fase, implementering og kontrol, bliver derefter enkel og forbundet med lav risiko.

Du har lært at teste teorier og planlægge. Vigtige punkter:

• Test en teori, før du retter noget; bekræft den, eller formulér en ny teori.
• Eskalér, når årsagen ligger uden for din rækkevidde.
• Udarbejd en plan med trin, mulige virkninger og en tilbagerulning.
• Brug ændringsstyring og vedligeholdelsesvinduer i produktionsmiljøer.
• Ændr én ting ad gangen, og kommunikér planen.