En praktisk tilnærming
Introduksjon
Artikkelen definerer et planverk som skal gjøre det enklere å finne årsaken til feilsituasjoner, noe som ofte omtales som Root Cause Analysis, med fokus på Windows baserte systemer. Målgruppen er 3.linje support og driftsteam. Jeg definerer en analyseprosess og et sett med verktøy. Analyseprosessen skal være generisk nok til å passe de fleste miljøer, mens verktøyene er mer tenkt som en verktøykasse der man tar frem det man tror passer best til en gitt problemstilling.
Jeg har valgt å fokusere på en metodisk prosess, da jeg av erfaring vet at det er lett å få skylapper når man begynner å grave seg ned i et problem. Dette skjer uansett om man har en overordnet feilsøkingsprosess eller ikke, da det finnes svært få definerte prosesser for den faktiske feilsøkingen. Slike prosesser er ofte for overordnet eller fokusert på enkeltverktøy. Målet er ikke å ta bort skylappene helt, men å vite når man skal ta dem av og når man skal ha dem på.
Ideen kom en kveld etter en lang feilsøkingsøkt der vi til slutt fikk et system opp igjen etter å ha begynt på nytt og byttet innfallsvinkel. Jeg begynte å diskutere metodikk med en kollega, og vi kom frem til at de metodene vi lykkes best med egentlig har sin rot langt utenfor IT. Jeg henter inspirasjon fra metoder som egentlig brukes til etterforskning, førstehjelp og ettersøkning av savnede, fagfelt som sjelden assosieres med IT. Jeg bestemte meg for å skrive ned og publisere disse tankene, og håper de er til glede og eller nytte for andre.
Alle eksempler er hentet fra en Windows-verden, da det er det jeg jobber med. Prosessen i seg selv bør dog kunne tilpasses til bruk i ethvert IT-system der man leverer eller drifter en tjeneste.
Dette er et dokument under utarbeidelse, og jeg oppdaterer det innimellom etter hvert som jeg får skrevet ferdig flere kapitler eller for å rette opp feil og uklarheter.
Relasjon til ITIL
Dette er ikke ment som en erstatning for Incident Management eller Problem Management prosessene i ITIL, prosessen er ment som et tillegg og fokuserer mest på det som i ITIL heter Investigation & Diagnosis. Dersom du ikke bruker ITIL må du selv finne ut hvor den passer inn i arbeidsflyten din.
Ordet problem brukes her også synonymt med Incident og Event, og ikke bare for å referere til et Problem i ITIL terminologi. Med sak menes en sak i det saksbehandlingsverktøy man måtte ha, for eksempel MS System Center Service Manager.
Symptomer og tegn
Jeg mener at det er viktig å skille mellom symptomer og tegn, eller for å si det på en annen måte, skille mellom følelser og fakta. Jeg definerer et symptom som noe brukeren eller vi selv opplever som galt, mens funn er noe som er målbart, for eksempel en feilmelding i en logg eller en nettverkskobling som er nede. Dette er et sentralt konsept i planverket, derfor beskriver jeg dette først.
Symptomer kan også være målbare, men så lenge man ikke har samlet inn data og målt er det et symptom. Noen eksempler:
· «Pålogging går treigt» er et symptom, «pålogging tar 10 sekunder mer enn grenseverdien» er et funn.
· «Programmet krasjer ofte» er et symptom, «programmet krasjet 10:15, 10:28, 10:35 og 10:45 den 30/3 2012» er et funn.
· «Programmet virker ikke» er et symptom, «forsøk på å starte programmet og logge på klokka 13:42 30/3 2012 resulterte i feilmeldingen Access Denied» er et funn.
Et symptom kan ha en veldig fri form, alt som beskriver noe som er galt eller mistenkelig og som er relatert til saken er et symptom. Et funn krever derimot mer struktur. Et funn skal som minimum inneholde:
· En feilmelding, loggbeskjed, beskrivelse eller bilde som dokumenterer en spesifikk hendelse som man tror er relatert til saken
· Ett eller flere tidspunkt for når hendelsen oppstår, avrundet til nærmeste minutt eller sekund.
Om man er heldig, inneholder det også noe om årsak og konsekvens. For eksempel «når jeg gjør A skjer B istedenfor C». Et funn trenger ikke å være en feilmelding, det kan også beskrive en normalsituasjon som man mistenker at er relatert til saken.
Ved å ha et tydelig skille mellom funn og symptomer er det lettere å vurdere dem opp mot hverandre.
Analyseprosessen
Motta saken
All feilsøking har sitt utspring i en feilmelding. Hvordan feilmeldingen åpenbarer seg kan dog variere, og det avgjør ofte hvordan saken håndteres videre. Hovedpoenget her er at man må sørge for at de prosesser man har for incident management, problem management, eller andre tilsvarende prosesser blir fulgt. Ellers risikerer man å forsinke feilsøkingen senere i prosessen dersom man må eskalere, da man i så fall ofte må stoppe feilsøkingen for å dokumentere og informere. Uansett om det er en loggmelding, Incident, Event eller Problem omtaler jeg det som en sak for enkelthets skyld.
Saken mottas direkte fra bruker/kunde
Dette bør unngås og eventuelt videresendes til førstelinje slik at feilen logges og følger den overordnede incident-prosessen eller tilsvarende arbeidsflyt. Det ofte vanskelig å motstå fristelsen til å sjekke feilen med en gang, men selv om man føler seg sikker på at den vil komme tilbake oppover fra førstelinje, vil det å følge arbeidsflyten ofte gi bedre resultater over tid. Og man kan selvsagt gjøre begge deler, videresende nedover og feilsøke mens man venter, men da risikerer man at det utføres dobbeltarbeid ved at førstelinje jobber med saken eller eskalerer den til noen andre. Det kan derfor være en ide å gi dem et vink om at man ser på saken.
Feil oppdages under proaktivt vedlikehold
Dersom man finner en feil under vanlig proaktivt vedlikehold der man titter rundt i logger og ser om alt er som det skal være, bør man starte med å sjekke om det allerede finnes aktive saker som kan være relatert til feilen. Videre bør man undersøke om feilen påvirker brukerne, og i så fall i hvilken grad. Det er viktig at man ikke bare kaster seg inn i feilsøking og feilretting, da man igjen risikerer dobbeltarbeid og i verste fall kan gjøre feilen verre. Feilen må meldes på et vis, enten via saksbehandlingssystemet førstelinje bruker, eller på 3.linjeteamets saksbehandlingssystem om man har et eget system.
Saken mottas “tjenestevei”
Feil mottas via saksbehandlingssystemet til førstelinje eller via et automatisert overvåkingssystem som MS SCOM, nettverksovervåking eller lignende. I disse tilfellene har man vanligvis fulgt incident prosessen, problem management prosessen eller en annen prosess som leder frem til at man starter feilsøking.
Verifiser saken
Jeg har ikke tall på alle de gangene jeg har fått en feilmelding eskalert som har vært igjennom både to og tre ledd før meg, uten at noen har klart å avsløre at «feilmeldingen er feil». For å sitere en viss tv-lege: It’s a basic truth of the human condition that everybody lies. The only variable is about what.
Hovedproblemene med feilmeldinger fra brukere er at de ofte:
· Overdriver
· Krisemaksimerer
· Mangler kunnskap
· Ikke får med viktige data
· Blander feil med forespørsler om ny funksjonalitet
De fleste team har minst en person som er god på kommunikasjon med brukere, og det vil ofte bringe nytt lys over saken bare å ta en telefon til brukeren som meldte inn problemet og stille noen kontrollspørsmål. I mange tilfeller kan man etter dette omdefinere saken til en kjent problemstilling og sende den tilbake til førstelinje for oppfølging, eller registrere at brukeren ønsker en designendring.
Automatiske feilmeldinger må også verifiseres. Det går en del falske alarmer, og det hender også at feilmeldingen som alarmeres ikke er den egentlige feilen men en følgefeil.
Uansett hva som er kilde for feilmeldingen er det en del momenter som bør avklares før man går videre. Se også sjekkliste for verifisering av sak.
Primæranalyse
Nå kommer tiden for å jobbe med problemet. Bruk opptil 30 minutt på å lete etter de årsakene som først faller deg inn basert på de data du har. Noter resultatene, samle inn funn og symptomer, og sjekk så mye du har tid til. Bruk om nødvendig stoppeklokke, for det er viktig å motstå fristelsen til og “bare sjekke en ting til”. Det er ikke så viktig at denne innsatsen er koordinert, det er normalt at det er kaos i denne fasen dersom det oppstår en større feilsituasjon der flere er involvert. Det som er viktig er at det ikke utføres endringer uten at man er koordinert og følger en form for prosedyre. Vel så viktig er det at den/de som analyserer får ro til å gjøre jobben. Ved større feilsituasjoner oppstår det ofte et informasjonsvakum i denne fasen, som kan føre til at «alle» står og maser, noe som hindrer arbeidet. Man må respektere at primæranalysen tar tid, og en godt utført primæranalyse er den viktigste faktor for å få en hurtig løsning på problemet der det er mulig.
Om du tror du har en løsning alt nå, noe som ofte skjer, hopp videre i prosessen til «Endring». Om ikke, gå videre i prosessen.
Utarbeid hypoteser og klassifiser dem
Klassifisering
Om ikke primæranalysen ga umiddelbare resultater må vi gå grundigere og mer metodisk til verks. Etter min erfaring kan alle IT-problemer tilordnes en eller flere av de følgende tre kategoriene. Kategoriene er valgt ut fra at de avgrenser fagområder som vanligvis har egne team, eventuelt får man levert funksjonen fra en underleverandør. Det å forsøke å dele inn hypotesene i disse kategoriene gjør feilsøkingen enklere og vil forhåpentligvis føre til at det utarbeides hypoteser som kan bekreftes eller avkreftes.
Hardwarefeil
Feil i maskinvare på servere eller klienter involvert i tjenesten man feilsøker. Dette inkluderer en eventuell Hypervisor dersom man har virtualiserte servere. De vanligste feilene her er fysiske komponenter som feiler og mangel på fysiske ressurser ved virtualisering. Begge deler er vanligvis relativt enkelt å identifisere så lenge man har noenlunde profesjonelt utstyr.
Nettverksfeil
Noe er galt med nettverksstrukturen, data kommer ikke frem fra a til b, eller tilkoblingen mellom a og b er ustabil. De aller fleste nettverksfeil er brannmurproblemer, enten ved at programvare har byttet kommunikasjonsmetode eller ved at endringer i brannmurregler får uventede konsekvenser, eller man har rett og slett glemt å åpne opp for kommunikasjon som programvaren er avhengig av. Softwarebrannmuren i Windows ses som en del av nettverket i denne sammenhengen, selv om den ofte feilsøkes separat fra resten av nettverket. Ellers har man ustabile forbindelser og lave wan-hastigheter, samt fysiske feil som feil i swtichporter, moduler, kabler osv.
Programvarefeil
Noe er galt med programvaren, enten på operativsystemnivå eller applikasjonsnivå. Omfatter typiske feil som utdaterte drivere, fragmenterte disker, antivirusfeil, feil antivirus, oppdateringer som går skeis, feil i operativsystemet, feil i tredjepartskode, konfigurasjonsfeil osv.
Hypoteser
Ut fra de data som er hentet inn så langt i prosessen utarbeider du en eller flere hypoteser. Vanligvis velger man de funn som man syns ser mest interessante ut, og som passer best med den saken man jobber med. Man bør gjøre antakelser rundt hva som er den utløsende faktor, slik at man har et utgangspunkt for å innhente mer data. En hypotese bør altså bestå av ett eller flere funn, hva man tror det betyr for saken og en plan for hvordan man skal innhente data for å bekrefte eller avkrefte. En hypotese kan også opprettes på grunnlag av et eller flere symptom, så lenge man klarer å komme frem til en plan for innhenting av data. Det er legitimt å sjekke en hypotese man egentlig ikke tror på, for av og til er det de usannsynlige hypotesene som er de riktige, men dersom man må prioritere har disse lav prioritet.
Man bør om mulig ha minst to hypoteser, og her er det så absolutt lov å komme opp med sprø ideer, så lenge det er mulig å bekrefte eller avkrefte dem. Dersom man har mange mulige hypoteser må man prioritere dem ut fra sannsynlighet og velge noen å jobbe videre med. Jeg prøver også å samle en del standardhypoteser som kan påvirke mange forskjellige system og som kan være greie å sjekke ut uavhengig av funn, se eget kapittel.
Om man er mer enn to personer som jobber med saken, vil det være fordelaktig om hver enkelt setter seg ned og lager sine forslag hypoteser, før man møtes for å gjennomgå dem og velge ut hvilke man vil jobbe videre med. Selv om dette kan føre til at flere foreslår den samme hypotesen så vil det å dele seg erfaringsvis gi et bedre resultat enn om man setter seg ned i en større gruppe og prøver å komme frem til dem sammen. Her er det viktig å sette en tidsfrist for arbeidet for å unngå at man overanalyserer.
Som prosessen viser er dette noe man vanligvis gjør flere ganger etter hvert som man analyserer større og større mengder med data og avkrefter hypoteser.
Se også «Mal for hypotese».
Innhent data
Innhent data ut fra de hypotesene som er valgt ut. Dersom hypotesen er av en slik art at det er naturlig å få et annet team til å sjekke den ut, er det viktig at man kommuniserer tydelig hva slags svar man ønsker tilbake. Slik at man unngår den evige runddansen der teamene peker på hverandre. Hvem har vel ikke hørt driftsavdelingen si «Det må være et nettverksproblem», der nettverksavdelingen straks svarer at «Alt er i orden hos oss, det må være et programvareproblem». Istedenfor burde kommunikasjonen vært som i følgende eksempel:
Hypotese: Nettverket mellom databasecluster x og webfrontend y var ustabilt dato z.
Svar: Nettverksloggene fra verktøy a, viser at det ikke har vært unormalt høy trafikk mellom de to serverne i perioden. Videre viser loggene fra switch b og switch c som er koblet til henholdsvis databasecluster x og webfrontend y ingen feil i den nevnte perioden.
Vi stiller samme type krav til data som vi gjør til funn, de må være konkrete, faktabaserte, etterprøvbare og gjelde for et gitt tidspunkt eller tidsrom.
Sekundæranalyse
Nå er det tid for å ta frem skylappene. Det er viktig å fokusere på en hypotese om gangen, selv om man kommer over nye interessante funn. Det er hovedsakelig tre måter å analysere data på, og man velger ofte ut fra hvor god tid man har. Dersom du finner nye funn som peker på en annen mulig hypotese mens du analyserer data, noter dem og gå videre. Fall ikke for fristelsen til å skifte fokus før du er ferdig med analysen, det er viktig å fullføre hele analysen. Det samme gjelder om du halvveis i analysen tror du har en konklusjon. Målet med sekundæranalysen er å avkrefte eller bekrefte en hypotese på så solid grunnlag som mulig, og da er det viktig å sjekke mest mulig av de data du har innhentet. Det å avkrefte en hypotese er også fremskritt, og det er viktig å ha en solid analyse bak, slik at du unngår å måtte vende tilbake til hypotesen senere.
Her beskriver jeg tre måter å analysere loggdata på:
Grovanalyse
Du bruker søk og filter for å hente ut enkeltdata fra datagrunnlaget og undersøker disse nærmere. Dette er en svært raskt og relativt usikker analyse, men den kan gi gode resultater. Derfor kan det være en god ide å begynne med en grovanalyse, og så velge en annen analyseform dersom du ikke får de ønskede resultatene. Vær også obs på at en grovanalyse alene er et dårlig utgangspunkt for å avkrefte en hypotese, men dersom du har flaks kan den godt bekrefte den.
Punktanalyse
Du bruker filtrering som ved grovanalyse for å finne enkeltdata og leter rundt disse datapunktene for å se hva som skjer før og etter. Sett opp alle funn på en tidslinje dersom det er praktisk gjennomførbart, og sammenstill med eventuelle funn fra andre hypoteser. Dette er en relativt sikker analyse som vanligvis gir solide resultater. Den gir et godt grunnlag for både å avkrefte og bekrefte en hypotese, dersom hypotesen er basert på funn som eksisterer i datagrunnlaget du analyserer. Dette er den analyseformen som er mest brukt der man gjør en systematisk analyse.
Fullanalyse
Her leser/skummer du alle loggene/hele datagrunnlaget du har innhentet fra start til slutt, eventuelt utvalgte deler basert på en grovanalyse. Dette er tidkrevende og monotont arbeid som krever tung kunnskap om systemet som datagrunnlaget er hentet fra, men det kan gi resultater der en grov- eller punktanalyse kommer til kort. Denne analyseformen brukes ofte der man er veldig usikker på hvor feilen ligger eller bare har symptomer som grunnlag for hypotesen. Den kan avsløre problemer som ikke nødvendigvis gir seg utslag i feilmeldinger i datagrunnlaget du analyserer. Som ved punktanalyse er det viktig å lage en eller flere tidslinjer. Dette er en svært detaljert analyse som med sikkerhet kan avkrefte eller bekrefte en hypotese, forutsatt at hypotesen er basert på funn som kan eller skal eksistere i datagrunnlaget du analyserer. Dersom du analyserer en hypotese basert på symptomer, vil analysen kunne gi et godt grunnlag for å gjøre en kvalifisert gjetning om hvorvidt hypotesen kan avkreftes eller bekreftes. Den kan også føre til funn som kan legges til hypotesen, slik at hypotesen kan endres.
Plausible hypoteser?
Etter at sekundæranalysen er utført for alle hypotesene, eller for de du har valgt ut for analyse, tar du skylappene av og ser på resultatene samlet. Dersom man er flere som jobber med saken er dette noe som gjerne kan formaliseres som en kort workshop eller et møte, der det fortrinnsvis er noen tilstede som kan ta beslutninger om veien videre så som incident manager, problem manager, avdelingsleder, teamleder, tjenesteeier, kunde eller lignende ut fra situasjonen. Denne gjennomgangen kan også utføres før analysene er ferdige, da gjerne som følge av tidspress og eller kritikalitet.
Hver hypotese legges nå i en av følgende kategorier:
· Avkreftet, der det er sannsynlig at hypotesen ikke er årsak til problemet
· Plausibel, der det er sannsynlig at hypotesen er årsak eller medvirkende årsak til problemet.
· Bekreftet, der hypotesen er bekreftet å være årsak eller medvirkende årsak til problemet, og der en eller flere endringer er utført som fjerner hele eller deler av problemet.
· Uavklart, for hypoteser som ikke er analysert eller der vi ikke kan trekke en konklusjon ut fra analysen.
Målet er å konkludere med om vi har et eller flere forslag til løsning. Dersom du ikke klarer å trekke en konklusjon for en eller flere hypoteser kategoriseres de som uavklart, og du legger eventuelt en plan for innhenting av ytterligere data. Dersom du har flere plausible hypoteser, bør du velge hvilken du ønsker å jobbe videre med først. Hvordan du gjør det er ikke så viktig, så lenge du kommer frem til en prioritert liste. Ofte er det hvor store følger endringene får som avgjør hvilken hypotese som prioriteres først. Det er raskere å teste en hypotese som ikke krever nedetid, enn en som krever full stans av kanskje flere systemer.
Dersom du har plausible hypoteser går du videre til endringsprosessen. Om ikke må du avgjøre veien videre. Du kan for eksempel:
· Analysere videre dersom analysene ikke er ferdige
· Se om de innsamlede data gir rom for endring av hypotesene eller nye hypoteser og starte på nytt
· Gi opp
· Rette kjente feil i systemet som du kan løse og se om noe forandrer seg
På tide å gi opp?
Det er en fjellvettregel som sier at det er ingen skam å snu. På samme måte kan du komme til et punkt der det er nytteløst å fortsette, der du ikke har datagrunnlag for videre feilsøking eller rett og slett ikke klarer å løse feilen. Du kan også komme frem til at saken du forsøker å løse er på grunn av systemets design. Det er viktig å innse at det å gi opp er et mulig resultat av prosessen. Jeg har sett flere eksempler på enorm sløsing med tid og penger som følge av at man nekter å innse at et problem ikke kan løses innenfor de rammene man har, eller fordi man ikke liker den løsningen som er funnet.
Hva du gjør dersom du synes det er på tide å gi opp er vanligvis et ledelsesproblem mer enn et driftsproblem, men erfaringsvis har du følgende muligheter, litt avhengig av feilens art og alvorlighet:
· Hente inn ekstern/intern ekspertise
· Registrere problemet som et avvik og leve med det
· Skifte ut den feilende komponenten eller hele systemet
· Fullstendig reinstallasjon på ny maskinvare
De fleste problemer lar seg løse, men det betyr ikke at det er økonomisk forsvarlig å gjøre det. Og dersom du kommer over et kjent problem som er løst i en nyere versjon av systemet du jobber med, skal du tenke deg lenge og vel om før du velger å fortsette feilsøking på eksisterende versjon.
Dersom du ikke har noen plausible hypoteser og velger å fortsette, noe man vanligvis gjør noen ganger, går du som nevnt tilbake til utarbeiding av hypoteser.