Serviceniveaumål (SLO)

En SLO består af tre dele: en serviceniveauindikator (SLI), et mål og en overholdelsesperiode. SRE Workbook anbefaler at udtrykke enhver SLI som forholdet mellem gode hændelser og gyldige hændelser, så den ligger mellem 0 og 100 % og har en ensartet betydning: for tilgængelighed vellykkede svar divideret med alle gyldige forespørgsler, hvor fx 4xx-svar forårsaget af klienter udelades; for latenstid andelen af forespørgsler, der besvares hurtigere end en tærskel som 300 ms; og for datapipelines friskhed, korrekthed eller dækning. Latens-SLO'er angives normalt som et percentilmål (99 % af forespørgslerne under 300 ms) frem for et gennemsnit, der skjuler halen. Tidsbaserede SLI'er, der tæller gode minutter i stedet for gode forespørgsler, vægter en stille nat lige så højt som spidsbelastningen og giver derfor ofte et skævt billede af brugerpåvirkningen.

Fejlbudgettet er 1 minus målet anvendt på perioden. Ved 99,9 % over 30 dage må en tjeneste fejle på 0,1 % af de gyldige forespørgsler, hvilket er 1.000 fejl pr. million forespørgsler eller, for en tidsbaseret SLI, 43,2 minutter. Rullende perioder (de seneste 28 eller 30 dage) afspejler, hvad brugerne har oplevet for nylig, og undgår, at budgettet pludselig nulstilles den første i måneden; kalenderperioder passer til forretningsrapportering og SLA'er. Alarmering bør styres af burn rate, altså hastigheden, hvormed budgettet forbruges, frem for af den øjeblikkelige SLI.

Budgettet bliver et ledelsesværktøj gennem en fejlbudgetpolitik, som produkt, udvikling og drift aftaler på forhånd: fx at når budgettet er brugt op, sættes nye funktioner på pause, bortset fra rettelser af driftssikkerhed og sikkerhedsopdateringer, indtil tjenesten er tilbage inden for målet, og at enhver enkelt hændelse, der bruger mere end en fastsat andel af budgettet, kræver en postmortem. Uden en sådan politik er en SLO bare et dashboard. Omvendt er et stort resterende budget en tilladelse til at tage risici, fx hurtigere udrulninger eller chaos-eksperimenter.

Mål bør fastsættes ud fra brugernes forventninger og historisk ydeevne, ikke ambitioner. 100 % er det forkerte mål, fordi brugerne ikke kan skelne det fra meget høj tilgængelighed bag deres egne ufuldkomne netværk, og fordi jagten på det fryser al forandring. En SLO kan heller ikke realistisk overstige den samlede tilgængelighed af hårde afhængigheder, herunder tredjeparters SLA'er, uden redundans. For mange SLO'er spreder opmærksomheden; nogle få pr. kritisk brugerrejse er typisk. SLO'er måles bedst så tæt på brugeren som praktisk muligt, ved loadbalanceren eller med telemetri fra klienten, fordi metrikker på serversiden overser forespørgsler, der aldrig når frem. Specifikationer som OpenSLO gør det muligt at erklære SLO'er som kode sammen med tjenesterne, og SLO'en sættes strengere end enhver ekstern SLA, så den interne reaktion kommer før kontraktbruddet.