# Bonnes pratiques **Topics** + [Fondations](rel-found.md) + [Architecture de charge de travail](rel-workload-arch.md) + [Gestion des modifications](rel-chg-mgmt.md) + [Gestion des défaillances](rel-failmgmt.md) # Fondations Les exigences de base sont celles dont le champ d'application s'étend au-delà d'une seule charge de travail ou d'un seul projet. Avant de concevoir l'architecture d'un système, les exigences de base qui influent sur la fiabilité doivent être mises en place. Par exemple, vous devez avoir une bande passante réseau suffisante pour votre centre de données. Avec AWS, la plupart de ces exigences élémentaires sont déjà intégrées ou sont gérées au cas par cas. Le cloud est conçu pour être presque illimité. Il est donc de la responsabilité d'AWS de satisfaire l'exigence d'une capacité suffisante de mise en réseau et de calcul, ce qui vous laisse la liberté de modifier la taille des ressources et les allocations à la demande. Les questions suivantes sont axées sur ces quelques considérations relatives à la fiabilité. (Pour obtenir la liste des questions et bonnes pratiques liées à la fiabilité, consultez l' [Annexe](a-reliability.md).) | REL 1 : Comment gérer les quotas et les contraintes de service ? | | --- | | Pour les architectures de charge de travail basées sur le cloud, il existe des quotas de service (aussi appelés Service Limits). Le rôle de ces quotas est d'empêcher la mise en service accidentelle de plus de ressources que nécessaire et de limiter les taux de demandes sur les opérations d'API afin de protéger les services contre les abus. Il existe également des contraintes de ressource. Par exemple, la vitesse à laquelle vous pouvez transmettre des bits sur un câble de fibre optique, ou la quantité de stockage sur un disque physique. | | REL 2 : Comment planifier la topologie de votre réseau ? | | --- | | Les charges de travail existent souvent dans plusieurs environnements. Il s'agit notamment de plusieurs environnements cloud (accessibles publiquement et privés) et éventuellement de votre infrastructure de centre de données existante. Les plans doivent inclure des considérations réseau telles que la connectivité intrasystème et intersystème, la gestion des adresses IP publiques, la gestion des adresses IP privées et la résolution des noms de domaine. | Pour les architectures de charge de travail basées sur le cloud, il existe des quotas de service (aussi appelés Service Limits). Ces quotas visent à empêcher la mise en service accidentelle de plus de ressources que nécessaire et à limiter les taux de requêtes sur les opérations d'API pour protéger les services contre les abus. Les charges de travail existent souvent dans plusieurs environnements. Vous devez surveiller et gérer ces quotas pour tous les environnements de charge de travail. Il s'agit notamment de plusieurs environnements cloud (accessibles publiquement et privés) et peuvent inclure votre infrastructure de centre de données existante. Les plans doivent tenir compte de facteurs liés au réseau : connectivité intrasystème et intersystème, gestion des adresses IP publiques, gestion des adresses IP privées et résolution des noms de domaine. # Architecture de charge de travail Pour garantir la fiabilité d'une charge de travail, il faut commencer par choisir le bon logiciel et la bonne infrastructure. Vos choix d'architecture ont un impact sur le comportement des charges de travail sur les différents piliers Well-Architected. Pour des raisons de fiabilité, vous devez suivre des modèles spécifiques. Avec AWS, les développeurs de charges de travail peuvent choisir les langages et les technologies à utiliser. Les kits SDK AWS éliminent la complexité du codage en fournissant des API propres au langage pour les services AWS. Ces kits SDK, ainsi que le choix des langages, permettent aux développeurs de mettre en œuvre les bonnes pratiques de fiabilité répertoriées ici. Les développeurs peuvent également découvrir comment Amazon conçoit et exploite des logiciels dans [l'Amazon Builders' Library](https://aws.amazon.com/builders-library/?ref=wellarchitected-wp). Les questions suivantes sont axées sur ces quelques considérations relatives à la fiabilité. | REL 3 : Comment concevoir l'architecture de service de votre charge de travail ? | | --- | | Créez des charges de travail hautement évolutives et fiables à l'aide d'une architecture orientée service (SOA) ou d'une architecture de microservices. La SOA consiste à rendre les composants logiciels réutilisables via les interfaces de service. L'architecture des microservices va plus loin, en particulier en rendant les composants plus petits et plus simples. | | REL 4 : Comment concevoir des interactions dans un système distribué pour éviter les défaillances ? | | --- | | Les systèmes distribués s'appuient sur des réseaux de communication pour interconnecter des composants comme des serveurs ou des services. Votre charge de travail doit fonctionner de manière fiable malgré la perte de données ou la latence dans ces réseaux. Les composants du système distribué doivent fonctionner d'une manière qui n'a pas d'impact négatif sur les autres composants ou la charge de travail. Ces bonnes pratiques empêchent les défaillances et améliorent le temps moyen entre les défaillances (MTBF). | | REL 5 : Comment concevoir des interactions dans un système distribué pour atténuer ou résister aux défaillances ? | | --- | | Les systèmes distribués s'appuient sur des réseaux de communication pour interconnecter des composants (tels que des serveurs ou des services). Votre charge de travail doit fonctionner de manière fiable malgré la perte de données ou la latence sur ces réseaux. Les composants du système distribué doivent fonctionner d'une manière qui n'a pas d'impact négatif sur les autres composants ou la charge de travail. Ces bonnes pratiques permettent aux charges de travail de résister aux contraintes ou aux défaillances, de s'en remettre plus rapidement et d'atténuer l'impact de ces déficiences. Il en résulte une amélioration du temps moyen de récupération (MTTR). | # Gestion des modifications Les modifications apportées à votre charge de travail ou à son environnement doivent être anticipées et prises en compte pour assurer un fonctionnement fiable de la charge de travail. Les modifications incluent celles imposées à votre charge de travail telles que les pics de demande, ainsi que celles venant de l'intérieur comme les déploiements de fonctions et l'installation de correctifs de sécurité. Avec AWS, vous pouvez surveiller le comportement d'une charge de travail et automatiser la réponse aux KPI. Par exemple, votre charge de travail peut ajouter des serveurs supplémentaires à mesure que des utilisateurs supplémentaires s'y ajoutent. Vous pouvez contrôler les personnes qui ont l'autorisation d'apporter des modifications à la charge de travail et auditer l'historique de ces modifications. Les questions suivantes sont axées sur ces quelques considérations relatives à la fiabilité. | REL 6 : Comment surveiller les ressources de charges de travail ? | | --- | | Les journaux et les métriques sont de puissants outils pour obtenir informations sur l'état de votre charge de travail. Vous pouvez configurer votre charge de travail de sorte à surveiller les journaux et les métriques et envoyer des notifications lorsque les seuils sont franchis ou que des événements significatifs se produisent. La surveillance permet à votre charge de travail de reconnaître quand des seuils de faible performance sont franchis ou quand des défaillances se produisent, en vue de sa reprise automatique. | | REL 7 : Comment concevoir votre charge de travail pour qu'elle s'adapte aux changements de demande ? | | --- | | Une charge de travail évolutive fournit l'élasticité nécessaire pour ajouter ou supprimer automatiquement des ressources de telle sorte qu'elles correspondent étroitement à tout moment à la demande en cours. | | REL 8 : Comment implémenter les modifications ? | | --- | | Des modifications contrôlées sont nécessaires pour au moins deux raisons : déployer de nouvelles fonctionnalités et s'assurer que les charges de travail et l'environnement d'exploitation fonctionnent avec des logiciels connus et peuvent être corrigés ou remplacés de manière prévisible. Si les modifications ne sont pas contrôlées, il est difficile de prédire leur effet ou de résoudre les problèmes qui en découlent. | Lorsque vous concevez l'architecture d'une charge de travail de manière à ajouter ou supprimer automatiquement des ressources en réponse à l'évolution de la demande, cela accroît la fiabilité et garantit que la réussite commerciale ne devient pas un poids. Une fois la surveillance en place, votre équipe est automatiquement avertie lorsque les KPI cessent de correspondre aux valeurs attendues. La journalisation automatique des modifications apportées à votre environnement vous permet d'auditer et d'identifier rapidement les actions susceptibles d'avoir un impact sur la fiabilité. Les contrôles de la gestion des modifications permettent de s'assurer que vous appliquez les règles offrant la fiabilité dont vous avez besoin. # Gestion des défaillances Les pannes sont à prévoir dans tout système présentant un niveau de complexité raisonnable. Pour que votre charge de travail soit fiable, vous devez avoir connaissance des défaillances au moment où elles se produisent et prendre des mesures pour éviter qu'elles aient un impact sur la disponibilité des services. Les charges de travail doivent être en mesure de résister aux défaillances et de résoudre automatiquement les problèmes. Avec AWS, vous pouvez tirer profit de l'automatisation pour réagir aux données de surveillance. Par exemple, lorsqu'une métrique particulière franchit un seuil, vous pouvez déclencher une action automatique pour corriger le problème. De même, plutôt que de tenter de diagnostiquer et de corriger une ressource défaillante qui fait partie de votre environnement de production, vous pouvez la remplacer par une nouvelle ressource et exécuter l'analyse de cette ressource hors production. Comme le Cloud vous permet de maintenir les versions temporaires d'un système complet à bas coût, vous pouvez utiliser les tests automatiques pour vérifier les processus complets de récupération. Les questions suivantes sont axées sur ces quelques considérations relatives à la fiabilité. | REL 9 : Comment sauvegarder des données ? | | --- | | Sauvegardez les données, les applications et la configuration pour répondre à vos exigences en matière d'objectifs de temps de récupération (RTO) et d'objectifs de point de récupération (RPO). | | REL 10 : Comment utiliser l'isolation des pannes pour protéger votre charge de travail ? | | --- | | Les limites isolées pour les défaillances limitent l'effet d'une défaillance au sein d'une charge de travail à un nombre limité de composants. Les composants en dehors de la limite ne sont pas affectés par la défaillance. En utilisant plusieurs limites isolées par défaut, vous pouvez limiter l'impact sur votre charge de travail. | | REL 11 : Comment concevoir votre charge de travail pour la rendre résistante aux défaillances de composants ? | | --- | | Les charges de travail exigeant une haute disponibilité et un faible temps moyen de récupération (MTTR) doivent être conçues pour être résilientes. | | REL 12 : Comment tester la fiabilité ? | | --- | | Une fois que vous avez conçu votre charge de travail pour qu'elle soit résiliente aux sollicitations de la production, les tests sont le seul moyen de s'assurer qu'elle fonctionne comme prévu et d'obtenir la résilience voulue. | | REL 13 : Comment planifier la reprise après sinistre (DR) ? | | --- | | La mise en place de sauvegardes et de composants de charge de travail redondants constitue le début de votre stratégie de DR. [RTO et RPO sont vos objectifs](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) pour la restauration de votre charge de travail. Définissez-les en fonction des besoins de l'entreprise. Mettez en œuvre une stratégie pour atteindre ces objectifs, en particulier en tenant compte de l'emplacement et de la fonction des données et des ressources de charge de travail. La probabilité d'une perturbation et le coût de la reprise sont également des facteurs clés qui permettent de déterminer la valeur opérationnelle de la reprise après sinistre d'une charge de travail. | Sauvegardez régulièrement vos données et testez vos fichiers de sauvegarde pour vous assurer de pouvoir récupérer aussi bien après des erreurs logiques que des erreurs physiques. La clé de la gestion des pannes réside dans des tests réguliers et automatiques des charges de travail afin de créer des pannes, et dans l'observation de la façon dont ces charges reprennent. Effectuez ces opérations régulièrement et assurez-vous que de tels tests sont également déclenchés après des modifications significatives de la charge de travail. Suivez activement les KPI, ainsi que l'objectif de délai de reprise (RTO) et l'objectif de point de reprise (RPO) pour évaluer la résilience d'une charge de travail (notamment au cours de scénarios de test de panne). Le suivi des KPI vous aidera à identifier et à atténuer les points de défaillance uniques. L'objectif est de tester intégralement vos processus de reprise de charge de travail de telle sorte que vous soyez assuré de récupérer l'ensemble de vos données et de continuer à servir vos clients, même en présence de problèmes persistants. Vos processus de reprise doivent être aussi bien maîtrisés que vos processus de production habituels.