Vad är en SLO? Din praktiska guide till din felbudget

Vad är en SLO? Felbudgeten förklarad, med ett Sheets-mallexempel

Så, vad är en SLO? En service level objective är ett tillförlitlighetsmål du sätter för en tjänst, skrivet som ett tal över en tidsperiod. "99,9% av förfrågningarna lyckas under 30 dagar" är en SLO. Det säger till ditt team hur mycket fel som är acceptabelt innan du slutar leverera och börjar fixa. Matematiken bakom det är vanlig division, därför att ett kalkylblad klarar det fint.

Biscuit har redan hämtat formlerna åt dig. Du tar siffrorna.

De tre förkortningarna du hela tiden ser, sorterade

SLI, SLO, SLA. Folk blandas ihop dem i möten, så här är kortversionen.

• SLI (service level indicator): det du mäter. Andelen förfrågningar som returnerar utan fel, andelen sidor som laddar under 300 ms, andelen jobb som slutförs i tid.

• SLO (service level objective): målet för mätningen. "SLI:n måste vara minst 99,9% under 30 dagar."

• SLA (service level agreement): ett avtal med följdverkningar, oftast pengar tillbaka, kopplat till ett mål.

Det renaste testet kommer från Googles SRE-bok: fråga vad som händer om du missar målet. Om ingenting avtalsmässigt händer, tittar du på en SLO, inte en SLA. Din SLO bör vara snävare än någon SLA du har undertecknat, så du får en varning innan en kund får en återbetalning.

I kalkylbladstermer: SLI:n är en kolumn med mätningar, SLO:n är en cell med målet, och SLA:n är en PDF som någon i juridiken förvarar.

Varför 99,9% och 99,99% är mycket olika löften

Varje extra nia halverar din tillåtna stilleståndstid tio gånger. Under en 30-dagars månad (43 200 minuter) är här vad varje mål lämnar dig med:

• 99%: 1% budget, 432 minuter (7,2 timmar) tillåtet stillestånd per 30 dagar

• 99,5%: 0,5% budget, 216 minuter (3,6 timmar)

• 99,9%: 0,1% budget, 43,2 minuter

• 99,95%: 0,05% budget, 21,6 minuter

• 99,99%: 0,01% budget, 4,32 minuter

Den sista raden är fällan. Fyra minuter per månad betyder att en människa inte ens kan avsluta en läsning av varningen innan budgeten är slut. De flesta interna verktyg, instrumentpaneler och små SaaS-produkter behöver det inte, och att jaga det kostar riktiga pengar i redundans och on-call-timmar.

Hoppa över 99,99% om inte en kund betalar dig specifikt för det. Googles råd är också blunt: börja med ett löst mål du kan strama åt senare, för ett stramt mål du måste lossa lär alla att ignorera siffran.

Felbudgeten: det tal ditt team faktiskt diskuterar

Felbudgeten är vad SLO:n lämnar över. Mål 99,9%, så budgeten är 0,1%. Under 30 dagar är det 43,2 minuter av "dålig" tid som du får spendera.

Tänk på det som en bränslemätare. Riskfyllda utgivningar förbrukar bränsle. En dålig databasmigrering förbrukar bränsle. Ett avbrott klockan tre på natten förbrukar mycket bränsle. När tanken är full, skicka snabbare. När den är tom, sluta lägga till funktioner och fixa tillförlitligheten.

Googles eget exempelpolicy är konkret om det: om en tjänst spränger sin budget under en fyraveckorsperiod, alla ändringar stoppar förutom P0-fixes och säkerhetslappningar tills tjänsten är tillbaka inom sin SLO. Budgeten är ett förhandlingsverktyg, inte ett straff. Det låter en produktchef och en ingenjör diskutera från samma cell istället för från magkänsla.

Värt besväret om du har mer än ett team som rör samma tjänst. Överflödigt om du är en sologrundare med en landningssida och ett kontaktformulär.

Välja en SLI som dina användare skulle känna igen

De bästa SLI:erna beskriver ett ögonblick en person skulle märka. Tre täcker de flesta tjänsterna:

• Tillgänglighet: andelen förfrågningar som lyckas. Lätt att mäta, lätt att förklara.

• Latens: andelen förfrågningar snabbare än ett tröskelvärde. "95% av sökningar returnerar under 300 ms" är bättre än ett genomsnitt, för genomsnitt döljer den långsamma svans som irriterar folk.

• Aktualitet: för datapipelines och rapporter, andelen körningar som avslutas före deadline. Den här passar kalkylbladfolk väl: "försäljningsarket på morgonen uppdateras före klockan 8 på 99% av vardagar."

Skriv SLI:n som en bråkdel: bra händelser delat på giltiga händelser. Denna vana gör varje SLO beräkningsbar i en enda cell, och det tvingar dig att bestämma vad som räknas som "bra" innan incidenten, inte under den.

För fönstret är en rullande 30 dagar det vanligaste valet. En kalendermånad är enklare att rapportera men återställer budgeten på den första, som lockar team att skjuta riskfyllda utgåvor i slutet av månaden. I ett blad betyder ett rullande fönster bara att filtrera Incidents-fliken till de senaste 30 dagarna med SUMIFS(Incidents!C:C,Incidents!A:A,">="&TODAY()-30).

Bygg en SLO-spårare i Google Sheets eller Excel på 10 minuter

Du behöver inte en övervakningsplattform för att börja. Du behöver två flikar: Incidents och SLO.

På Incidents-fliken, logga varje avbrott med en starttid i kolumn A, en sluttid i kolumn B och varaktigheten i kolumn C:

=(B2-A2)*24*60

• B2 och A2: slut- och startdatum för incidenten.

• *24*60: omvandlar datumdifferensen till minuter.

Fungerar i både Excel och Sheets, alla versioner.

Nu SLO-fliken. Sätt dessa etiketter i kolumn A och formlerna i kolumn B:

B1: 0.999                         (ditt SLO-mål)
B2: 30                            (fönster i dagar)
B3: =B2*24*60                     (totala minuter i fönstret)
B4: =B3*(1-B1)                    (felbudget i minuter)
B5: =SUM(Incidents!C2:C)          (stillestånd hittills)
B6: =1-B5/B3                      (faktisk tillgänglighet)
B7: =B4-B5                        (budget kvar, i minuter)
B8: =B5/B4                        (andel av budget förbrukad)

Med ett 99,9%-mål returnerar B3 43 200 och B4 returnerar 43,2. Logga ett 12-minuters avbrott och B8 visar 27,8%. Voilà vad det ger i en riktig cell.

En notering om C2:C i B5: det öppna-ändat intervallet är Sheets-syntax. I Excel, använd ett fast intervall som Incidents!C2:C500 eller en tabellreferens.

Lägg till en statuscell så ingen behöver läsa numret:

=IF(B8>=1,"Frys utgåvor",IF(B8>=0.5,"Försiktig","Leverera"))

• B8>=1: budget helt förbrukad eller överförbrukad.

• B8>=0.5: hälften borta, så granska riskfyllda ändringar.

• Allt annat: grönt ljus.

Välj dina egna tröskelvärden. Femtio procent är en startgissning, inte en fysiklags.

Fast på syntaxen för din egen version av detta blad? Beskriv det på vanlig svenska och låt verktyget skriva det.

Räkna förfrågningar istället för minuter

Tidsbaserad spårning är lätt att förklara men grov. Om din tjänst är "nere" i 5 minuter klockan fyra på natten när ingen är online, gör det mindre skada än 5 minuter vid middagstid. De flesta seriösa team definierar SLI:n genom förfrågningar istället.

Klistra in en export av din begärlogg i en flik, med HTTP-statuskoden i kolumn B. Sedan:

=1-COUNTIF(B2:B,">=500")/COUNTA(B2:B)

• COUNTIF(B2:B,">=500"): räknar förfrågningar som returnerade ett serverfel.

• COUNTA(B2:B): räknar alla förfrågningar. En minus felandelen ger dig framgångsandelen.

Resultatet är din tillgänglighetsSLI som en bråkdel. Jämför den med målcellen och du har hela SLO:n på en rad. Excel 2016 och 365 accepterar båda COUNTIF; bara byt B2:B mot ett begränsat intervall.

Två ärliga varningar. Kalkylblad kvävas på miljoner rader, så exportera dagliga totaler istället för rå loggar. Och ett 4xx-svar är vanligtvis användarens misstag, inte ditt avbrott, så besluta denna regel en gång och skriv ned det.

Bränslehastighet: formeln som varnar dig innan det är för sent

Att veta att du förbrukade 27,8% av budgeten är trevligt. Att veta att du förbrukar den snabbare än kalendern är användbar. Det förhållandet är bränslehastigheten.

=B8/(B9/B2)

• B8: andel av budget förbrukad hittills.

• B9: dagar förflutna i fönstret (ange det manuellt eller använd =TODAY()-B10, med fönstrets startdatum i B10).

• B2: totalt fönster i dagar.

En bränslehastighet på 1 betyder att du slutför fönstret med exakt noll budget kvar. Över 1 går du mot en frysning. Under 1 har du utrymme. Om du är 10 dagar in i en 30-dagarsperiod och redan förbrukade 60%, är bränslehastigheten 1,8. Det är det tal du ska sätta på en skärm.

Det är samma idé som de stora övervakningsverktygen använder för varningar om bränslehastighet. Ett blad sidar dig inte klockan tre på natten, så behandla det som ett rapporteringslager, inte en larm.

Här är ett konkret exempel med riktiga siffror. Din SLO är 99,9% under 30 dagar, så budgeten är 43,2 minuter. Dag 1 till 8: en dålig release tar betalningssidan offline i 14 minuter. Det är 32,4% av budgeten borta på en fjärdedel av fönstret, en bränslehastighet på cirka 1,2. Ingenting brinner, men bladet säger nu "Försiktig", och nästa riskfylld migrering får en andra titt. Dag 15: ett leverantörsavbrott lägger till 30 minuter. Totalt 44 minuter, 101,9% förbrukad. Statuscellen vänder till "Frys utgåvor", och samtalet om prioriteringar händer med ett tal på bordet istället för en känsla.

Det är hela värdet av övningen. Inte niornas, utan den delade cellen alla kan peka på.

När kalkylbladet slutar räcka till

En spårare som denna fungerar för en eller två tjänster och en veckovis granskning. Det bryter ihop när du har dussintals tjänster, behöver automatisk datainsamling eller vill ha varningar som löses ut på minuter istället för vid nästa måndagsmöte.

Dags att titta på ett riktigt observationsverktyg. Datadog och Grafana har båda inbyggda SLO-funktioner som drar SLI:n rakt från dina mätvärden och ritar budgeten åt dig.

Välj Grafana om du vill ha öppen källkod och redan kör Prometheus. Välj Datadog om du hellre betalar för att inte köra något själv. Hur som helst, behåll bladet runt för den månatliga granskningsdäcken, för alla i rummet kan öppna det och ingen behöver en inloggning hos en leverantör.

Om du vill ha hjälp med att skissa en första uppsättning SLI:er för en tjänst, är en allmän assistent en anständig brainstorming-partner. Verifiera varje siffra den ger dig, för den uppfinner villigt ett trovärdigt klingande mål.

Misstag som gör en SLO värdelös, och vad man gör på måndag

Några mönster som Biscuit har sett sluta illa:

• Kopierar din nuvarande prestanda som målet. Om du körde på 99,97% förra kvartalet, låser en SLO på 99,97% in en takt du kanske inte kan behålla.

• För många SLO:er. Två eller tre per tjänst. Bortom det, ingen kommer ihåg vilken som spelar roll.

• Mäter vad som är lätt, inte vad användare känner. CPU-användning är ingen SLI. Misslyckade checkouts är.

• Ingen följd. En SLO utan en felbudgetpolicy är en önskan. Bestäm i förväg vad som händer vid 50%, 100% och 150% förbrukad.

• Granskar aldrig målet på nytt. Granska det varje kvartal. Om du aldrig kommer nära att spendera budgeten, är målet för löst.

Nu måndagsdelen. Välj en tjänst. Skriv ned en SLI i en enda mening en icke-ingenjör kunde följa. Sätt ett löst mål, 99,5% eller 99,9%. Bygg de två flikorna ovan, logga förra månadens incidenter, och se vad budgeten säger.

Om svaret är "vi förbrukade 300% av den", fick du just reda på varför alla känner sig trötta. Om svaret är "vi förbrukade 4%", strama åt målet eller leverera snabbare. Hur som helst, du har nu ett tal att diskutera istället för en känsla.

God kille. Gå nu och logga dessa incidenter.