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.

Обзор

Управление релизами в Azure основывается на повторяемой доставке, управляемой политиками, которая защищает доступность и ускоряет получение обратной связи. Освоение стратегий развертывания, контролируемых проверок (gated validations), поэтапного развертывания по кольцам (ring-based exposure) и «темных» запусков с помощью флагов функций (feature-flagged dark launches) позволяет командам непрерывно поставлять продукт, не жертвуя безопасностью. Azure Pipelines, Azure Deployment Environments, Azure Front Door/Traffic Manager и Azure App Configuration предоставляют единый набор инструментов для прогрессивной доставки, оркестрации в нескольких средах и аудируемого контроля изменений. В этом разделе объясняется, когда и как использовать каждую из этих возможностей, как их связывать между собой, а также какие практики отката и документирования ожидаются в конвейерах производственного уровня.

Стратегии развертывания и прогрессивная доставка

Сине-зеленое (blue-green) или красно-черное (red/black) развертывание предполагает развертывание новой версии в параллельную среду (зеленую), в то время как текущая (синяя) обслуживает трафик. В Azure App Service сине-зеленое развертывание реализуется с помощью слотов развертывания (deployment slots): развертывание в промежуточный слот (staging), его «прогрев», а затем переключение слотов (slot swap). Откат происходит мгновенно путем обратного переключения, поэтому сине-зеленое развертывание является самым быстрым вариантом отката. Используйте переключение слотов в сочетании с функцией «Swap with preview», чтобы проверить привязки и настройки приложения до перенаправления трафика.

Канареечное развертывание (canary) сначала выполняется для небольшой группы пользователей, а затем трафик постепенно увеличивается, если показатели работоспособности остаются в норме. В Azure канареечное развертывание реализуется с помощью:

взвешенной маршрутизации Azure Front Door для разделения трафика между старыми и новыми бэкендами на уровне приложения с использованием проб работоспособности и WAF.
взвешенных конечных точек Azure Traffic Manager для глобальных канареечных развертываний на основе DNS, когда требуется контроль на уровне регионов.
канареечного развертывания в AKS через Ingress (например, аннотации canary в NGINX) или разделения трафика в service mesh. Контрольные шлюзы (gates) должны оценивать бюджеты ошибок, перцентили задержек и насыщенность перед переходом к следующему этапу.

Последовательные обновления (rolling updates) заменяют экземпляры постепенно, что позволяет избежать затрат на содержание двух парков экземпляров. В AKS настройте rollingUpdate с параметрами maxSurge и maxUnavailable; убедитесь, что пробы готовности/работоспособности (readiness/liveness probes) и бюджеты нарушений работы pod’ов (PDBs) защищают доступность. Для VM Scale Sets используйте политики последовательного обновления с пробами работоспособности приложения. Последовательное обновление экономично, но восстановление после системных регрессий происходит медленнее, чем при сине-зеленом развертывании.

Флаги функций (feature flags) отделяют релиз от развертывания. «Темный» запуск (dark launching) доставляет ветки кода, отключенные по умолчанию, что позволяет протестировать инфраструктуру, не открывая функции пользователям. Используйте флаги для контроля дорогостоящих миграций, постепенного открытия нового UI и быстрого отключения проблемного функционала. Это дополняет канареечные и кольцевые развертывания: развертывайте на широкую аудиторию, а затем постепенно включайте функционал.

Развертывание по кольцам (ring-based deployment) формализует постепенное предоставление доступа для разных групп пользователей (когорт). Определите кольца, например: R0 (внутренние пользователи), R1 (клиенты для канареечного тестирования), R2 (один регион) и R3+ (глобально). Критерии перехода на следующий этап должны быть объективными: соответствие SLO, отсутствие инцидентов уровня Sev2+ и приемлемые бизнес-показатели (KPI). Сочетайте кольца с переключением трафика (Front Door/Traffic Manager), проверками среды и шлюзами утверждения (approval gates), чтобы остановить или откатить развертывание на раннем этапе.

Сравнение Azure Front Door и Traffic Manager для постепенного переключения трафика: Front Door работает на 7-м уровне (L7) с мгновенными изменениями, пробами работоспособности, привязкой сессий (session affinity), маршрутизацией на основе пути и взвешенным разделением трафика — идеально для канареечных развертываний на уровне приложения и A/B-тестирования. Traffic Manager работает на уровне DNS; он лучше подходит для геомаршрутизации, аварийного переключения между облаками или канареечных развертываний на уровне регионов, но имеет ограничения, связанные с DNS TTL, и не обладает функциями уровня приложения.

Среды, утверждения и шлюзы

Azure Deployment Environments стандартизируют предоставление сред разработки/тестирования с помощью защитных механизмов (guardrails). Определения сред (environment definitions) — это шаблоны инфраструктуры как кода (Bicep/ARM/Terraform), описывающие воспроизводимые стеки. Определения хранятся в каталогах — Git-репозиториях, зарегистрированных в сервисе, — что позволяет создавать версионируемые и легко обнаруживаемые схемы сред. Разработчики самостоятельно создают экземпляры для разработки/тестирования в рамках корпоративных политик (квоты, RBAC, сетевые настройки), что устраняет «уникальные» конфигурации (snowflakes) и приводит среды низшего уровня в соответствие с топологией производственной среды.

Утверждения (approvals) устанавливают контроль со стороны человека там, где это необходимо. В Azure Pipelines:

Утверждения перед развертыванием (pre-deployment approvals) блокируют этап до получения согласия от назначенных утверждающих лиц. Используйте их для переходов с высоким риском, например, из промежуточной среды в производственную или при расширении кольца за пределы канареечной группы.
Утверждения после развертывания (post-deployment approvals) подтверждают выполнение проверочных действий (приемочное тестирование пользователями (UAT), аудит) до того, как релиз будет помечен как завершенный.
Настройте тайм-ауты для утверждений, чтобы запросы автоматически истекали; просроченные утверждения приводят к сбою этапа и предотвращают неконтролируемые расхождения. Требуйте нескольких утверждающих или последовательные утверждения, когда необходимо разделение обязанностей. Применяйте утверждения к средам и подключениям к сервисам через раздел «Approvals and checks» для обеспечения единообразного управления.

Шлюзы релиза (release gates) требуют объективных доказательств перед повышением уровня развертывания. Azure Pipelines поддерживает такие проверки, как:

Проверки Azure Monitor, которые запрашивают метрики или оповещения (например, отсутствие активных оповещений уровня Sev2, уровень ошибок ниже порогового значения, задержка p95 ниже целевого показателя). Шлюзы выполняют повторную оценку через определенные интервалы до тех пор, пока не будет достигнут успех/неудача или не истечет тайм-аут.
Проверки вызова REST API для обращения к внешним сервисам контроля качества, нагрузочным тестам или внутренним конечным точкам для проверки соответствия. Анализируйте ответы и блокируйте развертывание, если критерии не выполнены.
Проверки запросов к рабочим элементам (work item), чтобы убедиться, что необходимые задачи, ошибки или запросы на изменение находятся в правильном состоянии перед релизом (например, все дефекты с пометкой «Must Fix» исправлены). Используйте запросы, ограниченные областью релиза или диапазоном коммитов.

Внедряйте шлюзы на границах колец и во время канареечного развертывания, чтобы перейти от субъективных к измеримым решениям о продвижении релиза.

Конвейеры для нескольких сред, переменные и зависимости

Проектируйте многоэтапные YAML-конвейеры с явными зависимостями и привязкой к средам. Используйте задания развертывания с блоками стратегий (runOnce, rolling, canary) для моделирования постепенного выката и включайте хуки preDeploy, routeTraffic, postRouteTraffic и on: failure для автоматического отката. Этапы должны объявлять dependsOn и conditions, чтобы последующие среды запускались только после прохождения предыдущими шлюзов и утверждений.

Управляйте конфигурацией для конкретной среды с помощью:

Групп переменных, привязанных к среде и связанных с Azure Key Vault для хранения секретов. Ссылайтесь на группы на каждом этапе и храните конфиденциальные значения вне системы контроля версий.
YAML-шаблонов и параметров времени выполнения для стандартизации развертываний между сервисами и передачи значений для конкретной среды (строки подключения, значения флагов функций по умолчанию, веса Front Door).
Задач токенизации или преобразования для appsettings и манифестов Kubernetes, обеспечивая конфигурацию как код без дрифта.

Для развертываний в несколько сред предпочитайте неизменяемые артефакты с продвижением по средам (сборка один раз, развертывание много раз). Связывайте рабочие элементы с коммитами и сборками для обеспечения прослеживаемости, пока один и тот же артефакт перемещается от dev до prod, что позволяет создавать точные заметки к выпуску и проводить аудиты.

Стратегии отката и работа с базами данных

Планируйте стратегии отката до релиза:

Автоматический откат использует сигналы о состоянии работоспособности для возврата к предыдущей версии без вмешательства человека. В AKS устанавливайте maxSurge/maxUnavailable консервативно и включайте автоматический откат при неудачных выкатах; используйте

undefined

или полагайтесь на хуки сбоя стратегии развертывания для запуска предыдущего ReplicaSet. В Azure App Service обратный обмен слотами происходит мгновенно; используйте его в паре с проверками работоспособности и шлюзами развертывания для автоматического принятия решений.

Ручной откат уместен, когда для восстановления требуется решение оператора (риск для данных, частичный сбой). Предоставьте задачи конвейера, запускаемые в один клик, которые перенаправляют веса Front Door/Traffic Manager, отменяют обмен слотами или повторно развертывают последнюю заведомо рабочую сборку. Держите предыдущий артефакт в свободном доступе и документируйте процесс принятия решений.
Откат базы данных требует особой осторожности. Избегайте обратно несовместимых изменений. Используйте паттерн «расширение-сжатие»: добавляйте столбцы/таблицы и заполняйте их, пока операции чтения/записи остаются совместимыми; при необходимости развертывайте код, который пишет в обе схемы; удаляйте устаревшие элементы только на более позднем этапе. Для Azure SQL Database комбинируйте:
- DACPAC или фреймворки миграции (EF Core) с идемпотентными, версионированными скриптами и проверкой до и после развертывания.
- Онлайн-операции (перестроение индексов с возможностью возобновления, переключение партиций) для минимизации конкуренции за блокировки.
- Восстановление на определенный момент времени и активную георепликацию в качестве крайней меры, осознавая риск потери данных. Отключайте функциональность с помощью флагов перед любым понижением версии схемы. Контролируйте продвижение по средам с помощью шлюзов, основанных на показателях работоспособности базы данных (DTU/CPU, взаимоблокировки), собираемых в Azure Monitor и Query Store.

Флаги функций в Azure App Configuration и автоматизация заметок о выпуске

Azure App Configuration централизует управление функциями с помощью SDK для .NET, Java, Node.js и других платформ. Используйте метки для разграничения области действия флагов по средам или кольцам развертывания и включите динамическое обновление, чтобы приложения получали изменения без повторного развертывания.

Фильтры таргетинга позволяют гранулярно включать функции на основе пользователя/группы, утверждений (claims), устройства или пользовательских атрибутов. Определите когорты (например, внутренние арендаторы, VIP-клиенты) для согласования с кольцами развертывания.
Процентное развертывание постепенно делает функции доступными для случайной подвыборки пользователей. Начните с 1–5%, проверьте KPI, а затем увеличивайте процент. Координируйте это с распределением весов в Front Door для многоуровневого контроля на уровне пользователей и трафика.
Аварийные выключатели (kill switches) мгновенно отключают функцию при возникновении инцидентов. Защитите высокорискованные операции (платежи, запись данных) с помощью глобального переключателя, который срабатывает без развертывания. Логируйте все переключения для аудита и сопоставления с инцидентами.

Автоматизируйте создание заметок о выпуске для обеспечения отслеживаемости и коммуникации:

Обеспечьте принудительную привязку рабочих элементов, требуя, чтобы сообщения коммитов и PR содержали их идентификаторы. Azure DevOps автоматически связывает сборки и релизы с рабочими элементами и коммитами.
Генерируйте журналы изменений (changelogs) в конвейерах с помощью задачи Generate Release Notes или вызовов REST API для получения списка изменений и рабочих элементов с момента последнего успешного развертывания в целевую среду. Выводите результат в формате Markdown с разделами для новых функций, исправлений, критических изменений и миграций базы данных.
Публикуйте заметки в Wiki проекта, упаковывайте их как артефакт сборки и прикрепляйте к релизу. Включайте метаданные развертывания (номер сборки, SHA коммита, среда, утверждающие лица, пройденные шлюзы) для соответствия требованиям.

Практический сценарий

Компании Adobe необходимо внедрить новый механизм персонализации на своих маркетинговых сайтах, размещенных в Azure, не рискуя показателями конверсии во время пиковых кампаний. Команда должна часто выполнять развертывания, постепенно предоставлять доступ к новой функции, проверять SLO и мгновенно выполнять откат в случае ухудшения KPI.

Определение сред с помощью Azure Deployment Environments

Создайте определения сред (Bicep) для приложений, AKS, Azure SQL и Front Door в каталоге на базе Git. Разработчики могут безопасно самостоятельно подготавливать среды разработки/тестирования, обеспечивая их паритет с производственной средой и используя эфемерные тестовые стеки для экспериментов. ADE применяет квоты и RBAC для контроля расходов и доступа.

Одна сборка, множество развертываний с помощью многоэтапных YAML-конвейеров

Единый артефакт продвигается по этапам: ring-r0, ring-r1, ring-r2 и prod. Этапы зависят друг от друга и используют задания развертывания со стратегиями: canary и rolling (скользящее) там, где это уместно, гарантируя консистентность бинарных файлов во всех кольцах.

Использование сине-зеленого развертывания со слотами App Service для унаследованного веб-уровня

Разверните приложение в промежуточный слот (staging), прогрейте его, а затем выполните переключение для внутренних пользователей кольца ring-r0. Если SLO Adobe ухудшатся, обратное переключение слотов обеспечит самый быстрый откат с почти нулевым временем простоя.

Внедрение канареечного развертывания через взвешенную маршрутизацию Azure Front Door

Зарегистрируйте как унаследованный, так и новый бэкенд персонализации. Начните с направления 1% трафика на новый бэкенд в кольце ring-r1. Пробы работоспособности (health probes) и мгновенное обновление весов в Front Door позволяют безопасно и быстро вносить корректировки в соответствии с паттернами трафика.

Контроль продвижения по этапам с помощью объективных проверок (gates)

Добавьте проверки Azure Monitor для задержки p95, частоты ошибок и KPI конверсии из Application Insights. Добавьте проверку через REST API к внутреннему сервису экспериментов Adobe для подтверждения защитных метрик (guardrail metrics). Настройте проверку запроса рабочих элементов, чтобы убедиться, что все ошибки с пометкой “Must Fix” закрыты до перехода на следующее кольцо. Шлюзы (gates) выполняют периодическую оценку и имеют тайм-аут, чтобы предотвратить зависание изменений.

Требование подтверждений на критически важных переходах

Подтверждения перед развертыванием (pre-deployment approvals) для кольца ring-r2 и prod требуют подписи от отделов маркетинга и SRE, с 4-часовым тайм-аутом для предотвращения “подвисших” релизов. Подтверждения после развертывания (post-deployment approvals) удостоверяют, что UAT и проверка аналитики завершены, прежде чем релиз будет закрыт.

Управление доступом к функции с помощью флагов функций Azure App Configuration

Реализуйте “темный запуск” (dark launching), чтобы новый механизм присутствовал в коде, но изначально был отключен. Используйте фильтры таргетинга, чтобы включить его для внутренних сотрудников (ring-r0) и выбранных когорт клиентов (ring-r1). Применяйте процентное развертывание для расширения аудитории. Аварийный выключатель (kill switch) глобально отключает механизм за секунды без повторного развертывания в случае появления аномалий.

Защита данных с помощью миграций по схеме “расширение-сжатие” (expand-contract)

Сначала разверните аддитивные изменения в SQL, асинхронно заполните данные и используйте двойную запись (dual-write), где это необходимо. Только после подтверждения стабильности удаляйте устаревшую схему. Шлюзы (gates) отслеживают DTU, взаимоблокировки (deadlocks) и длительные запросы, чтобы предотвратить небезопасное продвижение релиза.

Автоматизация путей отката

Обработчики сбоев (failure hooks) в заданиях развертывания запускают откат: веса в Front Door для нового бэкенда возвращаются к 0%; App Service выполняет обратное переключение слотов; AKS выполняет команду kubectl rollout undo. Ручной откат в один клик остается доступным для операторов в сложных сценариях.

Автоматизация документации к релизу

Конвейер генерирует заметки о выпуске в формате Markdown на основе связанных рабочих элементов и коммитов, выделяя включенные функции, изменения в базе данных и пройденные шлюзы. Заметки публикуются в Azure DevOps Wiki и прикрепляются к релизу, обеспечивая соответствие требованиям аудита и прозрачность для заинтересованных сторон.

Этот подход использует сильные стороны каждого инструмента: ADE для безопасных, воспроизводимых сред; стратегии YAML и подтверждения для управляемого потока; Front Door и App Configuration для многоуровневой постепенной доставки; Azure Monitor и шлюзы (gates) для объективного контроля качества; а также автоматизированные откаты и заметки о выпуске для обеспечения отказоустойчивости и отслеживаемости.

← Контейнеризация и Kubernetes · Все домены · Безопасность →

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