Tutoriel : Déployer un exemple d’application et tester sa résilience de zone avec Chaos Studio

Dans ce tutoriel, vous déployez un exemple d’application commerciale sur un cluster Azure Kubernetes Service (AKS) redondant interzone, puis utilisez un espace de travail Azure Chaos Studio pour simuler un échec de zone de disponibilité deux fois. La première exécution met en évidence une véritable faille de résilience : le front-end de l’application est délibérément rattaché à une seule zone, de sorte que la vitrine devient indisponible lorsque cette zone tombe en panne. Vous corrigez ensuite le déploiement, réexécutez le même scénario et observez l’échec de l’application. Au fil du processus, vous lancez un outil de surveillance dans le navigateur qui affiche la panne et sa correction au moment où elles se produisent, et vous découvrez pourquoi la disponibilité de la boutique en ligne et l’état des nœuds du cluster ne changent pas au même moment.

Ce tutoriel effectue une bonne première démonstration et réutilise l'exemple d'application de démonstration AKS store à partir des guides de démarrage rapide AKS. Il n'existe donc pas d'étape de registre de conteneurs ou de build. Planifiez environ une heure : la création d’un cluster plus deux exécutions de scénario d’environ 5 minutes chacune.

Dans ce tutoriel, vous allez apprendre à :

Ce tutoriel vise à obtenir une démo fonctionnelle. Pour les concepts qui se trouvent derrière chaque étape, les avertissements liés à l’interruption de l’infrastructure gérée par AKS et la façon d’interpréter les résultats sur une charge de travail réelle, consultez Tester la résilience des charges de travail sur AKS avec Chaos Studio.

Prerequisites

• Un abonnement Azure. Si vous n’avez pas de compte Azure, créez un compte gratuit avant de commencer.
• Azure CLI, kubectl, kubeloginet Python 3 (bibliothèque standard uniquement - aucun package à installer). Azure Cloud Shell a les quatre préinstallés. Si vous travaillez en local, installez kubectl avec az aks install-cli et kubelogin séparément.
• Le fournisseur de ressources Microsoft.Chaos est enregistré dans votre abonnement. Pour l’inscrire pour la première fois, consultez Inscrire le fournisseur de ressources Chaos Studio.

Créer un cluster AKS redondant interzone

Un test de défaillance de zone n’a de sens que pour un cluster conçu pour y survivre ; créez donc un cluster avec trois nœuds répartis sur trois zones de disponibilité. Cet exemple utilise USA Est 2 ; toute région avec des zones de disponibilité convient.

1. Créez un groupe de ressources et le cluster :

   az group create --name chaos-demo-rg --location eastus2
   
   az aks create \
     --resource-group chaos-demo-rg \
     --name chaos-demo-aks \
     --node-count 3 \
     --zones 1 2 3 \
     --generate-ssh-keys
   

   La création de cluster prend quelques minutes.

2. Dans une nouvelle session Cloud Shell, kubectl n'est pas encore connectée à un cluster. Définissez votre abonnement, récupérez les informations d’identification et convertissez le kubeconfig pour l’authentification Microsoft Entra avant d’exécuter une kubectl commande :

   az account set --subscription <SUBSCRIPTION_ID>
   az aks get-credentials --resource-group chaos-demo-rg --name chaos-demo-aks
   kubelogin convert-kubeconfig -l azurecli
   

   Remplacez votre ID d’abonnement par <SUBSCRIPTION_ID>. Passez az account set si cet abonnement est déjà actif. L’étape kubelogin est requise même dans une nouvelle session Cloud Shell : sans cela, la première kubectl commande sur un cluster entra-authentifié échoue avec une erreur d’authentification.

3. Vérifiez que les nœuds s’étendent sur trois zones :

   kubectl get nodes -L topology.kubernetes.io/zone
   

   La colonne ZONE affiche un nœud dans chaque zone, comme eastus2-1, eastus2-2 et eastus2-3. Le numéro de zone après le nom de la région correspond à ce que vous ciblez plus loin dans la configuration du scénario.

Déployer l’exemple d’application

La démonstration du magasin AKS est une petite vitrine de vente au détail avec un front-end web, un service de produit, un service de commande et une file d’attente RabbitMQ. Ses images conteneur sont publiques. Vous pouvez donc la déployer avec une seule commande.

1. Déployez l’application :

   kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/2.2.0/aks-store-quickstart.yaml
   

   Le manifeste déploie chaque composant avec une seule réplique. Le cluster est redondant entre zones, mais l’application ne l’est pas. Ce didacticiel expose et corrige ensuite cet écart de résilience.

2. Attendez que le serveur frontal obtienne une adresse IP publique :

   kubectl get service store-front --watch
   

   Lorsque la valeur EXTERNAL-IP passe de <pending> à une adresse IP publique, appuyez sur Ctrl+C pour arrêter la surveillance.

3. Ouvrez http://<EXTERNAL-IP> dans un navigateur et vérifiez que la boutique se charge. Maintenez cet onglet ouvert. Il s’agit d’une vue secondaire de l’état de santé de l’application pendant le test : le moniteur que vous lancez plus tard est le moniteur principal.

Pour savoir comment l’application elle-même est générée et déployée, consultez la série de didacticiels AKS.

Épingler le front-end à une seule zone pour une démonstration déterministe

En l’absence d’un épinglage explicite, le planificateur peut placer l’unique réplica du frontal dans n’importe quelle zone, et une simple replanification peut se produire suffisamment rapidement pour que l’impact passe facilement inaperçu. Le fait d’épingler le réplica dans une zone connue rend la cible prévisible et l’échec observable chaque fois que vous exécutez la démo.

1. Recherchez le nœud sur lequel le store-front pod est en cours d’exécution et lisez l’étiquette de zone de ce nœud :

   STORE_NODE="$(kubectl get pods -l app=store-front -o jsonpath='{.items[0].spec.nodeName}')"
   PIN_ZONE="$(kubectl get node "$STORE_NODE" -o jsonpath="{.metadata.labels['topology\.kubernetes\.io/zone']}")"
   echo "$PIN_ZONE"
   

   PIN_ZONE est l’étiquette de zone complète, telle que eastus2-1. Laissez cette session shell ouverte : vous réutilisez cette valeur pour le moniteur, puis ultérieurement pour la configuration du scénario (qui demande uniquement le nombre, la partie après le dernier trait d’union, par exemple, 1 dans eastus2-1).

2. Appliquez un correctif au déploiement store-front pour imposer la planification dans cette zone, et ajoutez une annotation indiquant que le correctif est uniquement un modèle de démonstration :

   kubectl patch deployment store-front --patch "$(cat <<EOF
   {
     "metadata": {
       "annotations": {
         "chaos-demo.aks-zone-down-demo/deliberate-anti-pattern": "Pins the single front-end replica to zone ${PIN_ZONE} so run 1 is deterministic. Removed as part of the fix later in this tutorial - do not carry this pin into a real deployment."
       }
     },
     "spec": {
       "template": {
         "spec": {
           "affinity": {
             "nodeAffinity": {
               "requiredDuringSchedulingIgnoredDuringExecution": {
                 "nodeSelectorTerms": [
                   {
                     "matchExpressions": [
                       {"key": "topology.kubernetes.io/zone", "operator": "In", "values": ["${PIN_ZONE}"]}
                     ]
                   }
                 ]
               }
             }
           }
         }
       }
     }
   }
   EOF
   )"
   
   kubectl rollout restart deployment/store-front
   kubectl rollout status deployment/store-front --timeout=300s
   

3. Vérifiez que l’épinglage a bien été conservé : la réplique devrait être revenue sur un nœud dans $PIN_ZONE:

   STORE_NODE="$(kubectl get pods -l app=store-front -o jsonpath='{.items[0].spec.nodeName}')"
   STORE_ZONE="$(kubectl get node "$STORE_NODE" -o jsonpath="{.metadata.labels['topology\.kubernetes\.io/zone']}")"
   echo "Pod is in zone: $STORE_ZONE (expected $PIN_ZONE)"
   

   Si les deux valeurs ne correspondent pas, répétez l’étape précédente : l’exécution 1 ne sera pas déterministe tant qu’elles ne le feront pas.

Télécharger et lancer le moniteur de démonstration

Un watch uniquement dans le terminal kubectl est trop lent et passe facilement inaperçu lors d’une démo en direct. Le signal propre à la vitrine n’évolue pas en phase avec celui du groupe. Ce tutoriel utilise un petit script de surveillance Python à partir du référentiel d’exemples Chaos Studio comme moyen principal de regarder l’exécution.

1. Téléchargez le moniteur et le script de vérification des correctifs :

   curl -O https://raw.githubusercontent.com/microsoft/chaos-studio/f9573c943694e88cf3aacbca38debe84fa91a62c/samples/aks-zone-down-demo/monitor.py
   curl -O https://raw.githubusercontent.com/microsoft/chaos-studio/f9573c943694e88cf3aacbca38debe84fa91a62c/samples/aks-zone-down-demo/verify-fix.sh
   chmod +x verify-fix.sh
   

   Ces liens sont associés à un commit spécifique afin qu’ils continuent de fonctionner quelles que soient les modifications ultérieures apportées à l’exemple de code. Une fois la pull request concernée fusionnée, les révisions ultérieures de ce tutoriel pourront s’appuyer sur une version étiquetée à la place.

2. Démarrez le moniteur, pointant vers l’adresse IP externe de la vitrine et la zone que vous avez épinglée dans la section précédente :

   python3 monitor.py --storefront-url http://<EXTERNAL-IP> --target-zone "$PIN_ZONE"
   

   Le moniteur utilise uniquement la bibliothèque standard Python. Il n'y a donc rien d'autre à installer. Par défaut, il interroge toutes les 5 secondes : configurable avec --interval ou la variable d’environnement MONITOR_INTERVAL_SECONDS . Cette valeur par défaut est assez fréquente pour résoudre l’ordre des signaux sans interroger l’API Kubernetes ou la vitrine trop agressivement.

3. Dans Cloud Shell, sélectionnez Web Preview et définissez le port sur 8787 pour ouvrir le moniteur dans un onglet de navigateur. Si vous exécutez localement, ouvrez http://localhost:8787 plutôt.

   La page moniteur est désormais votre vue principale pour les deux exécutions. Il montre quatre signaux :

   • État HTTP de la boutique - une requête contournant le cache vers la boutique, afin d’afficher un état en temps réel indiquant si elle est accessible ou non, au lieu d’une réponse positive mise en cache.
   • État du nœud de zone cible - que le nœud de votre zone cible soit Ready ou NotReady.
   • Placement des pods frontaux - quels store-front pods sont en cours d’exécution et dans quelle zone chacun se trouve.
   • Historique de transition : chronologie en cours d’exécution de chaque changement d’état ci-dessus, avec horodatages, afin de pouvoir passer en revue la séquence après la fin de l’exécution au lieu de compter sur ce que vous avez remarqué en direct.

   Si une interrogation de kubectl ou de l’API Kubernetes échoue — par exemple, si le serveur API est brièvement inaccessible ou si le kubeconfig est obsolète —, le moniteur affiche une bannière rouge bien visible indiquant l’erreur, au lieu de laisser le signal concerné bloqué sur l’indication « vérification ». Le reste du tableau de bord continue d’afficher son dernier état valide connu ainsi que son historique tant que la bannière est affichée. Traitez la bannière comme un signal en son propre droit : cela signifie que le moniteur a perdu la visibilité, et non que la chose qu’il observe est saine.

Créer un espace de travail limité au groupe de ressources d’infrastructure

AKS place les groupes identiques de machines virtuelles des nœuds du cluster dans un groupe de ressources d’infrastructure distinct (dont le nom commence par MC_ par défaut), et non dans le groupe de ressources qui contient la ressource du cluster. Étendez l’espace de travail au groupe de ressources d’infrastructure afin qu’il découvre les nœuds. Pour l’arrière-plan, consultez Pourquoi un espace de travail étendu à votre cluster AKS ne trouve aucune cible de calcul.

1. Recherchez le nom du groupe de ressources d’infrastructure :

   az aks show --resource-group chaos-demo-rg --name chaos-demo-aks --query nodeResourceGroup -o tsv
   

2. Dans le portail Azure, recherchez Chaos Studio, sélectionnez Espaces de travail, puis Créez.

3. Sous l’onglet Informations de base , sélectionnez le chaos-demo-rg groupe de ressources, nommez l’espace de travail chaos-demo-workspaceet choisissez une région prise en charge. La région de l’espace de travail n’a pas besoin de correspondre à la région du cluster.

4. Sous l’onglet Étendue , sélectionnez Groupe de ressources comme type d’étendue, puis sélectionnez le groupe de ressources d’infrastructure à l’étape 1.

5. Sous l’onglet Identité , choisissez Affecté par le système.

6. Sélectionnez Vérifier + Créer>, puis accéder à la ressource.

   Une fois la découverte terminée, le groupe de machines virtuelles identiques de nœud du cluster (nommé comme aks-nodepool1-12345678-vmss) apparaît sous la forme d’une ressource découverte.

7. Si le portail affiche une bannière indiquant que l’identité ne dispose pas d’autorisations de lecture sur l’étendue de l’espace de travail, sélectionnez Attribuer le rôle Lecteur sur l’étendue de l’espace de travail. Pour créer des attributions de rôles, vous avez besoin de droits d’administrateur d’accès utilisateur ou propriétaire sur le groupe de ressources d’infrastructure.

Vous attribuez à l’identité les rôles dont le scénario lui-même a besoin dans la section suivante, où la validation vous indique exactement les éléments manquants. Pour obtenir une procédure pas à pas complète de chaque étape de création de l’espace de travail, consultez le guide de démarrage rapide de l’espace de travail.

Exécuter le scénario et surveiller l’échec de l’application

Le scénario Compute Zone Down simule une panne d’une zone de disponibilité en arrêtant les instances du groupe de machines virtuelles identiques dans la zone cible pendant la durée configurée. Les instances redémarrent lorsque la durée de l’action se termine.

1. Dans l’espace de travail, sélectionnez Scénarios, puis sélectionnez Zone de calcul vers le bas dans la bibliothèque de scénarios.

2. Configurez le scénario. Pour la zone de disponibilité, entrez le nombre à partir de $PIN_ZONE (la partie après le dernier trait d’union, par exemple 1 dans eastus2-1). Réglez la durée sur 5 minutes : c’est suffisamment long pour voir les signaux du storefront, du nœud et du pod se stabiliser, sans devoir attendre trop longtemps. Cette figure de 5 minutes est dimensionnée pour cette démonstration spécifique ; d’autres types de scénarios comportent leurs propres conseils de durée en fonction de ce qu’ils testent. Par exemple, un scénario basé sur le comportement de mise en cache DNS nécessite une durée suffisante pour dépasser la durée de vie du cache de l’enregistrement, ce qui peut être beaucoup plus long que 5 minutes. Sélectionnez Enregistrer la configuration.

3. La validation vérifie si l’identité managée de l’espace de travail peut effectuer chaque action dont le scénario a besoin sur les ressources cibles. Si la validation signale des autorisations manquantes, sélectionnez Corriger les autorisations dans la page de configuration du scénario pour accorder à l’identité les rôles intégrés recommandés. Dans ce scénario, il s’agit du rôle Contributeur de machine virtuelle au niveau du groupe de machines virtuelles identiques du nœud. Pour attribuer les rôles vous-même ou pour utiliser des rôles personnalisés avec des privilèges minimum plutôt que des rôles intégrés, consultez Autorisations et identité dans Chaos Studio Espaces de travail et Utiliser des rôles personnalisés avec des privilèges minimum avec des espaces de travail Chaos Studio.

   Si un rôle requis est toujours manquant au moment de l’exécution, l’exécution démarre de toute façon, mais les actions d’arrêt échouent avec une erreur d’autorisation dans le rapport de scénario.

4. Sélectionnez Exécuter et confirmer.

Il peut s’écouler quelques minutes après le démarrage de l’exécution pour que l’arrêt prenne effet, alors ne vous inquiétez pas si rien ne change immédiatement à l’écran. Surveillez ensuite la page de surveillance :

• Le signal HTTP du front-end et l’état du nœud cible ne changent pas au même moment. Le signal au niveau applicatif est ce que vos utilisateurs perçoivent réellement, et c’est celui qu’il faut considérer comme prioritaire ; les signaux du nœud et du pod ne sont que des indicateurs internes au cluster, qui ne se mettent à jour qu’ensuite. Attendez-vous à ce que la vitrine affiche « injoignable » bien avant que le nœud n’affiche NotReady : ce décalage est normal, il est dû à la propagation asynchrone du signal, et non à un problème de la démonstration.
• L’état du nœud cible passe à NotReady.
• Étant donné que le frontal est fixé à cette zone, son unique réplica ne peut s’exécuter nulle part ailleurs. La vitrine reste inaccessible jusqu’à ce que Kubernetes puisse replanifier le pod, qui, avec l’épingle en place, ne se produit qu’une fois le nœud cible retourné ou que vous modifiez la contrainte de placement. Ne vous fiez pas ici à une valeur fixe de durée d’indisponibilité ; consultez l’historique des transitions du moniteur afin de voir ce qui s’est réellement passé lors de votre exécution.

Ce résultat est la conclusion. Le cluster était redondant entre zones, mais le choix de placement de l’application a transformé une défaillance d’une zone en interruption de service sans échéance définie, tant que la contrainte restait en place. L’historique des changements d’état du moniteur de surveillance consigne précisément les moments où la boutique en ligne a été indisponible puis, plus tard, où elle a été de nouveau accessible.

Résolution des problèmes : l’impact n’est pas visible

Si le moniteur indique que la boutique en ligne reste accessible pendant toute l’exécution 1, vérifiez ces éléments avant de supposer que le scénario n’a pas fonctionné :

• Vérifiez que la broche a pris effet. Exécutez kubectl get pods -l app=store-front -o wide et vérifiez que le nœud du pod est dans $PIN_ZONE. Si le correctif n’a pas été appliqué, le planificateur a peut-être placé la réplique ailleurs. Une simple reprogrammation pendant la panne peut être si rapide que vous pouvez passer à côté sans le repère.
• Vérifiez que le moniteur surveille la zone et l’URL appropriées. Redémarrez monitor.py avec la valeur exacte --target-zone et l’URL de vitrine de votre cluster. Une valeur obsolète ou mal typée indique un état « sain » trompeur.
• Consultez le rapport du scénario pour voir les actions Skipped. Si les actions d’arrêt affichent Skipped au lieu de Succeeded, l’opération n’a trouvé aucune cible correspondante dans la zone cible. Consultez Interpréter les résultats.
• Donnez-lui quelques secondes de plus. L’opération d’arrêt proprement dite met un certain temps à prendre effet une fois l’exécution démarrée. L’historique de transition du moniteur affiche les horodatages exacts une fois qu’ils se produisent.

Corriger le déploiement et le vérifier

Remplacez maintenant la broche à zone unique délibérée par un correctif réel à l’échelle du cluster : trois réplicas, difficilement limités à un par zone.

1. Supprimez le repère de zone que vous avez ajouté précédemment :

   kubectl patch deployment store-front --type=merge --patch '{"spec":{"template":{"spec":{"affinity":null}}}}'
   

2. Mettez à l’échelle le serveur frontal sur trois réplicas et ajoutez une contrainte de propagation de topologie qui nécessite un réplica par zone au lieu de le préférer simplement :

   kubectl patch deployment store-front --patch '{"spec":{"replicas":3,"template":{"spec":{"topologySpreadConstraints":[{"maxSkew":1,"topologyKey":"topology.kubernetes.io/zone","whenUnsatisfiable":"DoNotSchedule","labelSelector":{"matchLabels":{"app":"store-front"}}}]}}}}'
   

   whenUnsatisfiable: DoNotSchedule fait de la répartition d’une réplique par zone une exigence stricte. Une réplique qui ne peut pas la satisfaire reste sur Pending au lieu de se retrouver dans une zone qui en a déjà une. C’est un compromis délibéré : il garantit la couverture des zones dont ce test dépend, au prix du risque qu’un réplica reste non planifié si une zone manque temporairement de capacité. ScheduleAnyway permettrait au planificateur d’ignorer la contrainte en cas de forte charge, ce qui correspond précisément au scénario de défaillance auquel ce correctif remédie.

3. Vérifiez le correctif avant de l’approuver. Exécutez le script de vérification. Il attend la fin du déploiement afin que les pods obsolètes de l’ancienne révision à une seule réplique ne soient pas comptés, puis confirme que chaque zone dispose d’au moins un pod Readystore-front :

   ./verify-fix.sh
   

   Un kubectl appel, une demande d’API ou le JSON qu’il retourne peut échouer temporairement - un court délai d’attente, une connexion supprimée - sans signification que le correctif lui-même a échoué. Le script réessaie ces erreurs transitoires jusqu’à expiration de son propre délai d’attente, au lieu de s’arrêter dès la première. Ce n’est qu’après l’expiration de ce délai qu’il se termine avec un code de retour non nul et un message de diagnostic indiquant quelle zone ne dispose toujours pas d’une réplique prête. Ne passez pas à la deuxième exécution tant que la précédente n’a pas réussi. Un résultat positif est ce qui fait de « un réplica par zone » un fait avéré plutôt qu’une hypothèse déduite de la commande patch.

Réexécutez le scénario et comparez

1. Dans l’espace de travail, exécutez de nouveau le scénario Compute Zone Down avec la même zone cible et la même durée de 5 minutes.

2. Regardez le moniteur. Le nœud cible tombe toujours en panne NotReady et entraîne sa réplique store-front dans sa chute, mais la boutique en ligne continue de répondre, grâce aux répliques situées dans les zones survivantes. L’affirmation testée est une disponibilité maintenue malgré la panne de zone, démontrée par l’historique continu du moniteur — et non l’absence totale de requêtes abandonnées, ni le fait que le moniteur affiche un état sain ininterrompu du début à la fin. Une brève interruption reste possible pendant qu’Azure Load Balancer bascule vers les réplicas sains restants ; un test ponctuel montre une brève perturbation de convergence, et non une panne durant toute la durée de la perturbation. La durée de la convergence varie selon l’environnement. Par conséquent, ne reposez pas sur une limite de temps fixe : utilisez l’historique de transition du moniteur pour indiquer un blip temporaire en dehors d’une panne soutenue.

Les composants à une seule réplique peuvent néanmoins subir une brève interruption. Si le nœud de la file d’attente RabbitMQ se trouve dans la zone cible, la soumission des commandes est ralentie pendant que son pod se rétablit. Trouver le maillon faible suivant et décider s’il vaut la peine de le corriger, c’est précisément la boucle que les tests de chaos visent à alimenter.

Comparer les rapports de scénario

1. Dans l’espace de travail, sélectionnez Historique des exécutions. Vous disposez maintenant de deux exécutions terminées du même scénario.

2. Sélectionnez chaque exécution, puis sélectionnez Générer un rapport. Vérifiez que les actions d’arrêt affichent le statut Réussi dans les deux cas, ce qui signifie que chaque exécution a trouvé et interrompu des instances dans la zone cible. Si les actions sont ignorées, l’exécution n’a trouvé aucune cible correspondante. Les causes habituelles sont une étendue qui n’inclut pas le groupe de ressources d’infrastructure ou une zone cible sans nœuds. Pour plus d’informations, consultez Tester la résilience des charges de travail sur AKS avec Chaos Studio.

3. Notez que les deux rapports semblent identiques même si les résultats de l’application étaient opposés. Réussite signifie que la perturbation a bien été exécutée - cela ne signifie pas que l’application a continué à fonctionner correctement. Le rapport prouve quelles perturbations se sont produites et quand ; l’historique de transition du moniteur est ce qui prouve le comportement de l’application en réponse. Associer les deux permet de transformer une exécution en élément de preuve : le rapport horodate la défaillance, et le moniteur montre la différence avant et après l’application du correctif.

Vous pouvez télécharger les deux rapports comme pièces justificatives avant/après dans le cadre des examens de résilience. Pour plus d’informations, consultez les rapports de scénario.

Nettoyer les ressources

Supprimez le groupe de ressources pour supprimer le cluster, l’exemple d’application et l’espace de travail. La suppression du cluster supprime également son groupe de ressources d’infrastructure.

az group delete --name chaos-demo-rg --yes --no-wait

Signaler des problèmes et des fonctionnalités de demande

Azure Chaos Studio est développé dans l’open. Pour signaler un bogue, demander une fonctionnalité ou poser une question sur les espaces de travail, les scénarios ou l’extension Azure CLI, ouvrez un problème dans le référentiel Chaos Studio sur GitHub. En plaçant un problème, vous pouvez suivre sa progression et voir les demandes d’autres clients.

Étapes suivantes

• Testez la résilience des charges de travail sur AKS avec Chaos Studio couvre les mises en garde et les conseils d’interprétation pour l’exécution de ce test sur une charge de travail réelle.
• Pour rendre la réussite ou l’échec objectifs pour une charge de travail réelle, associez les exécutions de scénario à des tests de disponibilité Application Insights et à vos propres indicateurs de niveau de service, plutôt qu’à un onglet de navigateur.
• Tutoriel : Exécuter un scénario de basculement PostgreSQL en cas de panne de zone ajoute un basculement de la couche de données au même scénario de panne.
• Les scénarios de Azure Chaos Studio décrivent la bibliothèque de scénarios complète.
• Le référentiel Chaos Studio GitHub contient des scripts de déploiement pour cet exemple (y compris les scripts de surveillance et de vérification utilisés dans ce didacticiel), des scénarios personnalisés partageables et un plug-in CLI Copilot pour conduire Chaos Studio à partir de GitHub Copilot.