Microsoft AZ-400: Мониторинг, наблюдаемость и обратная связь — Руководство по подготовке

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

Часть Microsoft DevOps Engineer Expert AZ-400 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Современные команды DevOps рассматривают мониторинг, наблюдаемость и обратную связь как непрерывный цикл, который влияет на инженерные, операционные и продуктовые решения. В Azure телеметрия от приложений и инфраструктуры поступает в Azure Monitor и Log Analytics, где ее запрашивают, коррелируют и визуализируют. Распределенная трассировка связывает сервисы в сквозные транзакции, в то время как оповещения и интеграции с дежурными службами обеспечивают быстрое устранение неполадок. Панели мониторинга Azure DevOps, аналитика рабочих элементов и эксперименты замыкают цикл, возвращая ценные сведения в процессы планирования и поставки. Этот раздел предоставляет необходимую глубину для проектирования интегрированного стека наблюдаемости, который обеспечивает действенную обратную связь на каждом этапе.

Телеметрия, трассировка и Azure Monitor

Application Insights — это компонент мониторинга производительности приложений (APM) в составе Azure Monitor. Инструментация добавляется через:

SDK и авто-инструментацию: .NET/.NET Core, Java, JavaScript, Node.js, Python, а также Application Insights Agent для .NET и Java. Используйте строку подключения и установите cloud_RoleName для различения компонентов.
Инициализаторы и обработчики телеметрии: добавляйте или изменяйте свойства (например, tenantId) и фильтруйте персональные данные (PII) перед отправкой.
Пользовательская телеметрия: TrackEvent для бизнес-действий, TrackMetric для числовых KPI, TrackException для контекстов ошибок и TrackDependency для внешних вызовов, которые необходимо моделировать явно.

Типы телеметрии включают запросы, зависимости (HTTP, SQL, Azure SDK), трассировки, исключения, просмотры страниц, производительность загрузки страниц, результаты тестов доступности, пользовательские события/метрики и live-метрики. Сэмплирование контролирует объем и стоимость, сохраняя при этом полезный сигнал: адаптивное сэмплирование в SDK автоматически настраивает частоту для каждого типа, чтобы поддерживать целевую пропускную способность и корреляцию; сэмплирование с фиксированной частотой обеспечивает детерминированное сэмплирование для соответствия требованиям. Предпочитайте сэмплирование на стороне SDK, чтобы последующие системы никогда не обрабатывали отброшенные данные. Поддерживайте «липкое» сэмплирование (sticky sampling) для обеспечения целостности сквозной трассировки.

Распределенная трассировка обеспечивает сквозную видимость транзакций. Application Insights реализует стандарт W3C Trace-Context (traceparent/tracestate), автоматически распространяя идентификаторы корреляции через HTTP; передавайте контекст через асинхронные границы и пользовательские протоколы, чтобы избежать разрывов в трассировке. Отслеживание зависимостей автоматически собирает данные о распространенных исходящих вызовах; создавайте пользовательские зависимости для переходов в очередях сообщений или нестандартных RPC, чтобы завершить граф вызовов. App Map и Transaction Search визуализируют межсервисные потоки, задержки и горячие точки сбоев. Для корреляции между фронтендом и бэкендом включите JavaScript SDK и убедитесь, что серверная сторона принимает заголовки корреляции, чтобы измерять истинное время загрузки страниц и пути пользователей.

Azure Monitor объединяет телеметрию платформы и приложений:

Метрики: многомерные, в режиме, близком к реальному времени (с гранулярностью в одну минуту или лучше). Используйте оповещения по метрикам со статическими или динамическими порогами для быстрого обнаружения с низкой задержкой.
Логи: полуструктурированная телеметрия в рабочей области Log Analytics, запрашиваемая с помощью KQL для глубокого анализа и поиска аномалий.
Оповещения: правила для метрик, логов и журнала действий направляются в группы действий. Используйте динамические пороги, нацеливание на несколько ресурсов и общую схему оповещений для согласованной обработки.
Группы действий: Email/SMS/голосовые вызовы, push-уведомления, веб-хуки (включая PagerDuty/OpsGenie), коннекторы ITSM, Logic Apps, Azure Functions и runbook’и Automation для устранения неполадок.
Параметры диагностики: настройте каждый ресурс Azure для потоковой передачи метрик/логов платформы в Log Analytics, Azure Storage (для архивации) и Event Hubs (для приема в SIEM). Обеспечьте согласованность с помощью развертывания на основе политик.

Запросы и аналитика с помощью Log Analytics (KQL)

Рабочая область Log Analytics — это граница для запросов и управления логами. Планируйте по окружению и суверенитету данных: отдельные рабочие области для prod и non-prod могут упростить RBAC и политики хранения; централизация облегчает межсервисную корреляцию. Источники данных включают Azure Diagnostics (логи/метрики платформы), агенты ВМ (Syslog/события Windows, счетчики производительности), Container Insights/AKS, логи компонентов Application Insights (объединенные в Azure Monitor Logs), входы в Azure AD, пользовательские логи через API приема данных и Data Collection Rules для точной маршрутизации и преобразования потоков.

Kusto Query Language (KQL) оптимизирован для анализа временных рядов и телеметрии:

Основные операторы: where (фильтрация), project (выбор), extend (создание производных столбцов), summarize by (агрегация), join/union (корреляция), parse/parse_json (извлечение), mv-expand (массивы), make-series и bin для группировки по времени, render для построения диаграмм.
Паттерны: исчерпание бюджета ошибок (взвешенные по времени показатели сбоев), распределения задержек p50/p95, обнаружение выбросов в зависимостях, соотношение успешности запросов к трафику и обнаружение аномалий с помощью series_decompose_anomalies для оповещений с учетом сезонности.
Управление: сохраненные запросы и функции способствуют повторному использованию; RBAC и доступ на уровне таблиц ограничивают доступ к конфиденциальным наборам данных.
Межресурсные и межрабочие запросы: используйте workspace(“workspaceNameOrId”).Table и функцию workspaces() для объединения наборов данных из разных окружений и подписок; используйте resource() для межресурсных соединений. Применяйте привязки let и materialize() для контроля производительности при больших соединениях.

Визуализация и Agile-обратная связь в Azure DevOps

Дашборды в Azure DevOps информируют о работоспособности операционных процессов и самого процесса разработки. Дашборды уровня команды фокусируются на бэклоге, итерациях и незавершенной работе (WIP) команды; дашборды уровня проекта отображают межкомандные и портфельные представления. Виджеты включают Sprint Burndown (диаграмма сгорания спринта), Burnup (диаграмма выгорания), Velocity (скорость команды), Cumulative Flow Diagram (CFD, накопительная диаграмма потока), Cycle Time (время цикла), Lead Time (время выполнения), Work Item Chart/Query Results (диаграмма по рабочим элементам/результаты запроса), сводки по Build/Release (сборкам/релизам) и Markdown для инструкций (runbooks) и статуса SLO. Защищайте виджеты с помощью разрешений для дашбордов и строго ограничивайте область действия запросов командами/областями, чтобы избежать утечки данных между командами.

Запросы Boards (созданные через конструктор запросов или WIQL) используются во многих виджетах. Параметризуйте запросы по пути области/итерации команды для повторного использования; по возможности отдавайте предпочтение виджетам на основе Analytics для повышения точности и производительности. Ключевые метрики потока:

Время цикла (Cycle time): Время, прошедшее с момента перехода в состояние «Активно» (в работе) до «Готово»; используйте виджет Cycle Time для отслеживания эффективности выполнения.
Время выполнения (Lead time): Время, прошедшее с момента создания/принятия в работу до «Готово»; сигнализирует об общей задержке системы, как ее воспринимают клиенты.
Пропускная способность (Throughput): Количество элементов, завершенных за интервал времени; сравнивайте с политиками WIP для выявления узких мест.
Накопительная диаграмма потока (Cumulative Flow Diagram): Визуализирует размеры очередей по состояниям с течением времени; расширяющиеся полосы указывают на ограничения и переключение контекста. Для отслеживания спринта используйте диаграмму сгорания (Burndown) (тренд оставшейся работы к нулю) и диаграмму выгорания (Burnup) (общий объем работ в сравнении с завершенным, устойчива к изменениям объема). Скорость команды (Velocity) показывает средний объем завершенной работы за спринт и используется для планирования мощностей; агрегируйте только однотипные единицы оценки между командами.

Когда требуется продуктовая аналитика, подключите Azure DevOps Analytics к Power BI, чтобы объединять метрики поставки с операционной телеметрией (например, время выполнения в сравнении с количеством дефектов, пропущенных на продуктив) для приоритизации улучшений.

Надежность, оповещения и непрерывная обратная связь

SLI/SLO/SLA делают надежность ключевой характеристикой системы:

SLI (индикаторы уровня обслуживания): Количественные метрики пользовательского опыта, например, процент успешных запросов, p95 задержки, доступность критически важных эндпоинтов или процент завершения задач в UI.
SLO (цели уровня обслуживания): Целевые показатели за определенный период, например, 99,9% доступности в месяц или p95 < 300 мс. Привязывайте SLO к пользовательским сценариям (user journeys), а не к инфраструктуре.
Бюджеты ошибок: 1 − SLO; определяют риски релиза, критерии отката и реакцию на инциденты. Внедряйте оповещения о скорости исчерпания бюджета (burn-rate), например, при сжигании 2x и 14x бюджета, используя KQL или метрические оповещения как для быстрых, так и для медленных нарушений.
SLA (соглашения об уровне обслуживания): Внешние обязательства перед клиентами; обычно менее строгие, чем SLO, и включают штрафные санкции; задают направление, но не диктуют инженерные ограничения (guardrails).

Оповещения и дежурства:

Используйте метрические оповещения для условий, чувствительных к задержкам; используйте оповещения по логам для сложных предикатов (например, для корреляции нескольких сигналов или оценок аномалий).
Снижайте усталость от оповещений с помощью дедупликации (правила обработки оповещений), динамических порогов, настройки серьезности и автоматического подавления во время планового обслуживания.
Интегрируйтесь с PagerDuty/OpsGenie через вебхуки групп действий (action group) с использованием общей схемы оповещений (common alert schema); сопоставляйте ключи корреляции оповещений для дедупликации инцидентов и определяйте политики эскалации для каждого сервиса.
Автоматизируйте исправление с помощью раунбуков Azure Automation, Functions или Logic Apps (например, горизонтальное масштабирование при увеличении глубины очереди, перезапуск сбойного экземпляра, переключение функционального флага). Записывайте каждое автоматическое действие как пользовательское событие (custom event) в Application Insights для возможности аудита.

Непрерывная обратная связь и эксперименты:

A/B-тестирование и постепенное развертывание: Используйте Azure Front Door или Traffic Manager для разделения трафика на границе сети (at the edge) или внедряйте функциональные флаги с помощью Azure App Configuration Feature Manager для развертывания для отдельных пользователей или когорт. Защищайте ветки кода флагами и собирайте телеметрию событий для каждого варианта.
Пользовательская телеметрия: Отправляйте TrackEvent с состоянием функционального флага, свойствами пользователя (без персональных данных, non-PII) и идентификаторами сценариев. Анализируйте воронки, пользовательские потоки (user flows), удержание (retention) и производительность когорт в Application Insights для проверки гипотез.
Аналитика использования функций: Создавайте дашборды, отслеживающие DAU/WAU/MAU, внедрение функций и метрики конверсии. Используйте результаты для приоритизации бэклога. Используйте шлюзы (gates) в Azure Pipelines для блокировки развертывания в продакшен, если базовые показатели SLI на стейджинге не выполняются или обнаружены регрессии KPI эксперимента.

Практический сценарий проблемы

Spotify необходимо улучшить сквозную видимость и обратную связь для своих сервисов загрузки и воспроизведения подкастов, развернутых на Azure Kubernetes Service (AKS) и API на базе Azure App Service. Инциденты обнаруживаются с опозданием, а у продуктовых команд нет надежных метрик внедрения новых функций воспроизведения.

Инструментирование и корреляция телеметрии приложений

Добавьте SDK Application Insights в сервисы .NET и Node.js; включите Application Insights JavaScript SDK на веб-клиентах. Настройте cloud_RoleName и строки подключения; включите распространение W3C trace-context между микросервисами и через очереди сообщений. Зачем: Обеспечивает согласованные идентификаторы корреляции и распределенную трассировку для полной видимости транзакций от браузера до сервисов и их зависимостей.

Потоковая передача диагностических данных платформы в Log Analytics

Примените параметры диагностики через Azure Policy ко всем кластерам AKS, планам App Service, Application Gateways, Cosmos DB и учетным записям Storage, направляя данные в центральное рабочее пространство (workspace) продакшена с 90-дневным хранением и архивацией в Storage. Зачем: Гарантирует единое покрытие логов/метрик платформы для корреляции с помощью KQL и экономически эффективное долгосрочное хранение.

Определение SLI, SLO и бюджетов ошибок

SLI: p95 задержки API, процент успешных запросов, пропускная способность конвейера загрузки и успешный запуск плеера.
SLO: 99,95% успешных запросов в месяц, p95 времени запуска воспроизведения < 300 мс, задержка загрузки < 2 минут.
Создайте оповещения о скорости исчерпания бюджета ошибок (burn-rate) на основе KQL (для быстрых/медленных нарушений) и метрические оповещения о задержке с динамическими порогами. Зачем: Преобразует бизнес-цели в измеримые, действенные целевые показатели надежности со своевременными оповещениями.

Создание действенных оповещений и интеграция с дежурствами

Создайте правила оповещений в Azure Monitor с интеллектуальной группировкой (smart grouping); направляйте их в группу действий (action group), которая вызывает PagerDuty через вебхук с использованием общей схемы оповещений. Привяжите раунбуки Azure Automation для автоматического масштабирования при увеличении глубины очереди и перезапуска неработоспособных подов. Зачем: Сокращает MTTA/MTTR за счет надежных оповещений дежурным и безопасного, аудируемого автоматического исправления.

Создание дашбордов для инженеров и продуктовых команд

Дашборды уровня команды в Azure DevOps: Cycle Time (Active→Done), Lead Time (Created→Done), CFD, Velocity и Sprint Burndown для команд. Дашборды уровня проекта: Burnup для релизов, пропускная способность между командами и статус SLO через виджеты Markdown/Analytics. Зачем: Дает командам понимание процесса выполнения задач, а руководству — представление о состоянии портфеля проектов и надежности.

Внедрение экспериментов и аналитики использования

Используйте функциональные флаги (feature flags) в Azure App Configuration для постепенного развертывания новой функции «Smart Skip Silence». Разделяйте когорты с помощью правил Front Door для A/B-тестирования на границе сети (at the edge), где это необходимо. Отправляйте TrackEvent с featureFlagState, когортой пользователя и метриками результата. Зачем: Позволяет безопасно проверять влияние изменений, собирая высокоточную пользовательскую телеметрию для принятия решений на основе данных.

Обеспечение качества релизов с помощью шлюзов (gates)

В Azure Pipelines добавьте шлюзы (gates), которые запрашивают из Application Insights/Log Analytics KPI для стейджинга (p95 задержки, процент сбоев, производительность варианта эксперимента). Шлюзы должны блокировать развертывание, если базовые показатели или пороги, согласованные с SLO, не соблюдаются. Зачем: Предотвращает попадание регрессий в продакшен и приводит решения о развертывании в соответствие с KPI надежности и продукта.

← Стратегия тестирования и инженерия качества · Все домены · Управление пакетами и артефактами →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →