Scénario à deux 9 (99 %)

Ces charges de travail sont utiles pour l'entreprise, mais n'entraînent qu'un contretemps si elles ne sont pas disponibles. Ce type de charge de travail comprend notamment les outils internes, la gestion des connaissances internes ou le suivi de projets. Il peut également s'agir de charges de travail réelles orientées client, mais exécutées à partir d'un service expérimental, avec une fonction d'activation/désactivation qui peut masquer le service si nécessaire.

Ces charges de travail peuvent être déployées avec une région et une zone de disponibilité.

Surveiller les ressources

Nous avons une surveillance simple, indiquant si la page d'accueil du service affiche un statut HTTP 200 OK. Lorsque des problèmes se produisent, notre playbook indique que les journaux de l'instance seront utilisés pour établir la cause racine.

s'adapter aux modifications de la demande ;

Nous disposons de playbooks pour les défaillances matérielles courantes, les mises à jour logicielles urgentes et d'autres modifications perturbatrices.

Implémentation de la modification

Nous utilisons AWS CloudFormation pour définir notre infrastructure en tant que code, et spécifiquement pour accélérer la reconstruction en cas de panne.

Les mises à jour logicielles sont réalisées manuellement à l'aide d'un runbook, avec les temps d'arrêt requis pour l'installation et le redémarrage du service. Si un problème se produit pendant le déploiement, le runbook décrit comment restaurer la version précédente.

Toutes les corrections de l'erreur sont effectuées à l'aide de l'analyse des journaux par les équipes d'exploitation et de développement. La correction est ensuite déployée une fois le correctif hiérarchisé et terminé.

sauvegarder les données ;

Nous utilisons une solution de sauvegarde d'un fournisseur ou spécialisée pour envoyer des données de sauvegarde chiffrées dans Amazon S3 à l'aide d'un runbook. Nous vérifions que les sauvegardes fonctionnent en restaurant les données et en vérifiant qu'il est possible de les utiliser régulièrement à l'aide d'un runbook. Nous configurons la gestion des versions sur nos objets Amazon S3 et supprimons les autorisations de suppression des sauvegardes. Nous suivons une politique de cycle de vie de compartiment Amazon S3 pour archiver ou supprimer définitivement en fonction de nos besoins.

Conception de la résilience

Les charges de travail sont déployées avec une région et une zone de disponibilité. Nous déployons l’application, y compris la base de données, dans une seule instance.

tester la résilience ;

Le pipeline de déploiement d'un nouveau logiciel est planifié, avec des tests d'unité, mais principalement des essais de boîte blanche/boîte noire de l'ensemble de la charge de travail.

Planification de la reprise après sinistre

En cas de panne, nous en attendons la fin en acheminant éventuellement les requêtes vers un site Web statique grâce à la modification DNS via un runbook. Le temps de récupération pour cet événement sera déterminé par la vitesse à laquelle l'infrastructure peut être déployée et la base de données restaurée à la dernière sauvegarde. Ce déploiement peut se faire dans la même zone de disponibilité ou dans une autre zone de disponibilité en cas de défaillance d'une zone de disponibilité à l'aide d'un runbook.

Objectif de la conception de la disponibilité

Nous prenons 30 minutes pour comprendre et décider d'exécuter la récupération, et 10 minutes pour déployer la pile entière dans AWS CloudFormation. Nous supposons que nous déployons sur une nouvelle zone de disponibilité et que la base de données peut être restaurée en 30 minutes. Cela signifie qu'il faut environ 70 minutes pour reprendre les activités après une défaillance. En supposant une défaillance par trimestre, notre impact estimé pour l'année est 280 minutes ou quatre heures et 40 minutes.

Cela signifie que la limite supérieure de disponibilité est de 99,9 %. La disponibilité réelle varie également selon le taux réel de défaillance, la durée des défaillances et la rapidité de récupération réelle après chaque panne. Pour cette architecture, nous avons besoin que l'application soit hors ligne pour les mises à jour (en estimant 24 heures par an : quatre heures par modification, six fois par an), ainsi que les événements réels. Ainsi, en nous reportant au tableau de disponibilité des applications présenté plus haut dans le livre blanc, nous voyons que notre objectif de la conception de la disponibilité est de 99 %.

Récapitulatif

Rubrique	Implémentation
Surveiller les ressources	Vérification de l'état du site uniquement ; aucune alerte.
s'adapter aux modifications de la demande ;	Mise à l'échelle verticale via redéploiement.
Implémentation de la modification	Runbook pour le déploiement et la restauration.
sauvegarder les données ;	Runbook pour la sauvegarde et la restauration.
Conception de la résilience	Reconstruction ; restauration à partir d'une sauvegarde.
tester la résilience ;	Reconstruction ; restauration à partir d'une sauvegarde.
Planification de la reprise après sinistre	Sauvegardes chiffrées, restauration dans une autre zone de disponibilité si nécessaire.