IT-JUSS | Kirill Miazine, Føyen
Smarte SLA-målinger gir bedre tjenester
Det er langt mer enn bare oppetid som kan – og bør – måles. Innlegget kommer med noen eksempler på hvilke typer parametere kan brukes for å overvåke tjenestenivå til en leveranse og hvordan slik monitorering kan innrettes.
En av mine erfaringer er at kjøpere av IT-tjenester som regel legger vekt på to-tre SLA-parametere, som blir gjenstand for måling, rapportering og sanksjonering: oppetid, responstid ved hendelser og løsningstid ved hendelser. Er det så smart, da?
Det meste kan måles
Å kreve en viss oppetid er vel det enkleste, er det ikke det? De fleste har en eller annen formening om hva oppetid er, de ønsker at noe skal være tilgjengelig i angitt tidsperiode og setter et eller annet prosenttall for kravet om tilgjengelighet.
Det høres enkelt ut, men ofte er det langt mer som burde måles og analyseres. For hva betyr det egentlig at noe er tilgjengelig? En tjeneste kan for så vidt være tilgjengelig, men være så treg at det driver brukerne til vannvidd. Et annet system kan være oppe, men ha en stor andel av forespørsler som feiler.
Burde man ikke i tillegg også se på responstid på transaksjonene og sette en grense for hva som er akseptabelt før man sier at systemet er nede? Hva med suksessraten på transaksjonene? At en og annen transaksjon feiler fra tid til annet er vel greit, men hvis feilene blir for mange, så er det kanskje rimelig betrakte tilstanden som utilgjengelighet?
Brukere er ikke bare mennesker
Systemer og tjenester har mange brukere: ordinære brukere, superbrukere, gjestebrukere, administratorer, inntrengere og roboter. Vi skal ikke snakke om inntrengere, men se på robotene. Som regel bruker roboter, eller andre systemer, noen tilgjengelige API-er. Skal det være forskjellige SLA-krav avhengig av om brukeren er et menneske som bruker et system interaktivt eller en integrasjon som bruker systemets API-kall?
Svaret er hva advokatene så gjerne svarer kundene sine: «det kommer an på». Det er jo ganske åpenbart at det må være forskjellige terskler avhengig av om brukeren er et menneske eller et annet system. I noen tilfeller er menneskene mer tilgivelige, mens i andre situasjoner kan man la en robot vente lenge. Man må vite hvem brukeren er, og hva som er viktig for brukeren.
Finnes mange hjul allerede
Standardisering har mange fordeler og man slipper å finne opp et eget hjul. Det finnes standarder, rammeverk og veiledere for SLA. Til og med EU har utarbeidet Cloud Service Level Agreement Standardisation Guidelines. Det er smart å bruke standarder, om ikke annet for inspirasjon.
Det er ofte fornuftig å kombinere måleparametere på et høyt nivå, som for eksempel oppetid, og måleparametere på lavere nivåer, som responstid og suksessrate på transaksjoner.
Mitt råd til kundene er å bruke tiden på å forstå egne behov og egne brukere, stille riktige spørsmål ved egenskapene av tjenesten og se på hvilke av egenskapene ved tjenesten som kan brukes til å vurdere kvaliteten. Det er ofte fornuftig å kombinere måleparametere på et høyt nivå, som for eksempel oppetid, og måleparametere på lavere nivåer, som responstid og suksessrate på transaksjoner. Det er også fornuftig å være restriktiv i hvilke parametere som formelt skal være relevante i en avtale: det bør ikke være for mange parametere som kan føre til straff og sanksjoner, men det kan gjerne være mange parametere som man overvåker og rapporterer på som en del av det operasjonelle arbeidet.
