En SLI (service level indicator) er en måling af, hvordan din tjeneste opfører sig, for eksempel andelen af vellykkede forespørgsler. En SLO (service level objective) er det interne mål for den måling, for eksempel at 99,9 % af tjekkene lykkes over 30 dage. En SLA (service level agreement) er det løfte, du giver kunderne, som regel med et lavere mål end SLO’en og en konsekvens, for eksempel en servicekredit, hvis du ikke lever op til det. Indikatoren er det, du måler, målsætningen er det, du sigter efter, og aftalen er det, du skriver under på.
Denne guide forklarer hvert begreb med eksempler, viser, hvad oppetidsprocenter betyder i minutter, og gennemgår, hvordan du vælger indikatorer for et website eller et API, beslutter, hvad der tæller som nedetid, og skriver en SLA, som kunderne kan forstå.
De tre begreber i et enkelt sprog
SLI: målingen
En service level indicator er et tal, du kan beregne ud fra reelle data. Det er næsten altid en brøk: gode hændelser divideret med alle hændelser. For et website kan det være andelen af oppetidstjek, der returnerede det forventede svar. For et API kan det være andelen af forespørgsler, der svarede med en status, som ikke er 5xx, på under 500 millisekunder. En SLI har intet mål knyttet til sig. Den siger bare, hvad der skete.
SLO: målet
En service level objective sætter et mål og et tidsvindue på en SLI. “99,9 % af tjekkene af checkout lykkes, målt over løbende 30 dage” er en SLO. Det er et internt værktøj. Den fortæller teamet, hvornår pålideligheden er god nok til at blive ved med at levere nye funktioner, og hvornår det er tid til at sætte tempoet ned og rette fejl.
SLA: kontrakten
En service level agreement er det eksterne løfte, skrevet ind i en kontrakt eller i servicevilkårene. Den angiver tjenesten, målet, hvordan det måles, hvad der er undtaget, og hvad kunden får, hvis du ikke lever op til det. Ikke alle tjenester har brug for en SLA, men alle SLA’er har brug for en SLO bag sig, ellers får du ingen tidlig advarsel om, at du er ved at bryde den.
Sådan hænger SLI, SLO og SLA sammen
Tænk på dem som lag. SLI’en er det rå signal. SLO’en er en strengere intern linje trukket på det signal. SLA’en er en løsere ekstern linje trukket på det samme signal. En almindelig opsætning for et SaaS-produkt ser sådan ud (eksempelværdier):
SLI: andelen af tjek hvert minut af app.lumenanalytics.io, der returnerer status 200 og indeholder dashboardets titel.
SLO: 99,95 % pr. kalendermåned.
SLA: 99,9 % pr. kalendermåned, med en servicekredit, hvis målet ikke nås.
Forskellen mellem 99,95 % og 99,9 % er sikkerhedsmarginen. Hvis teamet ser SLO’en skride i uge to, er der stadig tid til at handle, før det kontraktlige løfte er i fare.
Oppetidsprocenter i minutter
Oppetidsmål ser ud til at ligge tæt på hinanden på papiret, men hvert ekstra ni-tal skærer den tilladte nedetid ned til en tiendedel. Tabellen nedenfor bruger en gennemsnitlig måned (et år på 365,25 dage divideret med 12), ligesom oppetidsberegneren; en måned på 30 dage tillader lidt mindre.
OppetidsmålTilladt nedetid pr. månedTilladt nedetid pr. år99 %7 t 18 min 18 s3 dage 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
Det har to praktiske konsekvenser. For det første skal din overvågning kunne se den nedetid, du lover. Med tjek hvert femte minut kan du ikke ærligt måle et månedligt mål på 99,99 %, fordi et enkelt overset nedbrud kan bruge hele budgettet. For det andet efterlader ethvert mål over 99,9 % næsten ingen plads til manuel håndtering. Ved 99,99 % er måneden ødelagt af én langsom hændelse om natten.
Error budgets: Fra SLO til beslutninger
Et error budget er den mængde fejl, din SLO tillader. Med en månedlig SLO på 99,9 % er budgettet 0,1 % af måneden, omkring 43 minutter og 49 sekunder i en gennemsnitlig måned (43 minutter og 12 sekunder i en måned på 30 dage). Hver hændelse bruger en del af det.
Budgettet gør pålidelighed til en fælles beslutning i stedet for en diskussion. En enkel politik, som mange teams bruger:
Mere end halvdelen af budgettet tilbage: Udgiv som normalt.
Mindre end halvdelen tilbage: Gennemgå risikable udrulninger, og lad et ekstra sæt øjne se på databaseændringer.
Budgettet er brugt: Sæt nye funktioner på pause for den tjeneste, og arbejd på årsagerne til de seneste hændelser, indtil vinduet nulstilles.
Et eksempel: harborlabs.dev har en månedlig SLO på 99,9 % for sit offentlige API. Den 9. giver en dårlig udrulning 18 minutters fejl. Den 20. giver et certifikatproblem 9 minutter mere. Det er 27 af 43 minutter brugt, med ti dage tilbage. Teamet holder den næste skemamigrering tilbage til den nye måned, fordi endnu en hændelse af samme størrelse ville bryde målsætningen.
Sådan vælger du SLI’er for et website eller et API
Gode SLI’er beskriver, hvad brugerne oplever, ikke hvad dine servere mærker. CPU på 90 % er ikke en SLI. En checkout, der fejler, er. Start med to eller tre indikatorer pr. tjeneste:
Tilgængelighed: andelen af tjek eller forespørgsler, der lykkes. For et website bør “lykkes” betyde den rigtige statuskode og det rigtige indhold, ikke kun et svar.
Latens: andelen af forespørgsler, der svarer hurtigere end en tærskel, for eksempel 95 % under 800 ms. En andel er lettere at forholde sig til end et gennemsnit, som skjuler langsomme afvigere.
Korrekthed: for API’er andelen af svar, der indeholder de forventede felter. En 200 med en tom body er ikke en succes.
Mål de stier, der betyder noget. For en webshop som northwind.shop betyder det checkout og produktsiderne, ikke kun den cachede forside. For et API betyder det de endpoints, kunderne integrerer med, helst via et health check-endpoint, der tester databasen og andre afhængigheder. En API-monitor, der validerer svarets body, gør det endpoint til en SLI, du kan stole på.
Hvad der tæller med i oppetiden
De fleste uenigheder om SLA’er handler ikke om tallet. De handler om, hvad der tæller med. Afgør disse punkter, før du offentliggør et mål:
Planlagt vedligeholdelse. Mange SLA’er undtager planlagt vedligeholdelse, der er varslet på forhånd, for eksempel med 72 timers varsel og et loft på fire timer om måneden. Hvis du undtager den, så skriv, hvordan den varsles, og sæt en grænse, ellers bliver “vedligeholdelse” et smuthul.
Delvise nedbrud. Er tjenesten nede, hvis login virker, men checkout fejler? Definér, hvilke komponenter der er omfattet, og om et nedbrud i én af dem tæller som nedetid for det hele.
Nedsat ydeevne. Beslut, om svar, der er langsommere end en tærskel, tæller som fejl. Hvis en side tager 30 sekunder, opfatter brugerne den som nede.
Årsager uden for din kontrol. Netværksproblemer hos kunden, misbrug og force majeure er ofte undtaget. Din egen hostingudbyder er det som regel ikke; kunderne har købt tjenesten af dig.
Minimumsvarighed. Nogle SLA’er tæller kun nedbrud, der varer mere end et minut eller er bekræftet af mere end ét tjek, hvilket svarer til, hvordan overvågning bekræfter fejl.
Internt er det ofte klogt at medregne planlagt vedligeholdelse i din SLO, selv om SLA’en undtager den. Brugerne kunne stadig ikke nå tjenesten, og SLO’en skal afspejle deres oplevelse.
Sådan skriver du en SLA til kunderne
En god SLA er kort og præcis. Den skal besvare seks spørgsmål: hvilken tjeneste, hvilket mål, målt hvordan, over hvilken periode, med hvilke undtagelser, og hvad der sker, hvis du ikke når det. Her er et eksempel på en klausul, du kan tilpasse:
Tjeneste: webapplikationen Lumen Analytics på app.lumenanalytics.io
og det offentlige API på api.lumenanalytics.io.
Mål: 99,9 % tilgængelighed pr. måned.
Måling: Tilgængeligheden måles med eksterne tjek hvert minut.
Et minut tæller som utilgængeligt, når tjenesten returnerer en fejl (5xx)
eller intet svar, bekræftet af et ekstra tjek.
Undtagelser: planlagt vedligeholdelse, der er varslet mindst 72 timer i forvejen
på vores statusside (maks. 4 timer pr. måned); problemer forårsaget af
kundens eget netværk eller egne systemer.
Kreditter: under 99,9 %: 10 % af månedsprisen.
under 99,0 %: 25 % af månedsprisen.
Kunden anmoder om kreditter senest 30 dage efter månedens udløb.
Sæt SLA’en lavere end det, du faktisk opnår. Hvis din overvågningshistorik viser 99,97 % over det seneste år, er det realistisk at love 99,9 %. At love 99,99 %, fordi det lyder bedre, gør hver hændelse til et kontraktligt problem.
Hold kreditterne rimelige og processen for at kræve dem enkel. Kunderne vil sjældent have pengene. De vil se, at du tager løftet alvorligt, og at du måler ærligt.
Måling med ekstern overvågning
Dine egne logs kan ikke måle et nedbrud, hvor din server aldrig modtog forespørgslen. DNS-fejl, udløbne certifikater, netværksproblemer og en load balancer, der er gået ned, efterlader alle de interne metrikker tavse. Derfor bør SLA-målingen komme udefra, på samme måde som kunderne når dig. Er idéen ny for dig, så start med hvad oppetidsovervågning er, og hvordan det virker.
En solid opsætning til SLA-rapportering:
Tjek hvert minut. Intervallet bestemmer opløsningen af din måling.
Bekræft hver fejl med et ekstra tjek. Det holder et enkelt blip på netværket ude af dine nedetidstal.
Validér indholdet. Tjek for et ord eller et felt, der kun vises, når tjenesten virker.
Gem historikken. Du skal bruge start- og sluttidspunkter for hændelser for hver måned, du rapporterer på.
Offentliggør den. En statusside med oppetidshistorik lader kunderne se de samme tal som dig.
Uptimecheck dækker det med oppetidsovervågning helt ned til hvert minut fra Stockholm, London og New York, SLA-rapporter pr. monitor for denne eller sidste måned eller de seneste 7, 30 eller 90 dage op mod dit mål, CSV-eksport til den månedlige SLA-opgørelse samt ugentlige og månedlige rapporter på e-mail. En statusside, der er koblet til de samme monitorer, viser kunderne oppetidshistorikken bag dit løfte.
Oppetid er kun den ene side af pålidelighed. Hvor hurtigt du opdager og løser hændelser, afgør, hvor meget af budgettet hver enkelt bruger; læs MTTR, MTTA og MTBF forklaret om reaktionssiden.
Tjekliste: Sådan fastsætter du SLI’er, SLO’er og en SLA
Skriv de brugerrejser ned, der betyder noget: login, checkout, det primære API.
Definér én SLI for tilgængelighed og, hvor det er relevant, én SLI for latens pr. brugerrejse.
Mål i en måned eller to, før du vælger mål.
Sæt SLO’en lidt under det, du opnår i dag, og bliv enige om en politik for error budgettet.
Sæt SLA’en under SLO’en, med tydelige undtagelser og rimelige kreditter.
Mål eksternt hvert minut, og gennemgå tallene hver måned.
Mål den oppetid, du lover, fra dér, hvor dine kunder står. Prøv Uptimecheck gratis i 14 dage, intet kreditkort påkrævet.