Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Azure Chaos Studio eenvoudig uitgelegd: chaos engineering, foutinjectie en veerkrachtige Azure-apps (AI-nasynchronisatie)

Transcript

Azure Chaos Studio eenvoudig uitgelegd: chaos engineering, foutinjectie en veerkrachtige Azure-apps (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

• 0:00
  Speaker 2: Klaar voor 10 dagen Microsoft 365, Copilot, AI, Azure en
• 0:05
  Speaker 2: de mensen die de toekomst van werk vormgeven? Deze januari
• 0:09
  Speaker 2: is M365 komt terug en we pakken groter uit. Doe
• 0:12
  Speaker 2: mee voor live sessies, praktijkdemo's en praktische kennis van MVP's
• 0:16
  Speaker 2: en experts van over de hele wereld. Geen algemene dia's,
• 0:20
  Speaker 2: geen eindeloze modewoorden. We pakken de echte uitdagingen aan Copilot Studio,
• 0:25
  Speaker 2: AI Agents, Fabric, Beveiliging, Governance en Automatisering. Of je nu IT-professional,
• 0:31
  Speaker 2: ontwikkelaar of business leader bent, er zijn sessies voor jou ontworpen.
• 0:35
  Speaker 2: Met 10 volledige dagen kun je meerdere technologieën verkennen en
• 0:38
  Speaker 2: verbinding maken met een wereldwijde community. Kijk live en neem
• 0:41
  Speaker 2: praktische inzichten mee terug naar jouw organisatie. Januari 2027, 10 dagen,
• 0:47
  Speaker 2: 1 Microsoft Community. De registratie is nu geopend. Ga naar m365com.net
• 0:54
  Speaker 2: en verzeker je vandaag nog van een plek. Dat is m365com.net.
• 1:00
  Speaker 2: Meld je nu aan op m365con.net en we zien je
• 1:03
  Speaker 2: live in januari. Welkom bij een nieuwe aflevering van Microsoft
• 1:06
  Speaker 2: Knowledge Nuggets. Ik ben je gastheer Milko Peters. Wat als
• 1:09
  Speaker 2: je je eigen cloud apps opzettelijk en gecontroleerd zou kunnen
• 1:11
  Speaker 2: verbreken om ze sterker te maken? Klinkt tegenstrijdig, maar het
• 1:14
  Speaker 2: is dezelfde logica die brandweerlieden gebruiken bij gecontroleerd afbranden. Ze
• 1:17
  Speaker 2: steken bewust kleine brandjes aan om droogstruikgewas te verwijderen, zodat
• 1:20
  Speaker 2: er bij een echte bosbrand niets meer is om te branden.
• 1:22
  Speaker 2: Dat is wat Azure Chaos Studio voor jouw cloud apps doet.
• 1:25
  Speaker 2: Aan het eind van deze aflevering begrijp je wat de
• 1:27
  Speaker 2: service is, waarom je het zou willen gebruiken en hoe
• 1:29
  Speaker 2: het je helpt systemen te bouwen die niet bezwijken als
• 1:31
  Speaker 2: er iets misgaat. Dus pak je koffie en laten we
• 1:34
  Speaker 2: beginnen met het probleem. Het probleem, waarom traditioneel testen niet
• 1:38
  Speaker 2: genoeg is. Dit is het punt met traditioneel testen. Het
• 1:40
  Speaker 2: controleert of je software werkt zoals ontworpen onder normale omstandigheden.
• 1:44
  Speaker 2: Je schrijft een test, voert deze uit en als de
• 1:46
  Speaker 2: uitvoer overeenkomt, ben je geslaagd. Geweldig voor het vinden van bugs,
• 1:49
  Speaker 2: maar het mist hoe je systeem zich gedraagt als iets
• 1:51
  Speaker 2: onverwachts faalt. Zoals een netwerk time-out, een virtuele machine die
• 1:54
  Speaker 2: crash of een volledige beschikbaarheidszone die uitvalt. Moderne cloud apps
• 1:58
  Speaker 2: zijn niet simpel meer. Het zijn gedistribueerde systemen die communiceren
• 2:01
  Speaker 2: met databases, caches, identiteitsdiensten, externe APIs en andere microservices en
• 2:05
  Speaker 2: al die onderdelen hebben verborgen afhankelijkheden. Een kleine fout kan
• 2:07
  Speaker 2: door het hele systeem kaskaderen. Een database wordt traag. De
• 2:10
  Speaker 2: app krijgt een time-out, de load balancer markeert deze als ongezond,
• 2:13
  Speaker 2: verkeer wordt omgeleid, andere instanties raken overbelast en plotseling ligt
• 2:16
  Speaker 2: je hele applicatie plat. Traditioneel testen vangt dat niet op,
• 2:18
  Speaker 2: omdat het test onder perfecte omstandigheden met alles beschikbaar, nul
• 2:22
  Speaker 2: netwerklatentie en niemand die VM's afsluit tijdens je testrun. Dus
• 2:25
  Speaker 2: je implementeert in productie vol vertrouwen en dan slaat de
• 2:27
  Speaker 2: realiteit toe. En dat vals vertrouwen is gevaarlijk, want het
• 2:30
  Speaker 2: is het verschil tussen weten dat je systeem werkt en
• 2:32
  Speaker 2: weten dat het overleeft. En daar komt chaos engineering om
• 2:35
  Speaker 2: de hoek kijken. Wat is chaos engineering eigenlijk? Chaos engineering
• 2:39
  Speaker 2: is een praktische methode. Je injecteert echte, gecontroleerde fouten in
• 2:42
  Speaker 2: je systeem en observeert hoe het reageert. Dit gebeurt niet
• 2:44
  Speaker 2: in een lab of een simulatie. Het gebeurt op je
• 2:46
  Speaker 2: werkelijke resources. Het idee is simpel. Je begint met een hypothese. Bijvoorbeeld,
• 2:50
  Speaker 2: als we één virtuele machine verliezen, moet de load balancer
• 2:53
  Speaker 2: het verkeer naar de overige instanties blijven leiden. Dan voer
• 2:55
  Speaker 2: je een experiment uit. Je sluit die VM af en
• 2:57
  Speaker 2: kijkt wat er gebeurt. Doet de load balancer zijn werk?
• 3:00
  Speaker 2: Blijft de app in de lucht? Werken je waarschuwingen correct?
• 3:03
  Speaker 2: Je meet alles en repareert vervolgens wat kapot gaat. Dit
• 3:06
  Speaker 2: is het punt. Chaos engineering is geen willekeurige vernietiging. Het
• 3:09
  Speaker 2: is niet een ontwikkelaar die de surferuimte inloopt en voor
• 3:11
  Speaker 2: de lolkabels lostrekt. Het is wetenschappelijk, herhaalbaar en veiligheidsgebonden. Je
• 3:15
  Speaker 2: bepaalt de actieradius en controleert precies wat er faalt, wanneer
• 3:18
  Speaker 2: en voor hoe lang. En het belangrijkste is dat je
• 3:20
  Speaker 2: ervan leert. Elk experiment levert bewijs op. Of je hypothese
• 3:23
  Speaker 2: was juist en je systeem is veerkrachtig, of het was
• 3:25
  Speaker 2: onjuist en je hebt een zwak punt gevonden om te herstellen.
• 3:28
  Speaker 2: Hoe dan ook. Je wint. De uitdaging is dat het
• 3:30
  Speaker 2: bouwen van je eigen Chaos Engineering Tools lastig is. Je
• 3:33
  Speaker 2: moet scripts schrijven om VM's af te sluiten, CPU-druk te injecteren,
• 3:36
  Speaker 2: netwerkverkeer te blokkeren en dat alles veilig en herhaalbaar orkestreren.
• 3:39
  Speaker 2: Dat is veel werk en dat is precies waarom Azure
• 3:41
  Speaker 2: een beheerde service heeft gebouwd om dit af te handelen.
• 3:43
  Speaker 2: Maak kennis met Azure Chaos Studio. Azure Chaos Studio is
• 3:46
  Speaker 2: een volledig beheerde service voor het uitvoeren van chaos-experimenten direct
• 3:49
  Speaker 2: op je Azure resources. Geen aangepaste scripts, geen tools van derden,
• 3:52
  Speaker 2: Geen eigen platform voor foutinjectie bouwen. Het zit allemaal in
• 3:55
  Speaker 2: de Azure portal, klaar voor gebruik. Zo werkt het. Garel
• 3:58
  Speaker 2: Studio geeft je twee manieren om fouten te injecteren. Service
• 4:01
  Speaker 2: directe fouten verlopen via het Azure besturingsvlak zelf. Je vertelt
• 4:04
  Speaker 2: Garel Studio om een VM af te sluiten en het
• 4:06
  Speaker 2: doet dit via Azures eigen APIs. Geen agent nodig. Agentgebaseerde
• 4:09
  Speaker 2: fouten installeren een kleine agent in je virtuele machine. Daarna
• 4:13
  Speaker 2: kan deze de CPU naar 100% jagen, het geheugen vullen
• 4:15
  Speaker 2: of een specifiek proces beëindigen. Hiermee kun je problemen simuleren
• 4:19
  Speaker 2: die zich in het besturingssysteem voordoen, niet alleen op resourceniveau.
• 4:22
  Speaker 2: Dit is een analogie. Stel je voor dat je een
• 4:24
  Speaker 2: groot kantoorpand bezit. Je wilt weten of je nooduitgangen echt werken.
• 4:27
  Speaker 2: Wachten op een echte brand is een vreselijk idee. Dus
• 4:29
  Speaker 2: huur je een gespecialiseerd calamiteiten team in. Ze komen binnen,
• 4:32
  Speaker 2: blokkeren een trappenhuis, simuleren rook op de derde verdieping en
• 4:34
  Speaker 2: kijken hoe mensen reageren. Dat is Garel's Studio. Het is
• 4:37
  Speaker 2: je calamiteiten-team. Je roept ze op, ze voeren de oefening
• 4:40
  Speaker 2: uit en je leert of je gebouw veilig is voordat
• 4:42
  Speaker 2: de echte noodsituatie zich voordoet. Garel's Studio ondersteunt een breed
• 4:45
  Speaker 2: scala aan Azure Resources, virtuele machines, VM-schaalzets, Azure Kubernetes, Service Clusters,
• 4:51
  Speaker 2: Azure Cosmos DB, Azure Cache voorredens, netwerkbeveiligingsgroepen en meer. De
• 4:56
  Speaker 2: bibliotheek met fouten blijft groeien. Dus of je nu een
• 4:58
  Speaker 2: eenvoudige tweelaagse app draait of een complexe microservicesarchitectuur op aks,
• 5:02
  Speaker 2: je kunt het testen. Dit is het goede nieuws. Je
• 5:04
  Speaker 2: hoeft geen aangepaste tools te bouwen. Alles is beschikbaar via
• 5:07
  Speaker 2: de Azure Portal, de CLI, Rest APIs, ARM schablonen of Bicep.
• 5:11
  Speaker 2: Je kunt je experimenten als code definiëren en integreren in
• 5:13
  Speaker 2: je implementatiepijplijnen. Maar laten we niet op de zaken vooruit lopen.
• 5:16
  Speaker 2: Laten we eerst eens kijken hoe deze experimenten feitelijk zijn gestructureerd.
• 5:19
  Speaker 2: De bouwstenen, targets, stappen, vertakkingen en acties. Elk chaos-experiment begint
• 5:23
  Speaker 2: met targets. Wat is een target? Het is simpelweg een
• 5:26
  Speaker 2: Azure resource waarop je fouten wilt testen. Je opent Chaos Studio,
• 5:29
  Speaker 2: vind je resource, zoals een VM, een schaalset of een axe-cluster,
• 5:33
  Speaker 2: en je voegt deze toe. Dat betekent dat je tegen
• 5:35
  Speaker 2: Chaos Studio zegt, deze resource is beschikbaar voor experimenten. Dit
• 5:38
  Speaker 2: is essentieel. Wanneer je een target toevoegt Kies je ook
• 5:41
  Speaker 2: welke fouten je wilt toestaan op die resource. Je schakelt
• 5:43
  Speaker 2: niet alles in. Je kiest zelf. CPU druk? Ja. Volledige
• 5:47
  Speaker 2: VM afsluiting? Misschien niet voor productie. Jij beslist. Zodra je
• 5:50
  Speaker 2: targets zijn toegevoegd, maak je een experiment aan. Zie een
• 5:52
  Speaker 2: experiment als een blauwdruk. Het beschrijft precies welke fouten er
• 5:55
  Speaker 2: worden geïnjecteerd, in welke volgorde, op welke targets en voor
• 5:58
  Speaker 2: hoe lang. Je zegt niet zomaar, maak iets kapot. Je
• 6:00
  Speaker 2: definieert het hele scenario vooraf. Experimenten hebben een eenvoudige structuur, stappen,
• 6:04
  Speaker 2: vertakkingen en acties. Stappen worden na elkaar uitgevoerd. Stap 1 eindigt,
• 6:08
  Speaker 2: dan begint stap 2 en daarna stap 3. Zo modeleer
• 6:10
  Speaker 2: je een tijdlijn. Eerst het netwerk vertragen, dan de CPU
• 6:13
  Speaker 2: belasten en daarna een VM afsluiten. Elke stap is een
• 6:16
  Speaker 2: fase in je scenario. Binnen elke stap kun je één
• 6:18
  Speaker 2: of meer vertakkingen hebben. Hier wordt het interessant. Vertakkingen worden
• 6:21
  Speaker 2: parallel uitgevoerd. Dus binnen stap 1 kun je vertakking A
• 6:24
  Speaker 2: hebben die latentie toevoegt aan je database en vertakking B
• 6:26
  Speaker 2: die de CPU op je webserver zwaar belast, beide tegelijkertijd.
• 6:29
  Speaker 2: Hiermee kun je complexe scenario's met meerdere fouten simuleren die
• 6:32
  Speaker 2: echte incidenten nabootsen. En dan heb je acties. Acties zijn
• 6:35
  Speaker 2: de eigenlijke fouten. CPU-druk, geheuguitpoeting, VM-afsluiting, netwerkvertraging, DNS-blokkade, procesbeëindiging. Elke
• 6:42
  Speaker 2: actie richt zich op een specifiek resource of een groep resources.
• 6:45
  Speaker 2: En nogmaals, je kunt alleen acties gebruiken die je op
• 6:47
  Speaker 2: dat doel hebt ingeschakeld. Dat is je vangnet. Als je
• 6:49
  Speaker 2: VM-afsluiting niet op een doel hebt ingeschakeld, zal het experiment
• 6:52
  Speaker 2: die actie simpelweg niet uitvoeren. Dus, de workflow ziet er
• 6:54
  Speaker 2: zo uit. Onboard je doelen. Schakel de fouten in waar
• 6:57
  Speaker 2: je je prettig bij voelt. Maak een experiment met stappen,
• 6:59
  Speaker 2: vertakkingen en acties en voer het vervolgens uit. Maar voordat
• 7:01
  Speaker 2: we beginnen met het uitvoeren ervan, is er iets belangrijks
• 7:03
  Speaker 2: om te begrijpen. Wanneer Garel's Studio een experiment uitvoert, simuleert
• 7:06
  Speaker 2: het niets. Het doet deze dingen daadwerkelijk met je resources.
• 7:09
  Speaker 2: CPU-druk is echte CPU-druk. Een VM-afsluiting is een echte afsluiting.
• 7:13
  Speaker 2: Dat is precies het punt. Je test hoe je systeem
• 7:15
  Speaker 2: zich gedraagt onder werkelijke storingsomstandigheden. En dat betekent dat je
• 7:17
  Speaker 2: voorzichtig moet zijn. Dus laten we een echt experiment doorlopen
• 7:20
  Speaker 2: en zien hoe alles samenkomt. Het uitvoeren van je eerste chaos-experiment.
• 7:23
  Speaker 2: Laten we dit echt maken. Stel je voor dat je
• 7:25
  Speaker 2: een webapplicatie hebt die draait op drie virtuele machines binnen
• 7:28
  Speaker 2: een virtuele machineschaal zet. Elke VM bevindt zich in een
• 7:30
  Speaker 2: andere beschikbaarheidszone. Je hebt een Load Balancer aan de voorkant
• 7:33
  Speaker 2: die het verkeer over alle drie verdeelt. De hypothese is simpel.
• 7:36
  Speaker 2: Als we een volledige beschikbaarheidszone verliezen, moet de Load Balancer
• 7:40
  Speaker 2: het verkeer omleiden naar de overige twee VM's en blijft
• 7:42
  Speaker 2: de applicatie beschikbaar. Dus ontwerp je een experiment met twee stappen.
• 7:46
  Speaker 2: Stap 1. Belast twee van de drie VM's met 95%
• 7:49
  Speaker 2: CPU gedurende vijf minuten. Dat simuleert een scenario met een
• 7:52
  Speaker 2: noisy neighbor of een op hol geslagen proces. Stap 2.
• 7:55
  Speaker 2: Sluit abrupt alle VM's in zone 2 af. Dat simuleert
• 7:58
  Speaker 2: een echte zonnestoring. Je voert het experiment uit en kijkt
• 8:01
  Speaker 2: vervolgens wat er gebeurt. Dit is wat je zou zien.
• 8:04
  Speaker 2: In de eerste 5 minuten schieten 2 VM's naar 100% CPU.
• 8:07
  Speaker 2: De derde blijft normaal omdat je die niet hebt aangewezen.
• 8:10
  Speaker 2: Je monitoring dashboards lichten op. Waarschuwingen gaan af. De Load
• 8:12
  Speaker 2: Balancer merkt dat die twee VM's het zwaar hebben, maar
• 8:15
  Speaker 2: omdat ze technisch gezien nog draaien, blijft hij verkeer naar
• 8:17
  Speaker 2: ze sturen. Je app wordt trager maar gaat niet offline.
• 8:19
  Speaker 2: Dat is interessant. Je leert nu al iets. Dan treedstap
• 8:22
  Speaker 2: 2 in werking. De VM's in zone 2 worden abrupt afgesloten,
• 8:25
  Speaker 2: niet netjes, zonder waarschuwing. Ze verdwijnen gewoon. Een van die
• 8:28
  Speaker 2: twee zwaarbelaste VM's bevond zich in die zone, dus die
• 8:30
  Speaker 2: is weg. De Load Balancer ziet de gezondheidscheck falen, verwijdert
• 8:33
  Speaker 2: deze uit de back-endpool en routeert al het verkeer naar
• 8:35
  Speaker 2: de overige gezonde VM's. Je app blijft in de lucht.
• 8:38
  Speaker 2: De hypothese klopt, maar dit is wat je wellicht niet verwacht.
• 8:41
  Speaker 2: De overgebleven VM's moeten nu 100% van het verkeer afhandelen.
• 8:44
  Speaker 2: Als je niet genoeg capaciteit hebt om die last op
• 8:46
  Speaker 2: te vangen, zie je de latentie pieken. Misschien blijft de
• 8:48
  Speaker 2: app technisch online, maar de gebruikers ervaren hinder. Dat is
• 8:51
  Speaker 2: een bevinding. Je weet nu dat je meer reserve of
• 8:53
  Speaker 2: snellere autoscaling nodig hebt. En onthoud, dit is geen simulatie.
• 8:56
  Speaker 2: Wanneer Garel Studio dit experiment uitvoert, bereiken die VM's echt
• 8:59
  Speaker 2: 95% CPU. Die afsluiting van zone 2 is een echte afsluiting.
• 9:03
  Speaker 2: De VM stopt, de load balancer herverdeelt en je applicatie
• 9:06
  Speaker 2: overleeft het of niet. Dat is precies het punt. Je
• 9:09
  Speaker 2: bent niet aan het gokken. Je observeert echt gedrag onder
• 9:11
  Speaker 2: echte storingsomstandigheden. Je leert of je app in de lucht
• 9:14
  Speaker 2: blijft of onderuit gaat. En als hij onderuit gaat, herstel
• 9:16
  Speaker 2: je het voordat je klanten het ooit merken. Maar deze
• 9:18
  Speaker 2: kracht brengt verantwoordelijkheid met zich mee. Je moet voorzichtig zijn.
• 9:22
  Speaker 2: Veiligheid eerst om ongeplande uitval te voorkomen. Chaos Studio heeft
• 9:25
  Speaker 2: meerdere ingebouwde veiligheidsmechanismen. En voordat je je eerste experiment uitvoert,
• 9:30
  Speaker 2: moet je ze allemaal begrijpen. De eerste veiligheidslaag is identiteit
• 9:33
  Speaker 2: en rechten. Elk experiment dat je aanmaakt krijgt een eigen
• 9:35
  Speaker 2: door het systeem toegewezen beheerde identiteit. Maar die identiteit begint
• 9:39
  Speaker 2: standaard met nul rechten. Je moet expliciet toegang verlenen tot
• 9:42
  Speaker 2: de benodigde bronnen met de minimaal vereiste recht. Als een
• 9:45
  Speaker 2: experiment alleen de CPU van twee VM's moet belasten, beperk
• 9:49
  Speaker 2: je de rechten in plaats van alles in de resourcegroep
• 9:52
  Speaker 2: te laten afsluiten. Dan is er nog de foutinschakeling die
• 9:55
  Speaker 2: ik eerder noemde. Wanneer je een doel toevoegt, kies je
• 9:57
  Speaker 2: precies welke fouten je wilt toestaan. Als je VM-afsluiting nooit
• 10:01
  Speaker 2: inschakelt op een productieschaal zet, kan geen enkel experiment die
• 10:04
  Speaker 2: VM's afsluiten, zelfs niet als iemand dat probeert. Het is
• 10:07
  Speaker 2: een harde blokkade waarvoor je bewust moet kiezen voor elk fouttype. Nu,
• 10:10
  Speaker 2: waar te beginnen? En het antwoord is simpel. Begin klein
• 10:13
  Speaker 2: en begin in een niet-productieomgeving. Voer je eerste experimenten uit
• 10:17
  Speaker 2: in Dev of Staging. Test met 1 VM en 1
• 10:19
  Speaker 2: fout en valideer of je monitoring werkt. Je waarschuwingen afgaan
• 10:23
  Speaker 2: en je het experiment kunt annuleren als er iets misgaat.
• 10:25
  Speaker 2: Pas nadat je dat vertrouwen hebt opgebouwd in een veilige omgeving,
• 10:28
  Speaker 2: moet je overwegen om productie aan te raken. Microsoft heeft
• 10:31
  Speaker 2: hier een waarschuwing over die ik direct wil delen. Ze
• 10:33
  Speaker 2: noemen het een CV-genererend evenement. Als je een chaos-experiment uitvoert
• 10:37
  Speaker 2: in productie zonder juiste waarborgen en het haalt je hele
• 10:39
  Speaker 2: applicatie onderuit, is dat het soort fout waarvoor je ontslagen
• 10:42
  Speaker 2: kunt worden. Dat is geen overdrijving. Chaos Studio is krachtig
• 10:45
  Speaker 2: omdat het echt dingen doet met je bronnen, dus gebruik
• 10:48
  Speaker 2: die kracht verstandig. Het laatste van het is monitoring en annulering.
• 10:51
  Speaker 2: Terwijl een experiment loopt, kun je de voortgang in real-time volgen.
• 10:55
  Speaker 2: Je ziet welke stappen zijn voltooid, welke vertakkingen actief zijn
• 10:58
  Speaker 2: en welke acties worden uitgevoerd. Als er iets mis lijkt,
• 11:01
  Speaker 2: druk je op annuleren en stopt het experiment direct. De
• 11:04
  Speaker 2: getroffen resources blijven in hun huidige staat, maar er worden
• 11:06
  Speaker 2: geen nieuwe fouten geïnjecteerd. Hou dus je dashboards open en
• 11:09
  Speaker 2: je vinger bij de annuleerknop. Begin klein, werk doelbewust en
• 11:12
  Speaker 2: respecteer de kracht van de tool. Nu je weet hoe
• 11:14
  Speaker 2: je veilig kunt blijven, is de vraag, waar moet je
• 11:17
  Speaker 2: deze experimenten eigenlijk uitvoeren? Shifting left versus shifting right. Dus,
• 11:21
  Speaker 2: waar voer je deze experimenten eigenlijk uit? Er zijn twee
• 11:24
  Speaker 2: hoofdbenaderingen en de meeste teams gebruiken beide. De eerste is
• 11:27
  Speaker 2: shifting left. Je voert chaos-experimenten vroeg uit in je ontwikkelingscyclus.
• 11:31
  Speaker 2: Zodra code wordt uitgerold naar een testomgeving, bestook je deze
• 11:34
  Speaker 2: met fouten en maak je er onderdeel van je CI-CD
• 11:37
  Speaker 2: pipeline van. De pipeline installeert de app, voert een chaos-experiment
• 11:40
  Speaker 2: uit om deze te belasten, controleert of het systeem standhoudt
• 11:43
  Speaker 2: en pas dan gaat de beeld naar de volgende fase.
• 11:44
  Speaker 2: Zie het als een kwaliteitscontrole, net als unit tests of beveiligingsscans.
• 11:48
  Speaker 2: Als de app in de stagingomgeving een VM-afsluiting niet kan opvangen,
• 11:51
  Speaker 2: gaat hij niet naar productie. De tweede benadering is shifting right,
• 11:54
  Speaker 2: wat betekent dat je experimenten uitvoert in productie. En ja,
• 11:57
  Speaker 2: dat klinkt doodeng, maar luister naar me. Je begint daar
• 12:00
  Speaker 2: niet mee. Je gaat pas naar rechts als je vertrouwen
• 12:02
  Speaker 2: hebt opgebouwd in niet-productieomgevingen. Je begint met kleine, beperkte experimenten.
• 12:06
  Speaker 2: Misschien belast je de CPU op één instance tijdens een
• 12:08
  Speaker 2: periode met weinig verkeer. Je kijkt nauwlettend toe, je leert
• 12:11
  Speaker 2: ervan en dan breed je uit. Misschien sluit je tijdens
• 12:14
  Speaker 2: kantooruren een enkele VM af in productie en valideer je
• 12:17
  Speaker 2: of je Load Balancer het verkeer correct omleidt, of je
• 12:19
  Speaker 2: gebruikers niets merken en of je monitoring alles opvangt. Na
• 12:22
  Speaker 2: verloop van tijd bouw je op naar agressievere experimenten. Er
• 12:25
  Speaker 2: is een derde benadering die ertussenin zit, gamedays. Een gameday
• 12:28
  Speaker 2: is een geplande chaos oefening waarbij je je development team, operatiesteam,
• 12:31
  Speaker 2: beveiligingsteam en iedereen die bij een echt incident betrokken zou zijn, samenbrengt.
• 12:35
  Speaker 2: Je voert een chaos experiment uit en oefent je incident respons.
• 12:38
  Speaker 2: Wie ontvangt het alarm? Wie neemt het besluit om op
• 12:40
  Speaker 2: te schalen? Wat is de communicatieketen? Hoe snel kun je
• 12:42
  Speaker 2: het probleem diagnostiseren? Gamedays testen de technologie, maar nog belangrijker,
• 12:46
  Speaker 2: ze testen de mensen en processen eromheen. De kern van
• 12:48
  Speaker 2: alle drie de benaderingen is dat chaos engineering geen eenmalige
• 12:51
  Speaker 2: test is. Je voert niet één experiment uit, verklaart je
• 12:53
  Speaker 2: systeem veerkrachtig en gaat weer verder. Systemen veranderen, code veranderd,
• 12:57
  Speaker 2: configuraties veranderen, afhankelijkheden veranderen. Wat vorige maand veerkrachtig was, kan
• 13:01
  Speaker 2: vandaag kwetsbaar zijn. Het doel is continu validatie van veerkracht.
• 13:04
  Speaker 2: Je voert regelmatig experimenten uit, integreert ze in je release-proces
• 13:08
  Speaker 2: en maakt ze onderdeel van je operationele ritme. Dus, wat
• 13:11
  Speaker 2: is de echte waarde van al deze inspanning? De echte
• 13:13
  Speaker 2: waarde is het opbouwen van vertrouwen. Gaos Engineering doet meer
• 13:16
  Speaker 2: dan alleen bugs vinden. Het bouwt vertrouwen op, en dat
• 13:18
  Speaker 2: is iets compleet anders. Een bug is een specifiek defect.
• 13:21
  Speaker 2: Je lost het op en gaat verder. Maar vertrouwen is
• 13:23
  Speaker 2: een gevoel. Het is weten dat je systeem het onverwachte
• 13:26
  Speaker 2: kan overleven, en dat krijg je niet alleen met unit-
• 13:28
  Speaker 2: of integratietests. Dat krijg je door te zien hoe je
• 13:31
  Speaker 2: systeem een echte storing opvangt en weer herstelt. Dit proces
• 13:34
  Speaker 2: dwingt je om zaken te verbeteren die je anders misschien
• 13:36
  Speaker 2: zou negeren. Je monitoring, bijvoorbeeld. Wanneer je een chaos-experiment uitvoert,
• 13:40
  Speaker 2: ontdek je snel of je dashboards de juiste statistieken tonen,
• 13:43
  Speaker 2: of je waarschuwingen bij de juiste drempels afgaan en of
• 13:46
  Speaker 2: je on-call team tijdig wordt geïnformeerd. Als je de storing
• 13:48
  Speaker 2: niet ziet gebeuren, kun je er niet op reageren. Chaos-experimenten
• 13:51
  Speaker 2: leggen die jaten bloot. Ze onthullen ook verborgen aannames. Elke
• 13:55
  Speaker 2: architect heeft wel eens zoiets gezegd. Als de database uitvalt,
• 13:58
  Speaker 2: moet de app de laatst bekende data cachen en blijven draaien.
• 14:00
  Speaker 2: Dat klinkt goed op een whiteboard, maar werkt het ook echt?
• 14:03
  Speaker 2: Heb je het ooit getest? Ga als experimenten beantwoorden die
• 14:06
  Speaker 2: vraag met echt bewijs. Je sluit de database af en
• 14:08
  Speaker 2: kijkt wat er gebeurt. Misschien vangt de app het netjes op.
• 14:11
  Speaker 2: Misschien crash hij.