Bij Chaos Engineering voeren ontwikkelaars experimenten uit op hun software, servers en netwerkinfrastructuur waaraan ze aan het bouwen zijn. Door de principes van Chaos Engineering toe te passen, kan je anticiperen op eventuele problemen die er in een systeem kunnen opduiken.
De grote impact waartoe onverwachte omstandigheden kunnen leiden, kan op deze manier ingeperkt en onder controle gehouden worden.
Veel mensen gaan er bijvoorbeeld vanuit dat hun bedrijfsnetwerk altijd beschikbaar is. Hun meest kritische systemen draaien mogelijk ook in de cloud. Op het moment dat de services van de cloud provider uitvallen, of de infrastructuur het laat afweten, kunnen de gevolgen veel groter zijn dan verwacht.
Chaos engineering helpt je om deze risico’s zoveel mogelijk te beperken en minimaliseren.
Eén van de meest handige tools voor chaos engineering is Gremlin (failure as a service), al zal Chaos Monkey (random instance failures) van Netflix bij de meesten een belletje doen rinkelen.
Tools zoals Chaos Gorilla (herkennen jullie het thema al?) richten zich op het platleggen van volledige datacenters. De andere Chaos Engineering tools verstoren slechts één specifieke netwerk- of software-component.
Voor zowat elk denkbaar platform of systeem is er eigenlijk wel een compatibele tool te vinden om aan Chaos Engineering te doen.
Naast het introduceren van fouten en storingen via één van de tools, is Chaos Engineering ook een soort van cultuur of bedrijfsfilosofie.
Het uitgangspunt is dat iedereen naar het volledige systeem moet leren kijken, in plaats van enkel naar de losse componenten. De componenten kunnen elk op zichzelf prima werken, maar catastrofaal falen in combinatie met fouten in een andere component.
De theoretische kennis over het systeem kan worden afgetoetst tijdens zogenaamde Chaos Days (zeker niet te verwarren met de Chaos Days tijdens de jaren ’80 en ’90 waarbij punkers bij elkaar kwamen :-) ). Een Chaos Day is een speciale teamdag die gericht is op het gebruik van Chaos Engineering om zwakke punten in het systeem aan het licht te brengen.
Tijdens deze Chaos Days maken we gebruik van een Game Plan, oftewel draaiboek, dat ons hierin begeleidt. Het doel van een Chaos Day is om systemen robuuster te maken door dingen met opzet te breken.
In een Game Plan omschrijven we volgende zaken:
Ook wordt er een persoon aangeduid die notities neemt over wat er gebeurt, wat de resultaten zijn, en welk experiment er op dat moment lopende is. Dit is belangrijk om de gevonden soft spots in je troubleshooting proces, het systeem en monitoring/alerting achteraf aan te kunnen pakken.
Verder is er één bevelhebber die beslist welk experiment wanneer wordt gestart. Hij/zij is gemachtigd om een experiment vroegtijdig te laten stoppen. Zelf voert de bevelhebber echter geen experimenten of andere concrete acties uit. Een bevelhebber neemt vooral de leiding over de operatie.
Daarnaast zijn er één of meerdere developers, DevOps engineers en/of infrastructure engineers aanwezig om de experimenten uit te voeren.
Om de experimenten live te visualiseren, bijvoorbeeld met dashboards die de load of het aantal fouten in het geteste systeem tonen, kan er ook nog een persoon worden aangeduid.
Het ultieme doel is inderdaad om de experimenten op productiesystemen uit te voeren. Als het de eerste keer is dat een team zich aan een Chaos Day waagt, of je nog niet veel vertrouwen hebt in het systeem, raden we aan om eerst een dry-run uit te voeren in een test-omgeving.
De test-omgeving is misschien iets minder spannend, maar deze experimenten kunnen je vertrouwen doen groeien. Daarnaast bieden ze nuttige inzichten om je productiesysteem proactief te wapenen tegen eventuele problemen in de toekomst.
Altijd al willen weten waar we ons allemaal mee bezig houden doorheen het jaar? Schrijf je dan nu in voor onze nieuwsbrief en krijg al ons nieuws, vers van de pers.