Faire évoluer les opérations avec observabilité
 obtenir une visibilité sur le système, dériver des insights et prendre des décisions pilotées par les données. |
|---|
Créez une culture qui améliore continuellement la qualité en analysant la charge de travail et en prenant en compte tous les piliers de l’infrastructure Azure Well-Architected. Permettre à l’équipe et aux parties prenantes de prendre des décisions à court et à long terme sur de nombreuses facettes en fournissant les données, les statistiques et les tendances nécessaires. Découvrez vos données et apportez des améliorations.
Les opérations conçues à des fins d’observation sont essentielles à la maintenance proactive de l’application, de la qualité et de la sécurité, de la planification de la capacité et de la gestion des produits.
Un aspect crucial de la supervision de l’application consiste en la modélisation de l’intégrité pour vous permettre d’anticiper les problèmes avant qu’ils ne deviennent des incidents et affectent l’expérience client. Une surveillance efficace réduit les cycles réactifs consacrés à la gestion des incidents.
Exemple de scénario
Contoso a développé une application pour une utilisation interne appelée Contoso Real Estate. Cette application web permet aux nouveaux embauches ou employés existants qui se déplacent pour rechercher et réserver des logements à court terme pour aider à leur réinstallation. Le service RH de Contoso utilise également l’application pour faciliter les réinstallations.
L’application est en production et est déployée entièrement dans Azure. Il s’appuie sur des microservices à l’aide d’Azure Container Apps et utilise également Azure Functions, Azure Database pour PostrgreSQL, Stockage Blob Azure et Azure Monitor.
Observer votre charge de travail par le biais de la télémétrie
Émettez des données de télémétrie à partir du code d’application qui corréler les points clés du flux d’exécution et donne une vue de bout en bout à différents niveaux de granularité.
Hiérarchisez les actions en fonction du niveau de gravité et comprenez le contexte en fonction de sa détail. Ces informations sont cruciales à des fins de résolution des problèmes.
Problématique de Contoso
- Les utilisateurs signalent que, après une mise à jour récente de l’application Contoso Real Estate, ils voient parfois une page vide ou un message d’erreur générique sur la page de recherche de l’application web. Les erreurs semblent aléatoires et la fonctionnalité de recherche fonctionne généralement si les utilisateurs actualisent simplement la page ou soumettent à nouveau la recherche.
- En examinant les journaux sur le microservice de recherche, l’équipe remarque une augmentation des erreurs en raison de délais d’expiration de connexion au Azure Database pour PostgreSQL, mais ils n’ont actuellement aucun moyen de déterminer si une erreur qu’ils voient dans les journaux de microservice de recherche correspond aux pages d’erreur que les utilisateurs voient ou non.
Application de l’approche et résultats
- L’équipe de développement a décidé d’étendre les informations qu’ils consignent à partir de l’application web et des microservices de base pour approfondir le problème. Pour le scénario de recherche, ils veillent à capturer les termes de recherche ainsi que d’autres attributs de transaction disponibles tels que l’heure, l’adresse IP du client et le nom d’utilisateur associé à la recherche. Ces données supplémentaires doivent leur donner suffisamment d’informations pour pouvoir mettre en corrélation les transactions entre les niveaux.
- Cette modification a permis à l’équipe de confirmer que les délais d’expiration des requêtes de base de données, qui n’étaient pas gérés correctement dans la dernière mise à jour de l’application, étaient la cause racine des échecs rencontrés par les utilisateurs. Après avoir trouvé la cause racine, il était simple pour l’équipe d’implémenter un correctif.
- L’équipe conçoit désormais une nouvelle approche, à l’aide d’OpenTelemetry, pour implémenter une solution de suivi distribué plus complète qui couvre tous les niveaux de solution.
Visualiser les données de surveillance dans les tableaux de bord
Agréger et visualiser des données dans des tableaux de bord pour présenter des données de surveillance adaptées aux audiences et garder à l’esprit le contexte métier. Utilisez des tableaux de bord situationnels pour faire face aux données afin de sensibiliser les parties prenantes. Utilisez des tableaux de bord opérationnels et des classeurs avec des fonctionnalités d’exploration pour les activités d’opérateur telles que la réponse aux incidents. Actualisez fréquemment les tableaux de bord et fournissez des données granulaires.
Avec des visualisations, vous pouvez analyser les tendances, effectuer le suivi des cibles métier et gérer les incidents.
Les tableaux de bord adaptés à l’intérêt du client rendent l’interprétation pertinente et accélèrent la détection et l’action.
Problématique de Contoso
- L’équipe de charge de travail agrège les données de télémétrie de tous les niveaux de solution dans un espace de travail Log Analytics unique, accessible par les équipes d’exploitation et de développement et d’autres parties prenantes du projet. Toutefois, l’interaction avec les données est difficile et complexe, ce qui est frustrant pour les membres de l’équipe qui ont besoin de discerner le bruit de fond des données actionnables.
Application de l’approche et résultats
- L’équipe s’engage dans un effort d’agrégation et de visualisation des données à l’aide de tableaux de bord. Chaque tableau de bord sera adapté à un public spécifique :
- Les tableaux de bord des parties prenantes de la solution seront plus orientés métier, présentant une vue d’ensemble de l’intégrité globale de la solution, ainsi que des indicateurs métier tels que le nombre d’utilisateurs servis, les recherches et les réservations effectuées.
- Les tableaux de bord opérationnels et les classeurs auront des données plus détaillées et granulaires pour l’équipe des opérations. Ces tableaux de bord auront des fonctionnalités d’exploration qui permettent aux utilisateurs d’explorer les données à différents niveaux de granularité. Les utilisateurs pourront utiliser ces tableaux de bord et classeurs pour effectuer des tâches de résolution des problèmes et d’autres tâches de réponse aux incidents.
- Les tableaux de bord permettent aux utilisateurs d’analyser les tendances, de suivre les cibles métier et de gérer plus efficacement les incidents. Les données présentées sur chaque tableau de bord seront plus pertinentes pour son public prévu et seront pilotées par leurs intérêts et leurs besoins.
Concevoir une stratégie d’alerte robuste
Rendez les alertes exploitables en informant les rôles responsables avec des descriptions standardisées et des niveaux de gravité. Fournissez des informations compilées à partir de différentes sources et suivez les écarts des cibles métier.
Déclenchez des alertes uniquement pour les incidents nécessitant une action et recherchez des alertes proactives et déclenchées par la pensée qui lancent des actions avant qu’un état détérioré ne devienne un échec. Un bon système d’alerte identifie les actions et la gravité et fournit juste suffisamment de données pour améliorer la clarté et l’objectif. Les opérateurs peuvent commencer à corriger sans délai.
Problématique de Contoso
- Azure Monitor est utilisé pour envoyer des alertes à l’équipe des opérations lorsqu’un problème se produit. Toutefois, l’équipe reçoit actuellement trop d’alertes qui ne sont pas pertinentes, peu claires ou redondantes. Cela provoque la fatigue des alertes et affecte la productivité de l’équipe et provoque des alertes importantes qui passent inaperçues.
- Il y a également eu certaines situations de pannes qui auraient pu être évitées ou réduites si une alerte a été envoyée en prévision d’une défaillance. Si l’équipe recevait de meilleures alertes relatives aux dégradations avant que des pannes ne se produisent, ces situations pourraient être évitées. Par exemple, il y a eu des occasions dans lesquelles des ralentissements dans le temps de traitement des requêtes de base de données ont entraîné des pannes. Lors de la résolution des pannes, l’équipe remarque que les performances de traitement des requêtes diminuent lentement au fil du temps, s’aggravent et s’aggravent jusqu’à ce qu’elles provoquent une panne complète.
Application de l’approche et résultats
- L’équipe d’exploitation lance une initiative visant à propre toutes les alertes de faible priorité provoquant la fatigue des alertes. Seules les alertes critiques et exploitables sont autorisées à rester actives. En outre, l’équipe examine (et améliore si nécessaire) les alertes qui resteront actives pour s’assurer qu’elles contiennent suffisamment de contexte pour leur permettre de prendre les mesures correctives nécessaires.
- Ils profitent également de la possibilité de définir de nouvelles alertes proactives et exploitables qui leur permettront de prendre des mesures avant qu’un échec ne se produise. Par exemple, ils génèrent une nouvelle alerte pour notifier les administrateurs de base de données dès qu’un ralentissement cohérent des performances des requêtes de base de données s’affiche.
- À l’étape suivante, l’équipe cherche à automatiser les réponses aux alertes courantes, telles que la situation avec les performances des requêtes de base de données.