En SLI (service level indicator, servicenivåindikator) är en mätning av hur din tjänst beter sig, till exempel andelen lyckade förfrågningar. En SLO (service level objective, servicenivåmål) är det interna målet för den mätningen, till exempel att 99,9 % av kontrollerna lyckas under 30 dagar. Ett SLA (service level agreement, servicenivåavtal) är löftet du ger kunderna, oftast med ett lägre mål än SLO:n och en konsekvens, till exempel en servicekredit, om du inte når det. Indikatorn är det du mäter, målet är det du siktar på och avtalet är det du skriver under.
Den här guiden förklarar varje begrepp med exempel, visar vad upptidsprocent betyder i minuter och går igenom hur du väljer indikatorer för en webbplats eller ett API, bestämmer vad som räknas som driftstopp och skriver ett SLA som kunderna förstår.
De tre begreppen på ren svenska
SLI: mätningen
En servicenivåindikator är ett tal du kan räkna fram ur verkliga data. Den är nästan alltid en kvot: bra händelser delat med alla händelser. För en webbplats kan det vara andelen upptidskontroller som fick det förväntade svaret. För ett API kan det vara andelen förfrågningar som besvarades med en status som inte är 5xx på under 500 millisekunder. En SLI har inget mål kopplat till sig. Den säger bara vad som hände.
SLO: målet
Ett servicenivåmål lägger ett mål och ett tidsfönster på en SLI. ”99,9 % av kontrollerna mot kassan lyckas, mätt över rullande 30 dagar” är en SLO. Det är ett internt verktyg. Det talar om för teamet när tillförlitligheten är tillräckligt bra för att fortsätta leverera nya funktioner och när det är dags att sakta ner och laga saker.
SLA: avtalet
Ett servicenivåavtal är det externa löftet, nedskrivet i ett avtal eller i användarvillkoren. Det anger tjänsten, målet, hur det mäts, vad som är undantaget och vad kunden får om du inte når det. Alla tjänster behöver inte ett SLA, men varje SLA behöver en SLO bakom sig, annars får du ingen tidig varning om att du är på väg att bryta det.
Hur SLI, SLO och SLA hänger ihop
Se dem som lager. SLI:n är den råa signalen. SLO:n är en strängare intern gräns som dras på den signalen. SLA:t är en lösare extern gräns som dras på samma signal. En vanlig uppsättning för en SaaS-produkt ser ut så här (exempelvärden):
SLI: andelen kontroller varje minut mot app.lumenanalytics.io som returnerar status 200 och innehåller dashboardens titel.
SLO: 99,95 % per kalendermånad.
SLA: 99,9 % per kalendermånad, med en servicekredit om målet inte nås.
Skillnaden mellan 99,95 % och 99,9 % är säkerhetsmarginalen. Om teamet ser att SLO:n halkar efter vecka två har det fortfarande tid att agera innan det avtalade löftet är i fara.
Upptidsprocent i minuter
Upptidsmål ser ut att ligga nära varandra på papperet, men varje extra nia minskar den tillåtna nertiden tiofalt. Tabellen nedan utgår från en genomsnittlig månad (ett år på 365,25 dagar delat med 12), precis som upptidskalkylatorn; en månad på 30 dagar tillåter lite mindre.
UpptidsmålTillåten nertid per månadTillåten nertid per år99 %7 h 18 min 18 s3 dagar 15 h 39 min 36 s99,5 %3 h 39 min 9 s1 dag 19 h 49 min 48 s99,9 min 49 s8 h 45 min 57 s99,95 min 54 s4 h 22 min 58 s99,99 %4 min 22 s52 min 35 s99,999 s5 min 15 s
Det får två praktiska följder. För det första måste din övervakning kunna se den nertid du lovar. Med kontroller var femte minut kan du inte ärligt mäta ett månadsmål på 99,99 %, eftersom ett enda missat avbrott kan förbruka hela budgeten. För det andra lämnar varje mål över 99,9 % nästan inget utrymme för manuell hantering. Vid 99,99 % räcker en enda utdragen incident mitt i natten för att månaden ska vara förlorad.
Felbudgetar: så blir SLO:n till beslut
En felbudget är den mängd fel som din SLO tillåter. Med en SLO på 99,9 % per månad är budgeten 0,1 % av månaden, ungefär 43 minuter och 49 sekunder en genomsnittlig månad (43 minuter och 12 sekunder en månad på 30 dagar). Varje incident förbrukar en del av den.
Budgeten gör tillförlitlighet till ett gemensamt beslut i stället för en diskussion. En enkel policy som många team använder:
Mer än halva budgeten kvar: leverera som vanligt.
Mindre än hälften kvar: granska riskabla driftsättningar och låt ett extra par ögon titta på databasändringar.
Budgeten förbrukad: pausa nya funktioner för den tjänsten och arbeta med orsakerna till de senaste incidenterna tills fönstret nollställs.
Ett exempel: harborlabs.dev har en SLO på 99,9 % per månad för sitt publika API. Den 9:e orsakar en felaktig driftsättning 18 minuter av fel. Den 20:e orsakar ett certifikatproblem 9 till. Det är 27 av 43 minuter förbrukade, med tio dagar kvar. Teamet väntar med nästa schemamigrering till den nya månaden, eftersom ytterligare en incident av samma storlek skulle bryta målet.
Välj SLI:er för en webbplats eller ett API
Bra SLI:er beskriver vad användarna upplever, inte vad dina servrar känner. CPU på 90 % är ingen SLI. En kassa som inte fungerar är det. Börja med två eller tre indikatorer per tjänst:
Tillgänglighet: andelen kontroller eller förfrågningar som lyckas. För en webbplats bör ”lyckas” betyda rätt statuskod och rätt innehåll, inte bara att något svarar.
Latens: andelen förfrågningar som svarar snabbare än en gräns, till exempel 95 % under 800 ms. En andel är lättare att resonera kring än ett medelvärde, som döljer långsamma avvikare.
Korrekthet: för API:er, andelen svar som innehåller de förväntade fälten. En 200 med tom body är ingen framgång.
Mät de flöden som spelar roll. För en butik som northwind.shop betyder det kassan och produktsidorna, inte bara den cachade startsidan. För ett API betyder det de endpoints som kunderna integrerar mot, helst via en health check-endpoint som testar databasen och andra beroenden. En API-monitor som validerar svarets body gör den endpointen till en SLI du kan lita på.
Vad som räknas in i upptiden
De flesta tvister om SLA handlar inte om siffran. De handlar om vad som räknas. Bestäm de här punkterna innan du publicerar ett mål:
Planerat underhåll. Många SLA undantar schemalagt underhåll som aviserats i förväg, till exempel 72 timmar innan och med ett tak på fyra timmar per månad. Om du undantar det, ange hur det aviseras och sätt en gräns, annars blir ”underhåll” ett kryphål.
Delvisa avbrott. Är tjänsten nere om inloggningen fungerar men kassan inte gör det? Definiera vilka komponenter som omfattas och om ett avbrott i en av dem räknas som driftstopp för helheten.
Försämrad prestanda. Bestäm om svar som är långsammare än en gräns räknas som fel. Om en sida tar 30 sekunder anser användarna att den är nere.
Orsaker utanför din kontroll. Nätverksproblem hos kunden, missbruk och force majeure brukar undantas. Din egen hostingleverantör brukar inte göra det; kunderna köpte tjänsten av dig.
Minsta varaktighet. Vissa SLA räknar bara avbrott som varar längre än en minut eller som bekräftats av mer än en kontroll, vilket stämmer med hur övervakning bekräftar fel.
Internt är det ofta klokt att räkna in planerat underhåll i din SLO även om SLA:t undantar det. Användarna kunde ändå inte nå tjänsten, och SLO:n ska spegla deras upplevelse.
Skriv ett SLA för kunderna
Ett bra SLA är kort och konkret. Det ska svara på sex frågor: vilken tjänst, vilket mål, hur det mäts, under vilken period, med vilka undantag och vad som händer om du inte når det. Här är en exempelklausul som du kan anpassa:
Tjänst: webbapplikationen Lumen Analytics på app.lumenanalytics.io
och det publika API:t på api.lumenanalytics.io.
Mål: 99,9 % tillgänglighet per månad.
Mätning: tillgängligheten mäts med externa kontroller varje minut.
En minut räknas som otillgänglig när tjänsten returnerar ett fel (5xx)
eller inget svar, bekräftat av en andra kontroll.
Undantag: schemalagt underhåll som aviserats minst 72 timmar i förväg
på vår statussida (högst 4 timmar per månad); problem som orsakas av
kundens eget nätverk eller egna system.
Krediter: under 99,9 %: 10 % av månadsavgiften.
under 99,0 %: 25 % av månadsavgiften.
Kunden begär krediter inom 30 dagar efter månadens slut.
Sätt SLA:t under det du faktiskt uppnår. Om din övervakningshistorik visar 99,97 % det senaste året är ett löfte om 99,9 % realistiskt. Att lova 99,99 % för att det låter bättre gör varje incident till ett avtalsproblem.
Håll krediterna proportionerliga och processen för att begära dem enkel. Kunderna vill sällan ha pengarna. De vill se att du tar löftet på allvar och att du mäter ärligt.
Mät med extern övervakning
Dina egna loggar kan inte mäta ett avbrott där servern aldrig tog emot förfrågan. DNS-fel, utgångna certifikat, nätverksproblem och en kraschad lastbalanserare lämnar alla de interna mätvärdena tysta. Därför bör mätningen för ett SLA göras utifrån, på samma sätt som kunderna når dig. Om idén är ny för dig, börja med vad upptidsövervakning är och hur det fungerar.
En sund uppsättning för SLA-rapportering:
Kontrollera varje minut. Intervallet avgör hur fin upplösning mätningen har.
Bekräfta varje fel med en andra kontroll. Det håller en enstaka störning i nätverket borta från dina siffror för nertid.
Validera innehållet. Leta efter ett ord eller fält som bara visas när tjänsten fungerar.
Spara historiken. Du behöver start- och sluttider för incidenter för varje månad du rapporterar.
Publicera den. En statussida med upptidshistorik låter kunderna se samma siffror som du.
Uptimecheck täcker detta med upptidsövervakning så ofta som varje minut från Stockholm, London och New York, SLA-rapporter per monitor för den här eller förra månaden eller de senaste 7, 30 eller 90 dagarna mot ditt mål, CSV-export för den månatliga SLA-redovisningen samt veckovisa och månatliga rapporter via e-post. En statussida kopplad till samma monitorer visar kunderna upptidshistoriken bakom ditt löfte.
Upptid är bara ena sidan av tillförlitligheten. Hur snabbt du upptäcker och åtgärdar incidenter avgör hur mycket av budgeten varje incident förbrukar; läs MTTR, MTTA och MTBF förklarade för den sidan av saken.
Checklista: så sätter du SLI:er, SLO:er och ett SLA
Lista de användarflöden som spelar roll: inloggning, kassa, huvud-API:t.
Definiera en SLI för tillgänglighet och, där det spelar roll, en SLI för latens per flöde.
Mät i en eller två månader innan du väljer mål.
Sätt SLO:n något under det du uppnår i dag och kom överens om en policy för felbudgeten.
Sätt SLA:t under SLO:n, med tydliga undantag och proportionerliga krediter.
Mät externt varje minut och gå igenom siffrorna varje månad.
Mät upptiden du lovar från där dina kunder står. Testa Uptimecheck gratis i 14 dagar, inget kreditkort behövs.