Ik wil je uitdagen om dit jaar nog te proberen je applicatie stuk te maken. Maar voordat je je applicatie nu lokaal op je laptop of in een test omgeving opstart zal ik het wat interessanter maken. Probeer dit jaar nog je applicatie stuk te maken… in productie…

Ja, ik bedoel echt in productie en niet in een productie achtige omgeving. Het opzettelijk slopen van je applicatie wordt chaos engineering genoemd. Ok misschien niet letterlijk slopen, maar gecontroleerde chaos introduceren waarvan je verwacht dat het geen impact heeft op de productie omgeving.

Ik heb een aantal keer een workshop gegeven over Chaos engineering en tijdens het maken van deze workshop leerde ik zelf ook erg veel. Je weet vanuit de theorie wel dat monitoring handig is, maar je leert de toegevoegde waarde pas echt kennen wanneer je een probleem hebt en je geen monitoring hebt ingericht. Je merkt dan pas dat er iets kapot is wanneer een gebruiker dit bij je meldt. Dat is natuurlijk het laatste wat je wil, het liefst bel ik een klant op met de mededeling dat er iets mis was gegaan en dat het alweer verholpen is, waarop de klant kan antwoorden dat hij er niets van gemerkt heeft.

Ook heb je vast wel nagedacht over het horizontaal opschalen van je applicatie en dat dat allemaal geregeld wordt voor je door Azure. Maar heb je het ooit wel eens getest met een echte load van productie? Grote kans dat het opschalen een stuk langer duurt dan je in eerste instantie zou denken.

Chaos engineering dwingt je om hier goed over na te denken. De juiste monitoring in plaats te brengen en er zeker van te zijn hoe lang dat horizontaal opschalen nou echt duurt. Dat komt doordat je bij Chaos engineering je productie applicatie aan het testen bent. Je wil niet dat deze applicatie down gaat, dus moet je van tevoren met redelijke zekerheid weten te stellen dat deze onder bepaalde omstandigheden blijft draaien.

Chaos engineering?

Chaos engineering is nog een relatief onbekende term binnen de ICT. Waar iedereen wel een beeld heeft van DevOps (helaas heeft niet iedereen hetzelfde beeld hierbij maar dat terzijde), hebben nog maar weinig mensen een beeld bij chaos engineering. Zoals ik eerder al zei, bij Chaos engineering test je je applicatie in productie.

Dat testen gaat als volgt: je stelt een hypothese op. iets in de richting van, ik verwacht dat mijn applicatie overschakelt op de backup database als mijn primaire database uitvalt. Daarnaast verwacht ik dat er ergens een alarm afgaat omdat er een onderdeel van mijn applicatie offline gaat en dat het verantwoordelijke team dit binnen 20 minuten oppakt en binnen 90 minuten opgelost heeft. Wanneer je hypothese klaar is kan je je database uit offline halen en kijk je of je hypothese correct is.

Wanneer dit niet het geval is, zal je moeten kijken waar het dan precies mis ging, waarom het mis ging en wat je kan doen om het de volgende keer te voorkomen. Zoiets heet een Post mortem. Bij een post mortem ga je stap voor stap na wat er gebeurd is. Dit doe je enkel met feiten dus zonder meningen. Je probeert een post mortem zo precies mogelijk te maken, probeer van minuut tot minuut na te gaan wat er gebeurd is. Daarna kan je er conclusies aan verbinden. Je stelt een root cause op en de correctieve en preventieve maatregelen.

Wat heel belangrijk is bij een post mortem is het gevoel van veiligheid. Het moet niet een document worden waarin gewezen wordt naar persoon a want die deed alles fout. Maar enkel er is een verkeerd commando uitgevoerd of de volgorde van de acties was incorrect.

Dit is naar mijn mening een beetje de basis van Chaos engineering en door dit te doen zorg je ervoor dat je beter bestand bent tegen ongecontroleerde chaos.

Ongecontroleerde en gecontroleerde Chaos

Vroeg of laat ga je te maken krijgen met chaos, of je het nou zelf initieert of niet. Wanneer je met chaos te maken krijgt die je zelf geïnitieerd hebt, noemen we dat gecontroleerde chaos. In alle andere gevallen noemen we dat ongecontroleerde chaos. Je kan dus kiezen, wil je gecontroleerde chaos, waarbij je een hypothese hebt van wat er gaat gebeuren en je deze hypothese kan verifiëren of wil je ongecontroleerde chaos waarbij je je achteraf bedenkt: ik had natuurlijk kunnen weten dat dat zou gebeuren…

Kan dit niet op mijn acceptatie omgeving

Het is natuurlijk mogelijk om deze tests uit te voeren op acceptatie. Het nadeel hieraan is echter dat je nooit je acceptatie exact gelijk hebt aan je productie omgeving. Als het niet die ene missende patch op een van de vele servers of die ene applicatie die net een versie hoger zit dan op acceptatie is dan is het wel dat je je productie data, hoop ik, niet op acceptatie hebt.  Doordat je acceptatie omgeving niet gelijk is aan je productie omgeving, weet je dus ook niet zeker of je productie omgeving exact hetzelfde zal reageren als je verwacht.

De enige manier om dus zeker te weten dat je applicatie zal reageren zoals je verwacht is door het te testen in productie.

Ik kan mijn applicatie toch niet zomaar down brengen

Natuurlijk is het niet de bedoeling om je applicatie in productie offline te halen. Wanneer je van tevoren weet dat je applicatie iets niet aankan, dan zal je eerst moeten zorgen dat je applicatie reageert zoals jij wilt. Het heeft namelijk geen zin om je klanten te belasten met een niet werkende applicatie omdat jij wilde verifiëren of je applicatie inderdaad stopt wanneer je een storing introduceert. Wel is het interessant dat wanneer jij verwacht dat je applicatie blijft werken, om dat dan te gaan testen. Of om te bekijken hoe lang het duurt om automatisch op te schalen bij een hele hoge CPU load.

Voorbeeld

Dit klinkt waarschijnlijk allemaal nog heel erg vaag. Ik zal het met een voorbeeld uit proberen te leggen. Stel je voor, je hebt een hele hippe applicatie met een microservice architectuur. Je hebt een front end met service A en service B. Je hebt het cluster waar service A op draait zo ingesteld dat wanneer er over een periode van 10 minuten de CPU load boven de 70% blijft, er automatisch opgeschaald wordt. Mijn hypothese is, omdat ik enorm veel betaal aan mijn cloud provider, dat dit bijna direct gebeurd na die 10 minuten.

Daarom gebruik ik een tool om de CPU load op service A voor 20 minuten te verhogen naar 75%. Echter pas tegen het einde van de 20 minuten zie ik dat er opgeschaald is. Nu ik dit weet kan ik daar beter op inspelen en bijvoorbeeld besluiten om de treshold van 10 minuten naar 5 minuten verlagen.

Moet dit voor elke app

Je hoeft natuurlijk niet voor elke applicatie alles helemaal uit te denken, maar hoe belangrijker de applicatie is voor je business hoe eerder je applicatie in aanmerking komt voor chaos engineering. Wanneer je bedrijf zonder die applicatie enorm veel inkomsten misloopt moet je je gaan afvragen of het toch niet handig is om chaos engineering te proberen. Dit helpt je om je voor te bereiden op de onvermijdelijke ongecontroleerde chaos. Eigenlijk een beetjes hetzelfde als hoe je code kwaliteit zou toepassen, dit wordt ook belangrijker naarmate de applicatie een prominentere rol speelt in het applicatie landschap.

 

Share this