Vad är ett SLO? En guide till driftsmål för ingenjörer

Vad ar ett slo?

Vad ar ett slo? Ett Service Level Objective (SLO) är ett internt driftsmål som ditt team sätter för sig själv. Det är inte ett avtal med kunder och inte en rå mätning från ditt observabilitetssystem. Ett SLO svarar på en enkel fråga: hur tillförlitlig måste denna tjänst vara, och hur mäter vi det?

Ett komplett SLO ser ut så här: 99,9% av HTTP-förfrågningarna till /api/checkout returnerar en lyckad statuskod och avslutas inom 300 millisekunder, mätt över ett rullande 30-dagars fönster. Tre komponenter: mätningen, målet och tidsfönstret. Alla tre betyder något.

SLI, SLO, SLA: Tre förkortningar som betyder helt olika saker

Dessa tre termer dyker upp tillsammans konstant. Team använder dem utbytbart. De beskriver helt olika saker.

En SLI (Service Level Indicator) är den råmätning som ditt övervakningssystem producerar. Felfrekvens som en procentsats av totala förfrågningar. P99-latens i millisekunder. Andelen lyckade databasskriv. SLI är numret som kommer ut från Datadog, Grafana eller vad du än kör. Det berättar vad som hände.

Ett SLO (Service Level Objective) är målet du definierar ovanpå SLI:n. Det svarar på: av alla möjliga värden denna SLI kan ta, vilket intervall räknas som acceptabelt? Om din SLI är felfrekvens och ditt SLO är "felfrekvens under 0,1% för 99% av femminutersfönstren", då har du ett pass/fail-test, inte bara ett nummer på en dashboard.

Ett SLA (Service Level Agreement) är den externa versionen av samma logik, med avtalskonsekvenser. Ditt SLA kan säga "99,5% drifttid annars utfärdar vi 20% tjänstekrediter." Ditt SLO bör sitta över denna tröskel så att ditt team känner till en försämring innan SLA-brottet blir ett kundsamtal.

Klyftan mellan SLO och SLA är inte polstring för slarvighet. Det är en designad marginal som omvandlar "vi trender mot ett brott" till "vi har tid att fixa detta nu."

En annan viktig distinktion: SLI:er mäts kontinuerligt, men SLO:er utvärderas över ett fönster. Samma felfrekvens mätt över sju dagar jämfört med 30 dagar ger mycket olika pass/fail-resultat. En enda dålig timme betyder mycket i ett sjudagars fönster. I ett 30-dagars fönster är det ungefär en procent av perioden. Att välja rätt fönster är lika viktigt som att välja rätt mål.

Varför "Hur tillförlitlig?" inte är en fullständig fråga

Innan du väljer ett nummer måste du förstå vad användaren upplever när tjänsten försämras. "Vi behöver fem nior" är ett uttalande av ambition, inte en mätning. En checkout-API på 99,999% tillgänglighet betyder ungefär 26 sekunder med fel per månad. För en tjänst som behandlar tio transaktioner per sekund kan det vara acceptabelt. För en tjänst som hanterar finansiell reglering i realtid kanske inte.

Rätt SLO beror på två faktorer: användareffekten av en försämring och driftskostnaden för att upprätthålla ett tätare mål.

Om din tjänst har loggat 99,3% tillgänglighet under de senaste 90 dagarna, startar ditt första SLO på 99,9% är aspirerande, inte kalibrerat. Det praktiska tillvagagångssättet: hämta de senaste 90 dagarna av SLI-data, sätt SLO något tätare än nuvarande prestanda, granska sedan kvartalsvis. Ett 99,5% SLO med en verklig felbudgetpolicy slår ett 99,9% SLO som får ignoreras varje gång det bryter.

Vanliga SLO-mål efter tjänsttyp:

• Användarvända API:er (checkout, autentisering): 99,9% tillgänglighet, P99-latens under 500ms

• Interna tjänster (datapipelines, batchjobb): 99,5% framgångsfrekvens, mätt på jobbutsändning

• Administrationsverktyg: 99% tillgänglighet är ofta tillräckligt

• Bakgrundsarbetare: SLO på jobbutsändningstid snarare än HTTP-status

När du väljer vilket SLI att mäta använder du de fyra signalerna från Googles SRE-bok som utgångspunkt: tillgänglighet (lyckades förfrågan?), latens (hur lång tid tog det?), genomflöde (hur många förfrågningar hanterar systemet?) och felfrekvens (vilken andel misslyckades?). Inte varje tjänst behöver alla fyra. De flesta team får verklig signal från tillgänglighet plus en latenspercentil. Att lägga till fler SLI:er innan du har en tillförlitlig baslinje för de två första är ett vanligt sätt att skapa brus utan att få insikt.

Felbudgeten: Från mål till driftsbeslut

Ett felbudget är den matematiska inversen av ditt SLO. Om ditt tillgänglighetsSLO är 99,9%, då får 0,1% av förfrågningarna över mätfönstret misslyckas. För en tjänst som tar emot en miljon förfrågningar per månad är det 1 000 misslyckade förfrågningar innan SLO:t bryter.

Felbudgeten gör SLO:er driftsmässigt användbara. Utan det är ett SLO en tröskel som överskrids och sedan diskuteras. Med en felbudgetpolicy blir det ett beslutsramverk.

När felbudgeten är frisk, säg 80% återstöd med två veckor kvar i fönstret, kan teamet skicka snabbt. Nya funktioner, experiment, mer riskfyllda utplaceringar är alla inom gränser. Felbudgeten är signalen att hastighet för närvarande inte är begränsningen.

När felbudgeten bränner ner skiftar teamet. Icke-kritiska ändringar pausas. Utplaceringspolicyn skärps. Tillförlighetsfixeringar får prioritet. Felbudgeten gjorde beslutet, inte ett bedömningssamtal från en chef om huruvida saker "känns stabilt nog."

Ett konkret scenario: en checkout-tjänst hade en 12-minuters försämring en tisdag eftermiddag som konsumerade 15% av det månatliga felbudgeten. En andra incident på torsdag konsumerade ytterligare 12%. Vid 27% förbrukat i första veckan av månaden utlöser felbudgetpolicyn: ingen ny funktionsutplacering tills en postmortem är slutförd och rotorsaken är lagad. Det beslutet är inte en produkt/teknik-förhandling. Det är en avläsning från data.

Google publicerade sin felbudgetpolicy i SRE Workbook: en enstaka incident som förbrukar mer än 20% av det kvartalsvisa felbudgeten kräver en postmortem. Det är en konkret policy att anpassa.

Burn rate-varningar tar detta längre. Istället för att vänta tills felbudgeten nästan är borta, en burn rate-varning utlöser när förbrukningshastigheten tyder på att du kommer att tömt budgeten innan fönstret slutar. Om din tjänst förbrukar felbudget med 14 gånger den normala hastigheten kommer du att uttömma ett 30-dagars budget på ungefär 50 timmar. En varning på denna hastighet ger teamet två dagar att svara snarare än ett postmortem-meddelande efter brottet. Verktyg som Datadog och Grafana stöder multi-fönster, multi-burn-rate-varningar direkt. Att ställa in det tar en eftermiddag. Att inte ha det betyder att upptäcka SLO-brott efter att kunderna redan märkt.

Ställa ditt första SLO utan att få numret fel

Det vanligaste misstaget är att börja med målet innan man etablerar mätningen.

Steg 1: Definiera SLI:n. "Tillgänglighet" är inte en SLI. "HTTP-förfrågningar som returnerar en icke-felstatus (2xx/3xx), dividerat med alla HTTP-förfrågningar" är en SLI. Mätningen måste kunna produceras från telemetri du redan har. Att lova att instrumentera något "snart" betyder att SLO:t saknar datakälla.

Steg 2: Hämta historisk data. Titta på de senaste 60 till 90 dagarna. Hur ser SLI:n egentligen ut? Vilka var de två eller tre värsta dagarna? Detta berättar vad målet är uppnåeligt idag och hur mycket spelrum du har innan första brottet.

Steg 3: Ange tidsfönstret. Rullande 30-dagars fönster är mest vanliga och ger responsiv, alltid aktuell data. Kalendermånads-fönster skapar cliff-effekter vid månadsgränser. Sjudagars rullande fönster är mer känsliga men kan utlösa för ofta för team som fortfarande bygger tillförlitlighetsmuskler.

Steg 4: Skriv felbudgetpolicyn innan du behöver den. Vid vilken felbudget-burn rate pausar teamet icke-kritiska ändringar? Vid vilken burn rate eskalerar on-call? Dokumentera detta före incidenten, inte under den.

Steg 5: Börja med en tjänst. Att definiera SLO:er för 15 tjänster på en gång producerar 15 dashboards ingen läser. Börja med den mest användarsynliga tjänsten, kör en kvartal, justera, expandera sedan.

Alternativ för tidsfönster och deras avvägningar:

• 7-dagars rullande: snabb feedback, känsligare för korta incidenter, kan skapa varningsutmattning

• 30-dagars rullande: mest vanlig, balanserar signal och brus

• 90-dagars rullande: användbar för sällsynta men kritiska operationer som batchjobb

Ett konkret exempel: för ett e-handels-API kan du ange ditt första SLO som "95% av förfrågan till /checkout lyckas och returneras inom 500ms, mätt över ett rullande 28-dagars fönster." Det ger dig en konkret SLI (framgångsfrekvens kombinerad med latens), ett specifikt mål (95%) och ett definierat fönster (28 dagar). Därifrån beräknar du felbudgeten: 5% av totala förfrågningar kan misslyckas eller vara långsamma. Om du mottar 200 000 förfrågningar per dag är ditt månatliga felbudget ungefär 280 000 misslyckade förfrågningar innan SLO:t bryter.

Där SLO-övervakning ansluter till kodbasarbete

Ett felbudget som bränner snabbare än förväntat är ett kodbaseproblem oftare än ett infrastrukturproblem. Latensanpassningar spåras tillbaka till N+1-frågor som gick obemärkta i kodgranskning. Tillgänglighetsfall spåras tillbaka till ett null-pekarundantag i en kodsökväg som endast utlöses under en specifik lastblandning. SLO:t detekterar symptomen. Kodbasen innehåller orsaken.

Det är här tiden mellan "varning utlöses" och "rotorsak identifierad" blir den praktiska begränsningen. När checkout-tjänsten förbrukar 30% av sitt felbudget på tre dagar och on-call-ingenjören måste grep över en 150 000-rad monorepo för att hitta återförsöklogiken som beter sig annorlunda under belastning blir SLO:t användbart. Verktygen för rotorsaksanalys är det inte.

Team som har instrumenterat AI-assisterad kodsökning tillsammans med deras observabilitets-stack rapporterar signifikant kortare tid till diagnos under incidenter. En naturspråksfråga om var betaltjänsten hanterar försök på 503-svar visar den relevanta funktionen på sekunder snarare än de 20 minuter det tar att läsa över fem filer och en Confluence-sida. De 43-minutersfönstret för felbudget spenderas på att fixa problemet, inte på att läsa koden.

Fyra sätt som team får SLO:er fel

För många SLO:er. Ett team som spårar 12 SLO:er samtidigt kommer att behandla varningar som bakgrundsbrus inom två månader. Tre till fem SLO:er fokuserade på det mest användarsynliga beteendet är ett arbetbart tak för ett team på 10 ingenjörer. Om du behöver fler, organisera dem i nivåer: kritiska SLO:er som utlöser felbudgetpolicyer och informationsmässiga SLO:er som bara genererar data.

Mäta infrastruktur, inte användarupplevelse. CPU-användning, minnesanvändning och disk-I/O är användbara debug-signaler. De är dåliga SLI:er om du inte kan bevisa att de direkt korrelerar med användarsynlig försämring. Mäta vad användaren upplever: förfråganframgångsfrekvens, responstid vid P95 eller P99, tid för att rendera den första meningsfulla delen av data.

SLO:er satta utan analys av driftskostnad. Att uppnå 99,99% tillgänglighet kräver typiskt aktiv redundans, multi-region failover och omedelbar on-call-respons varje timme. Om teamet inte kan driftsmässigt arbeta på detta sätt kommer SLO:t att bryta regelbundet och sedan ignoreras. Ett bruten-och-ignorerat SLO är värre än inget SLO: det tränar teamet att avfärda tillförlitlighetsvarningar.

Använda felbudgetdata för att tillskriva skuld. Om det första svaret på ett förbrukat felbudget är att identifiera vem som skickade ändringen som orsakade det, kommer rapporteringen att sluta vara ärlig. Felbudgeter är en teamresurs. När budgeten blir lågt är frågan "vad fixar vi?" inte "vem är ansvarig?"

Det organisatoriska hälsotestet: skulle du dela din aktuella felbudgetstatus på en ingenjörs-all-hands utan att det utlöser en politisk diskussion? Om inte behöver kulturen omkring SLO:er mer uppmärksamhet än målen själva. Tillförlitlighetsmätvärden fungerar som beslutsverktyg endast när teamet litar på att rapportera ett problem inte skapar personlig risk.

SLO:er behöver kvartalsvisa granskningar, inte årliga

Att ställa ett SLO är inte en engångs-kalibrering. Tjänster förändras, trafikmönster skiftar och kostnaden för att upprätthålla en given tillförlitlighetsnivå förändras med dem.

Varje 90 dagar, gå genom fyra frågor:

1. Höll SLO:t? Om ja, var det bekvämt, vilket tyder på att målet kan vara tätere?

2. Förbrukades felbudgeten helt? Vilka incidenter körde det?

3. Levererade SLO:t användbar signal eller åsidosatte teamet felbudgetpolicyn?

4. Är tidsfönstret fortfarande lämpligt för hur tjänsten används?

Om teamet åsidosatte felbudgetpolicyn mer än två gånger i ett kvartal är SLO:t förmodligen felkalibrerat. Antingen är målet för tätt, fönstret är för kort, eller mätningen reflekterar inte vad användare faktiskt upplever.

SLO:er är kalibreringsverktyg. De är tänkta att justeras när tillförlitligheten förbättras, när trafiken växer och när verksamheten ändrar sin tolerans för stilleståndstid. Ett team som granskar och justerar sina SLO:er kvartalsvis kör en tillförlighetspraxis. Ett team som ställde dem en gång och inte har rört dem sedan har en dashboard med nummer som betyder ingenting för någon.