Microsoft AZ-400: Monitoring, Observability und Feedback — Lernleitfaden
Teil des Microsoft DevOps Engineer Expert AZ-400 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.
Überblick
Moderne DevOps-Teams behandeln Überwachung, Beobachtbarkeit und Feedback als einen kontinuierlichen Kreislauf, der Engineering-, Betriebs- und Produktentscheidungen beeinflusst. In Azure fließen Telemetriedaten von Anwendungen und Infrastruktur in Azure Monitor und Log Analytics, wo sie abgefragt, korreliert und visualisiert werden. Die verteilte Ablaufverfolgung verbindet Dienste zu End-to-End-Transaktionen, während Warnmeldungen und Bereitschaftsdienst-Integrationen eine schnelle Problembehebung vorantreiben. Azure DevOps-Dashboards, Arbeitsaufgabenanalysen und Experimente schließen den Kreis, indem sie Erkenntnisse in die Planung und Bereitstellung zurückführen. Dieser Abschnitt vermittelt die nötige Tiefe, um einen integrierten Beobachtbarkeits-Stack zu entwerfen, der in jeder Phase umsetzbares Feedback liefert.
Telemetrie, Ablaufverfolgung und Azure Monitor
Application Insights ist die Komponente für Application Performance Monitoring (APM) von Azure Monitor. Die Instrumentierung erfolgt über:
- SDKs und automatische Instrumentierung: .NET/.NET Core, Java, JavaScript, Node.js, Python und der Application Insights Agent für .NET und Java. Verwenden Sie eine Verbindungszeichenfolge und setzen Sie cloud_RoleName, um Komponenten zu unterscheiden.
- Telemetrie-Initialisierer und -Prozessoren: Fügen Sie Eigenschaften hinzu oder ändern Sie sie (z. B. tenantId) und filtern Sie personenbezogene Daten
Visualisierung und agiles Feedback in Azure DevOps
Dashboards in Azure DevOps kommunizieren sowohl den Zustand von Betrieb als auch von Prozessen. Dashboards auf Teamebene konzentrieren sich auf das Backlog, die Iterationen und das WIP eines Teams; Dashboards auf Projektebene zeigen teamübergreifende Ansichten und Portfolio-Ansichten. Zu den Widgets gehören Sprint Burndown, Burnup, Velocity, Cumulative Flow Diagram (CFD), Cycle Time, Lead Time, Work Item Chart/Query Results, Build/Release-Zusammenfassungen und Markdown für Runbooks und den SLO-Status. Sichern Sie Widgets mit Dashboard-Berechtigungen und grenzen Sie Abfragen eng auf Teams/Bereiche ein, um die teamübergreifende Preisgabe von Informationen zu vermeiden.
Boards-Abfragen (über den Query Builder oder WIQL) sind die Grundlage für viele Widgets. Parametrisieren Sie Abfragen nach Teambereichspfad/Iteration zur Wiederverwendung; bevorzugen Sie analysebasierte Widgets, wenn verfügbar, um Genauigkeit und Leistung zu verbessern. Wichtige Flow-Metriken:
- Cycle Time: Verstrichene Zeit von „Aktiv“ (in Bearbeitung) bis „Erledigt“; verwenden Sie das Cycle-Time-Widget, um die Effizienz der Ausführung zu verfolgen.
- Lead Time: Verstrichene Zeit von der Erstellung/Verpflichtung bis zur Erledigung; signalisiert die gesamte Systemverzögerung aus Kundensicht.
- Throughput: Abgeschlossene Elemente pro Zeitintervall; vergleichen Sie dies mit den WIP-Richtlinien, um Engpässe zu erkennen.
- Cumulative Flow Diagram: Visualisiert die Größe der Warteschlangen nach Status im Zeitverlauf; breiter werdende Bänder decken Engpässe und Kontextwechsel auf. Für das Sprint-Tracking verwenden Sie Burndown (Trend der verbleibenden Arbeit gegen Null) und Burnup (Gesamtumfang vs. abgeschlossen, unempfindlich gegenüber Umfangsänderungen). Velocity gibt den durchschnittlich abgeschlossenen Aufwand pro Sprint an und dient der Kapazitätsplanung; aggregieren Sie nur gleichartige Schätzungseinheiten über Teams hinweg.
Wo Produktanalysen erforderlich sind, verbinden Sie Azure DevOps Analytics mit Power BI, um Liefermetriken mit betrieblicher Telemetrie (z. B. Lead Time vs. Defect Escape Rate) zu kombinieren und Verbesserungen zu priorisieren.
Zuverlässigkeit, Alarmierung und kontinuierliches Feedback
SLI/SLO/SLA etablieren Zuverlässigkeit als ein erstklassiges Feature:
- SLIs: Quantitative Messgrößen für das Benutzererlebnis, z. B. Erfolgsrate von Anfragen, p95-Latenz, Verfügbarkeit kritischer Endpunkte oder Abschlussrate von Aufgaben in der Benutzeroberfläche.
- SLOs: Ziele über einen bestimmten Zeitraum, z. B. 99,9 % monatliche Verfügbarkeit oder p95 < 300 ms. Binden Sie SLOs an User Journeys, nicht an die Infrastruktur.
- Fehlerbudgets: 1 − SLO; steuern das Risiko von Releases, Rollback-Kriterien und die Reaktion auf Vorfälle. Implementieren Sie Burn-Rate-Alarme (z. B. 2x und 14x Budgetverbrauch) mittels KQL oder metrischen Alarmen für sowohl schnelle als auch langsame Überschreitungen.
- SLAs: Externe Verpflichtungen gegenüber Kunden; typischerweise lockerer als SLOs und beinhalten Strafen; sie steuern, aber diktieren nicht die technischen Leitplanken.
Alarmierung und Rufbereitschaft:
- Verwenden Sie metrische Alarme für latenzsensitive Bedingungen; verwenden Sie Protokollalarme für komplexe Prädikate (z. B. Korrelation mehrerer Signale oder Anomalie-Scores).
- Reduzieren Sie die „Alert Fatigue“ (Alarmmüdigkeit) durch Deduplizierung (Regeln zur Verarbeitung von Warnungen), dynamische Schwellenwerte, Anpassung des Schweregrads und automatische Unterdrückung während geplanter Wartungsarbeiten.
- Integrieren Sie PagerDuty/OpsGenie über Webhooks von Aktionsgruppen unter Verwendung des allgemeinen Alarmschemas; mappen Sie Korrelationsschlüssel von Alarmen für die Deduplizierung von Vorfällen und definieren Sie Eskalationsrichtlinien pro Dienst.
- Automatisieren Sie die Problembehebung mit Azure Automation Runbooks, Functions oder Logic Apps (z. B. Aufskalieren bei Warteschlangentiefe, Neustart einer fehlerhaften Instanz, Umschalten eines Feature-Flags). Zeichnen Sie jede automatische Aktion als benutzerdefiniertes Ereignis in Application Insights auf, um die Nachvollziehbarkeit zu gewährleisten.
Kontinuierliches Feedback und Experimente:
- A/B- und schrittweise Rollouts: Verwenden Sie Azure Front Door oder Traffic Manager für das Traffic-Splitting am Edge oder implementieren Sie Feature-Flags mit dem Azure App Configuration Feature Manager für benutzer- oder kohortenbasierte Rollouts. Sichern Sie Codepfade mit Flags ab und sammeln Sie Ereignistelemetrie für jede Variante.
- Benutzertelemetrie: Senden Sie
TrackEventmit dem Status des Feature-Flags, Benutzereigenschaften (keine personenbezogenen Daten) und Szenario-Identifikatoren. Analysieren Sie Funnels, User Flows, Retention und die Leistung von Kohorten in Application Insights, um Hypothesen zu validieren. - Analyse der Feature-Nutzung: Erstellen Sie Dashboards, die DAU/WAU/MAU, die Akzeptanz von Features und Konversionsmetriken verfolgen. Lassen Sie die Ergebnisse in die Priorisierung des Backlogs einfließen. Verwenden Sie Azure Pipelines Gates, um die Bereitstellung in der Produktion zu blockieren, wenn die SLI-Baselines im Staging fehlschlagen oder Regressionen bei den KPIs von Experimenten festgestellt werden.
Praktisches Problemszenario
Spotify muss die End-to-End-Sichtbarkeit und das Feedback für seine Dienste zur Podcast-Ingestion und -Wiedergabe verbessern, die auf Azure Kubernetes Service (AKS) und Azure App Service APIs bereitgestellt werden. Vorfälle werden zu spät erkannt, und den Produktteams fehlen vertrauenswürdige Adoptionsmetriken für neue Wiedergabefunktionen.
- Anwendungstelemetrie instrumentieren und korrelieren
- Fügen Sie Application Insights SDKs zu .NET- und Node.js-Diensten hinzu; aktivieren Sie das Application Insights JavaScript SDK auf Web-Clients. Konfigurieren Sie
cloud_RoleNameund Verbindungszeichenfolgen; aktivieren Sie die W3C Trace-Context-Propagation über Microservices und Message Queues hinweg. Warum: Gewährleistet konsistente Korrelations-IDs und verteiltes Tracing für eine vollständige Transaktionssichtbarkeit vom Browser bis zu den Diensten und Abhängigkeiten.
- Plattformdiagnosen zu Log Analytics streamen
- Wenden Sie Diagnoseeinstellungen über Azure Policy auf alle AKS-Cluster, App Service-Pläne, Application Gateways, Cosmos DB- und Storage-Konten an und leiten Sie die Daten an einen zentralen Prod-Workspace mit 90-tägiger Aufbewahrung und Archivierung in Storage weiter. Warum: Garantiert eine einheitliche Abdeckung von Plattformprotokollen/-metriken für die KQL-Korrelation und eine kosteneffiziente Langzeitaufbewahrung.
- SLIs, SLOs und Fehlerbudgets definieren
- SLIs: p95-API-Latenz, Erfolgsrate von Anfragen, Durchsatz der Ingestion-Pipeline und Erfolgsrate beim Start des Players.
- SLOs: 99,95 % monatliche Erfolgsrate, p95-Start der Wiedergabe < 300 ms, Ingestion-Verzögerung < 2 Minuten.
- Erstellen Sie KQL-basierte Alarme für die Burn-Rate des Fehlerbudgets (schnell/langsam) und metrische Alarme für die Latenz mit dynamischen Schwellenwerten. Warum: Wandelt Geschäftsergebnisse in messbare, umsetzbare Zuverlässigkeitsziele mit rechtzeitigen Alarmen um.
- Umsetzbare Alarme und Integration der Rufbereitschaft erstellen
- Erstellen Sie Azure Monitor-Alarmregeln mit intelligenter Gruppierung; leiten Sie sie an eine Aktionsgruppe weiter, die PagerDuty per Webhook unter Verwendung des allgemeinen Alarmschemas auslöst. Hängen Sie Azure Automation Runbooks an, um bei Warteschlangentiefe automatisch zu skalieren und fehlerhafte Pods neu zu starten. Warum: Reduziert MTTA/MTTR durch zuverlässiges Paging und sichere, nachvollziehbare automatische Problembehebung.
- Dashboards für Engineering und Produkt einrichten
- Azure DevOps Dashboards auf Teamebene: Cycle Time (Active→Done), Lead Time (Created→Done), CFD, Velocity und Sprint Burndown für Squads. Dashboards auf Projektebene: Burnup für Releases, teamübergreifender Durchsatz und SLO-Status über Markdown/Analytics-Widgets. Warum: Gibt den Squads Einblick in die Ausführung und bietet der Führungsebene einen Überblick über den Portfolio- und Zuverlässigkeitsstatus.
- Experimente und Nutzungsanalysen implementieren
- Verwenden Sie Azure App Configuration Feature-Flags, um eine neue Funktion „Smart Skip Silence“ schrittweise einzuführen. Teilen Sie Kohorten mit Front Door-Regeln für A/B-Tests am Edge auf, wo dies erforderlich ist. Senden Sie
TrackEventmitfeatureFlagState, Benutzerkohorte und Ergebnismetriken. Warum: Validiert sicher die Auswirkungen und erfasst gleichzeitig hochpräzise Benutzertelemetrie für evidenzbasierte Entscheidungen.
- Release-Qualität mit Gates durchsetzen
- Fügen Sie in Azure Pipelines Gates hinzu, die Application Insights/Log Analytics nach Staging-KPIs abfragen (p95-Latenz, Fehlerrate, Leistung der Experimentvarianten). Lassen Sie die Gates fehlschlagen, wenn Baselines oder an SLOs ausgerichtete Schwellenwerte nicht erfüllt werden. Warum: Verhindert, dass Regressionen die Produktion erreichen, und stimmt Bereitstellungsentscheidungen auf Zuverlässigkeits- und Produkt-KPIs ab.
← Teststrategie und Quality Engineering · Alle Domänen · Paketverwaltung und Artefaktverwaltung →
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →