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.

Étape 4 : opérer

Après avoir terminé l'étape 3 : évaluation et test, vous êtes prêt à déployer l'application en production. Au stade Operate, vous déployez votre application en production et gérez l'expérience de vos clients.  La conception et la mise en œuvre de votre application déterminent bon nombre de ses résultats en matière de résilience, mais cette étape se concentre sur les pratiques opérationnelles utilisées par votre système pour maintenir et améliorer la résilience. La mise en place d'une culture d'excellence opérationnelle contribue à créer des normes et à uniformiser ces pratiques.

Observabilité

Pour comprendre l'expérience client, il est essentiel de recourir à la surveillance et à l'alarme. Vous devez instrumenter votre application pour comprendre son état, et vous avez besoin de points de vue variés, ce qui signifie que vous devez mesurer à la fois du côté serveur et du côté client, généralement à l'aide de canaris. Vos métriques doivent inclure des données sur les interactions de votre application avec ses dépendances et des dimensions conformes à vos limites d'isolation des pannes. Vous devez également produire des journaux fournissant des détails supplémentaires sur chaque unité de travail effectuée par votre application. Vous pouvez envisager de combiner les métriques et les journaux en utilisant une solution telle que le format de métrique CloudWatch intégré Amazon. Vous constaterez probablement que vous souhaitez toujours plus d'observabilité, alors considérez les compromis en termes de coûts, d'efforts et de complexité nécessaires pour mettre en œuvre le niveau d'instrumentation souhaité.

Les liens suivants fournissent les meilleures pratiques pour instrumenter votre application et créer des alarmes :

Gestion d'événements

Vous devriez mettre en place un processus de gestion des événements pour gérer les défaillances lorsque vos alarmes (ou pire encore, vos clients) vous indiquent que quelque chose ne va pas. Ce processus doit inclure l'engagement d'un opérateur de garde, l'escalade des problèmes et l'établissement de guides pour des approches cohérentes de dépannage qui aident à éliminer les erreurs humaines. Cependant, les déficiences ne se produisent généralement pas de manière isolée ; une seule application peut avoir un impact sur plusieurs autres applications qui en dépendent. Vous pouvez résoudre rapidement les problèmes en comprenant toutes les applications concernées et en réunissant les opérateurs de plusieurs équipes lors d'une seule conférence téléphonique. Toutefois, en fonction de la taille et de la structure de votre organisation, ce processus peut nécessiter une équipe opérationnelle centralisée.

Outre la mise en place d'un processus de gestion des événements, vous devez régulièrement revoir vos indicateurs par le biais de tableaux de bord. Des évaluations régulières vous aident à comprendre l'expérience client et les tendances à long terme en matière de performances de votre application. Cela vous permet d'identifier les problèmes et les goulots d'étranglement avant qu'ils n'aient un impact significatif sur la production. L'examen des indicateurs de manière cohérente et standardisée présente des avantages importants, mais nécessite une adhésion du haut vers le bas et un investissement en temps.

Les liens suivants fournissent les meilleures pratiques en matière de création de tableaux de bord et de révisions des indicateurs opérationnels :

Résilience continue

Au cours de l'étape 2 : conception et mise en œuvre et de l'étape 3 : évaluation et test, vous avez lancé des activités de révision et de test avant de déployer votre application en production. Pendant la phase d'exploitation, vous devez continuer à répéter ces activités en production. Vous devez régulièrement revoir la posture de résilience de votre application par le biais des révisions du AWS Well-Architected Framework, des évaluations de l'état de préparation opérationnelle (ORR) et du cadre d'analyse de la résilience. Cela permet de s'assurer que votre application ne s'écarte pas des bases et des normes établies et de vous tenir au courant des nouvelles directives ou des mises à jour. Ces activités de résilience continues vous aident à découvrir des perturbations imprévues auparavant et à proposer de nouvelles mesures d'atténuation.

Vous pouvez également envisager de lancer des journées de jeu et des expériences d'ingénierie du chaos en production une fois que vous les aurez exécutées avec succès dans des environnements de pré-production. Les journées de jeu simulent des événements connus que vous avez mis en place des mécanismes de résilience pour atténuer. Par exemple, une journée de jeu peut simuler une défaillance du service AWS régional et mettre en œuvre un basculement multirégional. Bien que la mise en œuvre de ces activités puisse nécessiter des efforts considérables, les deux pratiques vous aident à vous assurer que votre système est résilient aux modes de défaillance pour lesquels vous l'avez conçu.

En exploitant vos applications, en rencontrant des événements opérationnels, en examinant les métriques et en testant votre application, vous aurez de nombreuses occasions de réagir et d'apprendre.