Recommandations pour définir des cibles de fiabilité

S’applique à cette recommandation de liste de contrôle de fiabilité d’Azure Well-Architected Framework :

RE :04	Définissez des cibles de fiabilité et de récupération pour les composants, les flux et la solution globale. Visualisez les cibles pour 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 les états sains, détériorés et non sains.

Ce guide décrit les recommandations relatives à la définition des métriques cibles de disponibilité et de récupération pour les charges de travail et les flux critiques. Les cibles de fiabilité sont dérivées par le biais d’exercices d’ateliers 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é des charges de travail afin que les parties prenantes puissent communiquer ces attentes aux clients par le biais d’accords contractuels. Les attentes réalistes aident également les parties prenantes à comprendre et à prendre en charge vos décisions de conception architecturale et à savoir que vous concevez pour répondre de manière optimale aux 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)	Mesure des performances et de la fiabilité d’une charge de travail ou d’une application. Un SLO est une cible spécifique et mesurable définie pour des interactions client particulières. Il s’agit d’une cible que vous définissez pour votre charge de travail sur l’application en fonction de la qualité du service que vos utilisateurs doivent s’attendre à recevoir.
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)	Accord contractuel entre le fournisseur de services et le client de service. 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 pour restaurer un composant après la détection d’un échec.
Temps moyen entre l’échec (MTBF)	Durée pendant laquelle la charge de travail peut effectuer 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 la 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 utilisateur 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 fait de ne pas atteindre les cibles affectera l’entreprise au-delà du niveau de tolérance.

Stratégies de conception

Les discussions techniques ne doivent pas déterminer comment vous définissez des cibles de fiabilité pour vos flux critiques. Au lieu de cela, les parties prenantes de l’entreprise doivent se concentrer sur les clients quand 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 des connaissances, les experts techniques permettent la négociation et le consensus mutuel sur les SLO réalistes.

Prenons un exemple de la façon de mapper les exigences à des valeurs numériques mesurables. Les parties prenantes estiment que pour un flux d’utilisateurs critique, une heure de temps d’arrêt pendant les heures d’activité régulières entraîne une perte de X dollars en revenus mensuels. Ce montant en dollars est comparé au coût estimé de la conception d’un flux qui a un SLO de disponibilité de 99,95 % au lieu de 99,9 %. Les décideurs doivent déterminer si le risque de cette perte de revenus dépasse les coûts ajoutés et le fardeau de gestion requis pour se protéger contre celui-ci. Suivez ce modèle lorsque vous examinez les flux et générez une liste complète des cibles.

N’oubliez pas que les cibles de fiabilité diffèrent des cibles de performances. Les cibles de fiabilité se concentrent sur la disponibilité et la récupération. Pour définir des cibles 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é d’application 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 et les transactions par seconde. La création d’un modèle entre ces deux vues peut être difficile. Plutôt que de surengineer la solution, essayez de l’aborder de manière économique mais significative.

Métriques de disponibilité

SLA et contrats SLA

Un SLO est une mesure des performances et de la fiabilité d’une charge de travail ou d’une application. Un SLO est une cible spécifique et mesurable définie pour des interactions client particulières. Il s’agit d’une cible que vous définissez pour votre charge de travail ou votre application sur la qualité du service que vos utilisateurs doivent recevoir.

Un SLO peut être défini en termes de diverses métriques, telles que la disponibilité, le temps de réponse, le débit, le taux de réussite et d’autres. Par exemple, un SLO pour un service web peut être qu’il sera disponible pour les utilisateurs 99,9 % du temps d’un mois donné, ou qu’il répondra à 95 % des demandes dans les 500 millisecondes.

Avant de définir les contrats SLA pour votre application ou votre charge de travail, passez en revue les contrats SLA publiés par Microsoft pour les services sous-jacents sur utilisant votre application ou votre charge de travail.

Remarque

Les contrats SLA de service Microsoft ne sont pas des SLA de plateforme ni des slaos

Lorsque vous passez en revue le contrat SLA pour chaque service, faites attention à la redondance dont vous avez besoin pour répondre à 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 à une seule région.

Remarque

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é pare-feu d’applications web Azure 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 contrats SLA.

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 votre conception d’architecture. Voici quelques exemples.

Remarque

Les valeurs sla dans les exemples suivants sont hypothétiques et sont uniquement à des fins de démonstration. Ils ne sont pas destinés à représenter les valeurs actuelles prises en charge par Microsoft.

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

• Applications web App Service = 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é d’échec de chaque service est indépendante. Par conséquent, 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 inattendue, car une application qui s’appuie sur plusieurs services a plus de points d’échec 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 le contrat SLA composite pour ce chemin combiné :

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

Le contrat SLA composite total :

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

Cette approche pose 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 à une seule région hypothétique 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,9999999 %

La définition d’un contrat SLA approprié prend du temps et prend soin d’être prise en compte. 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 du contrat 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 différents flux ont des définitions de criticité différentes. Tenez compte de ces différences lorsque vous générez 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.

Remarque

Les charges de travail orientées client et les charges de travail d’utilisation interne ont des contrats SLA différents. En règle générale, les charges de travail d’utilisation interne peuvent avoir des sla de disponibilité beaucoup moins restrictives que les charges de travail orientées client.

SLA

Considérez les sla comme des métriques au niveau des composants qui contribuent à un SLO. Les sla les plus significatifs sont ceux qui affectent vos flux critiques du point de vue de vos clients. Pour de nombreux flux, les SLA 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 enfreint. Mettre en corrélation le SLI à des clients spécifiques quand c’est possible.

Pour éviter de collecter des métriques inutiles, limitez le nombre de SLA pour chaque flux. Visez trois SLA par flux si possible.

Métriques de récupération

Les cibles de récupération correspondent aux métriques RTO, RPO, MTTR et MTBF. Contrairement aux cibles de disponibilité, les cibles 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 cibles de récupération réalistes s’appuient sur votre analyse du mode d’échec et vos plans et tests pour la continuité d’activité et la reprise d’activité. Avant de terminer ce travail, discutez des cibles aspirationnelles avec les parties prenantes et assurez-vous que votre conception d’architecture prend en charge les cibles de récupération au mieux de votre compréhension. Communiquez clairement aux parties prenantes que les flux ou charges de travail entières qui ne sont pas soigneusement testés pour les métriques de récupération ne doivent pas avoir garanti des contrats SLA. 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 les 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.

Remarque

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 complètement 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 cibles 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, compte tenu de 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.

Création d’un modèle d’intégrité

Utilisez les données que vous avez collectées pour vos cibles de fiabilité pour 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étériorés et non sains pour les flux et charges de travail. Les états garantissent une hiérarchisation opérationnelle appropriée. Ce modèle est également appelé modèle de lumière du trafic. Le modèle affecte le vert pour sain, jaune pour détérioré et rouge pour non sain. Un modèle d’intégrité garantit que vous savez quand l’état d’un flux passe de sain à détérioré ou non sain.

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

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

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

• Un état rouge ou non sain indique que la dégradation a persisté plus longtemps que autorisée par vos cibles de fiabilité ou que le flux n’est plus disponible.

Remarque

Le modèle d’intégrité ne doit pas traiter toutes les défaillances identiques. 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 développée et exploitée sur les principes d’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 détaillées sur la conception et des recommandations relatives à un modèle d’intégrité d’application en couches, consultez les instructions de modélisation de l’intégrité trouvées dans les domaines de conception de la charge de travail stratégique. Pour obtenir des instructions détaillées sur la surveillance et les configurations d’alerte, consultez le guide de surveillance de l’intégrité.

Visualisation

Pour informer vos équipes opérationnelles et les parties prenantes de la charge de travail sur l’état en temps réel et les 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 à consommer. Ils peuvent également souhaiter voir les rapports générés hebdomadairement, mensuels ou trimestriels.

Facilitation Azure

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

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

Liens connexes

• Conseils stratégiques du Framework bien architecte pour la modélisation de l’intégrité : modélisation de l’intégrité et observation 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é