Belangrijkste punten
- Chaos engineering is de praktijk waarbij u gecontroleerde storingsexperimenten uitvoert om proactief zwakke plekken in de weerbaarheid bloot te leggen voordat ze tot uitval in productie leiden.
- Bij chaos testing introduceert u een storing om het gedrag van het systeem te observeren, terwijl chaos engineering de discipline is die observaties omzet in bruikbare bevindingen.
- Effectieve chaos engineering volgt vastgelegde principes die experimenten veilig en herhaalbaar houden.
- Chaos engineering werkt goed bij het valideren van de betrouwbaarheid van failover, de nauwkeurigheid van monitoring, escalatiepaden en de RTO in gedistribueerde omgevingen of omgevingen met hoge beschikbaarheid.
- Chaos engineering levert op de lange termijn waarde als feedbackloop die het gat tussen veronderstelde en bewezen weerbaarheid continu verkleint.
Zelfs goed ontworpen systemen kunnen uitvallen, zeker in grote moderne omgevingen die leunen op cloudservices, diensten van derden en gedistribueerde systemen. In plaats van u te laten verrassen door storingen helpt chaos engineering u om zwakke plekken op te sporen voordat ze uitgroeien tot ongecontroleerde incidenten.
Wat is chaos engineering: een overzicht
Bij chaos engineering introduceert u gecontroleerde storingen en verstoringen in een systeem. Netflix zette de praktijk rond 2011 op de kaart met Chaos Monkey, waarmee het willekeurig instanties van virtuele machines in de eigen productieomgeving beëindigde.
Waar conventionele tests het gedrag beoordelen aan de hand van vooraf vastgelegde uitgangswaarden, onderzoekt chaos engineering het gedrag bij onverwachte problemen. Het proces voert wetenschappelijke experimenten uit om echt vertrouwen op te bouwen in de weerbaarheid van een systeem.
Een chaos-engineeringexperiment introduceert realistische storingsscenario’s in infrastructuur, afhankelijkheden en workflows, bijvoorbeeld:
| Storingsscenario | Wat het test |
| Een server wordt onbereikbaar | Of verkeer wordt omgeleid en services bereikbaar blijven zonder handmatig ingrijpen van een technicus. |
| Een cloudregio presteert slechter | Hoe het systeem zich gedraagt bij een gedeeltelijke regionale storing of volledige uitval |
| Een databaseverbinding wordt trager | Of time-outs van verbindingen, nieuwe pogingen en fallbacklogica correct zijn geconfigureerd |
| Een netwerkafhankelijkheid valt uit | Hoe het systeem omgaat met uitval van externe services of integraties van derden |
| Een service krijgt onverwachte latency | Of downstreamservices netjes degraderen of uitgroeien tot een bredere storing |
| Een groep endpoints verliest connectiviteit | Of load balancing en failover-routing in werking treden zoals verwacht |
| Een back-up- of failover-workflow moet worden geactiveerd | Of herstelprocedures in de praktijk werken zoals de documentatie beschrijft |
Het doel is vaststellen of systemen willekeurige storingen automatisch kunnen doorstaan en blootleggen hoe systemen op storingen reageren voordat die tot grootschalige uitval in productiesystemen leiden.
Het verschil tussen chaos engineering en chaos testing
Chaos testing is de praktijk waarbij u storingen in een systeem introduceert om te observeren hoe het reageert. Deze activiteit brengt onverwacht gedrag aan het licht en legt kwetsbare afhankelijkheden bloot, maar is in de kern observerend.
Chaos engineering is breder en strikter, omdat het een gestructureerde discipline omvat die gestuurd wordt door vastgelegde wetenschappelijke principes. Daarbij hoort het formuleren van een hypothese, het ontwerpen van een gecontroleerd experiment en het afleiden van bruikbare lessen nadat het experiment is afgerond.
Kort gezegd: chaos testing is de handeling waarbij u een storing in een systeem introduceert, terwijl chaos engineering de gestructureerde discipline is die uw testbevindingen omzet in bruikbare inzichten.
De belangrijkste principes van chaos engineering
De volgende principes maken van chaos testing een doordacht experiment en vervangen puur observerende workflows door een gestructureerde methodiek die herhaalbaar en meetbaar is.
Bepaal een stabiele toestand
Een stabiele toestand is de meetbare uitgangswaarde waartegen u uw experiment afzet. Voordat u storingen in een systeem introduceert, is het belangrijk om eerst een systeem- of prestatiebaseline voor endpoints op te stellen die de normale toestand vastlegt. Zonder baseline is het lastig te bepalen of een experiment een afwijking veroorzaakte of dat het systeem standhield.
Formuleer een hypothese
In plaats van alleen te noteren wat er gebeurt, legt u in uw hypothese vast welke resultaten u van het experiment verwacht. Door een hypothese op te stellen, documenteert u uw aannames voordat het experiment draait, zodat de resultaten ergens tegen afgezet kunnen worden.
Komt het resultaat overeen met de hypothese, dan geeft dat vertrouwen in de weerbaarheid van het systeem dat u test. Wijkt het resultaat af van uw hypothese, dan is er sprake van een zwakke plek.
Begin klein
In het begin houdt u chaos engineering beperkt in omvang en richt u zich op één service of component in niet-productieomgevingen. Elk klein experiment levert kennis op over de reactie van het systeem, het gedrag van monitoring en de grenzen van de blast radius.
Geleidelijk kunt u de reikwijdte van uw experiment uitbreiden naarmate u operationele ervaring opdoet. Daarnaast moet chaos engineering mogelijke gebeurtenissen uit de praktijk weerspiegelen en uiteindelijk ook in productiesystemen worden ingezet om de werkelijke weerbaarheid van uw omgeving goed te toetsen.
Beperk de blast radius
Door vóór een experiment een blast radius te bepalen en te handhaven, houdt u uw experimenten gecontroleerd in plaats van chaotisch. Dat betekent dat u een specifieke node, service-instantie of verkeersstroom als doelwit kiest in plaats van de hele omgeving.
Monitor continu
Monitoringfunctionaliteit, inclusief logging en alarmering, moet actief en gecontroleerd zijn voordat u met een experiment begint. Chaos-engineeringtests genereren signalen die in realtime moeten worden vastgelegd.
Continue monitoring laat u ook weten wanneer het experiment de grens van de blast radius nadert, wanneer de stabiele toestand snel verslechtert of wanneer een rollback nodig is.
Bereid rollbackstappen voor
Voordat u storingen introduceert, moet u weten hoe u het experiment stopzet, welke stappen nodig zijn om het normale gedrag te herstellen en wie verantwoordelijk is voor de uitvoering. Het advies is om niet aan een experiment te beginnen als u geen vooraf bepaalde rollbackprocedures hebt.
Leren en verbeteren met chaos engineering
Na elk experiment moeten de bevindingen grondig worden beoordeeld, waarbij u zwakke plekken prioriteert door verbeteracties toe te wijzen en op te volgen waar dat van toepassing is. Bovendien kunt u deze bevindingen gebruiken om runbooks te verbeteren, alarmdrempels bij te stellen, escalatiepaden bij te werken en bestaande failover-ontwerpen te versterken, om er een paar te noemen.
Automatiseer experimenten
Automatiseer uw chaosexperimenten door ze op vaste intervallen in te plannen of ze te laten starten na grote deployments. Zo houdt de validatie van weerbaarheid gelijke tred met de veranderingen in uw infrastructuur.
Het is echter belangrijk om eerst volledig te begrijpen hoe uw chaos-engineeringexperiment zich gedraagt en hoe de rollback werkt voordat u het automatiseert. Automatiseert u een experiment dat u niet goed doorgrondt, dan loopt u het risico op grote schaal ongevalideerde en onomkeerbare storingsscenario’s te introduceren.
Het belang van chaos testing en chaos engineering
Wachten tot productiesystemen zelf storingen aan het licht brengen is een dure manier om zwakke plekken in de weerbaarheid te verkleinen. Chaos engineering biedt een gedisciplineerde methode om bewust een storing te introduceren onder gecontroleerde omstandigheden, zodat u die zwakke plekken proactief blootlegt.
Waarom chaos engineering ertoe doet
Veel IT-teams reageren pas op storingen nadat ze zijn opgetreden: ze doen onderzoek, analyseren mogelijke onderliggende oorzaken en passen de juiste oplossing toe. In plaats van te wachten tot productiesystemen uitvallen kunt u met chaos testing en chaos engineering bewust zwakke plekken blootleggen onder gecontroleerde omstandigheden.
Daarmee verschuift de houding van uw omgeving van reactief herstel naar proactieve weerbaarheid. Consistent uitgevoerd helpt chaos engineering u bij het volgende:
- Single points of failure vinden voordat ze escaleren
- Failover en redundantie valideren om de betrouwbaarheid van back-upsystemen te verifiëren
- Monitoring- en alarmeringsprocedures testen om te bevestigen dat waarschuwingen consequent zichtbaar worden
- Bevestigen dat escalatiepaden werken, zodat incidenten tijdig worden afgehandeld
- Hiaten in runbooks en documentatie proactief signaleren
- Beter voldoen aan RTO-doelstellingen en uw mean time to repair (MTTR) verkorten
- Verborgen afhankelijkheden blootleggen die ongemerkt risico’s introduceren
- IT-teams operationeel vertrouwen geven doordat ze zich op uitval kunnen voorbereiden
Naast winst op infrastructuurvlak helpt chaos engineering ook om te verifiëren of uw bestaande supportprocessen, communicatieworkflows richting klanten en herstelverantwoordelijkheden uitvoerbaar zijn tijdens een verstoring.
Wanneer chaos engineering het meest nuttig is
Chaos engineering is het waardevolst in omgevingen die weerbaar moeten blijven ondanks storingen, zeker wanneer uitval veel geld kost.
Chaos testing en chaos engineering zijn daarmee vooral nuttig voor:
- Cloud-based services, waar regionale prestatieproblemen of storingen aan de providerkant een kettingreactie kunnen veroorzaken
- Gedistribueerde applicaties waar het uitvallen van componenten zich ongemerkt kan verspreiden
- Infrastructuur met hoge beschikbaarheid waar beloofde redundantie bewezen moet worden
- Omgevingen met meerdere locaties waar failover tussen locaties naadloos moet werken
- Netwerkafhankelijke services waar externe afhankelijkheden risico introduceren
- Kritieke interne platforms waar uitvaltijd de bedrijfsvoering raakt
- Systemen met vastgelegde RTO- en RPO-afspraken die gevalideerd moeten worden
Chaos engineering levert ook bewijs voor claims over weerbaarheid. Hoe langer een op aannames gebaseerde claim ongevalideerd blijft, hoe groter de kans dat een zwakke plek bij het aan het licht komen een kettingreactie in de omgeving veroorzaakt.
Wanneer u chaos testing en chaos engineering beter kunt vermijden
Chaos engineering kunt u beter vermijden of uitstellen wanneer een van de volgende situaties speelt:
- Onvolledige of vertraagde monitoringresultaten
- Onduidelijke rollbackprocedures
- Onduidelijk eigenaarschap waardoor niemand aanspreekbaar is
- Instabiele systemen die niet voldoen aan vooraf bepaalde stabiele uitgangswaarden
- Ongeteste back-up- of herstelworkflows
- Het ontbreken van goedkeuring door de juiste stakeholders
- Een slecht afgebakende blast radius
- Compliance- of veiligheidseisen die chaos testing en chaos engineering verbieden
Doen deze situaties zich voor in een systeem of omgeving, dan is het verstandig te stoppen en ze eerst aan te pakken. Chaos engineering levert de meeste waarde op wanneer de gedisciplineerde principes die het mogelijk maken aanwezig zijn.
Voer chaos-engineeringtests uit voor proactieve weerbaarheid
Het doel van chaos testing en chaos engineering is niet alleen om systemen bewust te laten falen, maar om zwakke plekken in de weerbaarheid bloot te leggen voordat ze de productieomgeving bereiken. Gecontroleerde storingen die aansluiten op gedisciplineerde principes en ondersteund worden door continue monitoring maken van zwakke plekken een kans om te verbeteren.
Gerelateerde onderwerpen:
