Microsoft AZ-400: Surveillance, observabilité et retour d'information — Guide d'étude

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Fait partie du Microsoft DevOps Engineer Expert AZ-400 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Les équipes DevOps modernes traitent la supervision, l’observabilité et le feedback comme une boucle continue qui éclaire les décisions d’ingénierie, d’exploitation et de produit. Dans Azure, la télémétrie provenant des applications et de l’infrastructure est acheminée vers Azure Monitor et Log Analytics, où elle est interrogée, corrélée et visualisée. Le traçage distribué relie les services en transactions de bout en bout, tandis que les alertes et les intégrations pour les astreintes permettent une remédiation rapide. Les tableaux de bord Azure DevOps, l’analytique des éléments de travail et l’expérimentation bouclent la boucle en réinjectant les informations dans la planification et la livraison. Cette section fournit la profondeur requise pour concevoir une pile d’observabilité intégrée qui fournit un feedback exploitable à chaque étape.

Télémétrie, traçage et Azure Monitor

Application Insights est le composant de surveillance des performances applicatives (APM) d’Azure Monitor. L’instrumentation est ajoutée via :

Des SDK et l’auto-instrumentation : .NET/.NET Core, Java, JavaScript, Node.js, Python, et l’agent Application Insights pour .NET et Java. Utilisez une chaîne de connexion et définissez cloud_RoleName pour distinguer les composants.
Initialiseurs et processeurs de télémétrie : Ajoutez ou modifiez des propriétés (par ex., tenantId) et filtrez les PII (informations d’identification personnelle) avant leur émission.
Télémétrie personnalisée : TrackEvent pour les actions métier, TrackMetric pour les KPI numériques, TrackException pour les contextes d’erreur, et TrackDependency pour les appels externes que vous devez modéliser explicitement.

Les types de télémétrie incluent les requêtes, les dépendances (HTTP, SQL, SDK Azure), les traces, les exceptions, les vues de page, la performance de chargement des pages, les résultats des tests de disponibilité, les événements/métriques personnalisés et les métriques en temps réel. L’échantillonnage contrôle le volume et le coût tout en préservant le signal : l’échantillonnage adaptatif du SDK ajuste automatiquement les taux par type pour maintenir le débit et la corrélation cibles ; l’échantillonnage à taux fixe fournit un échantillonnage déterministe pour la conformité. Privilégiez l’échantillonnage côté SDK afin que les systèmes en aval ne traitent jamais les éléments abandonnés. Maintenez un échantillonnage persistant (sticky) pour l’intégrité du traçage de bout en bout.

Le traçage distribué offre une visibilité des transactions de bout en bout. Application Insights implémente la norme W3C Trace-Context (traceparent/tracestate), propageant automatiquement les ID de corrélation via HTTP ; propagez le contexte à travers les frontières asynchrones et les protocoles personnalisés pour éviter les traces rompues. Le suivi des dépendances collecte automatiquement les appels sortants courants ; émettez des dépendances personnalisées pour les sauts de file d’attente de messages ou les RPC non standard afin de compléter le graphe d’appels. App Map et Transaction Search visualisent les flux inter-services, les latences et les points chauds de défaillance. Pour la corrélation entre le front-end et le back-end, activez le SDK JavaScript et assurez-vous que les en-têtes de corrélation côté serveur sont acceptés pour mesurer les temps de chargement de page réels et les parcours utilisateur.

Azure Monitor unifie la télémétrie de la plateforme et des applications :

Métriques : Multi-dimensionnelles, en quasi temps réel (granularité d’une minute ou mieux). Utilisez des alertes de métriques avec des seuils statiques ou dynamiques pour des détections rapides à faible latence.
Journaux : Télémétrie semi-structurée dans un espace de travail Log Analytics, interrogée avec KQL pour une analyse approfondie et la recherche d’anomalies.
Alertes : Les règles sur les métriques, les journaux et les journaux d’activité sont acheminées vers des groupes d’actions. Utilisez des seuils dynamiques, un ciblage multi-ressources et un schéma d’alerte commun pour un traitement cohérent.
Groupes d’actions : E-mail/SMS/voix, notifications push, webhooks (y compris PagerDuty/OpsGenie), connecteurs ITSM, Logic Apps, Azure Functions et runbooks Automation pour la remédiation.
Paramètres de diagnostic : Configurez chaque ressource Azure pour diffuser en continu les métriques/journaux de la plateforme vers Log Analytics, Azure Storage (pour l’archivage) et Event Hubs (pour l’ingestion par un SIEM). Assurez la cohérence avec un déploiement piloté par des stratégies.

Interrogation et analytique avec Log Analytics (KQL)

Un espace de travail Log Analytics est le périmètre d’interrogation et de gouvernance pour les journaux. Planifiez par environnement et souveraineté des données : des espaces de travail distincts pour la production et la non-production peuvent simplifier le RBAC et les stratégies de rétention ; la centralisation facilite la corrélation inter-services. Les sources de données incluent Azure Diagnostics (journaux/métriques de la plateforme), les agents de machine virtuelle (Syslog/événements Windows, compteurs de performance), Container Insights/AKS, les journaux des composants Application Insights (unifiés sous Azure Monitor Logs), les connexions Azure AD, les journaux personnalisés via les API d’ingestion, et les règles de collecte de données pour un routage et une transformation précis des flux.

Le Kusto Query Language (KQL) est optimisé pour l’analyse de séries temporelles et de télémétrie :

Opérateurs principaux : where (filtrer), project (sélectionner), extend (dériver), summarize by (agréger), join/union (corréler), parse/parse_json (extraire), mv-expand (tableaux), make-series et bin pour le regroupement temporel, render pour la création de graphiques.
Modèles (Patterns) : Consommation du budget d’erreur (taux d’échec pondérés dans le temps), distributions de latence p50/p95, détection des dépendances aberrantes, taux de réussite des requêtes par rapport au trafic, et détection d’anomalies à l’aide de series_decompose_anomalies pour des alertes tenant compte de la saisonnalité.
Gouvernance : Les requêtes et fonctions enregistrées favorisent la réutilisation ; le RBAC et l’accès au niveau des tables restreignent les jeux de données sensibles.
Inter-ressources et inter-espaces de travail : Utilisez workspace(“workspaceNameOrId”).Table et la fonction workspaces() pour combiner des jeux de données entre environnements et abonnements ; utilisez resource() pour les jointures inter-ressources. Appliquez des liaisons let et materialize() pour contrôler les performances sur les jointures volumineuses.

Visualisation et feedback Agile dans Azure DevOps

Dans Azure DevOps, les tableaux de bord communiquent à la fois la santé opérationnelle et celle des processus. Les tableaux de bord au niveau de l’équipe se concentrent sur le backlog, les itérations et le WIP (travail en cours) d’une équipe ; les tableaux de bord au niveau du projet présentent des vues inter-équipes et de portefeuille. Les widgets incluent Sprint Burndown, Burnup, Velocity, Cumulative Flow Diagram (CFD), Cycle Time, Lead Time, Work Item Chart/Query Results, les résumés de Build/Release, et Markdown pour les runbooks et le statut des SLO. Sécurisez les widgets avec les permissions de tableau de bord et limitez strictement la portée des requêtes aux équipes/zones pour éviter la fuite d’informations entre les équipes.

Les requêtes Boards (via le générateur de requêtes ou WIQL) alimentent de nombreux widgets. Paramétrez les requêtes par chemin de zone/itération d’équipe pour la réutilisation ; préférez les widgets basés sur Analytics lorsqu’ils sont disponibles pour plus de précision et de performance. Indicateurs de flux clés :

Cycle time : Temps écoulé entre l’état Actif (en cours) et Terminé ; utilisez le widget Cycle Time pour suivre l’efficacité de l’exécution.
Lead time : Temps écoulé entre la création/l’engagement et l’état Terminé ; signale le délai total du système tel que perçu par les clients.
Throughput (Débit) : Éléments terminés par intervalle de temps ; à comparer aux politiques de WIP pour détecter les goulots d’étranglement.
Cumulative Flow Diagram : Visualise la taille des files d’attente par état au fil du temps ; l’élargissement des bandes révèle les contraintes et le changement de contexte (context-switching). Pour le suivi des sprints, utilisez le Burndown (tendance du travail restant vers zéro) et le Burnup (périmètre total par rapport au travail terminé, résilient aux changements de périmètre). La Velocity indique l’effort moyen terminé par sprint et éclaire la planification de la capacité ; n’agrégez que des unités d’estimation de même nature entre les équipes.

Lorsque l’analyse produit est nécessaire, connectez Azure DevOps Analytics à Power BI pour combiner les métriques de livraison avec la télémétrie opérationnelle (par ex., le lead time par rapport au taux de défauts échappés) afin de prioriser les améliorations.

Fiabilité, alertes et feedback continu

Les SLI/SLO/SLA établissent la fiabilité comme une fonctionnalité de premier ordre :

SLI (Indicateurs de niveau de service) : Mesures quantitatives de l’expérience utilisateur, par ex., taux de réussite des requêtes, latence p95, disponibilité des points de terminaison critiques ou taux d’accomplissement des tâches dans l’interface utilisateur.
SLO (Objectifs de niveau de service) : Cibles sur une fenêtre de temps, par ex., 99,9 % de disponibilité mensuelle ou une latence p95 < 300 ms. Liez les SLO aux parcours utilisateur, pas à l’infrastructure.
Budgets d’erreur : 1 − SLO ; régissent le risque de mise en production, les critères de restauration (rollback) et la réponse aux incidents. Mettez en œuvre des alertes de taux de consommation du budget (par ex., consommation du budget de 2x et 14x) en utilisant KQL ou des alertes de métrique pour les dépassements rapides et lents.
SLA (Accords de niveau de service) : Engagements externes envers les clients ; généralement moins stricts que les SLO et incluent des pénalités ; ils orientent mais ne dictent pas les garde-fous techniques.

Alertes et astreintes :

Utilisez des alertes de métrique pour les conditions sensibles à la latence ; utilisez des alertes de journal pour les prédicats complexes (par ex., corrélation multi-signaux ou scores d’anomalie).
Réduisez la fatigue d’alerte avec le dédoublonnage (règles de traitement des alertes), les seuils dynamiques, l’ajustement de la sévérité et la suppression automatique pendant la maintenance planifiée.
Intégrez avec PagerDuty/OpsGenie via les webhooks de groupe d’actions en utilisant le schéma d’alerte commun ; mappez les clés de corrélation d’alerte pour le dédoublonnage des incidents et définissez des politiques d’escalade par service.
Automatisez la remédiation avec des runbooks Azure Automation, des Functions ou des Logic Apps (par ex., mise à l’échelle horizontale en fonction de la profondeur de la file d’attente, recycler une instance défaillante, activer/désactiver un feature flag). Enregistrez chaque action automatique comme un événement personnalisé dans Application Insights pour l’auditabilité.

Feedback continu et expérimentation :

Déploiements A/B et progressifs : Utilisez Azure Front Door ou Traffic Manager pour la répartition du trafic en périphérie (edge), ou implémentez des feature flags avec Azure App Configuration Feature Manager pour un déploiement par utilisateur ou par cohorte. Protégez les chemins de code avec des flags et collectez la télémétrie d’événement pour chaque variante.
Télémétrie utilisateur : Émettez des TrackEvent avec l’état du feature flag, les propriétés utilisateur (non-PII) et les identifiants de scénario. Analysez les entonnoirs (funnels), les flux utilisateurs, la rétention et la performance des cohortes dans Application Insights pour valider les hypothèses.
Analyse de l’utilisation des fonctionnalités : Créez des tableaux de bord qui suivent les DAU/WAU/MAU, l’adoption des fonctionnalités et les métriques de conversion. Utilisez les résultats pour la priorisation du backlog. Utilisez les portes (gates) Azure Pipelines pour bloquer le déploiement en production lorsque les lignes de base des SLI de pré-production (staging) échouent ou que des régressions de KPI d’expérimentation sont détectées.

Scénario de problème pratique

Spotify doit améliorer la visibilité de bout en bout et le feedback pour ses services d’ingestion et de lecture de podcasts déployés sur Azure Kubernetes Service (AKS) et des API Azure App Service. Les incidents sont détectés tardivement, et les équipes produit manquent de métriques d’adoption fiables pour les nouvelles fonctionnalités de lecture.

Instrumenter et corréler la télémétrie applicative

Ajoutez les SDK Application Insights aux services .NET et Node.js ; activez le SDK JavaScript d’Application Insights sur les clients web. Configurez cloud_RoleName et les chaînes de connexion ; activez la propagation du contexte de trace W3C à travers les microservices et les files de messages. Pourquoi : Assure des ID de corrélation cohérents et un traçage distribué pour une visibilité complète des transactions, du navigateur jusqu’aux services et dépendances.

Diffuser les diagnostics de la plateforme vers Log Analytics

Appliquez des paramètres de diagnostic via Azure Policy à tous les clusters AKS, plans App Service, Application Gateways, Cosmos DB et comptes de stockage, en les routant vers un espace de travail de production central avec une rétention de 90 jours et un archivage vers Storage. Pourquoi : Garantit une couverture uniforme des journaux/métriques de la plateforme pour la corrélation KQL et une rétention à long terme rentable.

Définir les SLI, SLO et budgets d’erreur

SLI : Latence p95 de l’API, taux de réussite des requêtes, débit du pipeline d’ingestion et réussite du démarrage du lecteur.
SLO : 99,95 % de réussite mensuelle, démarrage de la lecture p95 < 300 ms, latence d’ingestion < 2 minutes.
Créez des alertes de taux de consommation du budget d’erreur basées sur KQL (rapide/lent) et des alertes de métrique pour la latence avec des seuils dynamiques. Pourquoi : Convertit les résultats métier en objectifs de fiabilité mesurables et exploitables avec des alertes opportunes.

Construire des alertes exploitables et une intégration d’astreinte

Créez des règles d’alerte Azure Monitor avec regroupement intelligent ; routez vers un groupe d’actions qui déclenche PagerDuty via un webhook en utilisant le schéma d’alerte commun. Attachez des runbooks Azure Automation pour une mise à l’échelle automatique en fonction de la profondeur de la file d’attente et pour redémarrer les pods défectueux. Pourquoi : Réduit le MTTA/MTTR grâce à des notifications d’astreinte fiables et une auto-remédiation sûre et auditable.

Établir des tableaux de bord pour l’ingénierie et le produit

Tableaux de bord au niveau de l’équipe Azure DevOps : Temps de cycle (Actif→Terminé), Délai de réalisation (Créé→Terminé), CFD, Vélocité et Burndown de sprint pour les escouades (squads). Tableaux de bord au niveau du projet : Burnup pour les releases, débit inter-équipes et statut des SLO via des widgets Markdown/Analytics. Pourquoi : Donne aux escouades un aperçu de l’exécution tout en fournissant à la direction une vue sur la santé du portefeuille et de la fiabilité.

Mettre en œuvre l’expérimentation et l’analyse d’utilisation

Utilisez les feature flags d’Azure App Configuration pour déployer progressivement une nouvelle fonctionnalité « Saut intelligent des silences ». Divisez les cohortes avec des règles Front Door pour des tests A/B en périphérie (edge) si nécessaire. Émettez des TrackEvent avec featureFlagState, la cohorte d’utilisateurs et les métriques de résultat. Pourquoi : Valide l’impact en toute sécurité tout en capturant une télémétrie utilisateur haute-fidélité pour des décisions basées sur des preuves.

Garantir la qualité des releases avec des portes (gates)

Dans Azure Pipelines, ajoutez des portes qui interrogent Application Insights/Log Analytics pour les KPI de pré-production (staging) (latence p95, taux d’échec, performance des variantes d’expérimentation). Faites échouer les portes si les lignes de base ou les seuils alignés sur les SLO ne sont pas respectés. Pourquoi : Empêche les régressions d’atteindre la production et aligne les décisions de déploiement avec les KPI de fiabilité et de produit.

← Stratégie de test et ingénierie de la qualité · Tous les domaines · Gestion des paquets et des artefacts →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →