Wat is site reliability engineering? SLO's en error budgets

Dus, wat is site reliability engineering? Het is de praktijk om productiesystemen te draaien met softwareengineering in plaats van handmatige operations. Een SRE-team legt een numeriek betrouwbaarheidsdoel vast, meet daartegen en automatiseert het repetitieve werk dat diensten overeind houdt. Als je om 3 uur 's nachts wakker wordt voor dezelfde schijfalert, elke maand opnieuw, dan is dat precies het probleem dat SRE moet wegnemen.

Google heeft de term rond 2003 bedacht. Vandaag wordt het idee ver buiten Google gebruikt, van startups van 20 mensen tot banken. Wat verschilt is de schaal, niet de kernmechanica.

Wat doet een site reliability engineer eigenlijk?

Ben Treynor Sloss, die het SRE-team van Google opzette, zei het eenvoudig in het openingshoofdstuk van het Google SRE-boek: SRE is wat er gebeurt als je een softwareengineer vraagt een operationsteam te ontwerpen. Het werk is operations, gedaan met code.

In een gewone week betekent dat vier dingen. Je bepaalt wat "werkend" betekent voor een dienst. Je bouwt de monitoring die vertelt wanneer dat niet zo is. Je reageert als het breekt, en je schrijft de fix zodat de volgende persoon niet voor hetzelfde wordt opgeroepen.

Twee voorbeelden maken dat concreet. Een team dat elke donderdag handmatig deployt, bouwt een pipeline met automatische rollback. Een team dat een lekkende service elke nacht herstart, vindt het lek. Beide maken van een terugkerende klus een eenmalig project, en daar draait het om.

Het vierde deel is het deel dat teams overslaan. Een SRE die alleen op incidenten reageert, is een ops-engineer met een nieuwe titel. Het engineeringdeel maakt de rol anders.

Wat is het verschil tussen SRE en DevOps?

DevOps is een cultuur: developers en operators delen de verantwoordelijkheid voor wat er wordt uitgerold en hoe het draait. Het zegt je dat de muur tussen teams een probleem is. Het zegt je niet hoeveel downtime acceptabel is, of wanneer je moet stoppen met uitrollen.

SRE levert de cijfers. Het geeft je service level objectives, error budgets en een plafond op handmatig werk. Google's eigen kader is dat SRE één concrete manier is om DevOps-ideeën in de praktijk te brengen.

Laat het debat over welke van de twee "beter" is maar zitten. Als je een team van 8 leidt, leen je uit beide. De nuttige vraag is of je team in één zin kan zeggen hoe betrouwbaar een bepaalde dienst moet zijn.

Wat zijn SLI's, SLO's en SLA's, en waarom doen ze ertoe?

Drie afkortingen dragen het meeste gewicht in SRE, en mensen halen ze voortdurend door elkaar.

• SLI (service level indicator): een meting. Bijvoorbeeld het aandeel HTTP-verzoeken dat een niet-5xx-antwoord geeft in minder dan 300 ms.

• SLO (service level objective): het doel voor die meting. Bijvoorbeeld 99,9% over een rollend venster van 28 dagen.

• SLA (service level agreement): het contract met gevolgen, meestal terugbetalingen, als je het doel mist. Je SLA moet losser zijn dan je SLO.

De reden om er moeite voor te doen: "de site moet snel en betrouwbaar zijn" kun je niet testen. Een doel als "99,9% van de checkoutverzoeken slaagt in minder dan 500 ms" kun je wel testen, en dat beslecht discussies.

Begin met twee of drie SLI's per dienst. Meer en niemand onthoudt ze nog.

Kies SLI's die gebruikers voelen. CPU-gebruik is een oorzaak, geen symptoom. Mislukte betalingen, trage paginaladingen en verouderde data zijn wat een klant opmerkt.

Hoe werken error budgets?

Een error budget is de onbetrouwbaarheid die je SLO toestaat. Het is simpelweg 1 min de SLO. Een beschikbaarheidsdoel van 99,9% laat 0,1% over, ongeveer 43 minuten downtime in een maand van 30 dagen.

Hier is een kleine versie in code, want de rekensom is het hele idee:

slo = 0.999
window_minutes = 30 * 24 * 60          # 43200
budget = (1 - slo) * window_minutes    # 43.2 minuten
spent = 31                              # minuten slechte dienstverlening tot nu toe
print(f"{budget - spent:.1f} minuten over")  # 12.2 minuten over

Zolang er budget over is, levert het team snel. Als het op is, pauzeren featurereleases en verschuift het werk naar betrouwbaarheid. Het voorbeeld van een error budget policy in de SRE Workbook laat zien hoe een team zo'n regel opschrijft.

Het gaat niet om straf. Het vervangt de oude strijd, waarin developers willen uitrollen en operators stabiliteit willen, door één gedeeld getal dat beide kanten kunnen lezen. Het werkt alleen als het management vooraf akkoord gaat om de pauze te respecteren. Een budgetbeleid dat elk kwartaal wordt overruled, is decoratie.

Waarom bestaat de 50%-toilregel?

Toil is handmatig, repetitief werk dat meegroeit met je dienst en niets achterlaat. Een vastgelopen worker met de hand herstarten is toil. De health check schrijven die hem automatisch herstart, is engineering.

De SRE-organisatie van Google streeft ernaar toil onder de 50% van de tijd van elke engineer te houden, zoals beschreven in het hoofdstuk over het elimineren van toil. De rest gaat naar projecten die toekomstige toil verminderen of features toevoegen. De redenering is botweg: toil groeit tot 100% van ieders tijd als niemand er een einde aan maakt.

Behandel de 50% als plafond, geen doel. Een gezond team op een volwassen dienst zit er ruim onder. Als je er een kwartaal boven zit, doe je geen SRE meer, maar beheer je een ops-wachtrij.

Een simpele start: houd twee weken lang bij elk ticket en elke pager bij of het toil of project is. Rangschik de toil daarna op uren. De top drie is je automatiseringsbacklog.

Wat veranderen blameless postmortems?

Als er iets breekt, vraagt de postmortem hoe het systeem toeliet dat iemand een fout maakte, niet wie het deed. Schuld leert mensen informatie verbergen. Een blameless review leert ze het op te schrijven.

Een nuttige postmortem is kort en heeft vier delen: een tijdlijn, de bijdragende oorzaken, wat goed ging, en actiepunten met eigenaren en data. Actiepunten zonder eigenaar zijn wensen.

Het meeste van de waarde zit in de opvolging. Bespreek open actiepunten maandelijks. Als dezelfde oorzaak binnen zes maanden twee keer opduikt, is de eerste postmortem mislukt, wat er ook in het document stond.

Welke tools heeft een SRE-team eerst nodig?

Niet veel. Begin met de signalen en voeg daarna on-call en automatisering toe.

1. Metrics en dashboards. Genoeg om je SLI's te berekenen. Grafana en Prometheus vormen een veelgebruikte open-sourcecombinatie; Datadog en New Relic zijn de gehoste route.

2. Alerting gekoppeld aan SLO's. Alarmeer als het budget snel opbrandt, niet wanneer één host piekt. Minder pages, betere pages.

3. Feature flags en geleidelijke uitrol. Grofweg veroorzaakt de meeste storingen een wijziging, dus de goedkoopste betrouwbaarheidswinst is wijzigingen omkeerbaar maken. LaunchDarkly en Statsig dekken dit.

4. Een geschreven runbook voor elke page. Als een alert geen runbook heeft, schrijf er een of verwijder de alert.

Koop of bouw in die volgorde. Teams die beginnen met een toolaankoop zonder SLO eindigen met prachtige dashboards voor niets in het bijzonder.

Waar past het lezen van onbekende code in SRE?

Dit is het deel dat niemand in de functieomschrijving zet. Tijdens een incident moet een SRE vaak een dienst begrijpen die hij niet zelf schreef, in een repository die hij maanden niet heeft geopend. De vraag is zelden abstract. Het is "waar zit deze retry-loop, en wat doet die bij een timeout?"

Dat ken je al: grep, blame, en dan iemand appen die het bestand als laatste aanraakte. Op een repo van 80.000 regels werkt dat. Op 12 diensten van 6 teams kost het de eerste 20 minuten van een incident, en die minuten tellen mee in het budget.

Daar verdient een zoektool die vragen over je eigen repo beantwoordt zijn plek, bijvoorbeeld waar een dienst zijn timeouts instelt en welke callers ervan afhangen. Het lost de storing niet op. Het verkort de tijd die je kwijt bent aan lezen voordat je kunt handelen, en die tijd is meetbaar.

Is SRE overkill voor jouw team, en hoe begin je?

Sla een apart SRE-team over als je één dienst hebt, een handvol engineers, en gebruikers die een incidenteel slecht uur verdragen. Je hebt geen team nodig. Je hebt een SLO nodig, een degelijke alert en iemand die de pager bezit.

Overweeg het zodra een van deze dingen waar is: storingen kosten echt omzet, on-call brandt mensen uit, of developers worden vertraagd door ad-hocverzoeken aan operations. Veel bedrijven beginnen met één of twee engineers die deeltijds SRE worden, en kijken dan hoe het uitpakt.

Een veelgemaakte fout is het ops-team hernoemen tot "SRE" zonder de manier van werken te veranderen. Als het team nog steeds tickets, handmatige deploys en geen error budget heeft, is de titel veranderd en niets anders.

Hoe begin je volgende week?

Je hebt geen reorganisatie nodig. Kies de dienst die gebruikers het meeste pijn doet en doe vijf dingen.

1. Schrijf één SLI en één SLO voor die dienst. Houd ze saai.

2. Bereken het error budget en zet het op een dashboard dat het hele team ziet.

3. Houd twee weken toil bij en kies het bovenste item om te automatiseren.

4. Houd een blameless postmortem bij je volgende incident, met eigenaren op de actiepunten.

5. Leg schriftelijk vast wat er gebeurt als het budget nul bereikt.

Als het team over een maand minder discussieert over of er moet worden uitgerold en meer over wat de cijfers zeggen, werkt het. Als het budget nooit beweegt omdat de SLO te ruim is, maak hem dan strakker.