# 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é.