Punkt for punkt: Sådan håndterer du et it-nedbrud

Det kan være stressende at foretage fejlfinding ved nedbrud af et misisionskritisk system, men en langsom, metodisk tilgang kan i sidste ende spare tid. Her får du fem regler om, hvordan du gør.

3. oktober 2012 kl. 16.05

Matt Prigge

Computerworld News Service: Hvis du har været i it-branchen i mere end nogle få minutter, så taler sandsynligheden for, at du har set det ske:

Et missionskritisk produktionssystem går ned, og ingen har nogen idé om hvorfor.

Sådanne øjeblikke af rædsel, der afbryder ensformigheden af de mange projektmøder, udrulninger og systemopgraderinger, er i virkeligheden det, der gør it-arbejdet interessant - og er samtidig en god grund til, at dette job ikke er noget for alle.

Fejlfindingsproceduren ved tilsyneladende uforklarlige nedbrud kan være en af de mest stressende ting ved jobbet.

Ikke planlagt nedetid af et missionskritisk system kan afstedkomme hård kritik fra kolleger og ledelse i selv små virksomheder, og det bliver kun værre jo større virksomheden er, da der her som regel er mere på spil.

Dumme fejl

Dette pres får ofte selv de mest erfarne ingeniører til at gøre meget dumme fejl, hvilket kan forværre problemet yderligere og forlænge nedetiden.

Det er ikke let at holde hovedet koldt i en stressende situation, ligegyldigt hvor mange gange man har oplevet noget lignende.

Men der findes fem nemme regler, som du kan føje til din nødprocedure til fejlfinding.

De vil hjælpe dig til definitivt at bevise årsagen til nedbruddet, løse problemet hurtigere og undgå at forværre tingene.

1. Gør ikke skaden værre

Når man står overfor et tilsyneladende uforklarligt nedbrud, vil det være en naturlig impuls at kaste sig hovedkulds ud i et løsningsforsøg og begynde at foretage den ene ændring efter den anden for at prøve at løse problemet hurtigst muligt.

Selvom denne tilgang godt kan virke og endda løse problemet hurtigt, så er der en stor risiko for, at man ender med at forværre situationen.

Fejlfindings-tiltag såsom genstart af et ustabilt system eller automatisk reparation af database eller filsystem kan meget vel rette fejlen og få systemet tilbage i produktionstilstand.

Men de kan også betyde, at du mister din bedste chance for at gendanne data, enhver mulighed for at fastslå den underliggende årsag og ender med at forlænge nedbruddet væsentligt.

Sådan bør du gøre umiddelbart efter nedbruddet

I stedet er det bedste første skridt ved ethvert uforklarligt nedbrud også det, der muligvis føles mindst naturligt:

Tag en dyb indånding og overvej omhyggeligt, hvordan du kan annullere alle de ændringer, som du om lidt vil foretage i forsøget på at finde problemet.

Det kan være ting som at lave backup af konfigurationen, tage øjebliksbilleder af virtuelle maskiner eller SAN, lave kopier af logfiler, der måske slettes eller overskrives, samt kopiere ødelagte data til et upåvirket system.

Det føles måske forkert at gøre disse ting som det allerførste, fordi de tager værdifuld tid, mens stressniveauet er på sit højeste, og fordi de ikke direkte gør noget for at løse problemet.

De to store gevinster

Men du opnår to vigtige mål ved alligevel at gøre disse ting.

For det første, hvis din fejlfinding ender med at forværre tingene - såsom hvis den server, du beslutter at genstarte, slet ikke vil starte op igen - så vil du være meget bedre forberedt til at få aktuelle data op at stå på et nyt system.

For det andet, hvis din første runde af hektiske tryk på knapperne faktisk løser problemet, så har du i forvejen alle de data, du har brug for, til senere at rekonstruere problemet, så du kan finde ud af, hvad årsagen var.

At man ikke formår at løse et problem, er ikke meget værre, end at man løser det, uden at vide hvordan eller hvorfor løsningen fungerede.

Ikke alene vil man ikke være i stand til at forklare hændelsen for resten af virksomheden, men man vil heller ikke kunne give nogen reelle garantier om, at det ikke vil ske igen.

Husk dette vigtige punkt, når uheldet indtræffer

2. Tag notater

Sørg for helt fra starten at nedfælde en detaljeret beskrivelse af, hvad du observerer, og hvilke fejlfindings-trin, du forsøger, inklusiv det nøjagtige tidspunkt, hvis det er muligt.

Ligesom den første regel vil denne tilsyneladende stjæle værdifulde minutter i en situation, hvor tiden er helt afgørende, men faktisk kan også denne regel ende med at spare tid på længere sigt.

For det første afholder det dig fra at løbe i cirkler og forsøge de samme ting igen og igen - hvilket faktisk sker ret tit, når stressniveauet er højt.

For det andet, hvis du bliver nødt til at involvere leverandør-support, vil du have en omfattende liste over, hvad du allerede har forsøgt, så support-folkene ikke foreslår de samme ting en gang til.

For det tredje vil du kunne sammenligne dine egne angivelser af tidspunkt for hvert fejlfindings-forsøg med logfilernes tidsstempler.

Uden den mulighed ville du være nødt til at foretage alle fejlfindings-trinnene en gang til for at isolere, hvilken logning de genererer, hvilket er en del mere tidskrævende.

3. Læs grundigt op om problemet
Hvis du virkelig har ryggen mod muren, vil du uundgåeligt gribe efter halmstrå i forsøget på at finde ud af, hvordan dit problem løses (med andre ord søge på Google).

Med mindre du har at gøre med en utrolig specifik fejl, så kan du sandsynligvis finde adskillige folk, der har beskrevet problemer, der minder om det, du selv står med.

Her er det helt afgørende, at du forholder dig kritisk til disse beskrivelser af tilsyneladende det samme problem.

I mange tilfælde vil du opdage, at selvom symptomerne er ens, så er omstændighederne helt forskellige.

Jeg har set folk, der har spildt oceaner af tid på at jagte en løsning af et helt ubeslægtet problem - hvilket kunne være undgået ved hjælp af en mere omhyggelig læsning af problembeskrivelsen.

Sådan sparer du tid, når uheldet indtræffer

Hvis du arbejder som del af et team på at løse det samme problem eller prøver at holde vrede brugere stangen, vil du hurtigt opdage, at kommunikation er meget vigtig.

Det gælder både, når det handler om at holde brugerne informeret om, hvad du foretager dig (og at du faktisk arbejder på at løse problemet), og til at sørge for at teammedlemmerne ikke falder over hinanden.

I store team er det et godt første skridt at udpege en person, der skal holdes opdateret med, hvad hele teamet laver - den person kan så kommunikere med de ramte brugere og sørge for, at alle i teamet har et nogenlunde overblik over, hvad de andre laver.

5. Vær forberedt
Selvom der ikke er nogen skudsikker måde at forberede sig på uforudsete hændelser, så er der mange ting, man kan gøre, som vil spare masser af tid, hvis der sker noget uventet.

For eksempel er det en god idé at en have bærbar med et program til protokolanalyse såsom Wireshark sluttet til en port i den centrale switch.

Hvis du nogensinde får brug for at fejlfinde problemer i netværket, vil du således være 15 til 20 minutter tættere på en løsning, fordi du slipper for at skulle sætte det op i kampens hede.

Centraliseret netværksovervågning og logning gør det også langt lettere at sammenligne hændelser i netværket med hændelser i programmerne og på den måde kredse sig ind på problemets årsag.