Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Cycle de vie continu des expériences d'ingénierie du chaos

Comme indiqué dans la section précédente, vous pouvez implémenter des expériences d'ingénierie du chaos de différentes manières. Dans tous les cas, pour créer une expérience de chaos significative, il est essentiel de comprendre l'application, les incidents historiques et les mesures correctives mises en œuvre, ainsi que de bien comprendre les domaines à étudier, tels que la résilience ou la sécurité. Votre connaissance de l'application vous aide à formuler une hypothèse sur les faiblesses potentielles de l'application et à comprendre comment elle détectera, corrigera et réparera une fois le défaut injecté.

Le cycle de vie d'une expérience sur le chaos comprend les étapes suivantes :

Ces étapes sont illustrées dans le schéma et décrites dans les sections suivantes.

Définissez les objectifs et les attentes

Avant chaque expérience, assurez-vous que vos objectifs et vos attentes sont spécifiques, mesurables, réalisables, pertinents et limités dans le temps. Définissez clairement ce qui suit :

Sélectionnez l'application cible

L'ingénierie du chaos est une technique puissante, mais elle nécessite une hiérarchisation réfléchie pour maximiser la valeur. Lorsque vous décidez où concentrer les efforts d'ingénierie du chaos, commencez par prendre en compte les services essentiels de votre entreprise. Demandez à vos équipes de suivre les étapes du cycle de vie du développement logiciel et de commencer par injecter des défauts dans les environnements de test. Les applications critiques pour l'entreprise sont directement liées au chiffre d'affaires, à l'expérience client et aux activités principales. Les expériences chaotiques menées sur ces services peuvent révéler des vulnérabilités susceptibles d'avoir de graves répercussions sur l'entreprise, voire sur des marchés entiers, si elles ne sont pas corrigées. Par exemple, concentrez-vous d'abord sur les services destinés aux clients, tels que les systèmes de négociation ou les systèmes de commande. La priorisation de ces services centraux offre la meilleure protection par investissement de temps.

Après les services essentiels, examinez les composants fondamentaux tels que les bases de données, les files d'attente de messages, les réseaux et les services partagés. APIs Ils peuvent être utilisés en tant que composants ou services partagés au sein de votre organisation, de sorte que leur défaillance entraînera des problèmes généralisés. Confirmer la résilience des services d'infrastructure garantit qu'ils ne paralyseront pas les applications dépendantes situées au-dessus d'eux. Par exemple, une expérience d'ingénierie du chaos qui détruit un cluster Kafka en dit long sur la tolérance aux pannes des applications en aval. Bien que l'infrastructure du système ne soit pas directement orientée vers le client, elle constitue une cible privilégiée de l'ingénierie du chaos.

N'oubliez pas de cartographier les lacunes mentales liées aux personnes, aux processus, aux informations sur les installations et aux dépendances avec des tiers, car elles peuvent provoquer des perturbations majeures si elles ne sont pas conformes aux objectifs de tolérance aux impacts de votre organisation. Pour plus d'informations sur la mesure du retour sur investissement de l'ingénierie du chaos, consultez la section Quantifier le retour sur investissement de l'ingénierie du chaos dans le document de stratégie Investir dans l'ingénierie du chaos en tant que nécessité stratégique.

Le schéma suivant montre le retour sur investissement lié à l'exécution d'expériences de chaos sur différents niveaux de services.

Aligner des cartes mentales (découverte d'applications)

Lorsque vous lancez des expériences ad hoc ou des journées de jeu, vous commencez le processus de découverte des applications en organisant une session de tableau blanc qui vise à cartographier les détails de votre application. (Si vous exécutez les expériences dans le pipeline du chaos, vous aurez déjà aligné cette carte mentale en définissant l'application cible.) Une bonne approche pour comprendre les lacunes mentales consiste à demander au membre le plus subalterne de l'équipe de dessiner d'abord un schéma de l'application, puis de demander aux membres du personnel plus expérimentés d'ajouter progressivement des éléments au schéma. Cela permettra de découvrir toute lacune dans la compréhension entre les niveaux d'expérience.

Le diagramme doit décrire à la fois les dépendances directes en amont et en aval de l'application, ainsi que toutes les intégrations tierces critiques. Assurez-vous que le flux attendu d'une demande dans l'application est aligné. Cartographiez les principaux flux de travail et les parcours des utilisateurs pour mieux comprendre comment les clients utilisent l'application. Envisagez d'utiliser un diagramme de séquence pour saisir ces informations.

À l'issue de cette session collaborative, l'équipe devrait disposer d'un modèle mental commun de l'application, de ses dépendances critiques et de ses capacités de surveillance, ainsi que d'une compréhension des risques pour prendre une décision éclairée de poursuivre ou d'annuler une expérience de chaos potentielle.

Résoudre les problèmes connus liés à votre application

Les expériences d'ingénierie du chaos sont conçues pour détecter de manière proactive les défauts d'une application. En injectant des défaillances telles que des augmentations de latence, des redémarrages de serveurs ou des pannes d'alimentation dans la zone de disponibilité, vous pouvez vérifier la capacité de votre application à tolérer des perturbations réalistes. Toutefois, ce processus suppose un niveau sous-jacent de stabilité et de santé dans l'application cible. Mener des expériences chaotiques sur une application déjà problématique risque de masquer des problèmes plus profonds.

Avant d'entreprendre une ingénierie du chaos, les équipes doivent résoudre tous les défauts, bogues et problèmes de performance connus de leur application.

Définir l'hypothèse et l'expérience

Les incidents passés qui ont perturbé votre application ou d'autres applications au sein de votre organisation peuvent constituer d'excellentes sources d'idées d'expériences chaotiques. Par exemple, les pannes précédentes ont-elles été déclenchées par des erreurs de configuration ou par l'absence de modèles de résilience ? L'examen de l'historique des incidents et la redécouverte des causes profondes de ces défaillances réelles par le biais d'expériences chaotiques constituent un moyen efficace de développer la résilience face à des problèmes similaires à l'avenir.

Une autre source précieuse de concepts d'expérimentation peut provenir directement des ingénieurs, des architectes et des opérateurs qui connaissent le mieux une application. Permettre aux membres de l'équipe de soumettre des scénarios de défaillance hypothétiques qui, selon eux, pourraient perturber considérablement l'application vous permet de recueillir des idées basées sur des connaissances privilégiées. L'équipe chargée de l'application peut ensuite évaluer lequel de ces scénarios proposés est susceptible d'avoir l'impact potentiel le plus important ou d'exposer les plus grands risques inconnus. Cibler les expériences de chaos pour des scénarios aussi risqués et mal compris peut générer des enseignements importants et prévenir des problèmes à l'avenir.

Une troisième source d'idées provient de la modélisation de la résilience pour anticiper les conditions susceptibles d'entraîner des pertes commerciales identifiées. Certains exercices de modélisation de la résilience ont une approche basée sur les composants pour créer un modèle de résilience, tandis que d'autres ont une approche basée sur les systèmes. Une approche basée sur les composants pose la question suivante : « Que se passe-t-il lorsque le composant x est soumis à une charge extrême ou est défaillant ? » L'équipe qui développe le modèle de résilience émet ensuite des hypothèses sur l'effet d'un tel scénario sur l'application au sens large et identifie les contrôles de surveillance et de prévention actuellement en place pour détecter et atténuer les effets du scénario. Une approche basée sur les systèmes suit un processus descendant pour mettre en évidence un état indésirable de l'application, tel que « La vitrine Web affiche des niveaux d'inventaire périmés », et invite l'équipe chargée de l'application à anticiper la ou les conditions susceptibles de provoquer un tel comportement de l'application.

Garantir l'état de préparation opérationnelle pour l'expérience

Vous avez besoin d'indicateurs quantifiables pour mesurer l'impact des conditions défavorables sur l'application et son comportement, comme décrit précédemment dans la section consacrée à l'observabilité. Le fait de pouvoir mesurer le comportement de l'application vous permet de déterminer si les conditions défavorables ont eu un impact sur l'application et dans quelle mesure.

La meilleure façon de déterminer si votre application a un impact est de mesurer son état d'équilibre. Le régime permanent mesure à quoi ressemble le fonctionnement normal et s'aligne généralement sur les indicateurs commerciaux et d'expérience client pour une application donnée. Avant de passer à l'étape suivante, assurez-vous de disposer de l'observabilité nécessaire pour comprendre l'impact et de disposer de mécanismes de réduction au cas où l'expérience ne se déroulerait pas comme prévu.

Exécutez des expériences et des scénarios contrôlés

Chez AWS, nous vous déconseillons de mener une première expérience de chaos sur une application en production. Le but d'une expérience de chaos est d'apprendre quelque chose de nouveau sur le comportement de l'application dans des conditions stressantes. Le comportement de l'application peut être imprévisible au cours de l'expérience, de sorte que la réalisation d'une expérience pour la première fois en production peut avoir un impact sur le client. Par conséquent, vous devez toujours exécuter une première expérience de chaos dans un environnement de niveau inférieur présentant un risque minimal d'affecter les utilisateurs du monde réel, puis parcourir vos environnements une fois que vous avez vérifié et que vous êtes certain que votre application peut absorber les actions injectées, s'y adapter et s'en remettre.

Planifiez minutieusement chaque expérience à l'aide d'un document qui capture les détails clés, similaire au document de planification de l'expérience fourni en annexe. Certains des domaines critiques à inclure sont la définition de l'état stationnaire, l'hypothèse et la méthode d'injection des défaillances. La planification, l'exécution et l'analyse d'une expérience de chaos peuvent être couvertes par un seul artefact.

Après avoir finalisé le plan écrit pour l'expérience, préparez le code nécessaire pour injecter les perturbations planifiées décrites dans le document.

Pour saisir l'impact potentiel pendant l'expérience, assurez-vous que les mécanismes d'observabilité sont en place. Si vous ne disposez pas encore d'un moyen automatique pour capturer les résultats des expériences, tels que des rapports d' AWS FIS expérimentation, identifiez les membres de l'équipe qui prendront des notes pendant l'exécution, capturez des captures d'écran des tableaux de bord et dirigerez l'équipe tout au long de l'expérience.

Apprenez et peaufinez

Après chaque expérience, réunissez-vous en équipe pour passer en revue l'expérience du chaos et y réfléchir. Faites un effort conscient pour maintenir un état d'esprit irréprochable. Votre objectif doit être d'avoir un dialogue ouvert et constructif entièrement axé sur l'apprentissage maximal, et non sur le blâme.

Commencez par revoir la définition de l'état d'équilibre et l'hypothèse de l'expérience. L'application s'est-elle comportée comme prévu ? Y a-t-il eu des surprises qui ont invalidé les hypothèses ? Discutez des observations sur la façon dont l'application a réagi au cours de l'expérience, qu'elle soit positive ou négative. Les données collectées (métriques, journaux, captures d'écran, etc.) devraient raconter exactement ce qui s'est passé.

Abordez cet examen des données avec curiosité plutôt qu'avec jugement, et identifiez les domaines dans lesquels des améliorations peuvent être apportées à la conception des applications, à la documentation, à la surveillance ou à d'autres capacités sur la base des enseignements tirés. Ces actions sont capturées sous forme de projets de suivi afin de rendre l'application plus résiliente.

Grâce à cette approche irréprochable, vous pouvez avoir des conversations franches sur ce qui n'a pas fonctionné et comment vous pouvez y remédier. Supposez que toutes les personnes impliquées ont une intention positive et ayez la certitude qu'elles ont travaillé pour obtenir de bons résultats. Votre objectif commun est la croissance et la progression de l'organisation grâce à l'apprentissage continu et à l'adaptation. Les évaluations d'expériences Chaos menées de manière constructive et irréprochable offrent à votre équipe un espace sûr où elle peut obtenir des informations précieuses qui rendront vos applications et votre organisation plus fiables et résilientes sur le long terme. L'accent reste mis sur les apprentissages, pas sur les personnes. Pour diffuser les enseignements au sein de vos équipes, publiez le rapport sur les résultats de l'expérience dans un endroit central et publiez les résultats afin que d'autres puissent en tirer des enseignements.