# Vad är ett SLO? Praktisk guide för plattformsteam och SRE

URL: https://upstreamapi.com/sv/journal/vad-ar-ett-slo
Type: blog
Locale: sv
Published: 2026-10-31
Updated: 2026-11-01

---

> En tydlig förklaring av vad ett SLO är, hur felbudgetar och burn rate-larm fungerar, och hur man kopplar talet till utrullningar så att releaser stoppar sig själva.

Vad är ett SLO? Ett service level objective är ett mål för hur tillförlitligt ett specifikt beteende hos användarna ska vara, mätt över ett fast tidsfönster. "99.9% av utcheckningsanropen lyckas på under 800 ms, under 30 dagar" är ett SLO. "Sajten ska vara snabb" är en önskan. Talet spelar mindre roll än det som styrs av det: SLO:n avgör när ni fortsätter att leverera och när ni måste stanna upp.

Klockan är 03:12. PagerDuty säger att latensen i utcheckningen är "förhöjd". Du öppnar dashboarden och ser en p99-linje som har kravlat uppåt i fyrtio minuter. Ingen kan säga om det är ett problem, eftersom ingen någonsin skrev ner hur mycket latens som är för mycket. Diskussionen som följer, i ett samtal med ett öga på Slack, är priset för att inte ha ett SLO.

![Telefon som lyser på ett nattduksbord under ett jourlarm](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/da5f84-i1.webp)

## SLI, SLO och SLA: tre ord, tre ägare

Folk använder orden om varandra. De betyder inte samma sak, och det är så team hamnar i ett kontrakt de inte kan hålla.

- 
**SLI (service level indicator)** är mätvärdet. Ett förhållande mellan bra händelser och giltiga händelser: anrop som gav 2xx på under 800 ms, delat med alla anrop som borde ha gett det.

- 
**SLO (service level objective)** är målet för det förhållandet över ett fönster. 99.9% under 30 dagar.

- 
**SLA (service level agreement)** är avtalet med en kund, med pengar på spel om ni missar. Den är alltid lösare än SLO:n. Om SLA:n säger 99.9% och SLO:n också säger 99.9% har ni inget utrymme att märka ett problem innan ni måste betala krediter.

[Google SRE-boken, kapitlet om service level objectives](https://sre.google/sre-book/service-level-objectives/) drar samma gräns: SLO:n är ett internt mål som ligger strängare än allt ni lovar externt. Ingenjörer äger SLI:n och SLO:n. Produkt och juridik äger SLA:n.

Ta inte instinkten att lägga till ett fjärde ord för varje mätvärde ni redan samlar in. CPU, minne och köns djup är användbara för felsökning. De är inte SLI:er, eftersom ingen kund upplever dem direkt.

## Hur en bra SLI ser ut, och var den mäts

En bra SLI är ett förhållande, den mäts så nära användaren som möjligt, och den har en tydlig definition av vad "bra" betyder.

För en requestdriven tjänst är standarden två SLI:er: tillgänglighet (icke-5xx-svar delat med alla giltiga anrop) och latens (anrop under en tröskel delat med alla giltiga anrop). Använd en tröskel, inte ett medelvärde. Ett medelvärde döljer svansen, och svansen är där supportärendena kommer ifrån.

Mät vid lastbalanseraren eller vid kanten, inte inne i tjänsten. En tjänst som kraschar vid uppstart rapporterar en perfekt felfrekvens för de anrop den aldrig tog emot. Serversidiga mätvärden är blinda för det felet, och användaren upplever det som ett driftstopp.

Var explicit om vad som är undantaget. Hälsokontroller, syntetiska prober från er egen övervakning och 4xx-svar orsakade av felaktig indata från klienten bör oftast inte räknas mot er. Skriv ner undantagen bredvid SLO:n. När någon argumenterar om siffran i en incidentgenomgång ska diskussionen handla om definitionen, inte om vad dashboarden råkar visa.

Ni behöver inte en dedikerad SLO-produkt för att börja. Ni behöver en räknare för bra händelser, en räknare för totala händelser och en plats att lagra dem i 30 dagar.

Om era mätvärden redan finns i en hostad plattform är SLO-funktionen oftast ett tunt lager ovanpå data ni redan betalar för.

Datadog har SLO:er inbyggt, med burn rate-larm, och det är den enkla vägen om era traces och metriker redan finns där. Notan är fällan: anpassade metriker och taggar med hög kardinalitet multipliceras snabbt, så kontrollera priset för SLI-serierna innan ni binder er.

Om ni kör Prometheus täcker Grafana samma mark via recording rules och sitt SLO-verktyg, till priset av mer uppsättning och mer av er egen tid.

Den ärliga jämförelsen är tid till första användbara larm mot kostnad i skala. Datadog vinner det första. Grafana med Prometheus vinner oftast det andra. Välj efter vad ert team är mest brist på.

## Aritmetiken som ingen gör innan man väljer nior

Varje extra nia minskar era tillåtna driftstopp med en faktor tio. Det här är listan att ha kvar i dokumentet.

- 
**99%** över 30 dagar: 1% felbudget, 7.2 timmar tillåtet totalt driftstopp.

- 
**99.9%**: 0.1% budget, 43.2 minuter.

- 
**99.95%**: 0.05% budget, 21.6 minuter.

- 
**99.99%**: 0.01% budget, 4.32 minuter.

Läs den sista raden igen. Vid 99.99% har en enda dålig deploy som tar fem minuter att upptäcka och rulla tillbaka redan förbrukat hela månadens budget. Ingen hinner svara på ett larm, öppna en laptop och rulla tillbaka på under fyra minuter. Det betyder att målet bara går att nå med automation: en automatisk spärr som stoppar utrullningen innan budgeten är slut.

Välj alltså den siffra som tjänsten faktiskt behöver. De flesta interna API:er mår bra av 99.9%. En betalningsväg kan motivera mer. Ett batchjobb som körs på natten kan klara sig med 99%. Att välja 99.99% för att det låter seriöst är hur ett team skriver på för en jourrotation de inte kan bemanna.

![Timglas med det mesta av sanden runnen ut, en bild för felbudgeten](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/a422c2-i2.webp)

## Felbudgeten är poängen, inte SLO:n

En SLO på 99.9% betyder att ni får misslyckas 0.1% av tiden. De 0.1% är er felbudget, och det är den mest användbara idén i hela disciplinen.

Budgeten gör om en argumentation till ett tal. Produkt vill skicka den riskfyllda migreringen. SRE:n säger att den är riskfylld. Utan budget är det en åsikt mot en annan, och senioriteten vinner. Med budget blir frågan: hur mycket finns kvar, och hur mycket kan den här ändringen rimligen bränna?

Två regler gör att det fungerar.

- 
**Budget kvar: leverera.** Ni får ta risk, så ta den. Ett team som aldrig förbrukar sin budget investerar för mycket i tillförlitlighet som användarna inte bad om.

- 
**Budget slut: frys.** Funktionsarbete pausas tills tillförlitlighetsarbetet har fört SLI:n tillbaka över målet. Det gäller bara om ledningen gick med på det i förväg, inte under incidenten.

Om den andra regeln inte är överenskommen i förväg har ni inget SLO. Ni har en dashboard med en grön och en röd zon.

## Larma på burn rate, inte på SLI:n

Här faller de flesta första försök. Någon sätter ett larm när tillgängligheten sjunker under 99.9%. Larmet går först när skadan är skedd, eller så fladdrar det vid varje litet hack, eller både och.

Den bättre signalen är **burn rate**: hur snabbt ni förbrukar budgeten jämfört med takten som exakt skulle tömma den vid fönstrets slut. Burn rate 1 betyder att ni avslutar månaden med noll kvar. Burn rate 14.4 betyder att ni är på väg att bränna hela månadens budget på ungefär två dagar.

[Google SRE Workbook om att larma på SLO:er](https://sre.google/workbook/alerting-on-slos/) rekommenderar att kombinera ett långt och ett kort fönster, så att larmet både är signifikant och fortfarande pågår. För en 30-dagars SLO är två larm en bra startpunkt:

- 
Burn rate 14.4 över 1 timme, bekräftat över 5 minuter: förbrukar 2% av månadens budget. Väck någon.

- 
Burn rate 6 över 6 timmar, bekräftat över 30 minuter: förbrukar 5% av månadens budget. Väck någon.

Räkningen är enkel. Ett 30-dagarsfönster är 720 timmar. Om man bränner i 14.4x under en timme använder man 14.4 / 720 = 2% av budgeten. Det korta fönstret hindrar larmet från att gå en timme efter att problemet redan har upphört.

Här är den första regeln som Prometheus-larm, under antagandet att ni spelar in ett felförhållande per fönster:

`groups:
  - name: checkout-slo-burn
    rules:
      - alert: CheckoutErrorBudgetFastBurn
        expr: |
          job:checkout_error_ratio:rate1h > (14.4 * 0.001)
          and
          job:checkout_error_ratio:rate5m > (14.4 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "Utcheckningen bränner 2% av sin 30-dagars felbudget per timme"`Konstanten 0.001 är det tillåtna felförhållandet för en SLO på 99.9%. Ändra målet, så måste konstanten följa med. Håll den på ett ställe, annars glider larmet och SLO:n isär utan att någon märker det.

Långsammare förbrukning behöver inget larm till en person. Burn rate 1 under tre dagar hör hemma i ett ärende till nästa arbetsmorgon. Att väcka någon för ett långsamt läckage är hur jourlag lär sig att ignorera pipet.

![Datacenter-gång med serverrack och statuslampor](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/f23ee5-i3.webp)

## Koppla SLO:n till utrullningen, steget de flesta hoppar över

En SLO som bara producerar en rapport används till hälften. Steget som ändrar beteende är att koppla budgeten till deploy-flödet, så att releasen stoppar sig själv.

En progressiv utrullning med SLO-spärr fungerar så här. Skicka till 1% av trafiken bakom en flagga. Följ SLI:n för den kohorten mot baslinjen. Om kanarians burn rate passerar tröskeln rullas den tillbaka automatiskt. Om den håller går ni vidare till 5%, sedan 25%, sedan 100%.

Det är något annat än en dashboard som någon ska titta på klockan 03:12. Klockan 03:12 vill du inte tänka. Du vill ha en knapp, eller ännu hellre ingen knapp alls.

Här gör feature flags nytta, eftersom en flagga gör en återställning till en konfigurationsändring som tar sekunder i stället för en omdeploy som tar tio minuter.

LaunchDarkly och liknande plattformar ger er procentuell utrullning och en kill switch. Det de flesta lämnar åt er är beslutet: vilken SLI som ska läsas, vilket tröskelvärde som räknas som dåligt och vem som får åsidosätta. Det är gapet som en automatiserad pilot med auto-rollback på SLO är tänkt att täppa till, och det är vinkeln vi tar på upstreamapi. LaunchDarkly vinner på bredd i SDK:er och företagskontroller, och det säger vi.

Så här ser spärren ut i TypeScript. Beslutslogiken är den del som är värd att skriva själv, oavsett vilket flaggsystem ni använder:

`type Cohort = { good: number; total: number };

const SLO_TARGET = 0.999;
const BUDGET = 1 - SLO_TARGET; // 0.001
const PAGE_BURN_RATE = 14.4;

function burnRate(c: Cohort): number {
  if (c.total === 0) return 0;
  const errorRatio = 1 - c.good / c.total;
  return errorRatio / BUDGET;
}

export function rolloutDecision(canary: Cohort): "advance" | "hold" | "revert" {
  if (canary.total < 500) return "hold"; // för lite trafik för att bedöma
  return burnRate(canary) > PAGE_BURN_RATE ? "revert" : "advance";
}`Lägg märke till `hold`-grenen. En kanari på 1% av en lugn tjänst kan se fyrtio anrop på tio minuter, och ett fel av fyrtio är ett felförhållande på 2.5%. Utan minsta urval reverterar spärren på brus, och teamet lär sig att misstro den.

## Misstagen vi ser i team på 80 ingenjörer, och vem som bör skriva den första

Samma få fel dyker upp i team efter team, och nästan inget av dem är tekniskt.

**För många SLO:er.** Tjugo mål per tjänst gör att ingen minns något av dem. Två eller tre per användarresa räcker.

**SLO:er som ingen gick med på.** En ingenjör skriver dem ensam över en helg. Produkt har aldrig sett dem, så budgetpolicyn kollapsar första gången den säger nej till en lansering.

**SLO:er satta vid nuvarande prestanda.** Om tjänsten ligger på 99.97% idag och målet sätts till 99.97% finns ingen budget kvar och ett misslyckande är garanterat. Sätt det där användarna börjar bli missnöjda, vilket nästan alltid är lägre.

**SLO:n behandlas som permanent.** Granska siffran varje kvartal. Om ni aldrig förbrukar budgeten, skärp målet eller leverera snabbare. Om ni spricker den varje månad, åtgärda systemet eller erkänn att målet var en fantasi.

**Att räkna det som är lätt i stället för det som märks.** Ett 200-svar med en tom kundvagn är en framgång i era loggar och ett misslyckande för kunden. Definiera "bra" utifrån användarens sida.

Du behöver inget program. Välj den enda resa som skulle få VD:n att ringa någon om den gick sönder. Definiera en tillgänglighets-SLI och en latens-SLI för den. Sätt målet på 99.9% under första kvartalet, skriv frysningspolicyn i två meningar och få produkten att svara "godkänt" skriftligt.

Lägg sedan till ett burn rate-larm och en plats där hela teamet kan se återstående budget.

Om du behöver en lättviktig start innan du binder dig till en fullständig plattform hanterar Better Stack upptidsövervakning och incidentpaging med en mycket mindre uppsättning, även om den inte ger budgetmatematiken gratis.

Den första versionen kommer att vara fel. Det är acceptabelt. Det viktiga är att nästa incidentgenomgång startar från ett tal ni skrev ner i förväg, i stället för en känsla.

## Hur ser din 03:12 ut nu?

Ta den senaste incident ert team hade. Fanns det ett tal nedskrivet som sa om den betydde något? Om det ärliga svaret är nej är det ert första SLO, och efterarbetet har redan sagt vad ni ska mäta.

## FAQ

### Vad är ett SLO?

Ett SLO är ett tillförlitlighetsmål för ett specifikt användarbeteende över ett fast tidsfönster, till exempel att 99.9% av anropen lyckas under 30 dagar. Det visar hur mycket fel som är acceptabelt och när ni ska sluta leverera.

### Vad är skillnaden mellan SLI, SLO och SLA?

SLI är mätvärdet, SLO är det interna målet för mätvärdet och SLA är avtalet med kunden, med ekonomiska följder vid brott. SLA är alltid lösare än SLO.

### Vad är en felbudget?

Felbudgeten är det som återstår av 100 procent efter målet. Vid 99.9% är den 0.1% av fönstret. Budgeten avgör om ni kan ta risk eller om funktionsarbetet ska frysas.

### Vad är burn rate?

Burn rate är hur snabbt ni förbrukar felbudgeten jämfört med takten som exakt skulle tömma den vid fönstrets slut. Burn rate 1 betyder att budgeten precis tar slut, och högre värden betyder att ni brinner snabbare.

### Hur många SLO:er bör en tjänst ha?

Två eller tre per användarresa räcker för de flesta team. Fler än så gör att ingen minns dem och att ingen använder dem när något brinner.

### Kan ett SLO styra utrullningar?

Ja. Koppla burn rate för en kanarikohort till en spärr som rullar tillbaka automatiskt vid överskridande och håller utrullningen när urvalet är för litet för att bedöma.