• Blog
  • Info Support
  • Career
  • Training
  • International Group
  • Info Support
  • Blog
  • Career
  • Training
  • International Group
  • Search
logo InfoSupport
  • Latest blogs
  • Popular blogs
  • Experts
      • All
      • Bloggers
      • Speakers
  • Meet us
  • About us
    • nl
    • en
    • .NET
    • 3D printing
    • Advanced Analytics
    • Agile
    • Akka
    • Alexa
    • Algorithms
    • Api's
    • Architectuur
    • Artificial Intelligence
    • ATDD
    • Augmented Reality
    • AWS
    • Azure
    • Big Data
    • Blockchain
    • Business Intelligence
    • Chatbots
    • Cloud
    • Code Combat
    • Cognitive Services
    • Communicatie
    • Containers
    • Continuous Delivery
    • CQRS
    • Cyber Security
    • Dapr
    • Data
    • Data & Analystics
    • Data Science
    • Data Warehousing
    • Databricks
    • DataOps
    • Developers life
    • DevOps
    • Digital Days
    • Digital Twin
    • Docker
    • eHealth
    • Enterprise Architecture
    • Event Sourcing
    • Hacking
    • Infrastructure & Hosting
    • Innovatie
    • Integration
    • Internet of Things
    • Java
    • Machine Learning
    • Microservices
    • Microsoft
    • Microsoft Bot Framework
    • Microsoft Data Platform
    • Mobile Development
    • Mutation Testing
    • Open source
    • Pepper
    • Power BI
    • Privacy & Ethiek
    • Python
    • Quality Assistance & Test
    • Quality Assurance & Test
    • Requirements Management
    • Scala
    • Scratch
    • Security
    • SharePoint
    • Software Architecture
    • Software development
    • Software Factory
    • SQL Server
    • SSL
    • Start-up
    • Startup thinking
    • Stryker
    • Test Quality
    • Testing
    • TLS
    • TypeScript
    • Various
    • Web Development
    • Web-scale IT
    • Xamarin
    • All
    • Bloggers
    • Speakers
Home » Engineer met chaos
  • Engineer met chaos

    • By Yael Keemink
    • Continuous Delivery 2 years ago
    • Continuous Delivery 0 comments
    • Continuous Delivery Continuous Delivery
    Engineer met chaos

    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

Yael Keemink

DevOps engineer.

View profile

Related IT training

Go to training website

Related Consultancy solutions

Go to infosupport.com

Related blogs

  • Adding a package to your private WinGet.RestSource feed…

    Adding a package to your private WinGet.RestSource feed… Léon Bouquiet - 1 year ago

  • Migrate Azure API Management developer portal customiza…

    Migrate Azure API Management developer portal customiza… Caspar Eldermans - 1 year ago

  • Provision an Azure VM in an Azure Pipelines Environment

    Provision an Azure VM in an Azure Pipelines Environment Ronald Bosma - 2 years ago

Data Discovery Channel

  • Explainable AI - Break open the blackbox

  • Toekomstvaste microservice data architecturen

  • Modern Data Platform

Nieuwsbrief

* verplichte velden

Contact

  • Head office NL
  • Kruisboog 42
  • 3905 TG Veenendaal
  • T +31 318 552020
  • Call
  • Mail
  • Directions
  • Head office BE
  • Generaal De Wittelaan 17
  • bus 30 2800 Mechelen
  • T +32 15 286370
  • Call
  • Mail
  • Directions

Follow us

  • Twitter
  • Facebook
  • Linkedin
  • Youtube

Newsletter

Sign in

Extra

  • Media Library
  • Disclaimer
  • Algemene voorwaarden
  • ISHBS Webmail
  • Extranet
Beheer cookie toestemming
Deze website maakt gebruik van Functionele en Analytische cookies voor website optimalisatie en statistieken.
Functioneel Always active
De technische opslag of toegang is strikt noodzakelijk voor het legitieme doel het gebruik mogelijk te maken van een specifieke dienst waarom de abonnee of gebruiker uitdrukkelijk heeft gevraagd, of met als enig doel de uitvoering van de transmissie van een communicatie over een elektronisch communicatienetwerk.
Voorkeuren
De technische opslag of toegang is noodzakelijk voor het legitieme doel voorkeuren op te slaan die niet door de abonnee of gebruiker zijn aangevraagd.
Statistieken
De technische opslag of toegang die uitsluitend voor statistische doeleinden wordt gebruikt. De technische opslag of toegang die uitsluitend wordt gebruikt voor anonieme statistische doeleinden. Zonder dagvaarding, vrijwillige naleving door uw Internet Service Provider, of aanvullende gegevens van een derde partij, kan informatie die alleen voor dit doel wordt opgeslagen of opgehaald gewoonlijk niet worden gebruikt om je te identificeren.
Marketing
De technische opslag of toegang is nodig om gebruikersprofielen op te stellen voor het verzenden van reclame, of om de gebruiker op een website of over verschillende websites te volgen voor soortgelijke marketingdoeleinden.
Manage options Manage services Manage vendors Read more about these purposes
Voorkeuren
{title} {title} {title}