Partager via

Recommandations pour définir des objectifs de fiabilité

  • Article

S’applique à cette recommandation de liste de contrôle Fiabilité Power Platform Well-Architected :

RE:04 Définissez les objectifs 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 créer le modèle d’état. Le modèle d’état définit à quoi ressemblent les états sains, dégradés et malsains.

Ce guide décrit les recommandations pour définir les métriques cibles de disponibilité et de récupération pour les charges de travail critiques. Les objectifs de fiabilité sont dérivés d’exercices en atelier avec les parties prenantes de l’entreprise.

Les objectifs sont améliorés grâce au suivi et aux tests. Travaillez avec vos parties prenantes internes pour établir des attentes réalistes en matière de fiabilité. Cet exercice aidera également les parties prenantes à soutenir vos choix de conception architecturale et à comprendre que vous concevez pour atteindre au mieux les objectifs sur lesquels vous vous êtes mis d’accord.

Microsoft Power Platform gère la plupart niveau infrastructure des préoccupations de disponibilité et de fiabilité pour vous. Toutefois, la disponibilité des charges de travail que vous créez est une responsabilité partagée. Il est important de comprendre que même avec Microsoft engagement envers la haute disponibilité, le risque d’indisponibilité du système n’est jamais nul.

Pensez à utiliser les mesures suivantes pour quantifier les besoins de l’entreprise.

Terme Définition
Objectif de niveau de service (SLO) Un pourcentage cible qui représente l’intégrité du composant et le niveau de fiabilité. Plus le niveau est plus haut, plus le composant est fiable. SLO composite représente la cible globale de l’ensemble de la charge de travail et prend en compte les SLO des composants.
Indicateur niveau de service (SLI) Une métrique émise par un service. Les métriques SLI sont regroupées pour quantifier une valeur SLO.
Contrat de niveau de service (SLA) Un accord contractuel entre le prestataire de services et le client du service. L’accord définit les SLO. Le non-respect de l’accord pourrait avoir des conséquences financières pour le prestataire de services.
Temps moyen de récupération (MTTR) Le temps nécessaire pour restaurer un composant après la détection d’une panne.
Temps moyen entre é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 temps de récupération (RTO) Durée maximale acceptable pendant laquelle une application peut ne pas être disponible après un incident.
Objectif de point de récupération (RPO) La durée maximale acceptable de perte de données lors d’un incident.

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

Stratégies de conception clés

Les discussions techniques ne devraient pas déterminer la manière dont vous définissez les objectifs de fiabilité pour vos flux critiques. Au lieu de cela, les parties prenantes de l’entreprise doivent se concentrer sur leurs besoins et les attentes des utilisateurs finaux de la charge de travail. Les experts techniques aident les parties prenantes à attribuer des valeurs numériques réalistes qui répondent à ces exigences. En échangeant des informations, les experts techniques permettent de discuter et de se mettre d’accord sur des SLO réalisables.

Prenons un exemple de la manière de mapper les exigences à des valeurs numériques mesurables. Les parties prenantes estiment que pour un flux d’utilisateurs critique, une heure d’indisponibilité pendant les heures normales de bureau entraîne une perte de X dollars de revenus mensuels. Ce montant est comparé au coût estimé de la conception d’un flux ayant un SLO de disponibilité de 99,95 % au lieu de 99,9 %. Les décideurs doivent déterminer si le risque de perte de revenus l’emporte sur les coûts supplémentaires et la charge de gestion nécessaire pour s’en protéger.

Suivez ce modèle lorsque vous examinez les flux et créez une liste complète de cibles.

N’oubliez pas que les objectifs de fiabilité diffèrent des objectifs de performances. Les objectifs 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 mesures plus spécifiques pour répondre aux exigences de haut niveau.

Les exigences de fiabilité et de récupération les plus élevées et les mesures 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 aide à identifier les flux critiques impliqués dans ces cibles. Vous pouvez ensuite envisager des objectifs au niveau des composants.

Métriques de disponibilité

Les objectifs de disponibilité correspondent aux métriques SLO, SLA et SLI.

SLO et SLA

Les métriques de disponibilité sont liées aux SLO, que vous utilisez pour définir les SLA. Le SLO de la charge de travail détermine le temps d’arrêt tolérable sur une période donnée ; par exemple, moins d’une heure par mois. Pour vous assurer que vous pouvez atteindre l’objectif SLO, consultez les SLA Microsoft pour chaque composant.

Pour établir vos SLO, pensez à :

  • Exigences non fonctionnelles de votre charge de travail (par exemple, taux de demandes de pointe, utilisateurs simultanés) au cours des 1 à 2 prochaines années.

  • Métriques disponibles sur ce que vous pouvez mesurer, sur une période de temps spécifique. Ces données indiqueront les SLI à spécifier.

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

Définir des SLO appropriés demande du temps et une réflexion approfondie. Les parties prenantes commerciales doivent comprendre la tolérance en matière de fiabilité. Ces commentaires devraient éclairer les cibles.

Valeurs SLA

Le tableau suivant définit les valeurs SLA communes.

SLA Temps d’arrêt par semaine Temps d’arrêt par mois Temps d’arrêt par année
99 % 1.68 heures 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 minutes 4.32 minutes 52.56 minutes
99,999 % 6 secondes 25.9 secondes 5.26 minutes

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

SLI

Considérez les SLI comme des mesures 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 SLI pour chaque flux. Visez si possible trois SLI par flux.

Métriques de récupération

Les cibles 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 SLA Microsoft. Microsoft publie des garanties RTO et RPO uniquement pour certains produits, comme SQL Database.

Les définitions d’objectifs de rétablissement réalistes dépendent de votre analyse des modes de défaillance et vos plans et tests pour la continuité des activités et reprise après sinistre. 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. Expliquez clairement aux parties prenantes que les parties de la charge de travail qui ne sont pas minutieusement testées pour les mesures de récupération ne devraient pas avoir de SLA garantis. Assurez-vous que les parties prenantes comprennent que les objectifs 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 vous adoptez de nouvelles technologies pour améliorer l’expérience utilisateur. Ces changements peuvent augmenter ou diminuer vos mesures de récupération.

Note

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

Élaboration d’un modèle sain

Utilisez les données que vous avez collectées pour vos objectifs 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’état définit les états sains, dégradés et mauvais* pour les flux et les charges de travail. Les États veillent à une priorisation opérationnelle appropriée. Ce modèle est également connu sous le nom de modèle de feu de circulation. Le modèle attribue le vert aux éléments sains, le jaune aux éléments dégradés et le rouge aux éléments malsains. Un modèle d’intégrité garantit que vous savez quand l’état d’un flux passe de sain à dégradé ou malsain.

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

  • Un état vert ou sain indique que les principales exigences et objectifs non fonctionnels sont pleinement satisfaits et que les ressources sont utilisées de manière optimale.

  • Un état jaune ou dégradé indique qu’un ou plusieurs composants du flux émettent une alerte 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 mauvais indique que la dégradation a persisté plus longtemps que ce qui est autorisé par vos objectifs de fiabilité ou que le flux n’est plus disponible.

Note

Le modèle de santé ne devrait pas traiter tous les échecs de la même manière. Le modèle de santé doit faire la distinction entre les défauts transitoires etnon transitoires . Il doit clairement distinguer les pannes attendues, transitoires mais récupérables, et un véritable état de catastrophe.

Ce modèle fonctionne en utilisant une stratégie de surveillance et d’alerte développée et exploitée selon les principes d’amélioration continue. À mesure que vos charges de travail évoluent, vos modèles de santé doivent évoluer avec elles.

Pour obtenir des conseils détaillés sur les configurations de surveillance et d’alerte, consultez le guide de surveillance de l’état .

Visualisation

Pour tenir vos équipes opérationnelles et les parties prenantes de la charge de travail informées de l’état en temps réel et des tendances générales du modèle d’intégrité de la charge de travail, envisagez de créer des tableaux de bord dans votre solution de surveillance. 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, mensuellement ou trimestriellement.

Facilitation de Power Platform

Les contrats SLA Power Platform fournissent les engagements Microsoft en matière de disponibilité et de connectivité. Différents services ont des contrats SLA différents, et parfois les références SKU d’un service ont des contrats SLA différents. Pour plus d’informations, voir Contrats de niveau de service pour les services en ligne.

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

Microsoft Business Applications fournit des fonctionnalités de continuité d'activité et reprise d'activité (BCDR) à tous les environnements de type production dans les application SaaS de Dynamics 365 et Power Platform. Découvrez comment Microsoft garantit la résilience de vos données de production lors de pannes régionales.

Alignement organisationnel

Cloud Adoption Framework fournit des conseils sur les recommandations pour les SLO et les SLI liés à la surveillance au sein de l’organisation.

Pour plus d’informations, voir SLO surveillance cloud.

Liste de contrôle de fiabilité

Référez-vous à l’ensemble complet des recommandations.

Liste de contrôle de fiabilité