Vad är en SLO? En praktisk guide för solo-utvecklare

Vad är en SLO? Det är ett tal du lovar dig själv om hur ofta din tjänst ska fungera, mätt över ett fast tidsfönster. "99.9% av förfrågningarna lyckas under 30 dagar" är en SLO. Den gör att "sajten känns okej" blir något du kan kontrollera, och den visar när du ska sluta skicka nya funktioner och i stället laga det som är trasigt.

Du behöver inget plattformsteam för det här. En ensam utvecklare med ett API och en Postgres-databas kan skriva en användbar SLO på en eftermiddag. Här går vi igenom vad begreppet betyder, hur du väljer siffran och var det brukar gå snett.

Klockan två på natten och ingen visste om appen var trasig

Tänk dig ett sidoprojekt med 400 veckoanvändare. En natt börjar checkout-endpointen svara med 500-fel i ungefär 20 minuter. Ingen twittrar, ingen mejlar. Du får veta det tre dagar senare, via ett enda supportmejl.

Var det illa? Utan ett mål kan du inte svara på det. Med ett mål kan du det: om din SLO tillåter ungefär 43 minuters fel per månad och du just har förbrukat 20, vet du att du använt nästan hälften av utrymmet på en enda dålig natt. Det är hela poängen med en SLO. Den ersätter en känsla med en budget.

De tre förkortningarna, utan ordbokston

Folk blandar ihop SLI, SLO och SLA hela tiden, så här är den korta versionen.

En SLI (service level indicator) är en mätning. "Andelen HTTP-förfrågningar som gav en status utan 5xx under de senaste 30 dagarna" är en SLI. Det är ett förhållande mellan goda händelser och alla händelser.

En SLO (service level objective) är målet för den mätningen. "Det förhållandet ska ligga på minst 99.9%" är SLO:n. Den är intern. Du sätter den, du kan ändra den, och ingen stämmer dig för den.

En SLA (service level agreement) är ett kontrakt med konsekvenser, oftast återbetalningar eller krediter. De flesta sidoprojekt har ingen SLA, och det är helt okej. Du kan köra SLO:er utan en. Google SRE-workbookens kapitel om att införa SLO:er är standardreferensen om du vill ha den långa versionen.

Ordningen spelar roll: välj SLI först, sedan SLO, och tänk bara på en SLA om en betalande kund kräver det skriftligt.

Felbudgeten: delen som ändrar hur du jobbar

En SLO på 99.9% innebär också att 0.1% av händelserna får misslyckas. Den marginalen är din felbudget, och det är den användbara halvan av idén.

På en 30-dagarsmånad ger 99.9% tillgänglighet ungefär 43 minuters tillåten driftstopp. Räkningen är 30 dagar gånger 24 timmar gånger 60 minuter, vilket blir 43200 minuter, gånger 0.001. Ett mål på 99% ger ungefär 7.2 timmar. Ett mål på 99.99% ger ungefär 4.3 minuter.

De två sista siffrorna är skälet till att de flesta små projekt inte bör sikta högt. Fyra minuter i månaden betyder att en dålig deploy och en rollback redan bryter målet. Det som brukar överraska folk i praktiken: ju högre du siktar, desto mer av din tid går åt till att försvara siffran i stället för att bygga produkten.

Budgeten ger dessutom en regel för vad du ska bygga härnäst. Om budgeten i stort sett är intakt: skicka den riskfyllda funktionen. Om budgeten är förbrukad: fixa det ostadiga först. Inget möte behövs, bara en siffra på en instrumentpanel.

Hur du väljer en SLI du faktiskt kan mäta

Börja med vad en användare skulle kalla "trasigt". För en webbapp kokar det oftast ner till två frågor: lyckades förfrågan, och var den tillräckligt snabb?

För de flesta sidoprojekt täcker två SLI:er det mesta av nyttan:

• Tillgänglighet: lyckade förfrågningar delat med alla förfrågningar, där lyckad betyder ett svar utan 5xx.

• Latens: andelen förfrågningar som besvaras under en tröskel, till exempel 95% av förfrågningarna under 500 ms.

Lägg märke till att latens skrivs som en andel förfrågningar under en tröskel, inte som ett medelvärde. Medelvärden döljer den långsamma svansen, och det är där användarna ger upp. Percentiltänk är viktigt här: ett medelvärde på 300 ms kan ligga ovanpå en p99 på 4 sekunder.

Mät vid systemets kant, så nära användaren som möjligt. En hälsokontroll som pingar /healthz inifrån samma VPC visar att processen lever, inte att användare kan logga in. Om du bara har råd med en mätning, testa en riktig användarväg, till exempel inloggning eller checkout, utifrån.

Välja siffran: börja lägre än det känns rätt

Det ärliga svaret för ett nytt projekt är 99% eller 99.5%. Titta på dina senaste 30 dagars data, räkna ut vad du faktiskt levererade, sätt SLO:n något under det, och skärp den senare om användarna klagar.

Här är en grov vägledning för ett soloprojekt:

• Hobbyverktyg utan intäkter: 99% räcker gott. Runt 7 timmars fel i månaden är osynligt för de flesta användare.

• Betald SaaS med ett par dussin kunder: 99.5% till 99.9%, beroende på hur tidskänslig produkten är.

• Allt som kunder förlitar sig på under arbetstid: 99.9%, och testa din rollback innan du lovar den.

Testat, inte optimalt, men värt att göra ändå: en SLO du når 100% av gångerna är en siffra satt för lågt, och en SLO du missar varje månad är en siffra ingen litar på. Sikta på att missa den ibland, för då gör budgeten sitt jobb.

Är en SLO bara uptime-övervakning med extra steg?

Inte riktigt, även om de överlappar. En pingövervakning berättar att sajten svarade en viss minut. En SLO berättar hur stor andel av de riktiga användarförfrågningarna som fungerade under en månad, och vad det betyder för ditt nästa beslut.

Tänk dig två veckor där en pingövervakning visar grönt varje minut, men en långsam databasfråga gör att instrumentpanelen timeoutar för 3% av de inloggade användarna. Övervakningen säger att allt är bra. SLI:n säger att du missade ditt latensmål. Bara en av dem ändrar vad du gör på måndag.

Behåll pingövervakningen ändå. Den är billig och fångar totala avbrott snabbt. Behandla den bara som en indata, inte som definitionen av att något "fungerar".

En liten SLO du kan skriva ner idag

Du behöver ingen leverantör för att börja. Skriv det här i ditt repo, i en fil som heter SLO.md:

service: checkout-api
window: 30d
slis:
  availability:
    good: http_status < 500
    total: all requests except /healthz
  latency:
    good: response_time < 500ms
    total: all requests except /healthz
objectives:
  availability: 99.5%
  latency: 95%
if_budget_burned:
  - freeze non-urgent features
  - fix the top error source first

Om din stack redan exporterar antal förfrågningar är tillgänglighets-SLI:n i Prometheus-syntax en enda rad:

sum(rate(http_requests_total{status!~"5.."}[30d]))
  / sum(rate(http_requests_total[30d]))

Kvoten, jämfört med ditt mål, är hela din SLO-instrumentpanel. Allt annat är finlir. Tre paneler räcker: aktuell SLI, kvarvarande budget och en linje för burn rate.

Larma på burn rate, inte på varje missljud

Misstaget nästan alla gör är att larma varje gång felfrekvensen passerar ett tröskelvärde. Du blir väckt klockan tre på natten för en 90-sekunders topp som kostade dig 0.2% av månadens budget.

Burn rate löser det. Den frågar hur snabbt du förbrukar budgeten jämfört med takten som skulle tömma den exakt vid månadens slut. Burn rate 1 betyder att du avslutar månaden med en tom budget och inga överraskningar. Burn rate 10 betyder att den är tom om tre dagar.

En sund inställning för en person är två larm. Ett snabbt, till exempel burn rate över 10 under en timme, som väcker dig. Ett långsamt, runt burn rate 2 över ett dygn, som blir ett ärende till morgonen. Google SRE-bokens kapitel om service level objectives förklarar resonemanget bakom detta, och flerfönsterversionen finns i workbooken som länkas ovan.

Vilket verktyg när du är hela driftteamet

Du kan köra SLO:er från ett kalkylblad och ett cron-jobb i en månad medan du lär dig vad du bryr dig om. När siffrorna börjar betyda något förtjänar ett verktyg sin plats. Tre värda att titta närmare på, med förbehållet att din stack avgör mer än funktionslistan gör.

Grafana är standardvalet för dig som redan exporterar Prometheus-mätvärden. Gratisnivån är generös för ett sidoprojekt, och SLO-funktionen ligger ovanpå data du troligen redan har. Hoppa över den om du inte har någon mätpipeline än och ingen lust att bygga en.

New Relic har en gratisnivå med 100 GB dataintag per månad och SLO-verktyg inbyggda i plattformen. Det passar om du vill ha en agentbaserad installation med lite konfiguration. Avvägningen är att kostnaderna blir svårare att förutsäga när du passerar gratisgränsen.

Datadog är det mest kompletta alternativet och det dyraste, med infrastruktur, APM och loggar faktureras var för sig. Värt det om ett team växer runt dig. Hoppa över det för ett soloprojekt om inte någon annan betalar.

Vilket du än väljer: låt bli att definiera femton SLO:er första dagen. En SLO för tillgänglighet och en för latens per användarnära tjänst räcker för att lära dig något.

Ett helt uträknat exempel på en månad

Säg att din SLO är 99.5% tillgänglighet över 30 dagar, och du servar ungefär 600 000 förfrågningar i månaden. Målet tillåter 0.5% fel, alltså 3000 misslyckade förfrågningar innan budgeten är tom.

Dag 9 returnerar en dålig migrering 500-fel i 25 minuter och kostar dig 1100 misslyckade förfrågningar. Du har använt ungefär 37% av budgeten på en enda kväll. Dag 17 får ett externt API timeout och bränner 900 till. Nu står du på ungefär 67% förbrukat med 13 dagar kvar.

Det är i det ögonblicket budgeten förtjänar sitt uppehälle. Du behöver inte panika, men du bör inte heller skicka den riskfyllda refaktoriseringen du planerat till dag 20. Du lägger till en timeout och en reservlösning för det externa anropet, skriver migreringskontrollen du hoppade över, och flyttar refaktoriseringen till nästa månad.

Poängen är inte att fel är dåligt. Fel är väntade och inräknade. Det som siffran ger dig är ett lugnt, gemensamt svar på frågan "har vi råd med den här risken just nu?", även när den enda personen i rummet är du.

När du ska se över siffran igen

Gå igenom varje SLO en gång per kvartal, eller efter en månad där du missat den rejält eller aldrig rörde budgeten. Att missa den två gånger i rad betyder antingen att systemet behöver riktigt arbete eller att målet var ambitiöst för din nuvarande fas. Båda är användbara fakta.

Om du får betalande kunder, fråga dem vad "trasigt" betyder för dem. En kund som kör en veckorapport bryr sig om måndagsmorgonen, inte om en blipp på lördagskvällen, och din SLO kan spegla det med ett tätare mål under deras arbetstid.

Tre misstag som gör SLO:er värdelösa

Att mäta det som är lätt i stället för det användarna känner. CPU-användning är inte en SLI. Användare bryr sig inte om att din CPU ligger på 40%. De bryr sig om att sidan laddade.

Att sätta målet utifrån ambition. "Vi vill ha fem nior" låter seriöst och betyder ingenting om din databas är en enda instans på en liten VM. Sätt SLO:n utifrån observerad verklighet, förbättra sedan systemet, och skärp först därefter siffran.

Att aldrig använda budgeten. Om du avslutar varje månad med 98% av budgeten kvar kör du för långsamt, eller så är målet för löst. En oanvänd budget är oanvänd riskkapacitet.

Vad skulle du lägga under en SLO först?

Välj en endpoint som användarna skulle märka om den gick sönder. Skriv SLI:n på vanlig svenska, sätt målet 0.5 procentenheter under vad du levererade förra månaden, och kolla igen om 30 dagar. Om du vill ha ett sidoprojekt som tvingar dig att öva på det här är en liten instrumentpanel för drifttid och latens för dina egna appar en bra helgbygge. Vilken av dina tjänster skulle du lita minst på just nu?