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. Vous devez dériver des objectifs de fiabilité des exercices d’atelier avec les parties prenantes de l’entreprise. Affinez ensuite ces cibles en surveillez et testez vos charges de travail.
Définissez des attentes réalistes avec vos parties prenantes internes sur la fiabilité de la charge de travail. Ils peuvent ensuite utiliser des contrats contractuels pour communiquer ces attentes aux clients. 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 cibles sur lesquelles vous êtes d’accord.
Envisagez d’utiliser les métriques suivantes pour quantifier vos besoins 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 que vous définissez pour des interactions client particulières. Il s’agit d’une cible que vous définissez pour votre charge de travail ou votre application en fonction de la qualité de service que vos clients s’attendent à recevoir. |
| Indicateur de niveau de service (SLI) | Mesure quantitative d’un aspect particulier des performances d’un service. Vous pouvez utiliser un SLI pour mesurer la conformité de votre charge de travail avec un 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. |
Stratégies de conception
Les cibles de fiabilité représentent l’objectif de qualité souhaité d’une charge de travail, comme promis à ses utilisateurs et aux parties prenantes de l’entreprise. Cet objectif inclut la disponibilité et la récupération de la charge de travail. N’oubliez pas que les cibles de fiabilité diffèrent des cibles de performances, mais vous devez inclure des cibles de performances dans des cibles de fiabilité. Tenez compte des cibles de fiabilité suivantes :
Les objectifs de disponibilité définissent les normes de qualité pour qu’un système reste accessible et fonctionnel. S’il ne répond pas à ces normes, le système est considéré comme non fiable. Utilisez des contrats SLA pour vérifier si votre système répond à ces normes. Les parties prenantes métier et techniques collaborent pour définir des contrats SLA réalistes et prendre en compte des facteurs tels que l’analyse comparative, l’expérience utilisateur et le profil de charge de travail.
Les cibles d’exactitude garantissent que la charge de travail effectue correctement ses fonctions avec une qualité cohérente. Pour mesurer l’exactitude, quantifiez les indicateurs de la charge de travail afin de pouvoir les combiner en un score objectif unifié.
Les cibles de récupération correspondent aux métriques RTO, RPO, MTTR et MTBF, qui quantifient l’efficacité de vos plans et tests pour la continuité d’activité et la reprise d’activité.
Pour définir des cibles de fiabilité, les parties prenantes métier définissent des exigences générales. Ensuite, les experts techniques évaluent l’état actuel de la charge de travail et travaillent à atteindre et à maintenir des cibles par le biais de la surveillance et des alertes. Les deux parties doivent s’entendre sur des objectifs réalistes.
Identifiez et notez les flux utilisateur et système en fonction de leur importance pour vos besoins métier. Utilisez ces scores pour guider la conception, la révision, le test et la gestion des incidents de votre charge de travail. Définissez des cibles de fiabilité pour ces flux et comprenez que l’échec de ces cibles peut affecter considérablement votre entreprise.
Compromis : Vous risquez d’avoir un écart entre les limites techniques de votre système et son impact commercial, comme le débit et les transactions par seconde. Combler ce fossé peut être difficile. Visez une solution pratique et rentable au lieu de surengineering.
Définir des objectifs de disponibilité
Le SLO global d’une charge de travail reflète la qualité holistique, y compris toutes ses dépendances. Une déclaration mature du SLO doit indiquer la cible métier globale de cette charge de travail, pas seulement une composite de ces dépendances. Par exemple, si les clients attendent une disponibilité de 99,99 %, le SLO global devrait viser cet objectif, même si une partie atteint seulement 99,80 %.
Les parties prenantes évaluent l’expérience client et réfléchissent à la façon dont les temps d’arrêt affectent les revenus. Ils comparent cette perte au coût de conception et d’exploitation du flux d’affaires. Les décideurs décident ensuite s’ils doivent dépenser plus d’argent sur la fiabilité pour éviter toute perte de revenus et maintenir leur réputation.
Les propriétaires de charge de travail utilisent des objectifs financiers pour déterminer les objectifs. Les exigences métier correspondent à des métriques mesurables. L’objectif est d’identifier un ensemble de facteurs qui influencent la qualité de l’expérience client.
Les architectes de charge de travail prennent de nombreuses décisions techniques basées sur des slaos. Les SLO peuvent :
Servez-vous d’entrée critique dans les décisions architecturales lorsque vous envisagez d’autres dépendances.
Fournissez une vue quasi en temps réel et une compréhension partagée de l’intégrité d’une charge de travail pour permettre des discussions objectives. Ils aident également l’équipe de charge de travail à hiérarchiser les efforts pour améliorer la fiabilité et développer de nouvelles fonctionnalités.
Agissez comme un signal principal pour les opérations de déploiement, ce qui entraîne une restauration automatisée si des problèmes se produisent et fournit la validation que les modifications obtiennent les améliorations attendues de l’expérience client.
Accélérez la correction et la récupération en mettant l’accent sur les objectifs, générez une notification automatisée des problèmes aux clients et créez une confiance entre les équipes de votre organisation.
Important
Vous devez connaître la différence entre les contrats SLA et les contrats SLA. Bien que les contrats SLA et les contrats SLA puissent utiliser ou même présenter des données similaires, leur intention est différente. Un contrat SLA est un contrat formel entre une organisation et ses clients, et il a des implications financières et juridiques directes si l’organisation ne parvient pas à livrer sa promesse. Les organisations utilisent des contrats SLA pour déterminer si le temps d’arrêt potentiel est dans les limites tolérables.
Les contrats SLA et les contrats SLA partagent une relation commerciale et doivent être contrôlés indépendamment. Si le contrat SLA sert de tactique métier, l’organisation peut l’affecter intentionnellement à une valeur élevée en fonction des objectifs du propriétaire de l’entreprise. À l’inverse, les SLO peuvent être plus élevées. Prenons l’exemple des charges de travail stratégiques. Cette classe de charge de travail ne peut pas se permettre de longs temps d’arrêt, car les effets, y compris la perte financière et même les menaces pour la sécurité humaine, sont importants. Par conséquent, les SLO ciblent généralement une durée de fonctionnement de 99,999 %, communément appelées cinq neufs. Si les sla ne répondent pas à ces cibles, les organisations doivent réagir rapidement pour atténuer les défaillances et empêcher les résultats d’un contrat SLA ayant échoué.
L’exemple de cet article définit un contrat SLA élevé pour prendre en charge les objectifs métier.
Les fournisseurs de plateforme et de technologie cloud publient des contrats SLA sur leurs offres. Vous devez considérer les contrats SLA dans le cadre du calcul du SLO, mais vous ne devez pas les utiliser comme c’est le cas sans comprendre l’étendue de la couverture du contrat SLA. Pour plus d’informations, consultez Évaluer l’impact des contrats SLA Microsoft.
Prendre en compte les SLO courantes et les facteurs d’influence
Chaque SLO cible un critère de qualité spécifique. Considérez ces contrats SLA courants pour la fiabilité. Cette liste n’est pas exhaustive. Ajoutez des sla en fonction des besoins de votre entreprise.
Le taux de réussite mesure le succès des demandes et des processus par rapport à ceux qui retournent une erreur ou échouent leur tâche.
La latence mesure le temps entre le moment où une demande d’opération est lancée et lorsque le résultat est disponible ou que le processus est terminé.
La capacité mesure l’utilisation simultanée, comme le nombre de réponses basées sur la limitation.
La disponibilité mesure le temps d’activité du point de vue des clients.
Le débit mesure le taux minimal de transfert de données pendant un certain temps. Le débit est mesuré en tant qu’unité de débit de données, comme les transactions par seconde (TPS) ou les requêtes par seconde (RPS).
Comprendre les scénarios et les tolérances de votre charge de travail sur Azure. Les services Azure et les composants d’application affectent le SLO de charge de travail. Combinez les réponses du tableau suivant pour dériver le SLO global. Utilisez ces questions comme exemples pour évaluer l’utilitaire du composant de charge de travail.
| Caractéristiques des composants | Interaction avec les clients | Autres facteurs |
|---|---|---|
| - Est-ce qu’il expose les API de demande ou de réponse ? - Dispose-t-il d’API de requête ? - Est-ce qu’il s’agit d’un composant de calcul ? - Est-ce qu’il s’agit d’un composant de traitement de travaux ? |
- Contrôle de l’accès au plan de gestion et au plan de gestion pour les services Azure publics. - Accès au plan de données, par exemple, créer, lire, mettre à jour et supprimer (CRUD). |
- Votre processus de mise en production implique-t-il un temps d’arrêt ? - Quelle est la probabilité d’introduire des bogues ? Si la charge de travail s’intègre à d’autres systèmes, vous devrez peut-être prendre en compte les bogues d’intégration. - Comment les opérations de routine telles que la mise à jour corrective affectent-elles la cible de disponibilité ? Avez-vous pris en compte les dépendances des partenaires ? - Votre personnel est-il suffisant pour prendre en charge la rotation constante des urgences et des sauvegardes d’urgence en cas d’appel ? - L’application a-t-elle des voisins bruyants en dehors de votre étendue de contrôle qui peut potentiellement provoquer des perturbations ? |
Déterminer l’étendue SLO
Vous pouvez définir des contrats SLA à différents niveaux, tels que pour chaque application, charge de travail ou flux spécifique, dans votre système. Définissez des slaos spécifiques au niveau pour que vous puissiez personnaliser les SLO en fonction de l’importance de chaque composant.
Dans les solutions SaaS (Software as a Service), mesurez les contrats SLA par client pour optimiser l’expérience de chaque client. Les clients peuvent avoir des ressources d’infrastructure différentes dans leurs segments. Dans ce cas, un SLO à l’échelle du système qui agrège toutes les ressources entre les segments de client peut ne pas être judicieux. Au lieu de cela, mesurez les slaos qui s’alignent sur le contexte spécifique de chaque client. Pour plus d’informations, consultez l’article Modèles de location pour une solution multilocataire.
Définir des cibles SLO composites
Les SLO doivent être mesurables et mesurées dans une fenêtre d’observabilité.
Les sla sont souvent des pourcentages comme 99,90 %, mais ils peuvent également être des instructions. Utilisez les deux méthodes pour obtenir une valeur numérique qui inclut tous les facteurs.
Un SLO se compose de SLA mesurables qui définissent des facteurs acceptables. Les sla sont des métriques avec un seuil défini qui peut être alerté. Vous pouvez les collecter à partir d’une plateforme ou d’une application. Différents composants émettent des SLA pertinents. Lorsque vous choisissez des SLA, tenez compte des facteurs qui influencent le SLO.
Par exemple, pour calculer le SLO d’un flux qui utilise une API de réponse et de requête, mesurez la latence du serveur et le temps de traitement des requêtes. Les débits et les taux d’erreur ne s’appliquent pas aux environnements de calcul continus tels que les machines virtuelles, les groupes identiques ou Azure Batch.
Pour l’accès au plan de contrôle, tenez compte des taux d’erreur et de la latence des réponses d’API et des opérations de longue durée, telles que la création de ressources. L’accès au plan de données dépend des API utilisées, chacune avec leurs propres cibles SLO.
Un bon SLI indique quand vous risquez de violer un SLO. Il est généralement mesuré en centiles. Voici quelques centiles couramment utilisés et le temps estimé de non-conformité à la disponibilité attendue.
| Objectif | Non-conformité par semaine | Non-conformité par mois | Non-conformité par année |
|---|---|---|---|
| 99 % | 1,68 heure | 7,20 heures | 3,65 jours |
| 99,90 % | 10,10 minutes | 43,20 minutes | 8,76 heures |
| 99,95 % | 5 minutes | 21,60 minutes | 4,38 heures |
| 99,99 % | 1,01 minute | 4,32 minutes | 52,56 minutes |
| 99, 999 % | 6 secondes | 25,90 secondes | 5,26 minutes |
Important
Une valeur SLO composite est une distribution de produits des facteurs contributeurs.
Un exemple de SLO composite est de 99,95 % × 99,999999 % = ~99,95 %.
Lorsque vous créez des slaos composites pour différents flux, tenez compte de leur criticité et de leur pertinence différentes. Les flux peuvent avoir des composants que vous jugez non critiques et omettre à partir de vos calculs. Vous pouvez justifier leur omission en fonction du fait que leur brève indisponibilité affecte l’expérience du client. Dans certains cas, un composant peut ne pas être pertinent pour le cas d’usage que vous envisagez pour le SLO. Vous pouvez également omettre ces composants du calcul.
Le même principe s’applique aux opérations. Certaines opérations peuvent introduire des risques ou affecter le SLO, et d’autres sont insignifiantes. La décision devrait être explicite et basée sur un consensus.
Pour obtenir un exemple illustrant comment définir et mesurer des SLA et des SLA, consultez la section Exemple .
Évaluer l’impact des contrats SLA Microsoft
Un contrat SLA Microsoft fournit des informations sur la disponibilité des domaines auxquels Microsoft s’engage. Les contrats SLA ne garantissent pas une offre dans son ensemble. Lorsque vous évaluez des contrats SLA, comprenez bien la couverture fournie autour du centile publié.
Considérez Web Apps, une fonctionnalité d’Azure App Service. La fonctionnalité est considérée comme disponible lorsqu’elle retourne un état 200 OK dans un cas d’usage donné. Dans ce contexte et cette période spécifiques, elle ne couvre pas une garantie financièrement soutenue sur la disponibilité des fonctionnalités telles que l’authentification facile ou le changement d’emplacement. Vous devez considérer les domaines qui ne sont pas mentionnés explicitement dans l’accord comme disponibles par le meilleur effort de la plateforme.
Par conséquent, si votre charge de travail s’appuie sur des emplacements de déploiement, vous ne pouvez pas dériver votre SLO uniquement à partir du contrat SLA App Service. En tant qu’équipe de charge de travail, vous devez couvrir et prédire la disponibilité du temps d’activité. Toutefois, cette prédiction peut être incertaine, c’est pourquoi lier étroitement votre SLO au contrat SLA de la plateforme peut être problématique.
Prenons un autre exemple. Si Azure Front Door dispose d’une disponibilité de 99,99 %, votre conception doit respecter des critères spécifiques publiés dans le contrat. Par exemple, votre back-end doit inclure le stockage, vous avez besoin d’une GET opération qui peut récupérer un fichier d’au moins 50 Ko de taille, et vous devez déployer des agents sur plusieurs emplacements dans au moins cinq emplacements géographiquement différents. Ce cas d’usage étroit d’Azure Front Door ne garantit pas les fonctionnalités telles que la mise en cache, les règles de routage ou un pare-feu d’applications web. Ces aspects se trouvent en dehors de l’étendue du contrat SLA.
Implémenter des cibles multirégions
Du point de vue de la fiabilité, le déploiement multirégion est une implémentation du principe de redondance. L’objectif est d’atténuer le risque de panne régionale ou de dégradation des performances. Cette stratégie, lorsqu’elle est correctement conçue, peut améliorer les SLO, car elle ajoute une région secondaire à des fins de basculement.
Il existe deux cas d’usage principaux :
Modèle de haute disponibilité, dans lequel vous distribuez une charge entre les régions pour plus de capacité. La haute disponibilité ne limite pas les utilisateurs de charge de travail à une région, et les performances de l’ensemble du système contribuent au SLO.
Modèle de cloisonnement, dans lequel vous limitez les clients à des régions spécifiques pour les segmenter. Dans ce cas, traitez les déploiements multirégions comme des déploiements distincts, ou des tampons, dans chaque région. Mesurez l’intégrité de chaque tampon séparément, avec les SLA appropriés à votre charge de travail. Considérez le SLO de votre charge de travail globale en fonction de l’intégrité de chaque tampon. Si vous pouvez basculer entre des tampons, votre SLO de charge de travail globale est plus élevée, car une défaillance d’un tampon est récupérable par le biais d’un basculement vers un autre tampon.
Attention à la redondance dont vous avez besoin pour répondre à des slao é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.
Définir des métriques de récupération
Les définitions des cibles de récupération réalistes, telles que les métriques RTO, RPO, MTTR et MTBF, s’appuient sur votre analyse du mode d’échec et vos plans et tests pour la continuité d’activité et la récupération d’urgence. Lorsque vous définissez ces cibles, tenez compte des garanties de récupération fournies par la plateforme. Microsoft publie des garanties RTO et RPO uniquement pour certains produits, comme Azure SQL Database.
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 lorsque vous ajoutez des clients 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 modèles PaaS (Platform as a Service) ou SaaS peuvent échouer et récupérer sans notification du fournisseur de cloud, et le processus peut être entièrement 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 cinq minutes, ajoutez automatiquement un nouveau nœud au pool. Définissez des seuils pour tous les composants et réfléchissez à ce que la récupération d’un composant spécifique implique, 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, tels que la perte de données ou les interruptions de session pour les clients, des opérations de récupération.
Surveiller et visualiser les cibles
Utilisez les données que vous collectez pour vos cibles de fiabilité pour générer 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. Lorsque l’état change, le modèle doit alerter les parties responsables. Pour obtenir des considérations détaillées sur la conception et les recommandations, consultez les conseils de modélisation d’intégrité.
Pour informer vos équipes opérationnelles et les parties prenantes de la charge de travail, créez une visualisation qui reflète l’état en temps réel et les tendances globales du modèle d’intégrité de la charge de travail. Discutez des solutions de visualisation avec les parties prenantes pour vous assurer que vous fournissez des 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 via 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 produits au sein d’un service ont des contrats SLA différents. Pour plus d’informations, consultez les contrats SLA pour services en ligne.
Le contrat SLA Azure inclut des procédures pour obtenir un crédit de service si votre charge de travail ne répond pas au contrat SLA, ainsi que les définitions de disponibilité pour chaque service. Cet aspect du contrat SLA agit comme une stratégie d’application.
Explorez les tableaux de bord Azure Monitor pour votre système de visualisation.
Exemple
Contoso, Ltd. conçoit une nouvelle expérience mobile pour son système de tickets d’événements. Voici l’architecture de haut niveau.
Le logo Grafana est une marque déposée de son entreprise respective. L’utilisation de cette marque n’implique aucune approbation de sa part.
Composants
Voici quelques composants qui illustrent le concept de définition de SLO. Il existe des composants dans cette architecture qui ne sont pas inclus dans la liste suivante. Par exemple, même si Key Vault fait partie du flux de requête critique, il ne fait pas partie du cas d’usage de la réponse. Si Key Vault n’est pas disponible, l’application continue de fonctionner à l’aide de secrets chargés au démarrage. Toutefois, si l’application doit être mise à l’échelle, la disponibilité de Key Vault devient critique, car les nouveaux nœuds doivent être chargés avec des secrets. Dans cet exemple, les opérations de mise à l’échelle ne sont pas prises en compte. D’autres composants sont omis pour la concision.
Azure Front Door est le point d’entrée unique qui expose une API que les clients utilisent pour envoyer des demandes.
Azure Container Apps est l’environnement que l’équipe de charge de travail possède et utilise pour exécuter la logique métier pour l’application.
SQL Managed Instance est détenu et géré par une autre équipe et est une dépendance critique de la charge de travail.
Azure Private Link fournit une connectivité privée entre les déploiements Azure Front Door et Container Apps. SQL Managed Instance est également exposé à l’application via un point de terminaison privé.
Dans cette architecture, l’équipe d’API définit une cible SLO initiale pour les flux critiques dans l’application. Ils adoptent la stratégie décrite dans Facteurs qui influencent les SLO. Ils visent à définir des objectifs qui couvrent les fonctionnalités principales sans insister sur les fonctionnalités supplémentaires. Ils mesurent l’intégrité de trois flux d’utilisateurs critiques, qui impliquent toutes les fonctionnalités cloud principales et exécutent du code entre les déploiements. Toutefois, ces flux ne couvrent pas tout le code ou l’accès aux données. Voici les facteurs d’influence.
Calculer un SLO composite
SLO de disponibilité Azure : le contrat SLA d’engagement financier pour Azure sert de proxy pour évaluer la fiabilité de la plateforme.
Composant Azure Couverture du contrat SLA applicable Non couvert par le contrat SLA SLO ajusté Azure Front Door 99,99 % pour les opérations HTTP GETréussiesMise en cache, moteur de règles 99.98% Applications de conteneur 99,95 % en fonction des applications déployées accessibles par l’entrée intégrée Mise à l’échelle automatique, fonctionnalités de magasin de jetons 99.95% SQL Managed Instance 99,99 % en fonction de la connexion à l’instance SQL Server Performances, rétention des données 99.80% Liaison privée 99,99 % en fonction des minutes entières lorsque le réseau de point de terminaison privé n’a pas accepté le trafic ou lorsque le trafic n’a pas transité entre le point de terminaison et le service Private Link Défaillances individuelles de moins d’une minute 99,99 % L’ajustement est basé sur plusieurs facteurs qui dépendent de la promesse de l’équipe de charge de travail à leurs objectifs. Un facteur peut être sûr de la capacité de la plateforme en fonction de l’expérience précédente. Par exemple, pour Container Apps et Private Link, l’équipe se sent à l’aise de prendre la valeur sla telle quelle.
Il existe également des facteurs nuanceux. Par exemple, l’équipe réduit la valeur SLO de SQL Managed Instance à 99,80 % pour tenir compte des défaillances potentielles de leurs opérations de données, telles que les modifications de schéma et la prise de sauvegardes.
L’équipe définit le SLO composite en calculant l’impact des valeurs SLO individuelles ajustées. Cette valeur est de 99,72 %.
Il existe d’autres facteurs de contribution. L’architecture s’appuie sur des composants réseau Azure tels que des réseaux virtuels et des groupes de sécurité réseau (NSG) qui n’ont pas de contrat SLA publié. L’équipe de charge de travail décide de prendre en compte ces facteurs avec une disponibilité de 99,99 % pour chaque composant.
Un SLO composite basé sur la disponibilité prédite de la plateforme : 99,68 % par mois.
SLO du code d’application : l’équipe reconnaît que les bogues dans leur code d’application ou les procédures stockées peuvent affecter la disponibilité du système et qu’ils allouent une heure de temps d’arrêt mensuel pour prendre en compte les erreurs liées au code.
Ils utilisent des centiles de temps d’arrêt courants pour estimer le SLO pour des facteurs individuels tels que les défauts de code, les problèmes de mise à l’échelle et d’autres considérations liées au code.
Un SLO composite basé sur le code et la disponibilité des données : 99,86 % par mois.
SLO de configuration des ressources et des applications : l’équipe reconnaît que les ressources cloud et le code d’application doivent être correctement configurés. Cette cible inclut la configuration des règles de mise à l’échelle automatique, le déploiement de règles de groupe de sécurité réseau et la sélection de la taille correcte des références SKU. Pour tenir compte des erreurs de configuration, ils budgetent 10 minutes de temps d’arrêt mensuel, soit environ 99,98 % de disponibilité.
Un SLO composite basé sur la disponibilité de la configuration : 99,95 % par mois.
SLO Des opérations : l’équipe de charge de travail développe une bonne culture DevOps en suivant les principes de l’infrastructure bien architected pour l’excellence opérationnelle. Ils déploient des ressources cloud, une configuration et du code chaque sprint.
L’équipe considère que les déploiements sont un risque, car ils peuvent déstabiliser un système en cours d’exécution. Il peut y avoir des erreurs en raison des mises à jour de certificat TLS, des modifications DNS ou des erreurs d’outil. L’équipe considère également les temps d’arrêt potentiels causés par les correctifs d’urgence. Ils budgetent un total de 20 minutes de temps d’arrêt mensuel, soit environ 99,95 % de disponibilité.
Les fenêtres de maintenance sont des périodes désignées pendant lesquelles la maintenance ou les mises à jour du système se produisent. L’API est principalement inutilisée pendant environ quatre heures par jour. Pour réduire le risque d’indisponibilité, l’équipe peut planifier des tâches de maintenance pendant ces heures moins actives. Cette approche conduit à un SLO plus élevé, mais l’équipe décide de ne pas inclure la fenêtre de maintenance dans le cadre de son SLO.
Un SLO composite basé sur la disponibilité des opérations : 99,95 % par mois.
SLO des dépendances externes : l’équipe considère SQL Managed Instance comme la dépendance principale, qui a déjà une disponibilité de 99,80 % dans la disponibilité globale de la plateforme. Aucune autre dépendance externe n’est prise en compte.
Un SLO composite basé sur des dépendances externes : non applicable.
Déterminer le résultat SLO composite global
La cible SLO composite globale est définie à 99,45 %, ce qui équivaut à environ quatre heures de temps d’arrêt par mois.
Pour atteindre la cible SLO de seulement quatre heures d’indisponibilité par mois, l’équipe de charge de travail établit une rotation des appels. Le support client et la surveillance des transactions synthétiques peuvent appeler la prise en charge de l’ingénierie de fiabilité du site d’appel (SRE) pour démarrer rapidement les étapes de récupération pour résoudre les problèmes de SLO.
Définir le contrat SLA de charge de travail
Le contrat SLA pour la charge de travail est de 99,90 % de disponibilité par mois.
Les services juridiques et financiers de l’équipe de charge de travail définissent le contrat SLA pour la charge de travail à 99,90 % de disponibilité par mois, ce qui dépasse la cible SLO de 99,45 %. Ils font cette décision après avoir analysé les paiements financiers par rapport à la croissance projetée des clients en fonction d’un contrat SLA attrayant. Le contrat SLA couvre deux flux d’utilisateurs principaux et inclut des considérations sur les performances, pas seulement la disponibilité. Il s’agit d’un risque calculé pris par l’équipe métier pour bénéficier de l’entreprise, et l’équipe d’ingénierie est consciente de l’engagement.
Définir le SLO d’exactitude
Les flux d’utilisateurs principaux de l’application doivent être disponibles et utilisables, voire concurrentiels. L’équipe définit un SLO de temps de réponse spécifiquement pour l’API, à l’exclusion du temps de traitement du client et de la traversée réseau Internet. Ils évaluent ce SLO uniquement pendant les périodes de disponibilité. Ils choisissent le 75e centile comme cible SLO et la mesure des performances, qui capture l’expérience client classique et exclut les pires scénarios.
Liens connexes
Modélisation et observation de l’intégrité des charges de travail stratégiques sur Azure
Liste de contrôle de fiabilité
Reportez-vous à l’ensemble complet de recommandations.