Planifiez vos AWS expériences FIS - AWS Service d'injection de défauts

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.

Planifiez vos AWS expériences FIS

L'injection de défauts est le processus qui consiste à stresser une application dans des environnements de test ou de production en créant des événements perturbateurs, tels que des pannes de serveur ou une limitation des API. En observant la façon dont le système réagit, vous pouvez ensuite mettre en œuvre des améliorations. Lorsque vous effectuez des tests sur votre système, cela peut vous aider à identifier les faiblesses systémiques de manière contrôlée, avant que ces faiblesses n'affectent les clients qui dépendent de votre système. Vous pouvez ensuite résoudre les problèmes de manière proactive afin d'éviter des résultats imprévisibles.

Avant de commencer à exécuter des expériences d'injection de défauts à l'aide du AWS FIS, nous vous recommandons de vous familiariser avec les principes et directives suivants.

Important

AWSFIS réalise des actions réelles sur les AWS ressources réelles de votre système. Par conséquent, avant de commencer à utiliser AWS FIS pour exécuter des expériences, nous vous recommandons vivement de terminer une phase de planification et un test dans un environnement de pré-production ou de test.

Principes de base et directives

Avant de commencer les expériences avec le AWS FIS, suivez les étapes suivantes :

  1. Identifier le déploiement cible pour l'expérience : commencez par identifier le déploiement cible. S'il s'agit de votre première expérience, nous vous recommandons de commencer dans un environnement de pré-production ou de test.

  2. Passez en revue l'architecture de l'application : vous devez vous assurer d'avoir identifié tous les composants de l'application, les dépendances et les procédures de restauration pour chaque composant. Commencez par examiner l'architecture de l'application. En fonction de l'application, reportez-vous au AWSWell-Architected Framework.

  3. Définissez un comportement permanent : définissez le comportement permanent de votre système en termes de paramètres techniques et commerciaux importants, tels que la latence, la charge du processeur, les échecs de connexion par minute, le nombre de tentatives ou la vitesse de chargement des pages.

  4. Formuler une hypothèse — Formez une hypothèse sur la façon dont vous vous attendez à ce que le comportement du système change au cours de l'expérience. La définition d'une hypothèse suit le format suivant :

    Si une action d'injection de défauts est effectuée, l'impact des mesures commerciales ou techniques ne doit pas dépasser la valeur.

    Par exemple, l'hypothèse d'un service d'authentification peut se lire comme suit : « Si la latence du réseau augmente de 10 %, le nombre d'échecs de connexion augmente de moins de 1 % ». Une fois l'expérience terminée, vous évaluez si la résilience de l'application correspond à vos attentes commerciales et techniques.

Nous vous recommandons également de suivre les directives suivantes lorsque vous travaillez avec AWS FIS :

  • Commencez toujours à expérimenter avec AWS FIS dans un environnement de test. Ne commencez jamais par un environnement de production. Au fur et à mesure que vous progressez dans vos expériences d'injection de défauts, vous pouvez expérimenter dans d'autres environnements contrôlés que l'environnement de test.

  • Renforcez la confiance de votre équipe dans la résilience de vos applications en commençant par de petites expériences simples, telles que l'exécution de l'action aws:ec2:stop-instances sur une cible.

  • L'injection de défauts peut entraîner de réels problèmes. Procédez avec prudence et assurez-vous que vos premières injections de défauts se font sur des instances de test afin qu'aucun client ne soit affecté.

  • Testez, testez et testez encore. L'injection de défauts est destinée à être mise en œuvre dans un environnement contrôlé avec des expériences bien planifiées. Cela vous permet de renforcer votre confiance dans les capacités de votre application et de vos outils à résister à des conditions turbulentes.

  • Nous vous recommandons vivement de mettre en place un excellent programme de surveillance et d'alerte avant de commencer. Sans cela, vous ne serez pas en mesure de comprendre ou de mesurer l'impact de vos expériences, ce qui est essentiel pour des pratiques durables d'injection de défauts.

Directives de planification des expériences

Avec AWS FIS, vous réalisez des expériences sur vos AWS ressources afin de tester votre théorie sur le fonctionnement d'une application ou d'un système en cas de panne.

Les directives suivantes sont recommandées pour la planification de vos expériences AWS FIS.

  • Consultez l'historique des pannes : passez en revue les pannes et les événements précédents de votre système. Cela peut vous aider à vous faire une idée de l'état général et de la résilience de votre système. Avant de commencer à effectuer des tests sur votre système, vous devez résoudre les problèmes et faiblesses connus de votre système.

  • Identifiez les services ayant le plus d'impact — Passez en revue vos services et identifiez ceux qui ont le plus d'impact sur vos utilisateurs finaux ou vos clients s'ils tombent en panne ou ne fonctionnent pas correctement.

  • Identifier le système cible — Le système cible est le système sur lequel vous allez exécuter des expériences. Si vous utilisez AWS FIS pour la première fois ou si vous n'avez jamais effectué d'expériences d'injection de défauts auparavant, nous vous recommandons de commencer par exécuter des expériences sur un système de pré-production ou de test.

  • Consultez votre équipe — Demandez-lui ce qui l'inquiète. Vous pouvez formuler une hypothèse pour prouver ou réfuter leurs inquiétudes. Vous pouvez également demander à votre équipe ce qui ne l'inquiète pas. Cette question peut révéler deux erreurs courantes : l'erreur des coûts irrécupérables et l'erreur du biais de confirmation. L'élaboration d'une hypothèse basée sur les réponses de votre équipe peut aider à fournir plus d'informations sur la réalité de l'état de votre système.

  • Passez en revue l'architecture de votre application : passez en revue votre système ou votre application et assurez-vous d'avoir identifié tous les composants de l'application, les dépendances et les procédures de restauration pour chaque composant.

    Nous vous recommandons de consulter le AWS Well-Architected Framework. Le framework peut vous aider à créer une infrastructure sécurisée, performante, résiliente et efficace pour vos applications et vos charges de travail. Pour plus d’informations, veuillez consulter AWS Bien architecturé.

  • Identifiez les métriques applicables — Vous pouvez surveiller l'impact d'un test sur vos AWS ressources à l'aide des CloudWatch métriques Amazon. Vous pouvez utiliser ces mesures pour déterminer le niveau de référence ou « état stable » lorsque votre application fonctionne de manière optimale. Vous pouvez ensuite surveiller ces mesures pendant ou après l'expérience afin d'en déterminer l'impact. Pour plus d’informations, consultez Surveillez les statistiques d'utilisation duAWS FIS à l'aide d'Amazon CloudWatch.

  • Définissez un seuil de performance acceptable pour votre système : identifiez la métrique qui représente un état stable acceptable pour votre système. Vous allez utiliser cette métrique pour créer une ou plusieurs CloudWatch alarmes représentant une condition d'arrêt pour votre expérience. Si l'alarme est déclenchée, l'expérience est automatiquement arrêtée. Pour plus d'informations, consultez Conditions d'arrêt pour AWS FIS.