Wat SRE oplost
Welkom bij Site Reliability Engineering
Site Reliability Engineering (SRE) ontstond in 2003 bij Google. Ben Treynor Sloss nam een klein ops-team over en bouwde het opnieuw op alsof engineers, en niet menselijke pagers, de productie draaiende hielden. Het resultaat werd het standaardmodel voor het runnen van grote internetdiensten.
Traditionele operations-teams hielden diensten draaiende door handwerk: herstart deze server, bel die engineer, schrijf een runbook en hoop dat het blijft werken. Dat model breekt bij schaal. Een team van vijftig operators kan niet handmatig vijfduizend servers herstarten. Boven een bepaalde grootte wordt handmatig werk een belasting die elke productieve uur opslokt.
SRE keert het model om. In plaats van meer operators in te huren wanneer systemen groeien, huurt SRE software engineers in en zegt tegen hen: schrijf code die het operationele werk voor je doet. Je werk kwalificeert als software engineering toegepast op operationele problemen. Je output: automatisering, monitoring en engineered reliability, geen handmatige interventies.
Drie fundamentele ideeën sturen de SRE-praktijk:
- Service Level Objectives (SLOs): numerieke betrouwbaarheidsdoelen, vooraf overeengekomen
- Error budgets: de inverse van een SLO, besteed aan het nemen van risico’s
- Toil elimination: elk operationeel werk dat lineair schaalt met de systeemgrootte moet verdwijnen
Deze drie ideeën vloeien door in elke SRE-praktijk: postmortems, on-call-rotaties, capaciteitsplanning, monitoring en release engineering.
Traditionele Ops versus SRE
Waarom traditionele Ops faalt bij schaal
Een typisch ops-team groeit lineair mee met de systemen die het beheert. Verdubbel het aantal servers, verdubbel het aantal operators. Dit is financieel zinvol voor kleine implementaties en rampzalig op schaal: je kunt jezelf niet uit een kwadratisch probleem inhuren.
SRE beperkt operationeel werk tot vijftig procent van de tijd van een engineer. De andere helft moet naar engineering gaan: tools bouwen, processen automatiseren, de toil elimineren die hen in de eerste plaats tot vijftig procent bracht. Als toil te lang boven de vijftig procent uitkomt, moet het team werk teruggeven aan een development team of meer SRE’s aannemen. De vijftig-procentregel voorkomt dat een SRE-team onder aanhoudende druk in een traditioneel ops-team verandert.
Vergelijk de faalmodi:
- Traditionele ops: meer incidenten leiden tot meer handmatige reacties, waardoor er minder tijd overblijft voor preventie, wat weer meer incidenten veroorzaakt. Een doom loop.
- SRE: meer incidenten triggeren postmortems, die automatiseringskansen blootleggen, waardoor de responstijd bij het volgende incident afneemt. Een virtuous loop, als het werkt.
SLI, SLO, SLA
Drie letters die productie draaiende houden
Betrouwbaarheid zonder meting is toneelspel. SRE maakt betrouwbaarheid een getal, vooraf afgesproken, dat iedereen kan verifiëren.
Service Level Indicator (SLI): een meting van het gedrag van een dienst. Voorbeelden: verzoeklatentie, foutpercentage, doorvoer, wachtrijdiepte. Een SLI is iets wat je kunt grafieken.
Service Level Objective (SLO): een streefwaarde of bereik voor een SLI. Voorbeeld: '99,9% van de HTTP-verzoeken slaagt over een voortschrijdend venster van 28 dagen.' Een SLO is een belofte die je aan jezelf en je gebruikers maakt over aanvaardbare dienstkwaliteit.
Service Level Agreement (SLA): een contractuele verplichting, meestal met financiële sancties bij overtreding. Voorbeeld: 'We betalen 10% terug als de maandelijkse beschikbaarheid onder 99,9% zakt.' Een SLA is een belofte die door juristen wordt afgedwongen.
Belangrijk onderscheid: je SLA moet altijd ruimer zijn dan je SLO. Als je intern 99,9% nastreeft en extern 99,9% contracteert, heb je geen marge. SRE’s hanteren doorgaans SLO’s die één nine strenger zijn dan de SLA: 99,95% intern doel, 99,9% contract. De marge vangt de onvermijdelijke slechte week op.
Error Budgets: De Inverse SLO
Van betrouwbaarheidsdoelen naar engineeringbeslissingen
Een SLO stelt een betrouwbaarheidsdoel. Het error budget is wat overblijft: de hoeveelheid falen die je kunt besteden voordat je het doel mist.
Als je SLO 99,9 % succes belooft over 28 dagen, is je error budget 0,1 % van de verzoeken, of ongeveer 40 minuten volledige downtime per maand. Dat budget mag je naar eigen inzicht besteden: aan geplande releases, experimentele functies, chaos engineering of het tolereren van een onbetrouwbare afhankelijkheid.
Error budgets herformuleren het conflict tussen dev en ops. Zonder budget leidt elke storing tot discussie over wie de slechte wijziging heeft uitgerold en hoe de volgende te voorkomen. Met een budget:
- Budget over: sneller releasen, meer risico’s nemen, experimenten uitvoeren. Het budget betaalt daarvoor.
- Budget op: stoppen met nieuwe features, risicovolle wijzigingen bevriezen, focus leggen op betrouwbaarheidswerk totdat het budget weer is opgebouwd.
Dit maakt betrouwbaarheid van een emotioneel argument tot een meetbare resource. Engineers kunnen het budget bewust besteden, net als elke andere productie-input.
Toil definiëren
Wat telt als toil
Niet elke operationele taak kwalificeert als toil. SRE definieert toil precies: werk dat handmatig, repetitief, automatiseerbaar, tactisch, zonder blijvende waarde en lineair schaalt naarmate de service groeit.
Alle zes eigenschappen moeten gelden. Een eenmalige datamigratie is handmatig maar niet repetitief: dat kwalificeert niet als toil. Een senior engineer die een nieuwe servicearchitectuur ontwerpt neemt een tactische beslissing maar voegt blijvende waarde toe: dat kwalificeert niet als toil.
Voorbeelden die wel als toil kwalificeren:
- Handmatig een service herstarten na een crash door een memory leak
- Logfragmenten plakken in een chatkanaal tijdens incident triage
- Een ticketformulier invullen om een nieuwe database te provisioneren
- Handmatig een kwartaalcapaciteitsrapport uitvoeren
- Routinematige deploymentverzoeken een voor een goedkeuren
De vijftig-procentregel beperkt toil tot de helft van de tijd van een SRE. Boven de 50 % moet het team verantwoordelijkheid teruggeven aan een productteam of extra engineers aannemen, maar het doel blijft duidelijk: toil naar nul terugbrengen door het te vervangen door geautomatiseerde systemen die hetzelfde werk doen zonder menselijke tussenkomst.
Automatisering bespaart niet alleen tijd. Het verwijdert een hele klasse van menselijke fouten. Een script dat een database provisiont, vergeet geen stappen na een lange dienst.
Toil-auditredenering
Je team houdt bij hoe de tijd wordt besteed. Vorige kwartaal was de verdeling: 30 % deploys, 25 % incidentrespons, 20 % capaciteitswerk, 15 % feature-ontwikkeling, 10 % eenmalige verzoeken van productteams.
On-Call Hygiëne
Engineers, Not Pagers
On-call brengt echte kosten met zich mee. Slaap raakt verstoord, weekends worden onderbroken en de stress van onbekende problemen stapelt zich op. SRE behandelt on-call als een eindige resource die duurzaam moet blijven, geen heroïsche last die gedragen wordt door wie er het meest om geeft.
Gezonde on-call-rotaties volgen verschillende principes:
- Gecompenseerde tijd: on-call-uren worden omgezet in tijd-voor-tijd, extra salaris of een vergelijkbaar voordeel. Gratis on-call leidt tot burn-out van het team.
- Redelijke rotatiediepte: een team van zes personen met een primary plus secondary betekent dat elke engineer om de drie weken een dienst draait. Rotaties met twee personen vernietigen carrières.
- Budget voor aantal pagina’s: het SRE-boek van Google stelt een maximum voor van twee paging events per twaalf uur durende dienst. Daarboven moet het team engineering-tijd investeren in het verminderen van het aantal alerts, in plaats van het alleen maar te doorstaan.
- Alleen actionable alerts: elke page moet menselijk handelen vereisen. Als een page genegeerd zou worden, geautomatiseerd kan worden of herhaaldelijk afgaat tijdens normale operatie, mag die niet bestaan. Alert fatigue is een betrouwbaarheidsdefect.
- Follow-the-sun-handoffs: wereldwijd verspreide teams geven diensten door op tijdzonegrenzen zodat niemand om 3 uur ’s nachts gepingd wordt tenzij het systeem echt niet tot de ochtend kan wachten.
Blameless Postmortems
Hoe storingen verbeteringen worden
Elk significant incident krijgt een postmortem: een schriftelijke analyse van wat er is gebeurd, waarom, wat het oploste en welke veranderingen herhaling voorkomen. De postmortem is het SRE-equivalent van samengestelde rente: elk exemplaar voegt permanente betrouwbaarheid toe aan het systeem.
Blameless betekent dat het document storingen toeschrijft aan systemen en processen, nooit aan individuen. Als een engineer het verkeerde commando uitvoerde, vraagt de postmortem: waarom stond het systeem dat commando toe? Waarom ving geen safeguard het op? Welke wijziging aan het systeem, de documentatie of de tooling voorkomt dat de volgende engineer dezelfde fout maakt?
Blamelessness bestaat om één reden: mensen verbergen fouten als ze straf vrezen. Verborgen fouten worden het volgende incident. De kosten van een blameless cultuur zijn laag in vergelijking met het opstapelen van niet-gemelde defecten.
Postmortems behandelen doorgaans:
- Samenvatting: beschrijving van het incident en de impact in één alinea
- Tijdlijn: reconstructie per minuut met tijdstempels
- Root cause analysis: technische en procesfactoren die de storing mogelijk maakten
- Detection: hoe het team op de hoogte raakte van het incident en hoe lang dat duurde
- Resolution: de acties die zijn ondernomen om de dienst te herstellen
- Lessons learned: wat werkte en wat niet
- Action items: concrete, toegewezen en tijdgebonden engineeringtaken
Action items leven in een tracker. Ze worden geprioriteerd zoals elk ander engineeringwerk. Postmortems zonder action items reduceren tot verhalen vertellen. Het werk verandert niets.
De Vier Gouden Signalen
Wat Elke Service Moet Meten
Google's SRE-boek stelt vier signalen voor die elke user-facing service moet blootstellen: latency, traffic, errors en saturation. Samen beschrijven ze de gezondheid van de service vanuit het perspectief van de gebruiker. Monitoren met minder signalen laat blinde vlekken achter; monitoren met honderden metrics begraven het team in alert fatigue.
Latency: hoe lang verzoeken duren. Volg distributies, geen gemiddelden. p50 (mediaan) beschrijft de typische ervaring. p99 beschrijft de slechtste 1% van de gebruikers. Alleen een gemiddelde verbergt lange staarten: een service met mediaan 50 ms en p99 5.000 ms lijkt prima op het gemiddelde, maar ruïneert één gebruiker op de honderd.
Traffic: de vraag naar de service. Voor een webdienst betekent dit verzoeken per seconde. Voor een streamingdienst gelijktijdige verbindingen. Voor een batchjob items verwerkt per minuut. Traffic correleert met capaciteitsbeslissingen en onthult afwijkingen in de workload.
Errors: het percentage mislukte verzoeken. Expliciete fouten (HTTP 500), impliciete fouten (HTTP 200 met corrupte data) en beleidsfouten (reactie te traag om aan de SLO te voldoen) tellen allemaal mee. Het onderscheid tussen deze typen is belangrijk: een 200 met een slechte payload schaadt gebruikers vaak meer dan een eerlijke 500.
Verzadiging: hoe vol het systeem draait. CPU-gebruik, wachtrijdiepte, geheugendruk, bezetting van de connectiepool. Verzadiging voorspelt toekomstige latentie: een systeem op 95% CPU heeft nog maar weinig marge voordat de latentie voor gebruikers sterk toeneemt.
De meeste SRE-alerts zijn gebaseerd op deze vier signalen. Symptoomgebaseerd alarmeren (alarmen wanneer gebruikers het merken) presteert beter dan oorzaakgebaseerd alarmeren (alarmen wanneer CPU boven 80% komt). De vier gouden signalen beschrijven symptomen.
SRE-carrièrepaden
Waar SRE-vaardigheden lonen
SRE-carrières splitsen zich op basis van welk deel van de discipline een engineer het leukst vindt:
Infrastructure SRE: bouwt de platforms waarop andere teams draaien. Kubernetes, service meshes, interne cloud. Zware systems engineering, theorie van gedistribueerde systemen en platformontwerp. Betaalt extreem goed bij grote bedrijven omdat het werk schaalt: één infrastructure SRE ondersteunt honderden product engineers.
Embedded SRE: werkt samen met een product engineering team om de betrouwbaarheid van een specifieke service te verbeteren. Half engineer, half coach. Sterke communicatie- en code review skills zijn net zo belangrijk als technische diepgang. Vaak de beste route voor engineers die graag lesgeven.
Reliability tooling: bouwt de observability stack: monitoring, alerting, dashboards, postmortem tools, incident management platforms. Zware frontend- en data engineering werkzaamheden. De output wordt door elk ander team gebruikt.
Production engineering: de Facebook/Meta-term voor SRE gericht op capaciteit, deployment en traffic management. Zware networking- en systems werkzaamheden.
Technische certificeringen die de moeite waard zijn: de Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional en CNCF-certificeringen (Kubernetes Administrator, Kubernetes Application Developer) tonen cloud-native vaardigheid aan. Linux Foundation-certificeringen tonen systeemkennis. Geen van deze certificeringen vervangt portfolio-werk, maar ze helpen wel bij het passeren van recruiter-schermen.
Afronding
Wat je nu weet
Site reliability engineering begon als Googles antwoord op een schaalbaarheidsprobleem en groeide uit tot een discipline die nu in de hele sector wordt toegepast. Je hebt behandeld:
- De verschuiving van handmatige operaties naar engineered reliability
- SLI’s, SLO’s, SLA’s en het inverse-SLO-concept van error budgets
- Toil-definitie, de 50%-regel en engineering-gedreven reductie
- Duurzame on-call-rotaties en blame-free postmortem-praktijk
- De vier gouden signalen als startpunt voor service monitoring
- SRE-carrièrepaden en de certificeringen die deuren openen
Twee ideeën zijn het belangrijkst. Betrouwbaarheid is een getal, vooraf overeengekomen. En toil is een defect, geen functieomschrijving. Draag deze twee mee en de rest van SRE volgt vanzelf.
Aanbevolen literatuur: Google's SRE Book (gratis online: sre.google/books/), het SRE Workbook voor praktische oefeningen, en het werk van Charity Majors over observability. De geometry-of les gaat dieper in op de visuele structuur onder SRE-praktijk: latency-verdelingen, error-budgetkegels, afhankelijkheidsgrafieken en dashboard-indelingen.