Chaos engineering in 2026: hoe je begint, of het veilig is in productie en wat EU DORA aan testen vereist

De meeste productie-incidenten in een modern platform ontstaan niet doordat één component netjes uitvalt. Ze ontstaan door een afhankelijkheid die traag wordt in plaats van te falen, een retry-storm die een kleine hapering omzet in een storing, of een failoverpad dat nog nooit echt verkeer heeft gedragen. De outage-analyse 2026 van het Uptime Institute maakt hetzelfde punt op industrieschaal: Andy Lawrence, executive director van Uptime Intelligence, verwacht dat storingen steeds vaker "linked to complex interactions between systems, including software, networks, and external dependencies" zullen zijn in plaats van het gevolg van één single point of failure (Uptime Institute via ITWeb, mei 2026). Designreviews en unittests vinden die interacties niet. Gecontroleerde experimenten wel. Dat is de taak van chaos engineering, en hieronder staan de vragen die engineeringleiders er het vaakst over stellen.

Een netwerkkast vol verwarde blauwe patchkabels, een herinnering dat echte systemen falen door rommelige interacties en niet door nette losse fouten. — Foto: Brian Hankins (Bhankins) / Publiek domein, via Wikimedia Commons

Wat is chaos engineering nu eigenlijk?

De gangbare definitie komt uit de Principles of Chaos Engineering: het is de discipline van experimenteren op een systeem om vertrouwen op te bouwen in het vermogen van dat systeem om turbulente omstandigheden in productie te doorstaan. Het sleutelwoord is experimenteren. Chaos engineering is niet willekeurig servers uitschakelen om te zien wat er gebeurt. Elk experiment bestaat uit vier delen:

Een steady state, gedefinieerd als meetbare business-output en niet als interne metrics. AWS geeft het voorbeeld van een betaalsysteem dat 300 transacties per seconde verwerkt met 99% succes en 500 ms round-trip time (AWS Well-Architected, REL12-BP04).
Een hypothese die vastlegt welke fout je injecteert, welke mitigatie die moet opvangen en welke metric bewijst dat dat gelukt is. Bijvoorbeeld: als 20% van de nodes in een Kubernetes-nodegroep wordt beëindigd, houdt de transactie-API de p99-latency onder 100 ms en gaan alerts binnen drie minuten af.
Een gecontroleerde injectie met een afgebakende scope, stopcondities en een rollback.
Verificatie en verbetering: als de steady state brak, pas je het ontwerp aan en draai je het experiment opnieuw.

Weet je al dat het systeem omvalt, draai het experiment dan niet. AWS is expliciet: chaos engineering bestaat om known-unknowns en unknown-unknowns te vinden; experimenteren op iets waarvan je weet dat het kapot is, leert je niets nieuws. Repareer het eerst.

Wat is het verschil tussen chaos engineering, loadtesten en DR-testen?

De drie vullen elkaar aan, en teams die ze door elkaar halen houden meestal een gat over.

Loadtesten beantwoordt de vraag "hoeveel kan het hebben?" Het vindt capaciteitsgrenzen en bottlenecks bij bekende verkeerspatronen.
Disaster-recoverytesten beantwoordt de vraag "krijgen we het terug?" Het valideert failover, restore en je RTO- en RPO-doelen voor grote, zeldzame gebeurtenissen zoals het verlies van een regio.
Chaos engineering beantwoordt de vraag "wat gebeurt er als één onderdeel degradeert terwijl de rest gewoon doordraait?" Het richt zich op gedeeltelijk falen: extra latency, pakketverlies, een gethrottelde afhankelijkheid, een DNS-fout, een gekilde pod tijdens een deploy.

Gedeeltelijk falen is waar de interessante bugs zitten. Een studie uit mei 2025 van 971 GitHub-repositories die tien chaos-engineeringtools gebruiken, vond dat netwerkverstoring (40,9%) en het beëindigen van instances (32,7%) de foutscenario's domineren die teams daadwerkelijk schrijven, terwijl fouten op applicatieniveau slechts 3,0% uitmaken (Owotogbe et al., arXiv, 2025). Dat is een bruikbare startset, en ook een hint naar wat de meeste programma's te weinig testen: wat je eigen code doet als een downstream-call traag is in plaats van onbereikbaar.

Is chaos engineering veilig in productie?

Het is veilig als het zo ontworpen is, en de vangrails zijn bekend. De Principles stellen dat chaos "strongly prefers to experiment directly on production traffic", omdat staging zelden de echte request-paden, datavolumes en het gedrag van afhankelijkheden nabootst. Maar niemand die het serieus doet, begint daar. De volgorde die standhoudt in gereguleerde omgevingen:

Begin in een pre-productieomgeving die op productie lijkt, vooral om te bewijzen dat je stopcondities werken en dat je observability de fout daadwerkelijk ziet.
Definieer stopcondities op klantgerichte metrics. Foutpercentage, latency-percentielen en een synthetische user-canary, gekoppeld aan automatisch stoppen en terugdraaien van het experiment. AWS Fault Injection Service ondersteunt tot vijf stopcondities per experimenttemplate, gekoppeld aan CloudWatch-alarmen.
Beperk de blast radius. Eén instance, één availability zone, één procent van het verkeer, of een canary-deployment die een controle- en een experimentgroep naast elkaar draait.
Draai eerst buiten piekuren, met iedereen op de hoogte. Operations, SRE en klantenservice moeten weten dat er een experiment loopt en een kanaal hebben om het te stoppen.
Herstel de bekende goede toestand aan het einde, waar mogelijk automatisch, en leg de resultaten vast.

De risicoafweging is het echte argument. Je krijgt vroeg of laat hoe dan ook een timeout van een afhankelijkheid in productie. De enige keuze is of dat gebeurt op een dinsdag om 10:00 uur met een rollbackknop en de juiste engineers die meekijken, of om 03:00 uur tijdens een release freeze.

Hoe begin je met chaos engineering?

Begin niet met tooling. Begin met je incidenthistorie. AWS noemt het negeren van eerdere post-incidentanalyses bij het kiezen van fouten expliciet als antipatroon. Een praktisch eerste kwartaal ziet er zo uit:

Kies één kritieke gebruikersflow met goede observability en een SLO, bij voorkeur een die al eens een echt incident heeft veroorzaakt.
Breng de resiliencemechanismen in kaart (retries, timeouts, circuit breakers, multi-AZ, autoscaling) en de fout die elk ervan moet opvangen. Rangschik fouten op frequentie en impact.
Organiseer een begeleide game day voor de hoogst gerangschikte fout: injecteer hem, kijk of alerts afgaan, of het runbook klopt en of on-call de oorzaak kan vinden. Game days testen mensen en processen net zo goed als code.
Maak van geslaagde experimenten regressietests. Zodra een hypothese standhoudt, raadt AWS aan die te automatiseren in de CI/CD-pipeline, zodat een latere wijziging de mitigatie niet ongemerkt kan verwijderen. Experimenten niet zowel in de pipeline als buiten deployments draaien staat eveneens op de lijst met antipatronen.

Welke chaos-engineeringtools moet je gebruiken?

Op Kubernetes zijn de open-source CNCF-projecten Chaos Mesh en LitmusChaos de standaardkeuze, en de GitHub-studie hierboven zag Chaos Mesh en LitmusChaos voorop lopen in actieve ontwikkeling, met Toxiproxy en Chaos Mesh als meest gebruikte tools. Toxiproxy is een lichte manier om netwerkfouten in integratietests te injecteren. Op AWS dekt Fault Injection Service fouten in EC2, ECS, EKS en RDS met ingebouwde stopcondities, en kan het experimenten van Chaos Mesh en Litmus orkestreren. Azure biedt Chaos Studio, en Gremlin is het belangrijkste commerciële platform. Wat je ook kiest: AWS raadt ad-hocscripts af, tenzij ze de toestand van de workload kunnen lezen, logs uitsturen en kunnen terugdraaien. Behandel experimenten als code, gereviewd en geversioneerd zoals al het andere.

Verplicht EU DORA chaos engineering?

Niet bij naam. Maar de Digital Operational Resilience Act schept verplichtingen waaraan een gedisciplineerd chaosprogramma goed voldoet (Verordening (EU) 2022/2554):

Artikel 24 verplicht financiële entiteiten, met uitzondering van micro-ondernemingen, tot een risicogebaseerd testprogramma voor digitale operationele weerbaarheid, met tests door onafhankelijke partijen, een proces om bevindingen te prioriteren en te verhelpen, en ten minste jaarlijks passende tests van alle ICT-systemen die kritieke of belangrijke functies ondersteunen.
Artikel 25 somt de testtypen op die het programma moet omvatten, waaronder scenariogebaseerde tests en performancetests naast scans en penetratietests. Hypothesegedreven foutinjectie is een scenariogebaseerde test met bewijs erbij.
Artikel 26 verplicht entiteiten die door hun toezichthouder zijn aangewezen om ten minste elke drie jaar threat-led penetration testing uit te voeren, op live productiesystemen. Valt jouw organisatie daaronder, dan heeft de toezichthouder de discussie of experimenteren in productie te riskant is al beslecht.

Wat auditors willen zien is bewijs: de hypothese, de scope, het resultaat, de bevinding en de fix, plus aantoonbaar hertesten van die fix. Chaos-experimenten die als code zijn vastgelegd, met gelogde resultaten, leveren precies dat spoor op.

Waar begin je?

Kies één kritieke flow, schrijf drie hypotheses op basis van je laatste drie incidenten, bewijs je stopcondities in pre-productie en draai binnen een maand de eerste game day. Automatiseer daarna alles wat slaagt. Weerbaarheid die je onder gecontroleerd falen hebt gemeten, is voor je klanten en je toezichthouder veel meer waard dan weerbaarheid die je alleen hebt ontworpen.