Latest / M365.FM – Podcast Microsoft 365, Copilot & IA en français / Azure Chaos Studio expliqué simplement : chaos engineering, injection de pannes et applications Azure résilientes (Doublage IA)

Transcript

Azure Chaos Studio expliqué simplement : chaos engineering, injection de pannes et applications Azure résilientes (Doublage IA) · M365.FM – Podcast Microsoft 365, Copilot & IA en français

0:00
Speaker 2: Prêt pour 10 jours consacrés à Microsoft 365, Copilote, l'IA,
0:04
Speaker 2: Azure et aux acteurs qui façonnent l'avenir du travail? En
0:08
Speaker 2: janvier prochain, la M3065-N est de retour et nous voyons
0:11
Speaker 2: plus grand. Rejoignez-nous pour des sessions en direct, des démonstrations
0:15
Speaker 2: concrètes et des conseils pratiques d'experts et de MVPs du
0:17
Speaker 2: monde entier. Pas de diapositives génériques, pas de jargon à
0:20
Speaker 2: n'en plus finir. Nous abordons les vrais défis. Copilote Studio, agent, IA, fabrique, sécurité,
0:27
Speaker 2: gouvernance et automatisation. Que vous soyez professionnel de l'IT, développeur
0:32
Speaker 2: ou dirigeant, des sessions sont conçues pour vous. Avec 10
0:35
Speaker 2: jours complets, vous pourrez explorer diverses technologies et échanger avec
0:39
Speaker 2: une communauté mondiale. Suivez le direct et rapportez des idées
0:42
Speaker 2: concrètes au sein de votre entreprise. Janvier 2027, 10 jours,
0:47
Speaker 2: une seule communauté Microsoft. Les inscriptions sont désormais ouvertes. Rendez-vous
0:52
Speaker 2: sur m365con. net pour réserver votre place dès aujourd'hui. C'est m365con. net...
1:00
Speaker 2: Scrivez-vous sur m365con. net et nous vous attendons en direct en janvier.
1:05
Speaker 2: Bienvenue dans un nouvel épisode de Microsoft Knowledge Nuggets. Je
1:07
Speaker 2: suis votre hôte, Milko Pitars. Si vous pouviez casser vos
1:09
Speaker 2: propres applications cloud volontairement et de manière contrôlée, on les
1:12
Speaker 2: rend plus robustes. Cela semble contre-intuitif, mais c'est la même
1:14
Speaker 2: logique que celle utilisée par les pompiers lors de brûlages dirigés.
1:17
Speaker 2: Ils allument des feux maîtrisés pour éliminer les broussards et
1:19
Speaker 2: sèches afin qu'en cas d'incendie réel, il n'y ait plus
1:21
Speaker 2: rien à brûler. C'est exactement ce qu'Azure Chaos Studio fait
1:23
Speaker 2: pour vos applications cloud. A la fin de cet épisode,
1:25
Speaker 2: vous comprendrez ce qu'est ce service, pourquoi l'utiliser, comment il
1:28
Speaker 2: vous aide à créer des systèmes qui ne s'effondrent pas
1:30
Speaker 2: en cas de problème. Alors prenez votre café et commençons
1:34
Speaker 2: par le problème. Le problème? Pourquoi les tests traditionnels ne
1:38
Speaker 2: suffisent pas? Voici ce qu'il en est des tests traditionnels.
1:40
Speaker 2: Ils vérifient si votre logiciel fonctionne comme prévu dans des
1:43
Speaker 2: conditions normales. Vous écrivez un test, vous l'exécutez et si
1:46
Speaker 2: le résultat correspond, c'est réussi. C'est parfait pour détecter les bugs,
1:49
Speaker 2: mais cela ne révèle pas comment votre système réagit face
1:51
Speaker 2: à une panne imprévue, comme une interruption réseau, une machine
1:53
Speaker 2: virtuelle qui s'éteint, une zone de disponibilité entière qui tombe.
1:57
Speaker 2: Les applications cloud modernes ne sont plus saines. Ce sont
1:59
Speaker 2: des systèmes distribués qui communiquent avec des bases de données,
2:01
Speaker 2: des caches, des services d'identité, des API tierces et d'autres microservices,
2:04
Speaker 2: et d'autres microservices et tous ces éléments ont des dépendances cachées.
2:07
Speaker 2: Une petite défaillance peut provoquer une réaction en chaîne dans
2:08
Speaker 2: tout le système. Une base de données ralentit, l'application expire,
2:11
Speaker 2: l'équilibreur de charge la marque comme non saine, le trafic
2:13
Speaker 2: est redirigé, d'autres instances sont surchargées et soudain toute votre
2:15
Speaker 2: application est hors-service. Les tests traditionnels ne détectent pas cela,
2:18
Speaker 2: car ils testent dans des conditions idéales, avec tout disponible,
2:21
Speaker 2: une latence réseau nu, les personnes, pour éteindre des machines
2:23
Speaker 2: virtuelles pendant le test. Ainsi, vous déployez en production avec
2:26
Speaker 2: confiance jusqu'à ce que la réalité vous rattrape. Et cette
2:28
Speaker 2: fausse confiance est dangereuse, car c'est la différence entre savoir
2:31
Speaker 2: que votre système fonctionne et savoir qu'il survit. Et c'est
2:34
Speaker 2: là qu'intervient le chaos engineering. Qu'est-ce que le chaos engineering
2:37
Speaker 2: en fait? Le chaos engineering est une méthode pratique. Vous
2:40
Speaker 2: injectez des défaillances réelles et contrôlées dans votre système et
2:42
Speaker 2: observez sa réaction. Cela ne se passe pas dans un
2:45
Speaker 2: laboratoire ou une simulation. Cela se passe sur vos ressources réelles.
2:47
Speaker 2: L'idée est simple. Vous partez d'une hypothèse du type que
2:50
Speaker 2: si nous perdons une machine virtuelle, l'équilibreur de charge doit
2:53
Speaker 2: continuer à diriger le trafic vers les instances restantes. Ensuite,
2:55
Speaker 2: vous lancez une expérience. Vous éteignez cette machine virtuelle et
2:57
Speaker 2: regardez ce qui se passe. L'équilibreur de charge fait-il son travail?
3:00
Speaker 2: L'application reste elle en ligne. Vos alertes se déclenchent-elles correctement?
3:02
Speaker 2: Vous mesurez tout, puis vous réparez ce qui casse. Voici
3:06
Speaker 2: le point important. Le chaos engineering n'est pas une destruction aléatoire.
3:09
Speaker 2: Ce n'est pas un développeur qui entre dans la salle
3:10
Speaker 2: des serveurs pour débrancher des câbles par amusement. C'est scientifique,
3:13
Speaker 2: reproductible et contraint par la sécurité. Vous définissez le rayon
3:16
Speaker 2: d'impact et contrôlez exactement ce qui échoue quand et pour
3:18
Speaker 2: combien de temps. Et surtout, vous en tirez des enseignements.
3:21
Speaker 2: Chaque expérience vous apporte des preuves. Soit votre hypothèse était
3:23
Speaker 2: bonne et votre système est résilient, soit elle était fausse
3:26
Speaker 2: et vous avez découvert une faiblesse à corriger. Dans les
3:28
Speaker 2: deux cas, vous avez gagné. Le défi est que créer
3:30
Speaker 2: vos propres outils de Chaos Engineering est difficile. Vous devriez
3:33
Speaker 2: écrire des scripts pour arrêter des machines virtuelles, saturer le processeur,
3:36
Speaker 2: bloquer le trafic réseau et orchestrer tout cela de manière
3:38
Speaker 2: sûre et répétable. C'est beaucoup de travail et c'est exactement
3:41
Speaker 2: pourquoi Azure a créé un service géré pour s'en charger.
3:43
Speaker 2: Voici Azure Chaos Studio. Azure Chaos Studio est un service
3:46
Speaker 2: entièrement géré pour exécuter des expériences de chaos directement sur
3:49
Speaker 2: vos ressources Azure. Pas de script personnalisé, pas d'outil tiers,
3:52
Speaker 2: pas besoin de construire votre propre plateforme d'injection de pannes.
3:55
Speaker 2: Tout est dans le portail Azure, prêt à l'emploi. Voici
3:57
Speaker 2: comment ça fonctionne. Chaos Studio vous offre deux façons d'injecter
3:59
Speaker 2: des pannes. Les pannes directes de service passent par le
4:02
Speaker 2: plan de contrôle Azure lui-même. Vous demandez à Chaos Studio
4:04
Speaker 2: d'arrêter une machine virtuelle et il le fait via les
4:06
Speaker 2: propres API d'Azure. Aucun agent nécessaire. Les pannes basées sur
4:09
Speaker 2: un agent installent un petit agent à l'intérieur de votre
4:11
Speaker 2: machine virtuelle. Il peut ensuite faire monter le processeur à 100%,
4:14
Speaker 2: saturer la mémoire ou tuer un processus spécifique. Cela vous
4:18
Speaker 2: permet de simuler des problèmes survenant à l'intérieur du système d'exploitation,
4:20
Speaker 2: pas seulement au niveau des ressources. Voici une analogie. Imaginez
4:23
Speaker 2: que vous possédez un grand immeuble de bureau. Vous voulez
4:25
Speaker 2: savoir si vos issues de secours fonctionnent vraiment. Attendre un
4:27
Speaker 2: véritable incendie est une très mauvaise idée. Vous engagez une
4:30
Speaker 2: équipe spécialisée en gestion de casse. Ils arrivent, bloquent une
4:32
Speaker 2: cage d'escalier, simulent de la fumée au troisième étage et
4:34
Speaker 2: observent les réactions. C'est ça Chaos Studio et votre équipe
4:37
Speaker 2: d'intervention d'urgence. Vous les appelez, ils mènent l'exercice. Et vous
4:40
Speaker 2: apprenez si votre bâtiment est sûr avant qu'une vraie urgence
4:42
Speaker 2: ne survienne. Chaos Studio prend en charge un large éventail
4:45
Speaker 2: de ressources Azure. Machines virtuelles, groupes de machines virtuelles identiques,
4:49
Speaker 2: clusters Azure Kubernetes Service, Azure Cosmos DB, Azure Cache for Redis,
4:53
Speaker 2: groupes de sécurité réseau, et plus encore, la bibliothèque des
4:57
Speaker 2: renaissances de Sagran. Ainsi que vous exécutiez une application simple
4:59
Speaker 2: à deux niveaux ou une architecture complexe de microservices sur AKS,
5:02
Speaker 2: vous pouvez la tester. Voici la bonne nouvelle. Vous n'avez
5:04
Speaker 2: pas besoin de créer d'outils personnalisés. Tout est disponible via
5:07
Speaker 2: le portail Azure, interface CLI, les API REST, les modèles
5:09
Speaker 2: ARM ou Bicep. Vous pouvez définir vos expériences sous forme
5:12
Speaker 2: de code et les intégrer dans vos pipelines de déploiement.
5:14
Speaker 2: Mais ne brûlons pas les étapes. Analysons d'abord la structure
5:17
Speaker 2: réelle de ces expériences. Les blocs de construction, cibles, étapes,
5:21
Speaker 2: branches actions. Chaque expérience de chaos commence par des cibles.
5:24
Speaker 2: Qu'est-ce qu'une cible? C'est simplement une ressource Azure sur laquelle
5:26
Speaker 2: vous voulez provoquer des erreurs. Vous ouvrez Chaos Studio, trouvez
5:29
Speaker 2: votre ressource, une VM, un groupe identique, un cluster AKS
5:32
Speaker 2: et vous l'intégrez. Cela signifie que vous dites à Chaos Studio,
5:35
Speaker 2: cette ressource est disponible pour des expériences. Voici le point clé.
5:39
Speaker 2: Lorsque vous intégrez une cible, vous choisissez également les erreurs
5:42
Speaker 2: que vous autorisez sur cette ressource. N'activez pas tout. Vous choisissez.
5:45
Speaker 2: Pression sur le processus. Arrêt complet d'une VM? Peut-être pas
5:47
Speaker 2: pour la production. C'est vous qui décidez. Une fois vos
5:50
Speaker 2: cibles intégrées, vous créez une expérience. Considérez une expérience comme
5:53
Speaker 2: un plan d'été. Elle décrit exactement quelle panne injecter, dans
5:56
Speaker 2: quel ordre, contre quelle cible et pour quelle durée. Il
5:59
Speaker 2: ne s'agit pas juste de dire casser quelque chose. Définissez
6:01
Speaker 2: tout le scénario à l'avance. Les expériences ont une structure simple. Étape,
6:04
Speaker 2: branche et action. Les étapes s'exécutent les unes après les autres.
6:07
Speaker 2: L'étape 1 se termine, puis l'étape 2 commence, puis l'étape 3.
6:10
Speaker 2: C'est ainsi que vous modélisez une chronologie. D'abord dégrader le réseau,
6:12
Speaker 2: puis saturer le processeur, puis arrêter une VM. Chaque étape
6:15
Speaker 2: est une phase de votre scénario. A l'intérieur de chaque étape,
6:18
Speaker 2: vous pouvez avoir une ou plusieurs branches. C'est là que
6:20
Speaker 2: les choses deviennent intéressantes. Les branches s'exécutent en parallèle. Ainsi,
6:23
Speaker 2: au sein de l'étape 1, vous pourriez avoir la branche
6:24
Speaker 2: A ajoutant de la latence à votre base de données
6:26
Speaker 2: et la branche B sollicitant fortement le processeur de vos
6:28
Speaker 2: serveurs web simultanément. Cela vous permet de simuler des scénarios
6:31
Speaker 2: complexes à multiples pannes qui reflètent des incidents réels. Ensuite,
6:34
Speaker 2: il y a les actions. Les actions sont les pannes réelles.
6:36
Speaker 2: Pression CPU, saturation mémoire, arrêt de machine virtuelle, latence réseau,
6:39
Speaker 2: blocage DNS, arrêt de processus. Chaque action cible une ressource
6:43
Speaker 2: spécifique ou un groupe de ressources. Et encore une fois,
6:45
Speaker 2: vous ne pouvez utiliser que les actions que vous avez
6:47
Speaker 2: activées sur cette cible. C'est votre filet de sécurité. Si
6:49
Speaker 2: vous n'avez pas activé l'arrêt de VM sur une cible,
6:51
Speaker 2: l'expérience n'exécutera tout simplement pas cette action. Le flux de
6:53
Speaker 2: travail ressemble donc à ceci. Intégrez vos cibles. Activez les
6:56
Speaker 2: pannes avec lesquelles vous êtes à l'aise. Créez une expérience
6:59
Speaker 2: avec des étapes des branches et des actions, puis exécutez-la.
7:01
Speaker 2: Mais avant de passer à l'exécution, il y a un
7:03
Speaker 2: point important à comprendre. Lorsque Chaos Studio exécute une expérience,
7:06
Speaker 2: il ne simule rien. Il applique réellement ses actions sur
7:08
Speaker 2: vos ressources. La pression CPU est une réelle pression CPU.
7:11
Speaker 2: Un arrêt de VM est un véritable arrêt. C'est tout l'intérêt.
7:14
Speaker 2: Vous testez le comportement de votre système dans des conditions
7:16
Speaker 2: de panne réelles. Cela signifie que vous devez être prudent.
7:18
Speaker 2: Passons donc en revue une expérience réelle pour voir comment
7:20
Speaker 2: tout cela s'articule. Exécutez votre première expérience de cas. Rendons
7:23
Speaker 2: cela concret. Imaginez que vous ayez une application web s'exécutant
7:26
Speaker 2: sur trois machines virtuelles dans un groupe de machines virtuelles.
7:29
Speaker 2: Chaque VM se trouve dans une zone de disponibilité différente.
7:32
Speaker 2: Vous avez un équilibreur de charge en frontal qui distribue
7:34
Speaker 2: le trafic sur les trois. Hypothèse est simple. Si nous
7:37
Speaker 2: perdons une zone de disponibilité entière, l'équilibreur de charge devrait
7:40
Speaker 2: rediriger le trafic vers les deux VM restantes et l'application
7:42
Speaker 2: doit rester disponible. Concevez donc une expérience en deux étapes.
7:46
Speaker 2: Première étape, stressez deux des trois VM avec 94% de
7:49
Speaker 2: CPU pendant 5 minutes. Cela simule un scénario de voisin
7:52
Speaker 2: bruyant ou un processus incontrôlé. Deuxième étape, arrêtez brutalement toutes
7:56
Speaker 2: les VM de la zone 2. Cela simule une réelle
7:59
Speaker 2: panne de zone. Vous exécutez l'expérience puis vous observez ce
8:02
Speaker 2: qui se passe. Voici ce que vous verriez. Au cours
8:04
Speaker 2: des cinq premières minutes, deux VM atteignent 100% de CPU.
8:07
Speaker 2: La troisième reste normale car vous ne l'avez pas ciblée.
8:10
Speaker 2: Vos tableaux de bord de surveillance s'allument, des alertes se déclenchent,
8:12
Speaker 2: l'équilibre de charge remarque que ces deux VM peinent, mais
8:14
Speaker 2: comme elles fonctionnent toujours techniquement, ils continuent de leur envoyer
8:17
Speaker 2: du trafic. Votre application ralentit mais ne passe pas hors ligne.
8:20
Speaker 2: C'est intéressant. Vous avez déjà appris quelque chose. Ensuite, l'étape
8:22
Speaker 2: de débat. Les VM de la zone 2 sont brutalement arrêtées,
8:25
Speaker 2: sans préparation, sans avertissement. Elles disparaissent simplement. L'une de ces
8:28
Speaker 2: deux VM stressées se trouvait dans cette zone, elle a
8:29
Speaker 2: donc disparu. L'équilibreur de charge constate l'échec du test de santé,
8:33
Speaker 2: la retire du pull back-end et achemine tout le trafic
8:35
Speaker 2: vers les VM saines restantes. Votre application reste en ligne.
8:37
Speaker 2: L'hypothèse est confirmée. Mais voici ce à quoi vous nous
8:40
Speaker 2: attendiez peut-être. Les machines virtuelles restantes doivent désormais gérer 100%
8:43
Speaker 2: du trafic. Si vous n'aviez pas assez de capacité pour
8:45
Speaker 2: absorber cette charge, vous verriez la latence grimper. Peut-être que
8:47
Speaker 2: l'application reste techniquement en ligne, mais les utilisateurs en subissent
8:50
Speaker 2: les conséquences. C'est un résultat important. Vous savez maintenant qu'il
8:52
Speaker 2: vous faut plus de marge de manœuvre, un autoscaling plus rapide.
8:55
Speaker 2: Et n'oubliez pas, ce n'est pas une simulation. Lorsque Chaos
8:57
Speaker 2: Studio exécute cette expérience, ces machines virtuelles atteignent réellement 95%
9:00
Speaker 2: de CPU. Cet arrêt de la zone 2 est un
9:02
Speaker 2: véritable arrêt. La machine virtuelle s'arrête, l'équilibreur de charge se
9:05
Speaker 2: rééquilibre et votre application survit ou non. C'est là tout l'intérêt.
9:08
Speaker 2: Vous ne devinez pas. Vous observez un comportement réel, dans
9:11
Speaker 2: des conditions de défaillance réelles. Vous apprenez si votre application
9:14
Speaker 2: reste opérationnelle ou si elle tombe. Et si elle tombe,
9:15
Speaker 2: vous la corrigez avant que vos clients ne s'en aperçoivent.
9:18
Speaker 2: Mais ce pouvoir s'accompagne de responsabilités. Vous devez être prudent.
9:22
Speaker 2: La sécurité avant tout, pour éviter les pannes imprévues. Chaos
9:25
Speaker 2: Studio intègre de multiples mécanismes de sécurité. Et avant de
9:28
Speaker 2: lancer votre première expérience, vous devez tous les comprendre. La
9:31
Speaker 2: première couche de sécurité concerne l'identité et les autorisations. Chaque
9:34
Speaker 2: expérience que vous créez reçoit sa propre identité gérée attribuée
9:36
Speaker 2: par le système. Cette identité commence par défaut avec zéro autorisation.
9:40
Speaker 2: Vous devez lui accorder explicitement l'accès aux ressources nécessaires et
9:42
Speaker 2: vous n'accordez que le minimum d'autorisation requis. Si une expérience
9:46
Speaker 2: n'a besoin que de solliciter le CPU de deux machines virtuelles,
9:48
Speaker 2: vous restreignez les autorisations au lieu de lui permettre d'arrêter
9:51
Speaker 2: tout le groupe de ressources on-and-through. Ensuite, il y a
9:53
Speaker 2: l'activation des défaillances que j'ai mentionné plus tôt. Lorsque vous
9:56
Speaker 2: intégrez une cible, vous choisissez exactement quelle défaillance, vous êtes
9:58
Speaker 2: prêt à autoriser. Si vous n'activez pas la cible, vous
9:59
Speaker 2: n'aurez pas de défaillance. jamais l'arrêt des machines virtuelles sur
10:01
Speaker 2: un groupe de mise à l'échelle de production, aucune expérience
10:03
Speaker 2: ne pourra les arrêter, même si quelqu'un le tente. C'est
10:06
Speaker 2: un blocage strict qui nécessite que vous optiez délibérément pour
10:09
Speaker 2: chaque type de défaillance. Maintenant, par où commencer? La réponse
10:12
Speaker 2: est simple. Commencez petit et commencez dans un environnement hors production.
10:15
Speaker 2: Exécutez vos premières expériences en développement en pré-production. Testez avec
10:18
Speaker 2: une seule machine virtuelle et une seule défaillance et validez
10:21
Speaker 2: que votre surveillance fonctionne, que vos alertes se déclenchent et
10:23
Speaker 2: que vous pouvez annuler l'expérience en cas de problème. Ce
10:25
Speaker 2: n'est qu'après avoir acquis cette confiance dans un environnement sûr
10:28
Speaker 2: que vous devriez envisager de toucher à la production. Microsoft
10:31
Speaker 2: a un avertissement à ce sujet que je souhaite partager directement.
10:33
Speaker 2: Ils appellent cela un événement qui génère une mise à
10:35
Speaker 2: jour de votre CV. Si vous exécutez une expérience de
10:37
Speaker 2: chaos en production sans mesure de protection appropriée et qu'elle
10:39
Speaker 2: fait tomber toute votre application, c'est le genre d'erreur qui
10:41
Speaker 2: pourrait vous coûter votre emploi. Ce n'est pas une exagération.
10:44
Speaker 2: Chaos Studio est puissant car il agit réellement sur vos ressources,
10:46
Speaker 2: alors utilisez ce pouvoir avec sagesse et Le dernier filet
10:49
Speaker 2: de sécurité est la surveillance et l'annulation. Pendant qu'une expérience
10:53
Speaker 2: se déroule, vous pouvez suivre sa progression en temps réel.
10:55
Speaker 2: Voyez quelles étapes sont terminées, quelles branches sont actives et
10:57
Speaker 2: quelles actions s'exécutent. Si quelque chose semble anormal, vous cliquez
11:01
Speaker 2: sur annuler et l'expérience s'arrête immédiatement. Les ressources affectées restent
11:05
Speaker 2: dans leur état actuel, mais aucune nouvelle panne n'est injectée.
11:08
Speaker 2: Gardez donc vos tableaux de bord ouverts et le doigt
11:10
Speaker 2: sur le bouton d'annulation. Commencez petit, soyez prudent et respectez
11:12
Speaker 2: la puissance de l'outil. Maintenant que vous savez comment rester
11:14
Speaker 2: en sécurité, la question est, où mener ces expériences? Décalage
11:19
Speaker 2: vers la gauche ou décalage vers la droite? Alors où
11:21
Speaker 2: effectuez-vous réellement ces expériences? Il existe deux approches principales, et
11:24
Speaker 2: la plupart des équipes utilisent les deux. La première est
11:26
Speaker 2: le décalage vers la gauche, shifting left. Vous exécutez des
11:29
Speaker 2: expériences de chaos tôt dans votre cycle de développement. Dès
11:32
Speaker 2: que le code est déployé dans un environnement de test,
11:34
Speaker 2: vous y injectez des pannes et l'intégrez à votre pipeline CI-SOCD.
11:38
Speaker 2: Le pipeline déploie l'application, exécute une expérience de chaos pour
11:40
Speaker 2: la stresser, vérifie sa résilience, puis promeut la version à
11:43
Speaker 2: l'étape suivante. Considérez cela comme une porte de qualité, tout
11:46
Speaker 2: comme les tests unitaires ou les scans de sécurité. Si
11:49
Speaker 2: l'application ne supporte pas l'arrêt d'une machine virtuelle en staging,
11:51
Speaker 2: elle ne va pas en production. La deuxième approche est
11:53
Speaker 2: le décalage vers la droite, shifting rights, qui signifie tester
11:56
Speaker 2: en production. Oui, cela semble terrifiant, mais écoutez-moi bien. Vous
11:59
Speaker 2: ne commencez pas par là. Vous ne passez à droite
12:01
Speaker 2: qu'après avoir acquis de la confiance dans les environnements hors production.
12:04
Speaker 2: Commencez par de petites expériences limitées. Peut-être en stressant le
12:07
Speaker 2: CPU d'une instance lors d'une période de faible trafic. Vous
12:10
Speaker 2: surveillez attentivement, vous apprenez, puis vous étonnez. Peut-être arrêter une
12:13
Speaker 2: seule VM en production durant les heures de travail et
12:15
Speaker 2: vérifier que votre équilibreur de charge redirige bien le trafic
12:17
Speaker 2: que les utilisateurs ne remarquent rien et que votre supervision
12:20
Speaker 2: détecte tout. Avec le temps, vous montez en puissance vers
12:23
Speaker 2: des expériences plus agressives. Il existe une troisième approche intermédiaire,
12:27
Speaker 2: les Game Days. Un Game Day est un exercice de
12:29
Speaker 2: chaos planifié où vous réunissez vos équipes de développement, d'exploitation
12:32
Speaker 2: et de sécurité, tous ceux impliqués dans un incident réel.
12:35
Speaker 2: Vous menez une expérience de chaos et pratiquez votre réponse
12:37
Speaker 2: aux incidents. Qui reçoit l'alerte? Qui décide de l'escalade? Quelle
12:40
Speaker 2: est la chaîne de communication? A quelle vitesse pouvez-vous diagnostiquer
12:43
Speaker 2: le problème? Les Game Days testent la technologie, mais surtout
12:45
Speaker 2: ils testent les personnes et les processus qui l'entourent. L'idée
12:48
Speaker 2: clé à travers ces trois approches est que le chaos
12:49
Speaker 2: engineering n'est pas un test unique. On ne lance pas
12:52
Speaker 2: une seule expérience pour déclarer son système résilient avant de
12:54
Speaker 2: passer à autre chose. Les systèmes changent, le code change,
12:56
Speaker 2: les configurations changent, les dépendances changent, les dépendants changent. Ce
12:59
Speaker 2: qui était résilient le mois dernier pourrait être fragile aujourd'hui.
13:02
Speaker 2: L'objectif est la validation continue de la résilience. Vous menez
13:05
Speaker 2: des expériences régulièrement, vous les intégrez à votre processus de
13:08
Speaker 2: publication et vous en faites partie de votre rythme opérationnel.
13:11
Speaker 2: Alors quelle est la vraie valeur de tous ces efforts?
13:13
Speaker 2: La vraie valeur, c'est de renforcer la confiance. L'ingénierie du
13:15
Speaker 2: chaos ne se limite pas à trouver des bugs. Elle
13:17
Speaker 2: renforce la confiance, et c'est une chose totalement différente. Un
13:20
Speaker 2: bug est un défaut spécifique. Vous le corrigez et vous
13:21
Speaker 2: passez à autre chose. La confiance, c'est un sentiment. C'est
13:24
Speaker 2: savoir que votre système peut survivre à l'imprévu, ce que
13:26
Speaker 2: les tests unitaires ou d'intégration ne peuvent offrir seuls. Vous
13:30
Speaker 2: l'obtenez en observant votre système gérer une vraie panne et
13:32
Speaker 2: s'en sortir indemne. Ce processus vous force à améliorer des
13:35
Speaker 2: points que vous ignoriez peut-être autrement. Votre monitoring, par exemple.
13:38
Speaker 2: Lorsque vous lancez une expérience de chaos, vous découvrez rapidement
13:41
Speaker 2: si vos tableaux de bord affichent les bonnes métriques, si
13:43
Speaker 2: vos alertes se déclenchent au bon seuil, Et si votre
13:45
Speaker 2: équipe d'astreinte est avertie à temps, est avertie à temps?
13:48
Speaker 2: Si vous ne voyez pas la panne arriver, vous ne
13:50
Speaker 2: pouvez pas y répondre. Les expériences de chaos exposent ces lacunes.
13:52
Speaker 2: Elles révèlent aussi des hypothèses cachées. Chaque architecte a déjà
13:55
Speaker 2: dit quelque chose comme« Si la base de données tombe,
13:57
Speaker 2: l'appli doit juste mettre en cache les dernières données connues
13:59
Speaker 2: et continuer à tourner.» Cela semble bien sur un tableau blanc,
14:02
Speaker 2: mais est-ce que ça fonctionne vraiment? Avez-vous déjà testé? Les
14:04
Speaker 2: expériences de chaos répondent à cette question avec des preuves concrètes.
14:07
Speaker 2: Vous éteignez la base de données et vous observez ce
14:08
Speaker 2: qui se passe. Peut-être que l'appli le gère correctement. Peut-être
14:11
Speaker 2: qu'elle plante.