Wat is site reliability engineering? SRE voor solo devs
Samenvatting
Site reliability engineering behandelt operations als een softwareprobleem. Je stelt een meetbaar doel voor betrouwbaarheid, houdt bij hoe vaak je het mist, en laat dat getal beslissen of je features uitrolt of eerst repareert. Het error budget is 100% min je SLO: bij 99.9% over 30 dagen is dat ongeveer 43 minuten. Voor een side project is het een avondje werk: een SLI, een SLO, een health check en een postmortems-bestand.
Wat is site reliability engineering? Het is de aanpak waarbij je operations behandelt als een softwareprobleem: je stelt een meetbaar doel voor betrouwbaarheid, houdt bij hoe vaak je dat doel mist, en laat dat getal bepalen of je nieuwe features uitrolt of eerst dingen repareert. Google heeft de term bedacht, maar het idee werkt op elke schaal. Voor een solo dev met een app en een handvol gebruikers betekent het dat je vooraf vastlegt hoeveel downtime je accepteert.
Wat in de praktijk vastloopt: de meeste side projects hebben zo'n getal niet. Ze staan "aan" tot iemand je mailt. Deze gids legt SRE uit in gewone taal en krimpt het daarna tot iets wat een persoon in een weekend kan draaien.
Wat is site reliability engineering eigenlijk?
De korte versie komt uit het SRE-boek van Google: SRE is wat je krijgt als je een softwareontwikkelaar vraagt een operations-team te ontwerpen. In plaats van dat mensen servers met de hand herstarten, schrijf je code die het doet, en meet je de resultaten.
Drie ideeën dragen het meeste gewicht. Betrouwbaarheid is een feature met een doel, geen gevoel. Repetitief handwerk (het boek noemt dat toil) is een bug die je wegautomatiseert. En falen wordt verwacht, dus je plant hoe je ervan leert in plaats van hoe je schuld vermijdt.
DevOps en SRE overlappen flink. Het praktische verschil: DevOps is een cultuur waarin je code samen bouwt en draait, terwijl SRE je concrete cijfers geeft om over te discussiëren. Je hoeft geen kamp te kiezen om die cijfers te gebruiken.
Bij een groot bedrijf verdeelt een SRE zijn tijd over on-call, incidentrespons, capaciteitsplanning en automatisering. Het Google-boek zegt dat de operationele last rond de helft van iemands tijd moet blijven, zodat de rest naar engineering gaat. Die grens is een ontwerpeis, geen wensdenken.
Het terugkerende werk ziet er zo uit:
SLO's afspreken met de productteams en alerteren op het verbruik van het budget, niet op elke piek
On-callroosters draaien en runbooks schrijven, zodat de pagina om drie uur 's nachts een checklist heeft
Incidenten leiden en daarna een blameless postmortem schrijven
Alles automatiseren wat je meer dan een paar keer met de hand doet
Launches nakijken op betrouwbaarheidsrisico's voordat ze in productie gaan
Feature flags zijn een goed voorbeeld van die mindset. Met een flag zet je een slechte release in seconden uit, zonder redeploy, en dat beschermt het budget. Of je daar een gehoste tool voor nodig hebt, hangt af van het aantal flags: voor de eerste drie volstaat een environment variable.
SLI, SLO en SLA: drie afkortingen, elk één idee
Een SLI (service level indicator) is iets wat je meet. Voor een webapp is dat meestal het aandeel requests dat slaagt, of het aandeel dat binnen 300 ms antwoordt. Kies er een of twee. Niet twaalf.
Een SLO (service level objective) is het doel dat je op die meting zet, bijvoorbeeld "99.9% van de requests slaagt over 30 dagen". Dit is intern. Het is een belofte aan jezelf.
Een SLA (service level agreement) is een contract met een klant, meestal met terugbetaling als je het doel mist. Heeft niemand je ooit betaald voor uptime, dan heb je nog geen SLA, en je moet er ook niet per ongeluk een schrijven in de tekst van je prijspagina.
Error budgets: het deel dat je werkwijze verandert
Het error budget is simpelweg 100% min je SLO. Een doel van 99.9% over 30 dagen laat ongeveer 43 minuten toegestane storing over. Dat is het budget dat je mag uitgeven aan riskante deploys, migraties en experimenten.
Het nuttige zit in de regel die erbij hoort. Zolang er budget over is, ship je. Is het op, dan stop je met features en repareer je de betrouwbaarheid tot het budget weer hersteld is. Het hoofdstuk over risico in het boek gebruikt dit om de discussie tussen "sneller bewegen" en "niets kapotmaken" te beslechten met één gedeeld getal, in plaats van met onderhandelen.
Het legt ook een botte waarheid bloot die het herhalen waard is: 100% is bijna nooit het juiste doel. Gebruikers op een wankel mobiel netwerk merken het verschil tussen 99.99% en 99.9% niet, en elke extra negen kost veel meer dan de vorige. Het is geen perfect doel. Het is een werkbaar doel.
Wil je de concrete werkwijze voor het kiezen van indicatoren en het schrijven van je eerste doel? Het SRE-workbook over het implementeren van SLO's is het meest praktische hoofdstuk, en het is kort.
Heb je SRE nodig als je alleen bouwt?
Drie redenen om het te doen, één reden om het niet te doen.
Om het te doen: je eigen project gaat je vroeg of laat wakker bellen, een geschreven doel houdt je tegen over-engineering, en "ik draai productie met een SLO" leest goed als iemand bepaalt of hij je inhuurt of vertrouwt. De reden om het niet te doen: heeft je project nog geen gebruikers, dan oefen je voor een probleem dat je nog niet hebt. Bouw eerst, meet zodra iemand erop leunt.
Sla dus het volledige apparaat over. Huur geen pagingdienst in voor een hobbyapp, draai geen Kubernetes om serieus over te komen, en schrijf geen incidenttemplate van tien pagina's. Het loont wel zodra je tien echte gebruikers hebt: een health check, één SLO en een plek om te kijken als het breekt.
Een SRE-opzet voor een side project, in één avond
Dit is het minimum dat ook bij tienduizend gebruikers meestal overeind blijft. Het kost één avond. Getest. Niet optimaal. Waarom we het toch doen: het is saai, en saai overleeft.
Eerst kies je één SLI: het aandeel HTTP-requests dat iets anders teruggeeft dan een 5xx. Ten tweede zet je de SLO op 99.5% over 30 dagen, wat ongeveer 3.6 uur budget is. Begin ruim en draai later aan de schroef. Ten derde voeg je een externe uptimecheck toe die een echt health-endpoint aanroept.
Een health-endpoint dat de moeite waard is, controleert de dingen die echt breken, en niet alleen of het proces nog leeft:
// GET /healthz
app.get("/healthz", async (req, res) => {
try {
await db.query("select 1"); // database bereikbaar
await cache.ping(); // cache bereikbaar
res.status(200).json({ ok: true });
} catch (err) {
res.status(503).json({ ok: false });
}
});Ten vierde stuur je alerts naar een plek waar je ze ziet: een pushmelding op je telefoon, geen inbox. Ten vijfde houd je een gewoon tekstbestand bij, postmortems.md, en voeg je na elke storing vier regels toe: wat er gebeurde, waarom, hoe lang, en wat er verandert. Dat bestand is het meest onderschatte betrouwbaarheidsinstrument dat je bezit.
Een veelgemaakte beginnersfout is jezelf laten pagen bij elke mislukte request. Binnen een week zet je het kanaal op stil. Een beter signaal is de burn rate: hoe snel je het error budget opbrandt, vergeleken met het tempo dat het precies aan het einde van het venster zou uitputten. Voor een side project houd je het simpel. Stuur een pushmelding als het foutpercentage van de laatste tien minuten boven 5% ligt, en een e-mailoverzicht als het weekpercentage richting een gemiste SLO gaat. Dat geeft twee niveaus: nu wakker worden, of maandag kijken.
Waar AI-tools helpen en waar niet
Assistenten zijn goed in het toil-deel: de health check schrijven, de Terraform voor een uptimemonitor, een eerste versie van een runbook, of een script dat logs doorzoekt op het 5xx-percentage. Slecht zijn ze in het bepalen van je SLO, want dat is een productbeslissing over wat je gebruikers tolereren.
Tijdens een incident moet je voorzichtig zijn. Een assistent kan een plausibele fix voorstellen die jij om twee uur 's nachts op productie toepast zonder hem te lezen. Gebruik hem om een stacktrace uit te leggen of om de postmortem achteraf op te stellen, en laat de beslissing over de rollback bij een mens die wakker is.
Kwaliteitscontroles in de CI horen hier ook bij. Veel storingen gaan terug op een wijziging die er bij de review onschuldig uitzag. Statische analyse in de CI maakt je niet betrouwbaar, maar ze haalt een categorie domme fouten weg voordat ze budget kosten.
Hoe schrijf je een postmortem die iemand leest?
Houd hem kort en blameless. Blameless betekent niet dat niemand verantwoordelijk is. Het betekent dat je vraagt wat er in het systeem de fout mogelijk maakte, en niet wie hem maakte. Als je de enige persoon in het team bent, telt dit zwaarder dan het lijkt, want de verleiding is om je rot te voelen en het schrijven over te slaan.
Vier kopjes zijn genoeg: wat er gebeurde, waarom het gebeurde, hoe lang gebruikers last hadden, en wat er verandert. Het laatste punt moet een actie noemen die je echt gaat doen, met een datum. "Beter opletten" is geen actie. "Een stagingcheck voor migraties toevoegen voor de volgende release" wel.
Na een jaar wordt dat bestand een kaart van je zwakke plekken. De regel na drie storingen door hetzelfde verlopen certificaat: komt dezelfde oorzaak twee keer terug, dan automatiseer je hem. Het kostte één avond om renewal-monitoring toe te voegen, en het is sindsdien niet meer voorgekomen.
Is SRE een goed carrièrepad voor een dev die graag bouwt?
Dat hangt af van wat je leuk vindt. SRE-rollen passen bij mensen die meer van systemen, faalmodi en automatisering houden dan van UI's shippen. Haal je voldoening uit een rustigere pager, dan vind je het leuk. Wil je zien dat gebruikers op je nieuwe feature klikken, dan waarschijnlijk niet.
De instap loopt meestal via backend- of infrawerk: je gaat de deploys en alerts van een service beheren en neemt daarna meer van de betrouwbaarheid over. Vaardigheden die meekomen: Linux-basics, netwerken, één cloudprovider, een monitoringstack en de gewoonte om dingen op te schrijven. Side projects zijn een goede plek om dat allemaal op te bouwen, omdat jij het hele team bent.
Kies één ding dat je al draait, zelfs een gratis app, en schrijf de SLI, de SLO en de exacte actie op die je neemt als het budget op is. Kun je niet zeggen wat je zou stoppen met doen, dan is het getal decoratie. Welk van je projecten zou je merken dat het down is voordat een gebruiker het je vertelt?