Chaos-engineering is een benadering van het testen van softwarefouttolerantie die opzettelijk fouten veroorzaakt in live-implementaties. Het bevat een element van willekeur om de onvoorspelbaarheid van de meeste echte storingen na te bootsen.
Het idee om chaos toe te voegen aan een systeem wordt over het algemeen toegeschreven aan Netflix. In 2011 publiceerde het bedrijf Chaos Monkey, een tool die het bouwde om delen van zijn productie-infrastructuur uit te schakelen. Door willekeurige storingen te veroorzaken in gecontroleerde omgevingen, ontdekte Netflix dat het verborgen problemen kon ontdekken die onopgemerkt bleven tijdens reguliere tests.
Chaos-engineering zorgt voor een immuunresponseffect. Het is vergelijkbaar met hoe we gezonde mensen vaccineren. Je introduceert doelbewust een dreiging, die mogelijk korte maar waarneembare problemen veroorzaakt, om sterkere weerstand op lange termijn te ontwikkelen.
Resilience bouwen
It’ Het is veilig om aan te nemen dat elk voldoende groot systeem bugs bevat waarvan u niets weet. Ondanks al je geautomatiseerde tests en dagelijks gebruik in de echte wereld, kun je niet alles opvangen. Sommige problemen komen alleen aan het licht in zeer specifieke scenario's, zoals verlies van connectiviteit met een service van derden.
Chaos engineering accepteert dat onvoorziene operationele problemen altijd een feit zullen zijn, zelfs in zogenaamd waterdichte productieomgevingen. Terwijl veel organisaties uiteindelijk een “afwachten” aanpak, meedogenloos spelen als echte rapporten binnenkomen, chaos-engineering werkt volgens het principe dat een korte storing die je aanroept altijd beter is dan een die de klant als eerste ziet.
Advertentie
Met opzet dingen breken geeft je een manier om de algehele veerkracht van je systeem te bepalen. Wat gebeurt er als de database uitvalt? Wat dacht u van een storing bij uw externe e-mailverzendservice? De grootste kracht van chaos-engineering is het vermogen om gebeurtenissen te reproduceren die alleen door eenheidstests en gebruik in de echte wereld niet worden gedekt.
Chaos-testtools worden vaak uitgevoerd tegen echte implementaties om discrepanties tussen ontwikkel- en productieomgevingen te elimineren. U hoeft echter niet zoveel risico te nemen: zolang u er zeker van bent dat u uw infrastructuur nauwkeurig kunt repliceren, kunt u de techniek gebruiken tegen een gesandboxed staging-omgeving.
Chaos toevoegen aan uw systemen
U hebt meerdere opties als u wat chaos aan uw infrastructuur wilt toevoegen. Geautomatiseerde tools die voor dit doel zijn gebouwd, bieden een startpunt, maar kunnen lastig zijn om in uw eigen infrastructuur op te nemen. Normaal gesproken moet u integreren met VM- of containerbeheerplatforms zodat de tool kan communiceren met uw eigen instanties.
In het geval van Chaos Monkey moet je Spinnaker gebruiken, het continue leveringsplatform van Netflix. Hoewel het brede compatibiliteit heeft met populaire openbare cloudproviders, is het ook een andere afhankelijkheid die u aan uw stapel toevoegt.
Als je Kubernetes gebruikt, neemt kube-monkey de originele Netflix-principes en verpakt ze voor gebruik in je cluster. Het werkt op basis van opt-in, dus Kubernetes-bronnen met het label kube-monkey/enabled komen in aanmerking voor willekeurige beëindiging.
Pumba biedt vergelijkbare mogelijkheden voor reguliere Docker-containers. Het kan containercrashes veroorzaken, resourcetoelagen zoals CPU en geheugen belasten en netwerkstoringen veroorzaken.
Advertentie
Een tool die specifiek gericht is op netwerkfouten is Toxiproxy van Shopify. Dit biedt een TCP-proxy die een breed scala aan netwerkomstandigheden simuleert. U kunt het verkeer van uw toepassing filteren via Toxiproxy om te zien hoe het systeem presteert met ernstige latentie of verminderde bandbreedte.
Voor geavanceerde controle is VMWare's Mangle een “chaos-engineering” orkestrator” die zich richt op verschillende implementatiemechanismen. Het werkt met Kubernetes, Docker, VMware vCenter en generieke SSH-verbindingen. Met Mangle kunt u aangepaste fouten definiëren voor applicatie- en infrastructuurcomponenten. Applicatiefouten moeten betrekking hebben op één enkele service. Infrastructuurfouten zijn gericht op gedeelde componenten die meerdere services kunnen uitschakelen.
Hoewel chaos-engineering meestal wordt geassocieerd met backend-ontwikkeling en DevOps, is er ook een groeiende interesse onder frontend-engineers. React Chaos is een bibliotheek die willekeurige fouten van React-componenten genereert, waardoor je schilferige UI-secties kunt identificeren die je hele app kunnen laten crashen.
Je eigen ontwerpen Chaos-experimenten
Als je een open-source chaostool niet met succes kunt gebruiken, ontwerp dan je eigen experimenten. Maak een lijst van de aannames binnen de omgeving van uw applicatie. Identificeer de verbanden tussen services en denk na over wat er zou gebeuren als er een zou afhaken.
Je moet dan je hypothese testen. Breek het systeem en observeer de gevolgen. Bepaal vervolgens of het effect acceptabel was. Is de app gecrasht en heeft de gebruiker een stacktracering weergegeven? Of toonde het een storingsstatuspagina en e-mailde het de stacktracering naar uw oproepkrachten?
Het is belangrijk om elke test klein en gefocust te houden. Dit beperkt de impact in het geval van een productiestoring en helpt u er zeker van te zijn dat het probleem voortkomt uit de geteste veronderstelling, niet uit een ander deel van het systeem.
Advertentie
Zorg altijd voor een duidelijke herstelprocedure voordat u handmatig een chaos-experiment uitvoert. Een uitgelokte storing verheffen tot een live, ongeplande storing is het laatste wat je wilt. Als u een service beëindigt, houd dan rekening met de tijd die u nodig heeft om deze opnieuw te starten. Er kunnen domino-effecten op uw toepassing zijn tijdens langere uitval: als u een e-maildistributieservice verlaat, kan er een achterstand zijn om door te werken wanneer deze weer online komt. Deze aspecten moeten in uw actieplan worden opgenomen voordat u aan het werk gaat.
Nadat uw experiment is voltooid, moet u mogelijk uw systeem bijwerken voordat u de test opnieuw uitvoert. Door uw oplossing te testen, wordt de situatie daadwerkelijk verbeterd en kunt u erop vertrouwen dat uw systeem nu bestand is tegen dat specifieke scenario.
Hier is een samenvatting van het chaos-experimentproces:
- Ontwikkel een hypothese: “Het systeem is bestand tegen verhoogde netwerklatentie.”
- Ontwerp een gericht experiment: “We zullen de latentie kunstmatig verhogen tot 500 ms bij 70% van de verzoeken.” Zorg voor een duidelijke terugdraai- en herstelstrategie.
- Voer het experiment uit:Bekijk de impact op uw toepassing. Breng nadelige wijzigingen in productieomgevingen zo snel mogelijk terug.
- Analyseer de resultaten: Als u besluit dat uw systeem niet veerkrachtig genoeg was, implementeert u verbeteringen en herhaalt u het proces.
De niet-technische kant van Chaos Engineering
Chaos-engineering wordt normaal gesproken gezien als een technische taak voor ontwikkelings- en operatieteams. “engineering” zit in de naam. Naast de moeren en bouten van netwerken en diensten, is het belangrijk om ook naar de menselijke kant te kijken. Het is gemakkelijk om te denken dat uw systeem alleen afhankelijk is van een database, een paar app-servers en een stabiel netwerk. Dat is meestal niet het geval.
Bedenk hoe uw systeem zou reageren als teamleden niet beschikbaar waren. Is kennis gemakkelijk toegankelijk als een beheerder onverwacht een stap terug moet doen? Vooral in kleinere organisaties is het gebruikelijk dat een "team" om een alleenstaande te zijn. Wat gebeurt er als je netwerker ziek is tijdens een live-storing?
Op dezelfde manier waarop je de technische aspecten test door services te beëindigen, kun je ook anticiperen op menselijke scenario's. Probeer doelbewust belangrijke personen uit te sluiten terwijl u een storing oefent. Was de rest van het team in staat om de service in een acceptabele staat te herstellen? Als dat niet het geval was, zou u er baat bij kunnen hebben om meer van het systeem en zijn afhankelijkheden te documenteren.
Samenvatting
De term “chaos engineering” verwijst naar de praktijk van het doelbewust breken van dingen in productie om eerder verborgen problemen te ontdekken. Hoewel de aanpak in het begin ontmoedigend kan lijken, kunnen speciale tools zoals Chaos Monkey je helpen om met minimaal risico aan de slag te gaan.
Advertentie
Het toevoegen van chaos is een nuttige techniek, omdat het zowel voorbijgaande als systemische problemen aan het licht brengt. Het kan zijn dat piekend geheugengebruik gevolgen heeft voor uw infrastructuur, maar dat een verhoogde netwerklatentie een sporadisch effect heeft op specifieke delen van uw stack.
Effectief gebruik van chaos-engineering kan u helpen bugs sneller te vinden , voordat uw klanten ze opmerken. Het helpt u om veerkracht in uw systeem op te bouwen door anticipatie op problemen aan te moedigen. De meeste teams pakken problemen nog steeds reactief aan, wat leidt tot een langere cyclustijd die de efficiëntie belemmert.
Chaos-engineering kan het beste worden behandeld als een mentaliteit in plaats van als een specifieke procedure of softwareproduct. Als je erkent dat systemen neigen naar chaos, zul je vanzelf steun gaan bakken voor meer “wat-als” scenario's in uw code.
Het is altijd de moeite waard om na te denken over het “onmogelijke” gebeurtenissen, zoals een storing in het datacenter of ernstige netwerkcongestie. In werkelijkheid zijn ze niet onmogelijk, alleen uiterst zeldzaam. Als ze toeslaan, zijn het waarschijnlijk de meest destructieve gebeurtenissen die je systeem tegenkomt, tenzij je infrastructuur erop voorbereid is om ze af te handelen met terugvalroutines.