Recommandations pour la définition des cibles de fiabilité

S’applique à cette recommandation de liste de vérification de fiabilité Azure Well-Architected Framework :

RE :04	Définissez des objectifs de fiabilité et de récupération pour les composants, les flux et la solution globale. Visualisez les cibles à négocier, à obtenir un consensus, à définir des attentes et à mener des actions pour atteindre l’état idéal. Utilisez les cibles définies pour générer le modèle d’intégrité. Le modèle d’intégrité définit à quoi ressemblent les états sains, détériorés et non sains.

Ce guide décrit les recommandations pour définir des métriques de cible de disponibilité et de récupération pour les charges de travail et les flux critiques. Les objectifs de fiabilité sont dérivés d’exercices en atelier avec les parties prenantes de l’entreprise. Les cibles sont affinées par le biais de la surveillance et des tests.

Avec vos parties prenantes internes, définissez des attentes réalistes en matière de fiabilité de la charge de travail afin que les parties prenantes puissent communiquer ces attentes aux clients par le biais d’accords contractuels. Des attentes réalistes aident également les parties prenantes à comprendre et à prendre en charge vos décisions en matière de conception architecturale et à savoir que vous concevez pour atteindre de manière optimale les objectifs que vous avez convenus.

Envisagez d’utiliser les métriques suivantes pour quantifier les exigences métier.

Terme	Définition
Objectif de niveau de service (SLO)	Cible de pourcentage qui représente l’intégrité du composant et le niveau de fiabilité. Plus le niveau est élevé, plus le composant est fiable. Le SLO composite représente la cible agrégée de l’ensemble de la charge de travail et prend en compte les SLO du composant.
Indicateur de niveau de service (SLI)	Métrique émise par un service. Les métriques SLI sont agrégées pour quantifier une valeur SLO.
Contrat de niveau de service (SLA)	Un accord contractuel entre le fournisseur de services et le client du service. Le contrat définit les SLO. Le non-respect de l’accord peut avoir des conséquences financières pour le fournisseur de services.
Temps moyen de récupération (MTTR)	Temps nécessaire à la restauration d’un composant après la détection d’une défaillance.
Temps moyen entre l’échec (MTBF)	Durée pendant laquelle la charge de travail peut exécuter la fonction attendue sans interruption, jusqu’à ce qu’elle échoue.
Objectif de délai de récupération (RTO)	Il s’agit de la durée maximale acceptable pendant laquelle une application peut être indisponible après un incident.
Objectif de point de récupération (RPO)	Durée maximale acceptable de perte de données pendant un incident.

Définissez les valeurs cibles de la charge de travail pour ces métriques dans le contexte des flux d’utilisateurs et des flux système. Identifiez et notez ces flux en fonction de leur importance pour vos besoins. Utilisez les valeurs pour piloter la conception de votre charge de travail en termes d’architecture, de révision, de test et d’opérations de gestion des incidents. Le non-respect des objectifs affectera l’entreprise au-delà du niveau de tolérance.

Stratégies de conception

Les discussions techniques ne doivent pas déterminer la façon dont vous définissez des objectifs de fiabilité pour vos flux critiques. Au lieu de cela, les parties prenantes de l’entreprise doivent se concentrer sur les clients pendant qu’ils définissent les exigences d’une charge de travail. Les experts techniques aident les parties prenantes à attribuer des valeurs numériques réalistes qui correspondent à ces exigences. À mesure qu’ils partagent leurs connaissances, les experts techniques permettent la négociation et le consensus mutuel sur les SLO réalistes.

Prenons un exemple montrant comment mapper les exigences à des valeurs numériques mesurables. Les parties prenantes estiment que pour un flux d’utilisateur critique, une heure de temps d’arrêt pendant les heures normales de bureau entraîne une perte de X dollars en revenus mensuels. Ce montant en dollars est comparé au coût estimé de conception d’un flux dont le SLO de disponibilité est de 99,95 % au lieu de 99,9 %. Les décideurs doivent déterminer si le risque de cette perte de revenus l’emporte sur les coûts supplémentaires et le fardeau de gestion requis pour se protéger contre cette perte. Suivez ce modèle lorsque vous examinez les flux et créez une liste complète des cibles.

N’oubliez pas que les objectifs de fiabilité diffèrent des objectifs de performances. Les cibles de fiabilité se concentrent sur la disponibilité et la récupération. Pour définir des objectifs de fiabilité, commencez par définir les exigences les plus larges, puis définissez des métriques plus spécifiques pour répondre aux exigences générales.

Les exigences de fiabilité et de récupération les plus élevées et les métriques corrélées peuvent inclure, par exemple, une disponibilité des applications de 99,9 % pour toutes les régions ou un RTO cible de 5 heures pour la région Amériques. La définition de ces types de cibles vous permet d’identifier les flux critiques impliqués dans ces cibles. Vous pouvez ensuite envisager des cibles au niveau du composant.

Compromis : un écart conceptuel peut exister entre les limitations techniques des composants de votre charge de travail et ce que cela signifie pour l’entreprise, par exemple, le débit en mégabits par seconde par seconde par rapport aux transactions par seconde. La création d’un modèle entre ces deux vues peut être difficile. Plutôt que de suringénier la solution, essayez de l’aborder de manière économique mais significative.

Métriques de disponibilité

SLO et CONTRATS DE NIVEAU DE SERVICE

Les métriques de disponibilité sont corrélées aux SLO, que vous utilisez pour définir des contrats SLA. Le SLO de charge de travail détermine la quantité de temps d’arrêt tolérable pendant une période donnée, par exemple, moins d’une heure par mois. Pour vous assurer que vous pouvez atteindre la cible SLO, passez en revue les contrats SLA Microsoft pour chaque composant. Faites attention à la quantité de redondance dont vous avez besoin pour respecter des contrats SLA élevés. Par exemple, Microsoft garantit des contrats SLA plus élevés pour les déploiements multirégions d’Azure Cosmos DB que pour les déploiements dans une seule région.

Notes

Les contrats SLA Azure ne couvrent pas toujours tous les aspects d’un service. Par exemple, Azure Application Gateway dispose d’un contrat SLA de disponibilité, mais la fonctionnalité Azure Web Application Firewall n’offre aucune garantie d’empêcher le trafic malveillant de passer. Tenez compte de cette limitation lorsque vous développez vos contrats SLA et vos SLO.

Après avoir rassemblé les contrats SLA pour les composants de charge de travail individuels, calculez un contrat SLA composite. Le contrat SLA composite doit correspondre au SLO cible de la charge de travail. Le calcul d’un contrat SLA composite implique plusieurs facteurs, en fonction de la conception de votre architecture. Voici quelques exemples.

Notes

Les valeurs du contrat SLA dans les exemples suivants sont hypothétiques et servent uniquement à des fins de démonstration. Elles ne sont pas destinées à représenter les valeurs actuelles prises en charge par Microsoft.

Les contrats SLA composites impliquent plusieurs services qui prennent en charge une application, avec des niveaux de disponibilité différents. Prenons l’exemple d’une application web Azure App Service qui écrit dans Azure SQL Database. Hypothétiquement, ces contrats SLA peuvent être les suivants :

• App Service applications web = 99,95 %
• SQL Database = 99,99 %

Quel est le temps d’arrêt maximal que vous pouvez attendre pour cette application ? En cas d’échec d’un service, l’application entière échoue. La probabilité de l’échec de chaque service étant indépendante, le contrat SLA composite pour cette application est de 99,95 % × 99,99 % = 99,94 %. Cette valeur est inférieure aux contrats SLA individuels. Cette conclusion n’est pas surprenant, car une application qui s’appuie sur plusieurs services a plus de points de défaillance potentiels.

Vous pouvez améliorer le contrat SLA composite en créant des chemins d’accès de secours indépendants. Par exemple, si SQL Database n’est pas disponible, placez des transactions dans une file d’attente pour un traitement ultérieur :

Dans cette conception, l’application est toujours disponible même si elle ne peut pas se connecter à la base de données. Toutefois, elle échoue si la base de données et la file d’attente échouent en même temps. Le pourcentage de temps attendu pour une défaillance simultanée est de 0,0001 × 0,001. Voici donc le contrat SLA composite pour ce chemin combiné :

Base de données ou file d’attente = 1,0 − (0,0001 × 0,001) = 99,99999 %

Le contrat SLA composite total :

Application web et (base de données ou file d’attente) = 99,95 % × 99,99999 % = ~99,95 %

Cette approche présente des compromis :

• La logique d’application est plus complexe.
• Vous payez pour la file d’attente.
• Vous devez prendre en compte les problèmes de cohérence des données.

Pour les déploiements multirégions, le contrat SLA composite est calculé comme suit :

• N est le contrat SLA composite pour l’application déployée dans une région.

• R est le nombre de régions où l’application est déployée.

Le risque que l’application échoue dans toutes les régions en même temps est ((1 − N) ^ R). Par exemple, si le contrat SLA hypothétique à région unique est de 99,95 % :

• Contrat SLA combiné pour deux régions = (1 − (1 − 0,9995) ^ 2) = 99,999975 %

• Le contrat SLA combiné pour quatre régions = (1 − (1 − 0,9995) ^ 4) = 99,999999 %

La définition des SLO appropriés nécessite du temps et une attention particulière. Les parties prenantes de l’entreprise doivent comprendre comment les clients clés utilisent l’application. Ils doivent également comprendre la tolérance de fiabilité. Ces commentaires doivent informer les cibles.

Valeurs SLA

Le tableau suivant définit les valeurs sla courantes.

Contrat SLA	Temps d’arrêt par semaine	Temps d’arrêt par mois	Temps d’arrêt par an
99 %	1,68 heure	7,2 heures	3,65 jours
99,9 %	10,1 minutes	43,2 minutes	8,76 heures
99,95 %	5 minutes	21,6 minutes	4,38 heures
99,99 %	1,01 minute	4,32 minutes	52,56 minutes
99, 999 %	6 secondes	25,9 secondes	5,26 minutes

Lorsque vous pensez aux contrats SLA composites dans le contexte des flux, n’oubliez pas que les différents flux ont des définitions de criticité différentes. Tenez compte de ces différences lorsque vous créez vos contrats SLA composites. Les flux non critiques peuvent avoir des composants que vous devez omettre de vos calculs, car ils n’affectent pas l’expérience client s’ils sont brièvement indisponibles.

Notes

Les charges de travail orientées client et les charges de travail à usage interne ont des SLO différentes. En règle générale, les charges de travail à usage interne peuvent avoir des SLO de disponibilité beaucoup moins restrictives que les charges de travail orientées client.

Indicateurs de niveau de service (SLA)

Considérez les SLO comme des métriques au niveau des composants qui contribuent à un SLO. Les SLI les plus significatifs sont ceux qui affectent vos flux critiques du point de vue de vos clients. Pour de nombreux flux, les SLI incluent la latence, le débit, le taux d’erreur et la disponibilité. Un bon SLI vous aide à identifier quand un SLO risque d’être violé. Corrélez le SLI à des clients spécifiques lorsque cela est possible.

Pour éviter de collecter des métriques inutiles, limitez le nombre de SLO pour chaque flux. Si possible, visez trois SLI par flux.

Métriques de récupération

Les objectifs de récupération correspondent aux métriques RTO, RPO, MTTR et MTBF. Contrairement aux objectifs de disponibilité, les objectifs de récupération pour ces mesures ne dépendent pas fortement des contrats SLA Microsoft. Microsoft publie des garanties RTO et RPO uniquement pour certains produits, comme SQL Database.

Les définitions des objectifs de récupération réalistes s’appuient sur votre analyse du mode d’échec et vos plans et tests de continuité d’activité et de reprise d’activité. Avant de terminer ce travail, discutez des objectifs ambitieux avec les parties prenantes et assurez-vous que la conception de votre architecture prend en charge les objectifs de récupération au mieux de votre compréhension. Indiquez clairement aux parties prenantes que les flux ou charges de travail entières qui ne sont pas testés de manière approfondie pour les métriques de récupération ne doivent pas avoir de SLA garantis. Assurez-vous que les parties prenantes comprennent que les cibles de récupération peuvent changer au fil du temps à mesure que les charges de travail sont mises à jour. La charge de travail peut devenir plus complexe à mesure que des clients sont ajoutés ou que vous adoptez de nouvelles technologies pour améliorer l’expérience client. Ces modifications peuvent augmenter ou diminuer vos métriques de récupération.

Notes

MTBF peut être difficile à définir et à garantir. Les plateformes en tant que service (PaaS) ou SaaS (Software as a Service) peuvent échouer et récupérer sans notification du fournisseur de cloud, et le processus peut être totalement transparent pour vous ou vos clients. Si vous définissez des cibles pour cette métrique, couvrez uniquement les composants qui sont sous votre contrôle.

Lorsque vous définissez des objectifs de récupération, définissez des seuils pour lancer une récupération. Par exemple, si un nœud web n’est pas disponible pendant plus de 5 minutes, un nouveau nœud est automatiquement ajouté au pool. Définissez des seuils pour tous les composants, en tenant compte de ce qu’implique la récupération d’un composant spécifique, y compris l’effet sur d’autres composants et dépendances. Vos seuils doivent également tenir compte des erreurs temporaires pour vous assurer que vous ne démarrez pas les actions de récupération trop rapidement. Documentez et partagez avec les parties prenantes les risques potentiels des opérations de récupération, comme la perte de données ou les interruptions de session pour les clients.

Génération d’un modèle d’intégrité

Utilisez les données que vous avez collectées pour vos cibles de fiabilité afin de créer votre modèle d’intégrité pour chaque charge de travail et les flux critiques associés. Un modèle d’intégrité définit des états sains, dégradés et non sains pour les flux et les charges de travail. Les états garantissent une hiérarchisation opérationnelle appropriée. Ce modèle est également appelé modèle de feu de trafic. Le modèle affecte le vert pour l’intégrité, le jaune pour la dégradation et le rouge pour la mauvaise santé. Un modèle d’intégrité garantit que vous savez quand l’état d’un flux passe de sain à dégradé ou non sain.

La façon dont vous définissez des états sains, dégradés et non sains dépend de vos objectifs de fiabilité. Voici quelques exemples de façons de définir les états :

• Un état vert ou sain indique que les exigences et cibles non fonctionnelles clés sont entièrement satisfaites et que les ressources sont utilisées de manière optimale. Par exemple, 95 % des requêtes sont traitées dans <=500 ms avec Azure Kubernetes Service nœud (AKS) utilisé à X %.

• Un état jaune ou dégradé indique qu’un ou plusieurs composants du flux alertent par rapport à leur seuil défini, mais que le flux est opérationnel. Par exemple, une limitation du stockage a été détectée.

• Un état rouge ou défectueux indique que la dégradation a persisté plus longtemps que ce qui est autorisé par vos objectifs de fiabilité ou que le flux est devenu indisponible.

Notes

Le modèle d’intégrité ne doit pas traiter toutes les défaillances de la même façon. Le modèle d’intégrité doit faire la distinction entre les erreurs temporaires et nontransientes . Il doit clairement faire la distinction entre les défaillances temporaires prévues mais récupérables et un véritable état de sinistre.

Ce modèle fonctionne à l’aide d’une stratégie de surveillance et d’alerte qui est développée et appliquée selon les principes de l’amélioration continue. À mesure que vos charges de travail évoluent, vos modèles d’intégrité doivent évoluer avec eux.

Pour obtenir des considérations et des recommandations détaillées sur la conception d’un modèle d’intégrité d’application en couches, consultez les conseils de modélisation de l’intégrité disponibles dans les domaines de conception de charge de travail stratégiques. Pour obtenir des conseils détaillés sur la surveillance et les configurations d’alerte, consultez le guide de surveillance de l’intégrité .

Visualisation

Pour tenir vos équipes opérationnelles et les parties prenantes de charge de travail informées de la status en temps réel et des tendances globales du modèle d’intégrité de la charge de travail, envisagez de créer des tableaux de bord dans votre solution de supervision. Discutez des solutions de visualisation avec les parties prenantes pour vous assurer que vous fournissez les informations qu’elles apprécient et qui sont faciles à utiliser. Ils peuvent également souhaiter voir les rapports générés hebdomadaires, mensuels ou trimestriels.

Facilitation Azure

Les contrats SLA Azure fournissent les engagements Microsoft en matière de temps de fonctionnement et de connectivité. Différents services ont des SLA différents, et parfois, les références SKU au sein d’un service ont des SLA différents. Pour plus d’informations, consultez Contrats de niveau de service pour services en ligne.

Le contrat SLA Azure inclut des procédures permettant d’obtenir un crédit de service si le contrat SLA n’est pas respecté, ainsi que des définitions de disponibilité pour chaque service. Cet aspect du contrat SLA agit comme une stratégie d’application.

Alignement organisationnel

Cloud Adoption Framework fournit des conseils pour les recommandations pour les SLO et les SLO liés à la surveillance dans l’ensemble des organization.

Pour plus d’informations, consultez SLO de supervision cloud.

Liens connexes

• Conseils stratégiques de Well-Architected Framework pour la modélisation de l’intégrité : Modélisation de l’intégrité et observabilité des charges de travail stratégiques sur Azure

Liste de contrôle de fiabilité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de fiabilité