Wat is chaos-engineering & waarom is het belangrijk?
Waarom is chaosengineering belangrijk? Laten we eens kijken waarom kwaliteitsborging (QA) überhaupt bestaat.
Heel eenvoudig: QA bestaat omdat de echte wereld ons niet lijkt toe te staan om, hoe hard we ook proberen, perfecte software te maken die altijd doet waarvoor deze is ontworpen en wat ervan wordt verwacht.
Fouten sluipen erin. Machines interpreteren onze code anders dan wij bedoelden. Er gebeuren nu eenmaal dingen. kwaliteitsengineering bestaat om die onbedoelde problemen te vinden voordat onze klanten dat doen.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Wat is chaosengineering?
Chaosengineering is een gedisciplineerde aanpak om potentiële storingen te identificeren voordat ze uitval veroorzaken. Met chaosengineering ontwerp je experimenten waarbij storingen worden geïnjecteerd en vergelijk je wat je denkt dat er zal gebeuren met wat er daadwerkelijk in je systemen gebeurt. Je “maakt letterlijk met opzet dingen stuk” om te leren hoe je veerkrachtigere systemen bouwt.
Waarom is chaosengineering belangrijk?
Omdat systemen veranderen. Traditioneel voert QA een verscheidenheid aan tests en testtypen uit om deze problemen proactief op te sporen, lang voordat de code in productie terechtkomt. Deze tests worden uitgevoerd aan het einde van een build en voordat die code publiekelijk wordt geïmplementeerd, doorgaans in een acceptatie- of testomgeving in plaats van in productie.
Tot zover gaat het goed als we werken volgens een traditioneel model voor softwareontwikkeling en implementatie. Monolithische ontwerpen en implementaties op machines die eigendom zijn van het bedrijf bieden veel controle. Aan die controle is stabiliteit inherent. Hierdoor lijken deze acceptatie- en testomgevingen op de productieomgevingen en kunnen tests daarin succesvol worden uitgevoerd.
Gedistribueerde systemen zijn anders. De cloud is anders. We hebben geen controle over de infrastructuur. Deze verandert voortdurend. De infrastructuur verandert volgens ons ontwerp, waarbij afzonderlijke services en microservices automatisch extra rekenknooppunten opstarten of verwijderen wanneer dat nodig is. Failoversystemen passen zichzelf aan om ervoor te zorgen dat risico’s worden beheerd. De voortdurende veranderingen veroorzaken onverwacht, emergent gedrag. Dit gedrag kunnen we niet altijd voorspellen, maar we kunnen het wel reproduceren en veroorzaken met een testvorm die chaosengineering wordt genoemd.
Tests moeten zich aanpassen wanneer systemen veranderen
We kunnen niet alles wat onze productiecode en de omgeving zullen tegenkomen effectief testen door in een andere omgeving te testen. We kunnen veel dingen testen, waaronder zaken waar traditionele QA heel goed in is en mee door moet gaan, hoewel een deel daarvan nu misschien via automatisering tijdens de build-pijplijn kan worden uitgevoerd. Maar de manier waarop we QA hebben uitgevoerd, kan niet testen hoe ons gedistribueerde systeem reageert wanneer bijvoorbeeld de netwerkverbinding tussen een gegevensopslag en meerdere rekenknooppunten wordt overbelast en de latentie toeneemt.
Onze geautomatiseerde en door mensen aangestuurde tests houden geen rekening met deze snel veranderende productieomgeving, waarin services vanwege de vraag worden gestart en gestopt. De enige manier om te testen of een gedistribueerd systeem betrouwbaar blijft bij emergent gedrag dat wordt veroorzaakt door veranderende productieomstandigheden, is dezelfde aanpak te gebruiken als bij alle testparadigma’s: het proberen en ontdekken.
Hoe chaosengineering werkt: testen en leren door storingen
We hebben allemaal doelstellingen voor beschikbaarheid. We willen allemaal onze prestaties verbeteren. Om dat te doen, moeten we elke beschikbare hulpbron gebruiken om zo veel mogelijk te leren over hoe onze systemen omgaan met storingen, of het nu gaat om een gebruiker die geen geschikte gegevens in een formulierveld invoert of om een systeemcomponent in de cloud die niet functioneert zoals verwacht.
“Wat gebeurt er wanneer?” is een vraag die we allemaal graag stellen. Vervolgens proberen we het uit en ontdekken we het.
Omdat onze systemen en systeemontwerpen zich op zo’n ongekende manier hebben ontwikkeld, moeten ook onze testmethoden zich ontwikkelen om beter te begrijpen hoe onze gedistribueerde systemen met storingen omgaan en hoe storingen van componenten en afhankelijkheden het hele systeem beïnvloeden. Holistisch testen van dit type is waarvoor chaosengineering bestaat, omdat hiermee ons volledige systeem kan worden getest zoals het in productie bestaat.
Een chaosengineeringprogramma begint kleinschalig, met tests van dingen die we al weten of waarvan we denken dat we ze kennen:
- Vangt ons monitoringsysteem actief een netwerkvertraging boven een specifieke drempelwaarde op?
- Leidt dat tot een melding aan de dienstdoende technicus of misschien tot geautomatiseerde risicobeperking?
- Is onze configuratie in de loop der tijd afgeweken, of starten we nog steeds rekenknooppunten op volgens de specificaties?
Hoe houdt elke service-instantie zich staande bij lichte tests? Gemiddelde? Zware? Ze zouden allemaal hetzelfde moeten zijn en onze taakverdeling zou de belasting op de juiste manier over hen moeten verdelen. Wat gebeurt er als één instantie een aanzienlijk zwaardere belasting begint te ontvangen dan de andere, omdat onze service voor taakverdeling problemen ondervindt?
Systematisch testen van chaotische systemen levert essentiële voordelen op
We testen volgens de wetenschappelijke methode: we beginnen klein en gaan bewust te werk. We ontwerpen vroege experimenten om het impactgebied, de verzameling diensten en componenten waarvan we denken dat ze mogelijk worden beïnvloed, te beperken en om de omvang van de experimentparameters te minimaliseren.
Zodra we hier succesvol zijn, kunnen we besluiten stap voor stap verder te bouwen, waarbij we ons vertrouwen in ons systeem vergroten of onze geprioriteerde achterstand met verbeteringen die we zullen doorvoeren uitbreiden. Wanneer we die verbeteringen aanbrengen en opnieuw testen met hetzelfde chaosexperiment en dezelfde parameters, zal het systeem slagen en weten we dat het betrouwbaarder is dan voorheen.
Dit is de enige manier waarop we kunnen leren hoe onze systemen in de praktijk omgaan met storingen in productie, waar onze klanten uiteindelijk de resultaten zullen ervaren. Als we de kleine problemen nu kunnen vinden, voordat ze de kans krijgen om zich tot grote problemen aaneen te rijgen, kunnen we ervoor zorgen dat er steeds minder systemische storingen optreden.
Dit maakt chaosengineering tot een fantastisch hulpmiddel voor betrouwbaarheid. Het is een discipline die ons helpt om in de cloud en op schaal te doen wat we vroeger in kleinere, gecontroleerde omgevingen met traditionele QA konden bereiken.
Dit betekent uiteindelijk minder grootschalige productiestoringen en uitval. Wanneer chaosengineering consequent wordt geïmplementeerd en gebruikt, zullen storingen van diensten en componenten die naar verwachting zullen optreden in de chaos van de cloud geen gevolgen hebben voor onze klanten. Ze zullen zelfs nooit weten dat er een storing was, en dat is het echte doel.
Wat nu?
Ik heb chaosengineering uitgebreider besproken in een aflevering van de podcast van The QA Lead met Jonathon Wright.
Noot van de redactie:
Je kunt op de hoogte blijven van andere podcasts en artikelen van The QA Lead door je in te schrijven voor de nieuwsbrief.
Je kunt ook lid worden om toegang te krijgen tot het communityforum van The QA Lead, waar je best practices kunt delen met andere QA's en kwaliteitsingenieurs. Ik hoop je daar te zien!
Gerelateerd artikel: DE 10 BESTE SOFTWARETOOLS VOOR KWALITEITSENGINEERING: EEN COMPLETE GIDS
