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 1 : Fixer des objectifs
Comprendre quel niveau de résilience est nécessaire et comment vous allez le mesurer constitue la base de l'étape de définition des objectifs. Il est difficile d'améliorer quelque chose si vous n'avez pas d'objectif et si vous ne pouvez pas le mesurer.
Toutes les applications n'ont pas besoin du même niveau de résilience. Lorsque vous définissez des objectifs, considérez le niveau requis afin de faire les bons investissements et de faire les bons compromis. Une bonne analogie est celle d'une voiture : elle a quatre pneus mais un seul pneu de secours. Le risque de crevaison de plusieurs pneus pendant un trajet est faible, et le fait d'avoir des pièces de rechange supplémentaires pourrait nuire à d'autres caractéristiques, telles que l'espace de chargement ou le rendement énergétique. Il s'agit donc d'un compromis raisonnable.
Après avoir défini les objectifs, vous implémentez des contrôles d'observabilité lors des étapes ultérieures (étape 2 : conception et mise en œuvre et étape 4 : exploitation) pour déterminer si les objectifs sont atteints.
Cartographie des applications critiques
La définition des objectifs de résilience ne doit pas être exclusivement une conversation technique. Commencez plutôt par vous concentrer sur les besoins de l'entreprise afin de comprendre ce que l'application doit apporter et les conséquences d'une dépréciation. Cette compréhension des objectifs commerciaux se répercute ensuite sur des domaines tels que l'architecture, l'ingénierie et les opérations. Les objectifs de résilience que vous définissez peuvent être appliqués à toutes vos applications, mais la manière dont les objectifs sont mesurés varie souvent en fonction de la fonction de l'application. Vous exécutez peut-être une application essentielle à l'entreprise, et si cette application est altérée, votre entreprise risque de perdre des revenus importants ou de porter atteinte à sa réputation. Il se peut également que vous ayez une autre application qui n'est pas aussi critique et qui peut tolérer certains temps d'arrêt sans nuire à la capacité de votre entreprise à mener ses activités.
Prenons l'exemple d'une application de gestion des commandes pour une entreprise de vente au détail. Si les composants de l'application de gestion des commandes sont défectueux et ne fonctionnent pas correctement, les nouvelles ventes ne seront pas conclues. Cette entreprise de vente au détail possède également un café pour ses employés situé dans l'un de ses bâtiments. Le café dispose d'un menu en ligne auquel les employés peuvent accéder sur une page Web statique. Si cette page Web n'est plus disponible, certains employés peuvent se plaindre, mais cela ne causera pas nécessairement un préjudice financier à l'entreprise. Sur la base de cet exemple, l'entreprise choisira probablement de fixer des objectifs de résilience plus ambitieux pour l'application de gestion des commandes, mais n'investira pas de manière significative pour garantir la résilience de l'application Web.
Identifier les applications les plus critiques, les domaines dans lesquels déployer le plus d'efforts et les domaines dans lesquels il convient de faire des compromis est aussi important que de pouvoir mesurer la résilience d'une application en production. Pour mieux comprendre l'impact de la dépréciation, vous pouvez effectuer une analyse d'impact commercial (BIA). Un BIA fournit une approche structurée et systématique pour identifier et hiérarchiser les applications métier critiques, évaluer les risques et les impacts potentiels, et identifier les dépendances sous-jacentes. Le BIA permet de quantifier le coût des interruptions de service pour les applications les plus importantes de votre entreprise. Cette métrique permet de déterminer combien cela coûtera si une application spécifique est défectueuse et incapable de remplir sa fonction. Dans l'exemple précédent, si l'application de gestion des commandes est défectueuse, le commerce de détail pourrait perdre des revenus importants.
Cartographie des témoignages d'utilisateurs
Au cours du processus BIA, vous pouvez découvrir qu'une application est responsable de plusieurs fonctions commerciales ou qu'une fonction métier nécessite plusieurs applications. En utilisant l'exemple précédent d'une entreprise de vente au détail, la fonction de gestion des commandes peut nécessiter des applications distinctes pour le paiement, les promotions et les prix. Si une application échoue, l'impact peut être ressenti par l'entreprise et par les utilisateurs qui interagissent avec l'entreprise. Par exemple, il se peut que l'entreprise ne soit pas en mesure d'ajouter de nouvelles commandes, de donner accès à des promotions et à des remises, ou de mettre à jour le prix de ses produits. Ces différentes fonctions requises par la fonction de gestion des commandes peuvent reposer sur plusieurs applications. Ces fonctions peuvent également avoir de multiples dépendances externes, ce qui rend trop complexe le processus de mise en œuvre d'une résilience uniquement axée sur les composants. Une meilleure façon de gérer ce scénario est de se concentrer sur les user stories
En vous concentrant sur les témoignages d'utilisateurs, vous pouvez comprendre quels aspects de l'expérience client sont les plus importants, afin de créer des mécanismes de protection contre des menaces spécifiques. Dans l'exemple précédent, l'une des histoires d'utilisateur pourrait être Checkout, qui implique l'application de paiement et dépend de l'application de tarification. Une autre histoire d'utilisateur pourrait être la visualisation de promotions, ce qui implique l'application de promotion. Après avoir cartographié les applications les plus critiques et leurs user stories, vous pouvez commencer à définir les métriques que vous utiliserez pour mesurer la résilience de ces user stories. Ces indicateurs peuvent être appliqués à l'ensemble d'un portefeuille ou à des témoignages d'utilisateurs individuels.
Définition des mesures
Les objectifs de point de reprise (RPO), les objectifs de temps de restauration (RTO) et les objectifs de niveau de service (SLO) sont des mesures standard du secteur utilisées pour évaluer la résilience d'un système donné. Le RPO fait référence à l'ampleur des pertes de données que l'entreprise peut tolérer en cas de panne, tandis que le RTO est une mesure de la rapidité avec laquelle une application doit être à nouveau disponible après une panne. Ces deux mesures sont mesurées en unités de temps : secondes, minutes et heures. Vous pouvez également mesurer le temps pendant lequel l'application fonctionne correctement, c'est-à-dire qu'elle exécute ses fonctions comme prévu et qu'elle est accessible à ses utilisateurs. Ces SLO détaillent le niveau de service attendu des clients et sont mesurés par des indicateurs tels que le pourcentage (%) de demandes traitées sans erreur dans un délai de réponse inférieur à une seconde (par exemple, 99,99 % des demandes recevront une réponse chaque mois). Le RPO et le RTO sont liés aux stratégies de reprise après sinistre, en supposant que le fonctionnement des applications et les processus de restauration seront interrompus, qu'il s'agisse de restaurer des sauvegardes ou de rediriger le trafic utilisateur. Les SLO sont résolus par la mise en œuvre de contrôles de haute disponibilité, qui ont tendance à réduire les temps d'arrêt d'une application.
Les métriques SLO sont couramment utilisées dans la définition des accords de niveau de service (SLA), qui sont des contrats entre les fournisseurs de services et les utilisateurs finaux. Les SLA s'accompagnent généralement d'engagements financiers et décrivent les pénalités qui doivent être payées par le fournisseur si ces accords ne sont pas respectés. Cependant, un SLA n'est pas une mesure de votre posture de résilience, et l'augmentation d'un SLA ne rend pas votre application plus résiliente.
Vous pouvez commencer à définir vos objectifs en fonction des SLO, des RPO et des RTO. Une fois que vous avez défini vos objectifs de résilience et que vous avez bien compris vos objectifs de RPO et de RTO, vous pouvez effectuer une évaluation de votre architecture AWS Resilience Hub
Création de mesures supplémentaires
Le RPO, le RTO et les SLO sont de bons indicateurs de résilience, mais vous pouvez également réfléchir aux objectifs d'un point de vue commercial et définir des objectifs en fonction des fonctions de votre application. Par exemple, votre objectif pourrait être le suivant : les commandes réussies par minute resteront supérieures à 98 % si le temps de latence entre mon frontend et mon backend augmente de 40 %.Ou : les flux démarrés par seconde resteront dans les limites d'un écart type par rapport à la moyenne, même en cas de perte d'un composant spécifique. Vous pouvez également créer des objectifs pour réduire le temps moyen de restauration (MTTR) pour les types de défaillances connus ; par exemple : les temps de restauration seront réduits de x % si l'un de ces problèmes connus se produit. La création d'objectifs correspondant aux besoins de l'entreprise vous aide à anticiper les types de défaillances que votre application devrait tolérer. Il vous aide également à identifier les approches permettant de réduire le risque de détérioration de votre application.
Si vous pensez à l'objectif de continuer à fonctionner si vous perdez 5 % des instances qui alimentent votre application, vous pouvez déterminer que votre application doit être prédimensionnée ou qu'elle doit être capable d'évoluer suffisamment rapidement pour prendre en charge le trafic supplémentaire généré par cet événement. Vous pouvez également décider de tirer parti de différents modèles architecturaux, comme décrit dans la section Étape 2 : Conception et mise en œuvre.
Vous devez également mettre en œuvre des mesures d'observabilité pour vos objectifs commerciaux spécifiques. Par exemple, vous pouvez suivre le taux de commande moyen, le prix moyen des commandes, le nombre moyen d'abonnements ou d'autres indicateurs qui peuvent fournir des informations sur la santé de l'entreprise en fonction du comportement de votre application. En implémentant des fonctionnalités d'observabilité pour votre application, vous pouvez créer des alarmes et prendre des mesures si ces mesures dépassent les limites que vous avez définies. L'observabilité est abordée plus en détail dans la section Étape 4 : Fonctionnement.
