Microsoft AZ-400: Monitorowanie, obserwowalność i informacje zwrotne — Przewodnik do nauki

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

Część Microsoft DevOps Engineer Expert AZ-400 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Nowoczesne zespoły DevOps traktują monitorowanie, obserwowalność i feedback jako ciągłą pętlę, która dostarcza informacji do decyzji inżynieryjnych, operacyjnych i produktowych. W Azure telemetria przepływa z aplikacji i infrastruktury do Azure Monitor i Log Analytics, gdzie jest odpytywana, korelowana i wizualizowana. Śledzenie rozproszone (distributed tracing) łączy usługi w transakcje end-to-end, podczas gdy alertowanie i integracje z systemami on-call umożliwiają szybką naprawę. Pulpity nawigacyjne Azure DevOps, analityka elementów pracy i eksperymentowanie zamykają pętlę, dostarczając wnioski z powrotem do procesów planowania i dostarczania. Ta sekcja dostarcza szczegółowej wiedzy wymaganej do zaprojektowania zintegrowanego stosu obserwowalności, który dostarcza praktycznych informacji zwrotnych na każdym etapie.

Telemetria, śledzenie i Azure Monitor

Application Insights to komponent Azure Monitor do monitorowania wydajności aplikacji (APM). Instrumentacja jest dodawana poprzez:

Zestawy SDK i auto-instrumentację: .NET/.NET Core, Java, JavaScript, Node.js, Python oraz Application Insights Agent dla .NET i Javy. Użyj ciągu połączenia (connection string) i ustaw cloud_RoleName, aby rozróżnić komponenty.
Inicjalizatory i procesory telemetrii: Dodawanie lub modyfikowanie właściwości (np. tenantId) oraz filtrowanie danych PII przed wysłaniem.
Niestandardowa telemetria: TrackEvent dla akcji biznesowych, TrackMetric dla numerycznych wskaźników KPI, TrackException dla kontekstów błędów i TrackDependency dla zewnętrznych wywołań, które trzeba jawnie modelować.

Typy telemetrii obejmują żądania, zależności (HTTP, SQL, Azure SDK), ślady (traces), wyjątki, odsłony stron, wydajność ładowania stron, wyniki testów dostępności, niestandardowe zdarzenia/metryki oraz metryki na żywo. Próbkowanie (sampling) kontroluje wolumen danych i koszty, zachowując jednocześnie istotne sygnały: adaptacyjne próbkowanie SDK automatycznie dostosowuje częstotliwość dla każdego typu, aby utrzymać docelową przepustowość i korelację; próbkowanie o stałej częstotliwości (fixed-rate) zapewnia deterministyczne próbkowanie na potrzeby zgodności z regulacjami. Preferuj próbkowanie po stronie SDK, aby systemy podrzędne nigdy nie przetwarzały odrzuconych danych. Utrzymuj próbkowanie typu „sticky” dla zapewnienia integralności śledzenia end-to-end.

Śledzenie rozproszone zapewnia widoczność transakcji end-to-end. Application Insights implementuje standard W3C Trace-Context (traceparent/tracestate), automatycznie propagując identyfikatory korelacji przez HTTP; propaguj kontekst przez granice asynchroniczne i niestandardowe protokoły, aby uniknąć przerwanych śladów. Śledzenie zależności automatycznie zbiera informacje o popularnych wywołaniach wychodzących; emituj niestandardowe zależności dla skoków w kolejkach komunikatów lub niestandardowych wywołań RPC, aby uzupełnić graf wywołań. App Map i Transaction Search wizualizują przepływy międzyusługowe, opóźnienia i punkty zapalne awarii. Dla korelacji front-endu z back-endem, włącz JavaScript SDK i upewnij się, że nagłówki korelacji po stronie serwera są akceptowane, aby mierzyć rzeczywiste czasy ładowania stron i ścieżki użytkownika.

Azure Monitor unifikuje telemetrię platformy i aplikacji:

Metryki: Wielowymiarowe, niemal w czasie rzeczywistym (granulacja jednominutowa lub lepsza). Używaj alertów metryk ze statycznymi lub dynamicznymi progami do szybkiego wykrywania z niskim opóźnieniem.
Logi: Półustrukturyzowana telemetria w obszarze roboczym Log Analytics, odpytywana za pomocą KQL w celu głębokiej analizy i wyszukiwania anomalii.
Alerty: Reguły alertów dla metryk, logów i dziennika aktywności kierują powiadomienia do grup akcji. Używaj dynamicznych progów, targetowania wielu zasobów i wspólnego schematu alertów dla spójnej obsługi.
Grupy akcji: E-mail/SMS/połączenia głosowe, powiadomienia push, webhooki (w tym PagerDuty/OpsGenie), konektory ITSM, Logic Apps, Azure Functions i skrypty runbook w Automation do automatycznej naprawy.
Ustawienia diagnostyczne: Skonfiguruj każdy zasób Azure, aby przesyłał strumieniowo metryki/logi platformy do Log Analytics, Azure Storage (do archiwizacji) i Event Hubs (do pozyskiwania przez systemy SIEM). Zapewnij spójność dzięki wdrożeniom sterowanym przez polityki (policy-driven).

Odpytywanie i analityka za pomocą Log Analytics (KQL)

Obszar roboczy Log Analytics to granica dla zapytań i zarządzania logami. Planuj według środowiska i suwerenności danych: oddzielne obszary robocze dla środowisk produkcyjnych i nieprodukcyjnych mogą uprościć RBAC i polityki retencji; centralizacja ułatwia korelację międzyusługową. Źródła danych obejmują Azure Diagnostics (logi/metryki platformy), agenty maszyn wirtualnych (Syslog/zdarzenia Windows, liczniki wydajności), Container Insights/AKS, logi komponentów Application Insights (zunifikowane w ramach Azure Monitor Logs), logowania Azure AD, niestandardowe logi poprzez API do pozyskiwania danych oraz reguły zbierania danych (Data Collection Rules) do precyzyjnego routingu i transformacji strumieni.

Język Kusto Query Language (KQL) jest zoptymalizowany pod kątem analizy szeregów czasowych i telemetrii:

Podstawowe operatory: where (filtrowanie), project (wybór kolumn), extend (tworzenie nowych kolumn), summarize by (agregacja), join/union (korelacja), parse/parse_json (ekstrakcja), mv-expand (tablice), make-series i bin do grupowania w przedziałach czasowych, render do tworzenia wykresów.
Wzorce: Wypalanie budżetu błędów (ważone czasowo wskaźniki awaryjności), rozkłady opóźnień p50/p95, wykrywanie wartości odstających w zależnościach, wskaźnik sukcesu żądań w stosunku do ruchu oraz wykrywanie anomalii za pomocą series_decompose_anomalies dla alertów uwzględniających sezonowość.
Zarządzanie: Zapisane zapytania i funkcje promują ponowne użycie; RBAC i dostęp na poziomie tabeli ograniczają dostęp do wrażliwych zbiorów danych.
Zapytania między zasobami i obszarami roboczymi: Użyj workspace("nazwaLubIdObszaru").Tabela i funkcji workspaces() do łączenia zbiorów danych z różnych środowisk i subskrypcji; użyj resource() do złączeń między zasobami. Stosuj powiązania let i funkcję materialize() do kontrolowania wydajności przy dużych złączeniach.

Wizualizacja i zwinne informacje zwrotne w Azure DevOps

Pulpity nawigacyjne w Azure DevOps komunikują zarówno kondycję operacyjną, jak i kondycję procesu. Pulpity na poziomie zespołu koncentrują się na backlogu, iteracjach i pracy w toku (WIP) zespołu; pulpity na poziomie projektu przedstawiają widoki obejmujące wiele zespołów i portfolio. Widżety obejmują Sprint Burndown, Burnup, Velocity, Cumulative Flow Diagram (CFD), Cycle Time, Lead Time, wykresy elementów pracy/wyniki zapytań, podsumowania kompilacji/wydań oraz Markdown dla runbooków i statusu SLO. Zabezpieczaj widżety za pomocą uprawnień pulpitu nawigacyjnego i precyzyjnie określaj zakres zapytań do zespołów/obszarów, aby uniknąć wycieku danych między zespołami.

Zapytania Boards (tworzone za pomocą konstruktora zapytań lub WIQL) zasilają wiele widżetów. Parametryzuj zapytania według ścieżki obszaru/iteracji zespołu w celu ich ponownego wykorzystania; preferuj widżety oparte na Analytics, gdy są dostępne, ze względu na dokładność i wydajność. Kluczowe metryki przepływu:

Cycle time: Czas, który upłynął od stanu Aktywny (w toku) do Zakończony; użyj widżetu Cycle Time do śledzenia efektywności realizacji.
Lead time: Czas, który upłynął od utworzenia/zobowiązania do stanu Zakończony; sygnalizuje całkowite opóźnienie systemu postrzegane przez klientów.
Throughput: Liczba elementów ukończonych w danym przedziale czasowym; porównuj z politykami WIP, aby wykrywać wąskie gardła.
Cumulative Flow Diagram: Wizualizuje rozmiary kolejek według stanu w czasie; poszerzające się pasma ujawniają ograniczenia i przełączanie kontekstu. Do śledzenia sprintu używaj wykresów Burndown (trend pozostałej pracy do zera) i Burnup (całkowity zakres w porównaniu do ukończonej pracy, odporny na zmiany zakresu). Velocity raportuje średni ukończony wysiłek na sprint i stanowi podstawę do planowania pojemności; agreguj tylko te same jednostki estymacji między zespołami.

Gdy wymagana jest analityka produktu, połącz Azure DevOps Analytics z Power BI, aby połączyć metryki dostarczania z telemetrią operacyjną (np. lead time vs. wskaźnik defektów, które przedostały się na produkcję) w celu priorytetyzacji usprawnień.

Niezawodność, alertowanie i ciągła informacja zwrotna

SLI/SLO/SLA traktują niezawodność jako pierwszorzędną cechę:

SLI: Ilościowe miary doświadczenia użytkownika, np. wskaźnik pomyślnych żądań, opóźnienie p95, dostępność krytycznych punktów końcowych lub wskaźnik ukończenia zadań w interfejsie użytkownika.
SLO: Cele w danym oknie czasowym, np. 99,9% miesięcznej dostępności lub p95 < 300 ms. Wiąż SLO z podróżami użytkownika (user journeys), a nie z infrastrukturą.
Budżety błędów: 1 − SLO; zarządzają ryzykiem wydania, kryteriami wycofywania zmian i reakcją na incydenty. Zaimplementuj alerty o tempie zużycia budżetu (burn-rate) (np. 2x i 14x zużycia budżetu) używając KQL lub alertów metryk zarówno dla szybkich, jak i wolnych naruszeń.
SLA: Zewnętrzne zobowiązania wobec klientów; zazwyczaj mniej rygorystyczne niż SLO i zawierają kary umowne; są motorem napędowym, ale nie dyktują inżynierskich barier ochronnych (guardrails).

Alertowanie i dyżury (on-call):

Używaj alertów metryk dla warunków wrażliwych na opóźnienia; używaj alertów z logów dla złożonych predykatów (np. korelacji wielu sygnałów lub ocen anomalii).
Zmniejsz zmęczenie alertami dzięki deduplikacji (reguły przetwarzania alertów), dynamicznym progom, dostosowywaniu ważności (severity) i automatycznemu wyciszaniu podczas planowanych prac konserwacyjnych.
Zintegruj z PagerDuty/OpsGenie za pomocą webhooków grup akcji (action group), używając wspólnego schematu alertów (common alert schema); mapuj klucze korelacji alertów w celu deduplikacji incydentów i zdefiniuj polityki eskalacji dla każdej usługi.
Automatyzuj działania naprawcze za pomocą runbooków Azure Automation, Functions lub Logic Apps (np. skalowanie w poziomie w odpowiedzi na głębokość kolejki, restartowanie niestabilnej instancji, przełączanie flagi funkcji). Rejestruj każdą automatyczną akcję jako zdarzenie niestandardowe w Application Insights w celach audytowych.

Ciągła informacja zwrotna i eksperymentowanie:

Testy A/B i stopniowe wdrożenia (gradual rollouts): Użyj Azure Front Door lub Traffic Manager do dzielenia ruchu na brzegu sieci (at the edge) lub zaimplementuj flagi funkcji (feature flags) za pomocą Azure App Configuration Feature Manager w celu wdrożenia dla poszczególnych użytkowników lub opartego na kohortach. Zabezpieczaj ścieżki kodu flagami i zbieraj telemetrię zdarzeń dla każdego wariantu.
Telemetria użytkownika: Emituj TrackEvent ze stanem flagi funkcji, właściwościami użytkownika (bez danych osobowych - non-PII) i identyfikatorami scenariuszy. Analizuj lejki (funnels), przepływy użytkowników, retencję i wydajność kohort w Application Insights, aby weryfikować hipotezy.
Analityka wykorzystania funkcji: Twórz pulpity nawigacyjne (dashboardy) śledzące DAU/WAU/MAU, adopcję funkcji i metryki konwersji. Wykorzystuj wyniki do priorytetyzacji backlogu. Użyj bramek (gates) w Azure Pipelines, aby blokować wdrożenia na produkcję, gdy bazowe wskaźniki SLI na środowisku przejściowym (staging) nie są spełnione lub gdy wykryte zostaną regresje w KPI eksperymentu.

Praktyczny scenariusz problemowy

Spotify musi poprawić kompleksową widoczność (end-to-end visibility) i mechanizmy informacji zwrotnej dla swoich usług pozyskiwania (ingestion) i odtwarzania podcastów, wdrożonych na Azure Kubernetes Service (AKS) i jako API w Azure App Service. Incydenty są wykrywane z opóźnieniem, a zespoły produktowe nie mają wiarygodnych metryk adopcji dla nowych funkcji odtwarzania.

Instrumentacja i korelacja telemetrii aplikacji

Dodaj SDK Application Insights do usług .NET i Node.js; włącz Application Insights JavaScript SDK na klientach webowych. Skonfiguruj cloud_RoleName i connection stringi; włącz propagację W3C trace-context między mikrousługami i kolejkami komunikatów. Dlaczego: Zapewnia spójne identyfikatory korelacji i śledzenie rozproszone (distributed tracing) dla pełnej widoczności transakcji od przeglądarki po usługi i ich zależności.

Strumieniuj diagnostykę platformy do Log Analytics

Zastosuj ustawienia diagnostyczne za pomocą Azure Policy do wszystkich klastrów AKS, planów App Service, Application Gateways, kont Cosmos DB i Storage, kierując dane do centralnego obszaru roboczego (workspace) dla środowiska produkcyjnego z 90-dniową retencją i archiwizacją do Storage. Dlaczego: Gwarantuje jednolite pokrycie logów/metryk platformy dla korelacji w KQL oraz efektywną kosztowo długoterminową retencję.

Zdefiniuj SLI, SLO i budżety błędów

SLI: opóźnienie p95 dla API, wskaźnik pomyślnych żądań, przepustowość potoku pozyskiwania (ingestion pipeline) i pomyślne uruchomienie odtwarzacza.
SLO: 99,95% pomyślnych żądań miesięcznie, start odtwarzania p95 < 300 ms, opóźnienie pozyskiwania (ingestion lag) < 2 minuty.
Stwórz oparte na KQL alerty o tempie zużycia budżetu błędów (szybkie/wolne) oraz alerty metryk dla opóźnień z dynamicznymi progami. Dlaczego: Przekształca cele biznesowe w mierzalne, praktyczne cele niezawodnościowe z alertami uruchamianymi w odpowiednim czasie.

Zbuduj praktyczne alerty i integrację z dyżurami (on-call)

Stwórz reguły alertów w Azure Monitor z inteligentnym grupowaniem (smart grouping); kieruj je do grupy akcji (action group), która wyzwala PagerDuty przez webhook, używając wspólnego schematu alertów. Podłącz runbooki Azure Automation, aby automatycznie skalować w odpowiedzi na głębokość kolejki i restartować niestabilne pody. Dlaczego: Redukuje MTTA/MTTR poprzez niezawodne powiadamianie (paging) oraz bezpieczną, audytowalną automatyczną naprawę.

Stwórz pulpity nawigacyjne dla zespołów inżynierskich i produktowych

Pulpity nawigacyjne na poziomie zespołu w Azure DevOps: Cycle Time (Active→Done), Lead Time (Created→Done), CFD, Velocity i Sprint Burndown dla zespołów (squads). Pulpity na poziomie projektu: wykres Burnup dla wydań, przepustowość międzyzespołowa i status SLO za pomocą widżetów Markdown/Analytics. Dlaczego: Daje zespołom wgląd w realizację zadań, jednocześnie dostarczając kierownictwu informacji o stanie portfolio i niezawodności.

Wdróż eksperymenty i analitykę użycia

Użyj flag funkcji (feature flags) w Azure App Configuration, aby stopniowo wdrażać nową funkcję „Smart Skip Silence”. Podziel kohorty za pomocą reguł Front Door dla testów A/B na brzegu sieci (at the edge), tam gdzie to potrzebne. Emituj TrackEvent z featureFlagState, kohortą użytkownika i metrykami wyników. Dlaczego: Bezpiecznie weryfikuje wpływ zmian, jednocześnie przechwytując wysokiej jakości telemetrię użytkownika na potrzeby decyzji opartych na danych.

Wymuszaj jakość wydań za pomocą bramek (gates)

W Azure Pipelines dodaj bramki (gates), które odpytują Application Insights/Log Analytics o wskaźniki KPI na środowisku przejściowym (staging) (opóźnienie p95, wskaźnik błędów, wydajność wariantów eksperymentu). Bramka powinna zakończyć się niepowodzeniem, jeśli nie są spełnione wartości bazowe lub progi zgodne z SLO. Dlaczego: Zapobiega przedostawaniu się regresji na produkcję i dostosowuje decyzje wdrożeniowe do wskaźników KPI dotyczących niezawodności i produktu.

← Strategia testowania i inżynieria jakości · Wszystkie domeny · Zarządzanie pakietami i artefaktami →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →