Stratégies d’architecture pour la surveillance de la fiabilité des charges de travail

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

La surveillance de la fiabilité est la pratique de mesurer la façon dont un système répond à ses besoins métier au fil du temps, en ce qui concerne la résilience et la récupération. Un système de supervision bien conçu fournit une vue et des tendances en temps réel du comportement du système en établissant une visibilité sur les couches de plateforme, d’infrastructure et de charge de travail.

En mettant en corrélation ces signaux entre les composants et au fil du temps, la surveillance permet une analyse rapide et confiante des incidents et des pannes. Créez une approche structurée pour que les insights soient significatifs, les alertes conduisent les actions appropriées et les apprentissages reviennent dans l’architecture et les opérations.

Les stratégies clés de cet article reposent sur la pratique opérationnelle fondamentale de l’observabilité, décrites dans les stratégies d’architecture OE :07 pour la conception d’un système de surveillance. Des conseils sur l’implémentation de la pratique de surveillance sont disponibles dans le Guide de conception de surveillance. Nous vous recommandons d’examiner ces ressources en premier.

Définitions

Surveillance de la fonctionnalité de la charge de travail

Surveillez ce que votre système fournit réellement. Commencez par suivre si les flux de travail critiques se terminent correctement et produisent des résultats valides. Un système peut apparaître sain tout en produisant des sorties incorrectes ou incomplètes, de sorte que l’exécution seule n’est pas suffisante.

Par exemple, si une charge de travail génère des rapports toutes les six heures, la surveillance doit confirmer deux éléments : que le travail s’est exécuté comme planifié et qu’il a produit un résultat valide, tel qu’un rapport non vide avec du contenu et une taille attendus. Ce type de validation permet de s’assurer que le système s’exécute non seulement, mais également de fournir des fonctionnalités qu’il a conçues pour.

Surveiller l’expérience utilisateur

Surveillez la fiabilité du point de vue de l’entreprise et de l’utilisateur. Dans le cadre de votre analyse du mode d’échec (FMA), vous devez déjà avoir identifié des flux utilisateur clés. Pour chaque flux, suivez la façon dont les défaillances dans n’importe quel composant ou dépendance affectent l’expérience utilisateur et le résultat attendu. Par exemple, dans un processus de paiement d'un site de commerce électronique, une panne de service ou une surcharge des systèmes de paiement ou d'inventaire peut empêcher les clients de finaliser leurs achats.

La fiabilité reflète également la qualité de service. Dans un parcours d'achat, les utilisateurs doivent pouvoir finaliser leurs achats de A à Z sans interruption. Utilisez des métriques de latence basées sur centile telles que p50, p95 et p99 pour comprendre l’expérience utilisateur réelle, avec une attention particulière à la latence de queue où les problèmes de performances sont souvent exposés en premier.

Suivre les cibles de disponibilité

Suivez la façon dont votre système répond à ses objectifs définis pour la disponibilité, le débit et les temps de réponse. Ces cibles sont souvent formalisées en tant que contrats de niveau de service (SLA) et objectifs de niveau de service (SLA) et reflètent les attentes que vous avez définies avec vos utilisateurs. La surveillance contre eux maintient la fiabilité alignée sur les résultats métier réels. Pour plus d’informations, consultez Les cibles de fiabilité et les contrats de niveau de service.

Concentrez-vous sur les indicateurs clés qui contribuent à ces cibles et les suivent au fil du temps. Lorsque quelque chose dérive, vous devez être en mesure d’explorer les composants ou sous-systèmes spécifiques impliqués. Capturez tous les signaux pertinents, y compris les problèmes masqués par la redondance ou le basculement, afin de comprendre ce qui s’est réellement passé et d’empêcher les occurrences répétées.

Combinez la prise de conscience en temps réel avec le contexte historique. Les signaux en temps réel vous aident à répondre rapidement lorsque les cibles sont à risque, tandis que les tendances dans le temps révèlent des modèles et des problèmes récurrents. La classification des causes des erreurs de ciblage et l’agrégation de ces métriques soutient également des rapports SLA clairs et aide à guider les améliorations continues.

Surveillez les contrats SLA clés fournis par vos fournisseurs et services de plateforme (de Microsoft et d’autres). Vous devriez :

• Suivre les indicateurs des violations potentielles du contrat SLA en temps réel
• Capturer et conserver les preuves requises pour prendre en charge une revendication SLA si une violation se produit

Suivre les cibles de récupération

Effectuez le suivi de la récupération en traitant chaque test et chaque incident réel comme un événement mesurable. Utilisez les données de supervision pour vérifier que votre système et votre équipe peuvent atteindre des objectifs de récupération définis en conditions réelles.

Mesurez les signaux clés tels que le temps de détection, de réponse et de récupération (RTO), ainsi que l’exposition à la perte de données (RPO). Incluez des indicateurs tels que l'état de préparation et la capacité de basculement, les taux de réussite du basculement et la durée d'exécution, la réussite de la sauvegarde et de la restauration, le décalage de réplication et le niveau d'intervention manuelle nécessaire.

Ces métriques mettent également en évidence les lacunes opérationnelles, telles que les procédures peu claires, les retards de décision ou la documentation difficile à accéder, ce qui peut affecter les performances de récupération. Utilisez ces insights pour renforcer la conception du système et les pratiques de réponse aux incidents.

Rendre les alertes opérationnelles grâce à un modèle de santé

Concevez des alertes de manière à ce qu’elles pointent clairement vers quelque chose qui mérite une action, et intégrez-les dans un modèle de santé qui représente le système à l’aide d’états simples tels que sain, dégradé et malsain.

Structurez le modèle d’intégrité hiérarchiquement, à partir de composants individuels jusqu’au système complet, afin que vous puissiez rapidement tracer les problèmes vers leur source. Définissez des seuils à l’aide des objectifs de niveau de service (SLA) et combinez des signaux tels que des métriques, des journaux, des traces et des vérifications synthétiques pour créer une image fiable de l’intégrité du système. Cela donne aux opérateurs une vue claire de ce qui fonctionne, ce qui n’est pas, et où agir sans creuser dans les données brutes. Pour plus d’informations, consultez le guide de conception sur la modélisation de la santé.

Paramétrez les alertes pour les conditions réelles en mettant l’accent sur l’expérience de bout en bout et les transactions critiques, afin qu’elles reflètent l’impact réel de l’utilisateur. Réduisez le bruit en tenant compte des fluctuations temporaires et en déclenchant des changements significatifs d’état de santé plutôt que de pics ou de signaux isolés. Combinez des alertes en temps réel avec des insights de tendance pour détecter à la fois les problèmes immédiats et la dégradation progressive, aidant les équipes à répondre rapidement et à rester concentrés.

Risque : la modélisation de la santé nécessite la collecte de signaux significatifs sur l’ensemble du système. S’appuyer uniquement sur des métriques simples comme le processeur ou la mémoire peut manquer ce qui compte réellement. Incluez les données d’expérience utilisateur et les vérifications synthétiques pour obtenir une vue complète. La définition de « optimal » exige un alignement, et des seuils mal réglés peuvent créer du bruit et réduire l’efficacité.

Surveiller toutes les couches du système

Surveillez chaque couche du système, de l’application, du stockage et du réseau pour conserver une vue complète des signaux de fiabilité.

Au niveau de la couche applicative, suivez la réussite, l’échec et la latence à l’aide des journaux, des indicateurs et des sondes d’intégrité. Utilisez des ID de corrélation pour suivre les demandes entre les services et faciliter la résolution des problèmes. Collectez les journaux de manière asynchrone afin qu’ils n’affectent pas les performances des demandes et conservent les journaux de diagnostic et d’audit distincts pour plus de clarté. Ajoutez des transactions synthétiques et des sondes de point de terminaison pour confirmer l’expérience réelle des clients.

Compromis. Le choix entre la journalisation asynchrone et synchrone implique un équilibre entre les performances et la fiabilité des données de télémétrie.

• La journalisation asynchrone maintient la journalisation en dehors du chemin critique, ce qui réduit la latence et améliore les performances du système. Toutefois, elle présente un risque de perte de télémétrie, notamment si une défaillance survient avant que les logs ne soient vidés ou conservés.

• La journalisation synchrone garantit que les journaux sont écrits avant que le traitement ne continue, ce qui améliore la durabilité et l'auditabilité des données. Le compromis est une latence accrue et un couplage plus étroit entre les performances de l’application et le système de journalisation.

Dans la plupart des scénarios, la journalisation asynchrone est l’approche recommandée en raison de son impact minimal sur les performances. Toutefois, dans des environnements fortement réglementés ou sensibles à l’audit, la journalisation synchrone peut être nécessaire pour garantir que les événements critiques sont capturés de manière fiable.

Au niveau de la couche de données et de stockage, concentrez-vous sur la disponibilité, les taux de réussite d’écriture, la latence des requêtes, les délais d’expiration, les verrous et la pression des ressources. Examinez les tendances au fil du temps pour identifier les goulots d’étranglement croissants et distinguer les problèmes de courte durée de la dégradation soutenue.

Au niveau de la couche réseau, surveillez la connectivité, la latence, la perte de paquets, la bande passante et les modèles de trafic. Combinez les journaux de flux, les vérifications de point de terminaison et les tests synthétiques pour exposer les problèmes de routage, les anomalies ou le comportement lié à la sécurité. Connectez ces signaux aux données d’application et de plateforme pour comprendre où proviennent les problèmes.

Les journaux opérationnels permettent de diagnostiquer les problèmes, de suivre les performances et de comprendre le comportement du système. Elles ne sont pas conçues pour servir de source de vérité pour les événements métier, l’audit ou les rapports réglementaires, ce qui nécessite généralement une traçabilité plus forte.

Ce qu’il faut surveiller en détail pour chaque couche est abordé dans le Guide de conception de surveillance.

Définir et surveiller la capacité d’empreinte

Définissez des limites de capacité claires pour chaque unité de déploiement, ou instance, et surveillez-les étroitement. Chaque empreinte fonctionne dans un plafond fini, qu’il s’agisse de seuils d’utilisation de ressources, de débit ou d’utilisateurs simultanés maximum. Ainsi, rendre ces limites explicites vous donnera une base de référence fiable pour la prise de décision.

Cette visibilité vous permet d’identifier quand un tampon est proche de la saturation, bien avant qu’il n’affecte la fiabilité. Il prend également en charge les décisions d'extensibilité prises en temps opportun, telles que l'ajout de nouvelles unités ou la redistribution de la charge, et il confirme que le trafic circule conformément à votre conception.

La définition de ces limites n’est pas toujours simple. La capacité peut être difficile à mesurer, en particulier lorsqu’elle dépend de plusieurs services sous-jacents avec différentes caractéristiques de mise à l’échelle. Vous devez utiliser des conseils de plateforme, tels que des quotas et des limites de Microsoft Azure, comme point de départ. Dans la pratique, la capacité est souvent déterminée par le test de charge, l’observation et le réglage itératif plutôt que la modélisation initiale précise.

Surveiller la distribution de charge entre les instances redondantes

Lorsque vous exécutez la charge de travail sur plusieurs instances redondantes, notamment lorsque vous distribuez des instances dans différentes régions ou zones, le trafic et l’utilisation des ressources doivent rester équilibrés entre ces instances.

Vous souhaitez repérer les déséquilibres qui pointent souvent vers des problèmes de routage, des problèmes de configuration ou des contraintes de dépendance. Il garantit également que les cibles de basculement disposent d’une capacité suffisante pour absorber le trafic si nécessaire et confirme que les mécanismes de redondance se comportent comme prévu lors du fonctionnement en régime permanent et dans les scénarios d’échec.

Détecter les modes d’échec

Dans le cadre de votre exercice d’analyse du mode d’échec (FMA), vous devez avoir identifié les points potentiels d’échec.

Dans la pratique de surveillance de la fiabilité, surveillez continuellement ces points. Commencez par vous concentrer sur des signaux plus simples tels que les erreurs temporaires. Surveillez le comportement des nouvelles tentatives et les taux d’erreur temporaires pour comprendre comment vos dépendances et vos services sous-jacents se comportent dans des conditions d’exploitation réelles. Ces signaux donnent un aperçu précoce de l’instabilité émergente. Ils vous aident à reconnaître quand les modèles de nouvelle tentative dérivent de la norme attendue, conservent un sens indiquant si le système reste sain sous charge et identifie quand une dépendance ou un service externe commence à se dégrader avant qu’il n’ait un impact sur l’expérience utilisateur.

Incluez également des défaillances d’impact plus importantes telles que les pannes de zone de disponibilité qui ont un impact sur un sous-ensemble d’infrastructures, de pannes de service ou de pannes régionales qui prennent une région Azure entière hors connexion. Même surveiller les scénarios de sécurité tels que DDoS ou d’autres activités malveillantes, la configuration incorrecte des composants et les problèmes de performances, car chacun d’eux peut affecter la fiabilité globale de votre solution.

Pour plus d’informations sur FMA, consultez stratégies d’architecture pour l’analyse du mode d’échec.

Être informé de l’état de fiabilité de la plateforme

Vous avez besoin d’un aperçu clair de l’intégrité de la plateforme pour gérer efficacement la fiabilité. Cette sensibilisation vous permet de déterminer rapidement si un problème provient de votre charge de travail ou dans la plateforme cloud sous-jacente.

Azure Service Health fournit une visibilité sur l’état d’Azure. Configurez des alertes sur Service Health afin d’obtenir des notifications lorsque les conditions de la plateforme changent. Vous recevez des mises à jour sur les pannes actives affectant vos ressources, les événements de maintenance planifiés susceptibles d’entraîner des perturbations et des dégradations régionales ou propres aux services.

Facilitation par Azure

• Incorporer des services de supervision et d’alerte de plateforme cloud, notamment :

  • Intégrité au niveau de la plateforme, comme Azure Service Health.

  • Intégrité au niveau des ressources, comme Azure Resource Health.

• Azure Monitor est une solution de supervision complète utilisée pour collecter, analyser et répondre aux données de surveillance à partir de vos environnements cloud et locaux.

• Log Analytics est un outil du Portail Azure utilisé pour modifier et exécuter des requêtes de journal sur des données dans l’espace de travail Log Analytics.

• Application Insights est une extension de Azure Monitor. Il fournit des fonctionnalités de surveillance des performances des applications (APM).

• Azure Monitor Insights est des outils d’analyse avancés qui permettent de surveiller les services Azure, tels que les machines virtuelles, les services d’application et les conteneurs. Les insights sont basés sur Azure Monitor et Log Analytics.

• Azure Monitor pour solutions SAP est un produit de supervision Azure natif pour les paysages SAP qui s’exécutent sur Azure.

• Le moniteur de connexion est un outil permettant de suivre en continu la connectivité réseau et les performances entre les ressources Azure. Il exécute des tests synthétiques et fournit des alertes et des diagnostics en temps réel pour détecter les défaillances au début. Vous pouvez créer des classeurs personnalisés pour visualiser l’intégrité de la connectivité et les métriques de performances agrégées.

• Les journaux de flux de réseau virtuel peuvent être activés entre les charges de travail pour surveiller le trafic réseau. L’analytique du trafic peut être utilisée pour analyser et enrichir ces journaux de flux pour exposer des insights tels que le trafic bloqué, les flux malveillants et les ports actifs exposés à Internet. La création de classeurs permet aux équipes de surveiller le comportement du trafic en direct et de recevoir des alertes. Utilisez des vues de chronologie et des visualisations de topologie pour surveiller facilement les modèles de trafic susceptibles d’indiquer une dégradation des performances ou des menaces de sécurité.

• Pour connaître les meilleures pratiques relatives à plusieurs espaces de travail, consultez Concevoir une architecture d’espace de travail Log Analytics.

Example

Pour obtenir des exemples de solutions de surveillance réelles, consultez la surveillance des applications web sur Azure et l'architecture de référence pour un cluster Azure Kubernetes Service.

Liens de la communauté

• Les alertes de référence Azure Monitor (AMBA) sont un référentiel central de définitions d’alerte que les clients et les partenaires peuvent utiliser pour améliorer leur expérience d’observabilité grâce à l’adoption d’Azure Monitor.

Liste de contrôle de fiabilité

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