Site Reliability Engineering: techniek en discipline om diensten online te houden

Bijgewerkt: 2 september 2026 · 6 min leestijd

Stel je een grote webwinkel voor tijdens Black Friday. Miljoenen mensen proberen tegelijk te bestellen, servers piepen onder de belasting en één verkeerde configuratiewijziging kan de hele site laten crashen. Site Reliability Engineering (SRE) is de discipline die ervoor moet zorgen dat dit soort systemen toch betrouwbaar blijven draaien, zonder dat elke verandering aan de software een gok wordt. Het is geen los stukje techniek zoals een app of een chip, maar een manier van werken waarbij software engineers verantwoordelijk worden gemaakt voor het draaiend houden van diensten in productie.

De kernidee is simpel te begrijpen met een analogie: denk aan een vliegtuigmaatschappij. Vliegen brengt altijd risico met zich mee, en volledige veiligheid bestaat niet. In plaats daarvan werkt de luchtvaart met meetbare veiligheidsmarges, strikte procedures na incidenten en voortdurende verbetering op basis van data. SRE past diezelfde logica toe op digitale diensten: in plaats van te streven naar honderd procent uptime (wat onbetaalbaar en onrealistisch is), spreken teams af hoeveel storing acceptabel is, meten ze dat nauwkeurig, en gebruiken ze die ruimte bewust om sneller te kunnen vernieuwen.

Wat is het precies?

SRE ontstond uit een simpele maar ongebruikelijke keuze: laat software engineers, niet alleen traditionele systeembeheerders, verantwoordelijk zijn voor het beheer van productiesystemen. Het idee is dat engineers operationele problemen aanpakken zoals softwareproblemen: door ze te automatiseren in plaats van ze steeds handmatig op te lossen.

Een aantal begrippen vormt de kern van deze aanpak. Een SLI (Service Level Indicator) is een meetbare grootheid, bijvoorbeeld hoeveel procent van de verzoeken aan een website binnen 200 milliseconden wordt beantwoord. Een SLO (Service Level Objective) is het interne doel dat een team zichzelf stelt voor die meting, bijvoorbeeld "99,9% van de verzoeken binnen 200 milliseconden, gemeten over 30 dagen". Een SLA (Service Level Agreement) is vaak een naar buiten toe beloofde, contractueel vastgelegde versie daarvan, meestal met financiële consequenties als hij niet gehaald wordt.

Het verschil tussen 100% betrouwbaarheid en de afgesproken SLO heet het error budget: de hoeveelheid "toegestane" storing die een team mag "opmaken" voordat het moet stoppen met nieuwe features uitrollen en zich moet richten op stabiliteit. Dit budget is bedoeld om een eeuwige spanning te ontmijnen: productteams willen snel nieuwe functies lanceren, terwijl operationele teams voorzichtigheid willen. Met een error budget krijgt snelheid ruimte zolang de afgesproken betrouwbaarheid gehaald wordt, en wordt er automatisch afgeremd zodra dat niet meer zo is.

Een ander centraal begrip is toil: repetitief, handmatig operationeel werk dat geen blijvende waarde toevoegt, zoals het steeds opnieuw herstarten van een vastgelopen dienst. SRE-teams proberen toil structureel te verminderen door het te automatiseren, met een vaak genoemde vuistregel dat operationeel werk niet meer dan zo'n 50% van iemands tijd zou mogen innemen. Ten slotte hoort bij SRE de gewoonte van blameless postmortems: na een storing wordt uitgezocht wat er structureel misging, zonder individuen de schuld te geven, zodat mensen eerlijk durven te melden wat er is gebeurd.

Wat wil men ermee bereiken?

De achterliggende belofte van SRE is dat betrouwbaarheid en snelheid van ontwikkeling geen tegenpolen hoeven te zijn, maar met de juiste meetmethodes en afspraken in balans te brengen zijn. Zonder heldere doelen ontstaat vaak een cultuur waarin operations-teams reflexmatig "nee" zeggen tegen veranderingen, omdat elke wijziging risico op storing met zich meebrengt terwijl zij niet degenen zijn die de nieuwe functie bedacht hebben.

Een tweede doel is het voorkomen dat een groeiende dienst evenredig meer operationeel personeel nodig heeft. Door repetitief werk te automatiseren, kan in theorie één klein SRE-team een dienst ondersteunen die tien of honderd keer zo groot is als een paar jaar eerder, zonder dat het aantal mensen in dezelfde mate meegroeit.

Verder wil SRE incidenten ombuigen tot leermomenten in plaats van schuldvragen. Een storing wordt gezien als een systeemfout, niet als een persoonlijke fout van de engineer die op dat moment dienst had. Dat klinkt voor de hand liggend, maar in veel organisaties overheerst van oudsher toch een cultuur van verwijten na een grote uitval, wat mensen ervan weerhoudt fouten volledig te melden.

Voorbeelden uit de praktijk

Google geldt als bakermat van SRE. Rond 2003 kreeg ingenieur Ben Treynor Sloss de opdracht een team van zeven software engineers verantwoordelijk te maken voor een productiesysteem, en hij bedacht daarvoor de naam en de aanpak die we nu SRE noemen. In 2016 publiceerde Google, via uitgeverij O'Reilly, het boek Site Reliability Engineering: How Google Runs Production Systems, samengesteld door redacteurs Betsy Beyer, Chris Jones, Jennifer Petoff en Niall Richard Murphy. Dit boek maakte de aanpak wereldwijd bekend buiten Google. In 2018 volgde een praktischer vervolg, The Site Reliability Workbook, met concrete stappenplannen voor bedrijven die de aanpak zelf wilden invoeren.

Netflix ontwikkelde vanaf 2011 zijn "Simian Army", een verzameling tools waarvan Chaos Monkey de bekendste is. Chaos Monkey schakelt willekeurig onderdelen van Netflix' productie-infrastructuur uit, expres, om te controleren of het systeem zulke uitval automatisch en zonder gebruikersimpact opvangt. Dit werd de basis voor wat nu breder "chaos engineering" heet: bewust storingen veroorzaken om zwakke plekken te vinden voordat een storing je overkomt op een slecht moment.

Ook LinkedIn heeft publiekelijk gedocumenteerd hoe het error budgets en SLO's gebruikt om te bepalen wanneer teams zich op stabiliteit moeten richten in plaats van op nieuwe functies, met eigen interne tooling voor het meten van SLI's over honderden microservices.

Microsoft heeft SRE-praktijken breed ingevoerd binnen Azure, onder meer via eigen interne SRE-teams en via aanbevelingen aan klanten in het zogeheten Azure Well-Architected Framework. Amazon hanteert met AWS een vergelijkbare pijler, "operational excellence", als onderdeel van zijn Well-Architected Framework, al gebruikt Amazon niet altijd exact dezelfde terminologie als Google.

Hoe ver is de techniek?

SRE is geen technologie met een duidelijke rijpheidscurve zoals bijvoorbeeld kunstmatige intelligentie, maar een organisatorische en technische discipline. Die is inmiddels goed ingeburgerd bij grote techbedrijven en wordt sinds het Google-boek uit 2016 in rap tempo overgenomen door banken, telecombedrijven en overheidsorganisaties die grootschalige online diensten draaien.

Rond deze discipline is een stevig ecosysteem aan open source-gereedschap ontstaan: monitoringtools zoals Prometheus en Grafana, alarmerings- en on-call-systemen zoals PagerDuty, en platforms als Kubernetes die veel operationele taken kunnen automatiseren. Veel van deze projecten worden inmiddels beheerd door de Cloud Native Computing Foundation, een stichting die open source-infrastructuurprojecten host.

Er zijn ook reële knelpunten. SRE vraagt om engineers die zowel goed kunnen programmeren als operationele systemen begrijpen, en die combinatie is schaars op de arbeidsmarkt. In de praktijk zien critici bovendien geregeld dat bedrijven simpelweg hun bestaande operations-team omdopen tot "SRE-team" zonder de onderliggende cultuur van meten, automatiseren en error budgets daadwerkelijk in te voeren, soms smalend "SRE-washing" genoemd. Ten slotte blijft het lastig om voor complexe, snel veranderende systemen betekenisvolle en stabiele SLO's te bepalen: te strenge doelen remmen onnodig af, te losse doelen laten problemen ongemerkt voorbijgaan.

Wie werken eraan?

Naast pionier Google en Netflix passen vrijwel alle grote clouddiensten inmiddels vormen van SRE toe, waaronder Microsoft Azure en Amazon Web Services. Ook bedrijven als LinkedIn, Dropbox en GitHub hebben publiekelijk over hun SRE-praktijken gepubliceerd via engineeringblogs en conferentiepresentaties. Buiten de bedrijven zelf speelt de Cloud Native Computing Foundation een rol als beheerder van veel gereedschap dat SRE-teams gebruiken, en publiceert de vereniging USENIX via haar tijdschrift ;login: en de voormalige LISA-conferentie regelmatig over systeembeheer en betrouwbaarheidsengineering. Academisch onderzoek naar het onderwerp staat nog in de kinderschoenen vergeleken met de praktijkervaring bij deze bedrijven; het meeste gepubliceerde materiaal komt vooralsnog uit de industrie zelf, niet uit universitair onderzoek.