Planification de votre AWS FISexpériences - AWS Service d'injection de défauts
Principes de base et directivesDirectives de planification des expériences

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.

Planification de votre AWS FISexpériences

L'injection de défauts est le processus qui consiste à mettre une application sous pression dans des environnements de test ou de production en créant des événements perturbateurs, tels que des pannes de serveur ou des ralentissementsAPI. 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 de AWS FIS, nous vous recommandons de vous familiariser avec les principes et directives suivants.

Important

AWS FISréalise des actions réelles sur de vraies AWS les ressources de votre système. Par conséquent, avant de commencer à utiliser AWS FISpour effectuer des expériences, nous vous recommandons vivement de commencer par effectuer une phase de planification et un test dans un environnement de pré-production ou de test.

Principes de base et directives

Avant de commencer des expériences avec 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 AWS Framework Well-Architected.

  3. Définissez le comportement permanent : définissez le comportement permanent de votre système en termes de paramètres techniques et commerciaux importants, tels que la latence, le CPU chargement, 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 :

    If fault injection action est effectué, le business or technical metric impact ne doit pas dépasser value.

    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 ces directives lorsque vous travaillez avec AWS FIS:

  • Commencez toujours à expérimenter avec AWS FISdans 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 votre AWS des ressources pour 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 planifier votre AWS FISexpériences.

  • 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 êtes nouveau dans AWS FISou 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 Framework Well-Architected. 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, consultez .AWS Well-Architected.

  • Identifiez les indicateurs applicables — Vous pouvez surveiller l'impact d'une expérience sur votre AWS ressources utilisant CloudWatch les 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 de plus amples informations, veuillez consulter 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 de plus amples informations, veuillez consulter Conditions d'arrêt pour AWS FIS.