En SLI (service level indicator) er en måling av hvordan tjenesten din oppfører seg, for eksempel andelen vellykkede forespørsler. En SLO (service level objective) er det interne målet for den målingen, for eksempel at 99,9 % av sjekkene lykkes over 30 dager. En SLA (service level agreement) er løftet du gir kundene, vanligvis med et lavere mål enn SLO-en og en konsekvens, som en servicekreditt, hvis du ikke når det. Indikatoren er det du måler, målet er det du sikter mot, og avtalen er det du skriver under på.
Denne guiden forklarer hvert begrep med eksempler, viser hva oppetidsprosenter betyr i minutter, og går gjennom hvordan du velger indikatorer for et nettsted eller et API, avgjør hva som teller som nedetid og skriver en SLA kundene forstår.
De tre begrepene forklart enkelt
SLI: målingen
En service level indicator er et tall du kan regne ut fra ekte data. Det er nesten alltid en andel: gode hendelser delt på alle hendelser. For et nettsted kan det være andelen oppetidssjekker som ga det forventede svaret. For et API kan det være andelen forespørsler som svarte med en status som ikke er 5xx, på under 500 millisekunder. En SLI har ikke noe mål knyttet til seg. Den sier bare hva som skjedde.
SLO: målet
En service level objective legger et mål og et tidsvindu på en SLI. «99,9 % av sjekkene mot kassen lykkes, målt over løpende 30 dager» er en SLO. Det er et internt verktøy. Den forteller teamet når påliteligheten er god nok til å fortsette å levere nye funksjoner, og når det er på tide å senke tempoet og rette feil.
SLA: kontrakten
En service level agreement er det eksterne løftet, skrevet inn i en kontrakt eller i bruksvilkårene. Den oppgir tjenesten, målet, hvordan det måles, hva som er unntatt og hva kunden får hvis du ikke når det. Ikke alle tjenester trenger en SLA, men hver SLA trenger en SLO bak seg, ellers får du ingen tidlig advarsel om at du er i ferd med å bryte den.
Slik henger SLI, SLO og SLA sammen
Tenk på dem som lag. SLI-en er det rå signalet. SLO-en er en strengere intern linje trukket på det signalet. SLA-en er en løsere ekstern linje trukket på det samme signalet. Et vanlig oppsett for et SaaS-produkt ser slik ut (eksempelverdier):
SLI: andelen sjekker hvert minutt mot app.lumenanalytics.io som returnerer status 200 og inneholder tittelen på dashbordet.
SLO: 99,95 % per kalendermåned.
SLA: 99,9 % per kalendermåned, med en servicekreditt hvis målet ikke nås.
Avstanden mellom 99,95 % og 99,9 % er sikkerhetsmarginen. Hvis teamet ser at SLO-en glipper i uke to, har det fortsatt tid til å handle før det kontraktsfestede løftet står i fare.
Oppetidsprosenter i minutter
Oppetidsmål ser like ut på papiret, men hver ekstra nier kutter tillatt nedetid med en faktor på ti. Tabellen nedenfor bruker en gjennomsnittlig måned (et år på 365,25 dager delt på 12), slik oppetidskalkulatoren gjør; en måned på 30 dager gir litt mindre.
OppetidsmålTillatt nedetid per månedTillatt nedetid per år99 %7 t 18 min 18 s3 dager 15 t 39 min 36 s99,5 %3 t 39 min 9 s1 dag 19 t 49 min 48 s99,9 min 49 s8 t 45 min 57 s99,95 min 54 s4 t 22 min 58 s99,99 %4 min 22 s52 min 35 s99,999 s5 min 15 s
Dette får to praktiske følger. For det første må overvåkingen din kunne se den nedetiden du lover. Med sjekker hvert femte minutt kan du ikke ærlig måle et månedlig mål på 99,99 %, fordi ett enkelt driftsavbrudd du ikke fanger opp, kan bruke hele budsjettet. For det andre gir hvert mål over 99,9 % nesten ikke rom for manuell respons. Ved 99,99 % er måneden ødelagt etter én treg hendelse om natten.
Feilbudsjetter: slik blir SLO-en til beslutninger
Et feilbudsjett er hvor mye svikt SLO-en tillater. Med en månedlig SLO på 99,9 % er budsjettet 0,1 % av måneden, omtrent 43 minutter og 49 sekunder i en gjennomsnittlig måned (43 minutter og 12 sekunder i en måned på 30 dager). Hver hendelse bruker en del av det.
Budsjettet gjør pålitelighet til en felles beslutning i stedet for en krangel. En enkel policy mange team bruker:
Mer enn halve budsjettet igjen: lever som normalt.
Mindre enn halvparten igjen: gå gjennom risikable utrullinger, og la et ekstra par øyne se på databaseendringer.
Budsjettet er brukt opp: stans nye funksjonsleveranser for den tjenesten, og jobb med årsakene til de siste hendelsene til vinduet nullstilles.
Et eksempel: harborlabs.dev har en månedlig SLO på 99,9 % for det offentlige API-et sitt. Den 9. gir en dårlig utrulling 18 minutter med feil. Den 20. gir et sertifikatproblem 9 minutter til. Da er 27 av 43 minutter brukt, med ti dager igjen. Teamet venter med neste skjemamigrering til ny måned, fordi én hendelse til av samme størrelse ville brutt målet.
Slik velger du SLI-er for et nettsted eller et API
Gode SLI-er beskriver det brukerne opplever, ikke det serverne dine kjenner på. CPU på 90 % er ikke en SLI. En kasse som feiler, er det. Begynn med to eller tre indikatorer per tjeneste:
Tilgjengelighet: andelen sjekker eller forespørsler som lykkes. For et nettsted bør «lykkes» bety riktig statuskode og riktig innhold, ikke bare et svar.
Forsinkelse: andelen forespørsler som svarer raskere enn en terskel, for eksempel 95 % under 800 ms. En andel er enklere å resonnere rundt enn et gjennomsnitt, som skjuler trege avvikere.
Korrekthet: for API-er, andelen svar som inneholder de forventede feltene. En 200 med tom body er ikke en suksess.
Mål de stiene som betyr noe. For en nettbutikk som northwind.shop betyr det kassen og produktsidene, ikke bare den hurtigbufrede forsiden. For et API betyr det endepunktene kundene integrerer mot, helst gjennom et endepunkt for helsesjekk som tester databasen og andre avhengigheter. En API-monitor som validerer innholdet i svaret, gjør det endepunktet til en SLI du kan stole på.
Hva som teller med i oppetiden
De fleste uenigheter om SLA-er handler ikke om tallet. De handler om hva som teller. Avgjør disse punktene før du publiserer et mål:
Planlagt vedlikehold. Mange SLA-er unntar planlagt vedlikehold som er varslet på forhånd, for eksempel med 72 timers varsel og et tak på fire timer per måned. Hvis du unntar det, må du si hvordan det varsles og sette en grense, ellers blir «vedlikehold» et smutthull.
Delvise driftsavbrudd. Er tjenesten nede hvis innloggingen virker, men kassen feiler? Definer hvilke komponenter som omfattes, og om et avbrudd i én av dem teller som nedetid for helheten.
Redusert ytelse. Avgjør om svar som er tregere enn en terskel, teller som feil. Hvis en side tar 30 sekunder, mener brukerne at den er nede.
Årsaker du ikke rår over. Nettverksproblemer hos kunden, misbruk og force majeure er vanlige unntak. Din egen hostingleverandør er det som regel ikke; kundene kjøpte tjenesten av deg.
Minste varighet. Noen SLA-er teller bare avbrudd som varer lenger enn ett minutt eller er bekreftet av mer enn én sjekk, noe som stemmer med hvordan overvåking bekrefter feil.
Internt er det ofte lurt å telle med planlagt vedlikehold i SLO-en selv om SLA-en unntar det. Brukerne kom likevel ikke til tjenesten, og SLO-en skal gjenspeile det de opplever.
Slik skriver du en SLA for kundene
En god SLA er kort og konkret. Den bør svare på seks spørsmål: hvilken tjeneste, hvilket mål, målt hvordan, over hvilken periode, med hvilke unntak, og hva som skjer hvis du ikke når det. Her er et eksempel på en klausul du kan tilpasse:
Tjeneste: webapplikasjonen Lumen Analytics på app.lumenanalytics.io
og det offentlige API-et på api.lumenanalytics.io.
Mål: 99,9 % tilgjengelighet per måned.
Måling: tilgjengeligheten måles med eksterne sjekker hvert minutt.
Et minutt regnes som utilgjengelig når tjenesten returnerer en feil (5xx)
eller ikke svarer, bekreftet av en ny sjekk.
Unntak: planlagt vedlikehold som er varslet minst 72 timer i forveien
på statussiden vår (maks. 4 timer per måned); problemer som skyldes
kundens eget nettverk eller egne systemer.
Kreditter: under 99,9 %: 10 % av månedsprisen.
under 99,0 %: 25 % av månedsprisen.
Kunden ber om kreditter innen 30 dager etter utgangen av måneden.
Sett SLA-en under det du faktisk oppnår. Hvis overvåkingshistorikken din viser 99,97 % det siste året, er et løfte om 99,9 % realistisk. Å love 99,99 % fordi det høres bedre ut, gjør hver hendelse til et kontraktsproblem.
Hold kredittene rimelige og kravprosessen enkel. Kundene er sjelden ute etter pengene. De vil se at du tar løftet på alvor og at du måler ærlig.
Måling med ekstern overvåking
Dine egne logger kan ikke måle et driftsavbrudd der serveren aldri mottok forespørselen. DNS-feil, utløpte sertifikater, nettverksproblemer og en lastbalanserer som har krasjet, gjør alle at de interne måleverdiene er stille. Derfor bør SLA-målingen komme utenfra, på samme måte som kundene når deg. Er du ny på dette, kan du begynne med hva oppetidsovervåking er og hvordan det fungerer.
Et solid oppsett for SLA-rapportering:
Sjekk hvert minutt. Intervallet bestemmer oppløsningen på målingen.
Bekreft hver feil med en ny sjekk. Det holder et enkelt blaff i nettverket utenfor nedetidstallene dine.
Valider innholdet. Se etter et ord eller et felt som bare vises når tjenesten virker.
Ta vare på historikken. Du trenger start- og sluttid for hendelser for hver måned du rapporterer på.
Publiser den. En statusside med oppetidshistorikk lar kundene se de samme tallene som du.
Uptimecheck dekker dette med oppetidsovervåking så ofte som hvert minutt fra Stockholm, London og New York, SLA-rapporter per monitor for denne eller forrige måned eller de siste 7, 30 eller 90 dagene mot målet ditt, CSV-eksport til den månedlige SLA-oppstillingen, og ukentlige og månedlige rapporter på e-post. En statusside koblet til de samme monitorene viser kundene oppetidshistorikken bak løftet ditt.
Oppetid er bare én side av pålitelighet. Hvor raskt du oppdager og retter hendelser, avgjør hvor mye av budsjettet hver av dem bruker; les MTTR, MTTA og MTBF forklart for responssiden.
Sjekkliste: slik setter du SLI-er, SLO-er og en SLA
List opp brukerreisene som betyr noe: innlogging, kassen, hoved-API-et.
Definer én SLI for tilgjengelighet og, der det betyr noe, én SLI for forsinkelse per reise.
Mål i en måned eller to før du velger mål.
Sett SLO-en litt under det du oppnår i dag, og bli enige om en policy for feilbudsjettet.
Sett SLA-en under SLO-en, med tydelige unntak og rimelige kreditter.
Mål eksternt hvert minutt og gå gjennom tallene hver måned.
Mål oppetiden du lover fra der kundene dine står. Prøv Uptimecheck gratis i 14 dager, uten kredittkort.