# Fiabilité
Le pilier Fiabilité englobe la capacité d’une charge de travail à exécuter sa fonction de manière correcte et cohérente et ce, en temps utile. Cela inclut la possibilité d’exploiter et de tester la charge de travail tout au long de son cycle de vie. Ce livre blanc fournit des bonnes pratiques détaillées pour la mise en œuvre de charges de travail fiables sur AWS.
**Topics**
+ [Modèle de responsabilité partagée pour la résilience](shared-responsibility-model-for-resiliency.md)
+ [Principes de conception](design-principles.md)
+ [Définitions](definitions.md)
+ [Compréhension des besoins en disponibilité](understanding-availability-needs.md)
# Modèle de responsabilité partagée pour la résilience
La résilience est une responsabilité partagée entre AWS et vous. Il est important que vous compreniez comment la reprise après sinistre (DR) et la disponibilité, qui font partie de la résilience, fonctionnent dans le cadre de ce modèle partagé.
**Responsabilité AWS : résilience du cloud**
AWS est responsable de la résilience de l’infrastructure qui fait fonctionner tous les services proposés dans le AWS Cloud. Cette infrastructure est composée du matériel, des logiciels, du réseau et des installations exécutant les services AWS Cloud. AWS déploie des efforts commercialement raisonnables pour rendre ces services AWS Cloud disponibles, en veillant à ce que la disponibilité des services respecte ou dépasse les [contrats de niveau de service (SLA) AWS](https://aws.amazon.com/legal/service-level-agreements/).
L’[infrastructure cloud mondiale AWS](https://aws.amazon.com/about-aws/global-infrastructure/) est conçue pour permettre aux clients de créer des architectures de charge de travail hautement résilientes. Chaque Région AWS est entièrement isolée et comprend plusieurs [ zones de disponibilité](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/#Availability_Zones), qui sont des partitions physiquement isolées de l’infrastructure. Les zones de disponibilité isolent les défaillances susceptibles d’affecter la résilience des charges de travail, en les empêchant d’avoir un impact sur les autres zones de la région. Toutes les zones de disponibilité d’une Région AWS sont interconnectées avec un réseau à large bande passante et à faible latence, qui utilise une fibre métropolitaine dédiée entièrement redondante fournissant un réseau à haut débit et à faible latence entre les AZ. Tout le trafic entre les zones est chiffré. Les performances du réseau sont suffisantes pour réaliser une réplication synchrone entre les zones. Si une application est partitionnée sur plusieurs AZ, vous êtes mieux isolé et protégé contre les problèmes tels que les pannes de courant, la foudre, les tornades, les tremblements de terre, etc.
**Responsabilité des clients : résilience dans le cloud**
Votre responsabilité est déterminée par les services AWS Cloud que vous choisissez. Cela détermine la quantité de travail de configuration que vous devez effectuer dans le cadre de vos responsabilités en matière de résilience. Par exemple, un service tel que Amazon Elastic Compute Cloud (Amazon EC2) exige du client qu’il effectue toutes les tâches de configuration et de gestion de la résilience nécessaires. Les clients qui déploient des instances Amazon EC2 sont chargés de déployer des [instances Amazon EC2 sur plusieurs sites](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) (tels que les zones de disponibilité AWS), de [mettre en œuvre l’autoréparation](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) à l’aide de services tels que [Auto Scaling et d’appliquer les bonnes pratiques en matière d’architecture de charge de travail résiliente](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html) pour les applications installées sur les instances. Dans le cas des services gérés, comme Amazon S3 et Amazon DynamoDB, AWS exploite la couche infrastructure, le système d’exploitation et les plateformes, et les clients accèdent aux points de terminaison pour stocker et récupérer les données. Vous êtes responsable de la gestion de la résilience de vos données, y compris des stratégies de sauvegarde, de gestion des versions et de réplication.
Le déploiement de votre charge de travail dans plusieurs zones de disponibilité d’une Région AWS fait partie d’une stratégie de haute disponibilité conçue pour protéger les charges de travail en isolant les problèmes dans une zone de disponibilité donnée. Cette stratégie utilise la redondance des autres zones de disponibilité pour continuer à répondre aux requêtes. Une architecture Multi-AZ s’inscrit également dans une stratégie DR conçue pour mieux isoler et protéger les charges de travail contre des problèmes tels que les pannes de courant, la foudre, les tornades, les tremblements de terre, etc. Les stratégies de DR peuvent également faire appel à de multiples Régions AWS. Par exemple, dans une configuration active/passive, le service de la charge de travail passe de sa région active à sa région DR si la région active ne peut plus répondre aux requêtes.
![\[Graphique illustrant le modèle de résilience partagée.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/shared-model-resiliency.png)
Vous pouvez utiliser les services AWS pour atteindre vos objectifs de résilience. En tant que client, vous êtes responsable de la gestion des aspects suivants de votre système pour atteindre la résilience dans le cloud. Pour plus de détails sur chaque service en particulier, consultez [la documentation AWS](https://docs.aws.amazon.com/index.html).
**Réseaux, quotas et contraintes**
+ Les bonnes pratiques pour ce domaine du modèle de responsabilité partagée sont décrites en détail dans la section [Fondations](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/foundations.html).
+ Planifiez votre architecture avec une marge de manœuvre suffisante et comprenez les [quotas de service](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/manage-service-quotas-and-constraints.html) et les contraintes des services que vous incluez, en fonction des augmentations de charge attendues, le cas échéant.
+ Concevez la [topologie de votre réseau](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html) pour qu’elle soit hautement disponible, redondante et évolutive.
**Gestion des modifications et résilience opérationnelle**
+ [La gestion des modifications](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/change-management.html) inclut la manière d’introduire et de gérer les modifications dans votre environnement. La [mise en œuvre du changement](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/implement-change.html) nécessite de créer et de maintenir à jour des runbooks ainsi que des stratégies de déploiement pour votre application et votre infrastructure.
+ Une stratégie résiliente de [surveillance des ressources de charge de travail](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/monitor-workload-resources.html) prend en compte tous les composants, y compris les indicateurs techniques et commerciaux, les notifications, l’automatisation et l’analyse.
+ Les charges de travail dans le cloud doivent [s’adapter à l’évolution de la demande](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-adapt-to-changes-in-demand.html) en réaction à des déficiences ou à des fluctuations d’utilisation.
**Observabilité et gestion des pannes**
+ L’observation des défaillances par le biais de la surveillance est nécessaire pour automatiser la réparation afin que vos charges de travail puissent [résister aux défaillances des composants](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html).
+ La [gestion des défaillances](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/failure-management.html) nécessite de [sauvegarder les données](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/back-up-data.html), d’appliquer les bonnes pratiques pour permettre à votre charge de travail de résister aux défaillances des composants et [de planifier la reprise après sinistre](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html).
**Architecture de charge de travail**
+ [L’architecture de votre charge de travail](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html) inclut la manière dont vous concevez des services autour de domaines commerciaux, appliquez la SOA et concevez des systèmes distribués pour éviter les défaillances, et intégrez des fonctionnalités telles que la limitation, les nouvelles tentatives, la gestion des files d’attente, les délais d’attente et les leviers d’urgence.
+ Appuyez-vous sur [des solutions AWS](https://aws.amazon.com/solutions/) éprouvées, [Amazon Builders’ Library](https://aws.amazon.com/builders-library/) et [des modèles sans serveur](https://serverlessland.com/patterns) pour vous aligner sur les bonnes pratiques et accélérer les mises en œuvre.
+ Utilisez l’amélioration continue pour décomposer votre système en services distribués afin d’évoluer et d’innover plus rapidement. Utilisez les conseils relatifs aux [microservices AWS](https://aws.amazon.com/microservices/) et les options de services gérés pour simplifier et accélérer votre capacité à introduire le changement et à innover.
**Test continu des infrastructures critiques**
+ Pour [tester la fiabilité](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html), il faut effectuer des tests au niveau des fonctionnalités, des performances et du chaos, ainsi qu’adopter l’analyse des incidents et les pratiques des jours de jeu afin de développer une expertise en matière de résolution de problèmes mal compris.
+ Pour les applications tout cloud et hybrides, le fait de savoir comment votre application se comporte lorsque des problèmes surviennent ou que des composants tombent en panne permet une reprise rapide et fiable après une panne.
+ Créez et documentez des expériences reproductibles pour comprendre comment votre système se comporte lorsque les objets ne fonctionnent pas comme prévu. Ces tests prouveront l’efficacité de votre résilience globale et fourniront une boucle de rétroaction pour vos procédures opérationnelles avant de vous confronter à des scénarios de panne réels.
# Principes de conception
Dans le cloud, il existe un certain nombre de principes qui peuvent vous aider à renforcer la fiabilité. Gardez les éléments suivants à l’esprit lorsque nous aborderons les meilleures pratiques :
+ **Récupération automatique après une panne :** en contrôlant les indicateurs clés de performance d’une charge de travail, vous pouvez exécuter l’automatisation en cas de transgression d’un seuil. Ces KPI doivent couvrir la valeur commerciale et non des aspects techniques du fonctionnement du service. Cela permet la création de notifications automatiques, le suivi des pannes et l’exécution de processus de récupération automatique qui contournent ou corrigent les pannes. Une automatisation plus sophistiquée rend possible l’anticipation et la correction des pannes avant qu’elles ne se produisent.
+ **Test des procédures de récupération :** dans un environnement sur site, des tests sont souvent conduits pour prouver que la charge de travail fonctionne dans un scénario particulier. Ces tests ne sont généralement pas utilisés pour valider les stratégies de récupération. Dans le cloud, vous pouvez tester de quelle façon votre charge de travail cesse de fonctionner et valider vos procédures de récupération. Vous pouvez utiliser l’automatisation pour simuler différentes pannes ou recréer les scénarios qui ont déjà conduit à des pannes. Cette approche expose les chemins de défaillance que vous pouvez tester et corriger *avant* qu’un scénario de défaillance réelle ne se produise et réduire ainsi les risques.
+ **Mise à l’échelle horizontale pour augmenter la disponibilité de la charge de travail :** remplacez une ressource volumineuse par plusieurs petites ressources pour réduire l’impact d’une défaillance unique sur la charge de travail globale. Répartissez les demandes entre plusieurs ressources plus petites pour garantir qu’elles ne partagent pas un point de panne commun.
+ **Une capacité réellement adaptée à vos besoins :** une cause courante de défaillance des charges de travail sur site est la saturation des ressources, lorsque les demandes ciblant une charge de travail en dépassent la capacité (c’est souvent l’objectif des attaques par déni de service). Dans le cloud, vous pouvez contrôler la demande et l’utilisation de la charge de travail. Vous pouvez aussi automatiser l’ajout ou la suppression de ressources afin de maintenir le niveau optimal de satisfaction de la demande sans surallocation ou sous-allocation. Il existe toujours des limites, mais certaines peuvent être contrôlées et d’autres gérées (Consulter [Gestion des quotas de service et des contraintes](manage-service-quotas-and-constraints.md)).
+ **Gestion des changements avec l’automatisation** : les modifications apportées à l’infrastructure doivent être appliquées via l’automatisation. Les modifications qui doivent être gérées incluent celles apportées à l’automatisation et qui peuvent ensuite être suivies et vérifiées.
# Définitions
Ce livre blanc aborde la fiabilité dans le cloud et décrit les bonnes pratiques pour ces quatre domaines :
+ Fondations
+ Architecture de charge de travail
+ Gestion des modifications
+ Gestion des défaillances
Pour atteindre la fiabilité, vous devez commencer par les fondations : un environnement où les quotas de service et la topologie réseau s’adaptent à la charge de travail. L’architecture de la charge de travail du système distribué doit être conçue pour prévenir et atténuer les défaillances. La charge de travail doit gérer les modifications au niveau de la demande ou des exigences. Elle doit être conçue pour détecter les défaillances et se réparer automatiquement.
**Topics**
+ [Résilience et composants de la fiabilité](resiliency-and-the-components-of-reliability.md)
+ [Disponibilité](availability.md)
+ [Objectifs de reprise après sinistre](disaster-recovery-dr-objectives.md)
# Résilience et composants de la fiabilité
La fiabilité d’une charge de travail dans le cloud dépend de plusieurs facteurs, dont le principal est la *résilience* :
+ La **résilience** est la capacité d’une charge de travail à récupérer après des perturbations de l’infrastructure ou du service, d’acquérir de manière dynamique les ressources de calcul pour satisfaire la demande et d’atténuer les perturbations telles que les erreurs de configuration ou les problèmes réseau temporaires.
Les autres facteurs qui affectent la fiabilité de la charge de travail sont les suivants :
+ L’excellence opérationnelle qui comprend l’automatisation des modifications, l’utilisation de manuels pour corriger les pannes et les examens de disponibilité opérationnelle pour vérifier que les applications sont prêtes pour les opérations de production.
+ La sécurité qui englobe la prévention des dommages causés aux données ou à l’infrastructure par des acteurs malveillants pour prévenir tout impact sur la disponibilité. Par exemple, chiffrez les sauvegardes pour vous sécuriser les données.
+ L’efficacité des performances qui intègre la conception pour maximiser les taux de requêtes et réduire au maximum les latences de votre charge de travail.
+ L’optimisation des coûts, ce qui implique des compromis, tels que le choix entre une hausse des dépenses sur les instances EC2 pour atteindre la stabilité statique ou le recours à la mise à l’échelle automatique pour augmenter la capacité en fonction des besoins.
La résilience est l’objectif principal de ce livre blanc.
Les quatre autres aspects sont également importants et sont couverts par leurs piliers respectifs du [Cadre AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/). Un grand nombre des bonnes pratiques décrites ici traitent également des aspects liés à la fiabilité, mais l’accent est mis sur la résilience.
# Disponibilité
La *disponibilité* (ou *disponibilité du service*) est à la fois une métrique couramment utilisée pour mesurer quantitativement la résilience, ainsi qu’un objectif de résilience cible.
+ **La disponibilité** correspond au pourcentage de temps pendant lequel une charge de travail est disponible à’ l’utilisation.
*Disponible à l’utilisation* signifie que la charge de travail exécute bien sa fonction chaque fois que nécessaire.
Ce pourcentage se calcule sur une période, par exemple un mois, un an ou les trois dernières années. Dans son interprétation la plus stricte, la disponibilité est réduite chaque fois que l’application ne fonctionne pas normalement, y compris pendant les interruptions planifiées et non planifiées. Nous définissons la *disponibilité* comme suit :
![\[\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/availability-formula.png)
+ La disponibilité est un pourcentage de temps de fonctionnement (par exemple, 99,9 %) sur une période (généralement un mois ou un an)
+ Un raccourci courant consiste à parler du « nombre de neuf ». Par exemple, « cinq 9 » correspond à une disponibilité de 99,999 %.
+ Certains clients choisissent d’exclure les temps d’arrêt programmés (par exemple, la maintenance planifiée) de la *durée totale* dans la formule. Cependant, cela n’est pas conseillé, car vos utilisateurs voudront probablement utiliser votre service pendant ces périodes.
Voici un tableau des objectifs courants de disponibilité des applications et de la durée maximale des interruptions qui peuvent se produire sur une année, tout en continuant d’atteindre l’objectif. Le tableau contient des exemples des types d’applications généralement rencontrées à chaque niveau de disponibilité. Tout au long de ce document, nous ferons référence à ces valeurs.
| Disponibilité | Indisponibilité maximale (par an) | Catégories d’applications |
| --- | --- | --- |
| 99 % | 3 jours 15 heures | Tâches de traitement par lots, d’extraction de données, de transfert et de chargement |
| 99,9 % | 8 heures 45 minutes | Outils internes, tels que la gestion des connaissances, le suivi des projets |
| 99,95 % | 4 heures 22 minutes | Commerce en ligne, point de vente |
| 99,99 % | 52 minutes | Diffusion vidéo, charges de travail de diffusion |
| 99,999 % | 5 minutes | Transactions de distributeurs, charges de travail de télécommunications |
**Mesurez la disponibilité en fonction des demandes.** Pour votre service, il peut être plus facile de compter les demandes ayant réussi ou échoué au lieu du « temps disponible pour utilisation ». Dans ce cas, le calcul suivant peut être utilisé :
![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png)
Cette mesure porte souvent sur des périodes d’une minute ou de cinq minutes. Un pourcentage de disponibilité mensuelle (mesure de la disponibilité sur la base du temps) peut être calculé à partir de la moyenne de ces périodes. Si aucune demande n’est reçue au cours d’une période donnée, elle est comptée comme étant disponible à 100 % pour cette période.
**Calcul de disponibilité avec des dépendances strictes.** De nombreux systèmes ont des dépendances strictes avec d’autres systèmes. Dans ce cas, une interruption dans un système dépendant se traduit directement par une interruption du système appelant. Cette notion s’oppose à celle de dépendance souple, où une défaillance du système dépendant est compensée dans l’application. Quand de telles dépendances strictes se produisent, la disponibilité du système appelant est le produit de la disponibilité des systèmes dépendants. Par exemple, si un système conçu pour offrir une disponibilité de 99,99 % a une dépendance stricte avec deux autres systèmes indépendants, qui sont chacun conçus pour offrir une disponibilité de 99,99 %, la charge de travail peut théoriquement atteindre 99,97 % de disponibilité :
Availinvok × Avail*dep1* × Avail*dep2* = Availworkload
99,99 % × 99,99 % × 99,99 % = 99,97 %
Il est donc important de comprendre vos dépendances et leurs objectifs de conception de disponibilité dans votre propre calcul de disponibilité.
**Calcul de disponibilité avec des composants redondants.** Lorsqu’un système implique l’utilisation de composants redondants et indépendants (par exemple, des ressources redondantes dans des zones de disponibilité redondantes), la disponibilité théorique est calculée à hauteur de 100 %, moins le produit des taux de défaillance des composants. Par exemple, si un système utilise deux composants indépendants, chacun avec une disponibilité de 99,9 %, la disponibilité effective de cette dépendance est > 99,9999 % :
![\[Diagram showing calculation of availability with redundant components in a system.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/image2.png)
Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency))
99,9999 % = 100 % − (0,1 % × 0,1 %)
*Calcul de raccourci :* si les disponibilités de tous les composants de votre calcul contiennent uniquement le chiffre neuf, vous pouvez additionner le nombre de neuf pour obtenir votre réponse. Dans l’exemple ci-dessus, deux composants redondants et indépendants avec trois neuf disponibles donnent six neuf.
**Calcul de la disponibilité d’une dépendance.** Certaines dépendances fournissent des informations sur leur disponibilité, y compris les objectifs de conception de disponibilité pour de nombreux services AWS Si cette information n’est pas disponible (par exemple, pour un composant où le fabricant ne publie pas les données de disponibilité), un moyen d’estimation consiste à déterminer le **temps moyen entre deux pannes (MTBF)** et le **temps moyen de récupération (MTTR)**. Une estimation de disponibilité peut être établie par la formule suivante :
![\[\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png)
Par exemple, si le MTBF est de 150 jours et que le MTTR est de 1 heure, l’estimation de disponibilité est de 99,97 %.
Pour plus de détails, consultez [Availability and Beyond : Understanding and improving the resilience of distributed systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html), qui peut vous aider à calculer votre disponibilité.
**Coûts liés à la disponibilité.** La conception d’applications pour de plus hauts niveaux de disponibilité est généralement synonyme de coûts accrus. Par conséquent, il est nécessaire d’identifier les vrais besoins de disponibilité avant de démarrer la conception de votre application. Un haut niveau de disponibilité impose des exigences plus strictes pour les tests et la validation dans des scénarios de défaillance exhaustifs. L’automatisation est nécessaire pour la récupération à partir de toutes sortes de défaillances, et tous les aspects des opérations système doivent être conçus et testés selon les mêmes normes. Par exemple, l’ajout ou la suppression de capacité, le déploiement ou la restauration des mises à jour logicielles ou des modifications de configuration ou la migration des données système doivent être réalisées en fonction de l’objectif de disponibilité souhaité. Outre le coût de développement du logiciel, les très hauts niveaux de disponibilité sont un frein à l’innovation, car ils nécessitent de déployer beaucoup plus lentement les systèmes. Il est donc recommandé d’être minutieux dans l’application des normes et dans la sélection d’un objectif de disponibilité adapté pour tout le cycle de vie de l’exploitation du système.
La sélection de dépendances est un autre facteur d’augmentation des coûts pour les systèmes opérant avec des objectifs de conception de disponibilité élevés. Avec ces objectifs plus élevés, l’ensemble de logiciels ou services qui peuvent être choisis en tant que dépendances diminue en fonction des services qui ont bénéficié des investissements importants décrits précédemment. Quand l’objectif de conception de disponibilité augmente, les services multifonctions (par exemple, les bases de données relationnelles) sont moins nombreux par rapport aux services plus spécialisés. Ces derniers sont en effet plus faciles à évaluer, tester et automatiser, et ils sont moins susceptibles de présenter des interactions imprévues avec des fonctionnalités incluses, mais non utilisées.
# Objectifs de reprise après sinistre
Outre les objectifs de disponibilité, votre stratégie de résilience doit également inclure des objectifs de reprise après sinistre (DR) basés sur des stratégies de récupération de votre charge de travail en cas de sinistre. La reprise après sinistre se concentre sur des objectifs de reprise ponctuels en réponse à des catastrophes naturelles, des pannes techniques à grande échelle ou des menaces humaines telles qu’une attaque ou une erreur. Elle diffère de la disponibilité qui, elle, mesure la résilience sur une période en réponse aux pannes de composants, aux pics de charge ou aux bogues logiciels.
**L’objectif de délai de reprise (RTO)** est défini par l’organisation. La RTO correspond au délai maximum acceptable entre l’interruption du service et la restauration du service. Elle détermine ce qui est considéré comme étant un créneau de temps acceptable d’indisponibilité du service.
**L’objectif de délai de reprise (RTO)** est défini par l’organisation. Le RPO correspond au temps maximal acceptable depuis le dernier point de reprise des données. Il détermine ce qui est considéré comme étant une perte de données acceptable entre le dernier point de reprise et l’interruption du service.
![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/business-continuity.png)
*Relation entre le RPO (objectif de point de reprise), la RTO (durée maximale d’interruption admissible) et l’événement de sinistre.*
La RTO est similaire au MTTR (temps moyen de reprise) en ce que ces deux valeurs mesurent le délai entre le début d’une panne et la reprise de la charge de travail. Cependant, le MTTR est une valeur moyenne obtenue à partir de plusieurs événements ayant un impact sur la disponibilité au cours d’une période donnée, alors que la RTO est une cible, ou une valeur maximale autorisée, pour un *seul* événement ayant un impact sur la disponibilité.
# Compréhension des besoins en disponibilité
Il est fréquent de considérer initialement la disponibilité d’une application comme un objectif unique à atteindre pour l’application dans son ensemble. Toutefois, en y regardant de plus près, on constate souvent que certains aspects d’une application ou d’un service présentent différentes exigences en matière de disponibilité. Par exemple, certains systèmes peuvent prioriser la possibilité de recevoir et de stocker de nouvelles données, au détriment de la récupération de données existantes. D’autres systèmes vont privilégier les opérations en temps réel sur les opérations qui modifient la configuration ou l’environnement d’un système. Les services peuvent avoir des exigences de disponibilité très élevées à certains moments de la journée, mais tolérer des périodes de perturbation beaucoup plus longues le reste du temps. Voici quelques-unes des manières dont vous pouvez diviser une même application en différents éléments constitutifs, afin d’évaluer les exigences de disponibilité pour chaque partie. Cette façon de procéder a pour avantage de permettre de concentrer vos efforts (et dépenses) sur la disponibilité en fonction de besoins spécifiques, plutôt que de concevoir l’ensemble du système sur la base de l’exigence la plus stricte.
| Recommendation |
| --- |
| Évaluez de manière critique les aspects uniques de vos applications et, le cas échéant, différenciez les objectifs de conception de la disponibilité et de la reprise après sinistre pour refléter les besoins de votre entreprise. |
Chez AWS, nous divisons souvent les services en deux, avec un « plan de données » et un « plan de contrôle ». Le plan de données vise à fournir un service en temps réel, tandis que les plans de contrôle servent à configurer l’environnement. Par exemple, les instances Amazon EC2, les bases de données Amazon RDS et les opérations de lecture/écriture sur les tables Amazon DynamoDB sont autant d’opérations qui relèvent du plan de données. En revanche, le lancement de nouvelles instances EC2 ou bases de données RDS, ou l’ajout ou la modification des métadonnées de table dans DynamoDB sont considérés comme des opérations de plan de contrôle. Tandis que de hauts niveaux de disponibilité sont importants pour l’ensemble de ces fonctionnalités, les plans de données ont généralement des objectifs de conception de disponibilité plus élevés que les plans de contrôle. Par conséquent, les charges de travail avec des exigences de haute disponibilité doivent éviter la dépendance d’exécution vis-à-vis des opérations du plan de contrôle.
La plupart des clients AWS adoptent une approche similaire pour évaluer leurs applications avec un esprit critique et identifier les sous-composants avec différents besoins de disponibilité. Les objectifs de conception de disponibilité sont ensuite adaptés aux différents aspects et les efforts de travail appropriés sont mis en œuvre pour concevoir le système. AWS a accumulé une expérience importante dans l’ingénierie d’applications avec un éventail d’objectifs de conception de disponibilité, y compris des services avec une disponibilité de 99,999 % ou plus. AWS Les architectes de solution peuvent vous aider à concevoir de manière appropriée en fonction de vos objectifs de disponibilité. Impliquer AWS de manière précoce dans votre processus de conception nous permet de vous aider à atteindre vos objectifs de disponibilité. La planification pour la disponibilité ne se fait pas uniquement avant le lancement de votre charge de travail. Elle s’effectue également en continu de manière à affiner votre conception à mesure que vous accumulez de l’expérience opérationnelle, tirez des enseignements des événements réels et êtes confronté à différents types de défaillances. Vous pouvez ensuite appliquer l’effort de travail approprié pour améliorer votre mise en œuvre.
Les besoins en disponibilité requis pour une charge de travail doivent être alignés sur les besoins et la criticité de l’entreprise. En commençant par définir un cadre de criticité commerciale avec une RTO, un RPO et une disponibilité spécifiques, vous pouvez évaluer chaque charge de travail. Une telle approche exige que les personnes impliquées dans la mise en œuvre de la charge de travail connaissent le cadre et l’impact de leur charge de travail sur les besoins de l’entreprise.