Microsoft AZ-305: Well-Architected Framework и принципы проектирования — Руководство по подготовке

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

Обзор

Azure Well-Architected Framework (WAF) — это набор предписывающих принципов, которые определяют проектирование, создание и эксплуатацию надежных, безопасных, экономичных, операционно эффективных и производительных рабочих нагрузок в Azure. Приведение решений в соответствие с пятью основными принципами — надежностью, безопасностью, оптимизацией затрат, операционным совершенством и эффективностью производительности — гарантирует, что архитектурные решения представляют собой явные компромиссы, основанные на бизнес-приоритетах, допустимом уровне риска и таких ограничениях, как суверенитет данных и бюджет. Достижение согласованности в масштабе требует использования целевых зон (landing zones), управления на основе политик и автоматизации по умолчанию. Современные архитектуры делают акцент на слабой связанности (decoupling), событийно-ориентированном взаимодействии и таких шаблонах, как CQRS, Strangler Fig и микросервисы, реализуемых с помощью нативных сервисов Azure и интегрированной наблюдаемости, чтобы соответствовать как быстрым изменениям, так и строгим требованиям комплаенса.

Пять основных принципов: надежность, безопасность, затраты, операционное совершенство, производительность

Надежность гарантирует, что рабочие нагрузки продолжают соответствовать бизнес-SLA в условиях сбоев и во время изменений. Проектируйте с учетом доменов сбоя и доменов обновления, развертывая решения в нескольких зонах доступности или парных регионах, выбирая управляемые сервисы со встроенной высокой доступностью (HA) и реализуя шаблоны отказоустойчивости. Тестируйте восстанавливаемость с помощью хаос-инжиниринга и учений по аварийному восстановлению. Для данных с отслеживанием состояния выбирайте сервисы с функциями RPO/RTO — например, Azure SQL Database Active Geo-Replication или многорегионную запись в Cosmos DB — в сочетании с автоматизированными резервными копиями и протестированными сценариями (runbooks).

Безопасность — это многоуровневая, эшелонированная защита, основанная на принципе нулевого доверия (Zero Trust). Применяйте принцип наименьших привилегий с помощью Azure RBAC, Privileged Identity Management (PIM) и проверок доступа для постоянного контроля прав. Изолируйте радиус поражения сети с помощью частных конечных точек (private endpoints), групп безопасности сети (NSG) и Azure Firewall; интегрируйте Web Application Firewall (WAF) в Azure Front Door или Application Gateway. Исходите из предположения о взломе, используя непрерывный мониторинг через Defender for Cloud, обнаружение угроз в Sentinel и строгую защиту удостоверений (MFA, Conditional Access).

Оптимизация затрат уравновешивает ценность для бизнеса и общую стоимость владения. Подбирайте правильный размер вычислительных ресурсов и уровней обслуживания на основе телеметрии; используйте масштабирование для соответствия спросу и отключайте непроизводственные среды. Используйте резервирования и планы экономии для стабильных рабочих нагрузок, применяйте Spot VMs для прерываемых вычислений, распределяйте хранилище и данные по уровням в зависимости от срока хранения и отдавайте предпочтение бессерверным решениям, если они соответствуют профилю нагрузки. Внедряйте тегирование и бюджеты, а также используйте Azure Policy для стандартизации контроля затрат.

Операционное совершенство делает акцент на автоматизации, повторяемости и циклах обучения. Относитесь к средам как к коду (environments as code) с помощью Bicep/ARM или Terraform, обеспечивайте устранение расхождений (drift remediation) и внедряйте согласованные CI/CD. Операционные инсайты поступают из структурированных логов, метрик, трассировок и синтетических тестов, которые подключены к системам оповещения и дашбордам SLO, чтобы сократить среднее время восстановления (MTTR) и обеспечить проактивные улучшения.

Эффективность производительности гарантирует, что рабочая нагрузка соответствует целям по пропускной способности и задержке при изменяющейся нагрузке. Проектируйте для горизонтального масштабирования (scale-out), агрессивно кэшируйте, размещайте контент ближе к пользователям (на границе сети), выбирайте секционирование данных и реплики для чтения, соответствующие шаблонам доступа. Проверяйте производительность с помощью реалистичных нагрузочных тестов и настраивайте систему на основе полученных данных.

Шаблоны надежности и производительности в Azure

Шаблоны отказоустойчивости снижают вероятность и влияние сбоев, сохраняя при этом предсказуемую задержку.

• Повторные попытки с экспоненциальной задержкой и джиттером (Retry with exponential backoff and jitter): Используйте настраиваемые политики повторных попыток в Azure SDK или библиотеки, такие как Polly (.NET), для обработки временных сбоев от сервисов, например Storage, Service Bus или Cosmos DB. Задержка с джиттером помогает избежать лавинообразных запросов (thundering herds); ограничивайте количество повторных попыток, чтобы защитить SLA и вовремя выявлять сбои.

• Автоматический выключатель (Circuit breaker): Оборачивайте исходящие вызовы (например, к внешним API) в автоматический выключатель, чтобы быстро отказывать, когда частота ошибок превышает пороговые значения, предоставляя время для восстановления. Реализуйте на уровне клиента с помощью Polly или на уровне шлюза с помощью политик API Management (повтор, тайм-аут и кэш), чтобы избежать каскадных сбоев.

• Переборка (Bulkhead): Разделяйте ресурсы, чтобы один «шумный сосед» не приводил к нехватке ресурсов во всей системе. Изолируйте пулы потоков, реплики контейнеров и разделы обработки сообщений. На уровне платформы используйте отдельные планы App Service, пулы узлов AKS или очереди/разделы Service Bus для каждого ограниченного контекста (bounded context), чтобы локализовать сбои.

• Мониторинг конечной точки работоспособности (Health endpoint monitoring): Предоставляйте пробы работоспособности (liveness) и готовности (readiness) в сервисах. Пробы работоспособности в Application Gateway/Front Door направляют трафик только на работоспособные экземпляры. В AKS пробы Kubernetes управляют перезапуском подов и развертыванием. Комбинируйте с тестами доступности Application Insights и пользовательскими конечными точками «/healthz» для раннего обнаружения деградации зависимостей.

Шаблоны производительности дополняют отказоустойчивость:

• Стратегии кэширования: Используйте Azure Cache for Redis для «горячих» данных и выгрузки сессий. Применяйте кэширование вывода (output caching) в Azure Front Door или API Management для идемпотентных GET-запросов. Предпочитайте шаблоны сквозной записи (write-through) или отложенной записи (write-behind), где это уместно; инвалидируйте кэш по ключу или событию для поддержания актуальности. На уровне данных интегрированный кэш Cosmos DB снижает потребление RU для нагрузок с интенсивным чтением.

• CDN: Размещайте статические ресурсы и динамический контент ближе к пользователям с помощью Azure Front Door или Azure CDN, включая сжатие, TLS и WAF. Настраивайте кэширование на основе правил, проверки работоспособности источника и геофильтрацию для оптимизации задержки и затрат.

• Реплики для чтения (Read replicas): Масштабируйте рабочие нагрузки с интенсивным чтением с помощью читаемых вторичных реплик Azure SQL Database (Active Geo-Replication) или именованных реплик Hyperscale; используйте реплики для чтения Azure Database for PostgreSQL/MySQL для аналитики или отчетности; включайте многорегионное чтение в Cosmos DB с моделированием согласованности (например, Session, Consistent Prefix) в соответствии с бизнес-требованиями.

• Шаблоны автомасштабирования: Реализуйте горизонтальное масштабирование с помощью Virtual Machine Scale Sets, правил автомасштабирования App Service, AKS HPA/KEDA для масштабирования на основе событий и планов Consumption/Premium для Functions. Для данных используйте автомасштабирование RU/s в Cosmos DB и автоматическое расширение (auto-inflate) в Event Hubs для обработки пиковых нагрузок. Всегда проверяйте пороговые значения масштабирования и периоды охлаждения (cool-down), чтобы избежать колебаний.

Принципы проектирования для операционного совершенства, оптимизации затрат и безопасности

Инфраструктура как код: Стандартизируйте использование модулей Bicep/ARM или Terraform, с версионированием в Git и проверкой с помощью предразвёрточных тестов и политики как кода (policy-as-code). Используйте спецификации шаблонов (template specs) или реестры Terraform для повторного использования. Параметризуйте для каждой среды и обеспечивайте согласованное применение тегов, блокировок ресурсов и настроек диагностики. Интегрируйте с Azure DevOps или GitHub Actions; используйте поэтапные развёртывания и утверждения для контролируемого продвижения по средам.

Автоматизация развёртывания: Отдавайте предпочтение слотам развёртывания (deployment slots), стратегиям blue-green и canary, поддерживаемым App Service, AKS (с помощью прогрессивных выкатов через Deployment strategies) и Traffic Manager/Front Door для взвешенной маршрутизации. Автоматизируйте изменения схемы базы данных с помощью конвейеров миграции и обратно совместимых контрактов. Контролируйте выкаты с помощью проб работоспособности (health probes) и бизнес-KPI.

Наблюдаемость (Observability): Инструментируйте приложения с помощью OpenTelemetry, экспортируйте данные в Application Insights для распределённой трассировки, сбора метрик и построения карт зависимостей. Включите Azure Monitor для сбора метрик платформы, разверните рабочие области Log Analytics и создайте Workbooks и дашборды для отслеживания SLO и ёмкости. Определите правила оповещений с динамическими порогами, интегрируйте их с ITSM и централизованно храните Activity Logs и журналы диагностики для аудита и расследований.

Правильный подбор размеров и контроль затрат: Используйте Azure Advisor, метрики использования Azure Monitor и профилирование в Application Insights для выявления избыточных ресурсов (простаивающие ядра, излишне выделенные vCores, завышенные RU/s). Применяйте Reservations/Savings Plans для стабильных рабочих нагрузок (VMs, SQL, Synapse), зарезервированную ёмкость (reserved capacity) для Storage и уровни обязательств (commitment tiers) для Cosmos DB. Выбирайте Spot VMs для сборочных агентов, пакетной обработки и обучения ML с использованием контрольных точек (checkpointing). Соблюдайте баланс архитектурных компромиссов: управляемые PaaS-сервисы могут снизить операционные расходы и повысить надёжность при более высокой стоимости за единицу; кэширование снижает затраты на исходящий трафик (data egress) и RU, но усложняет инвалидацию кэша; высокая доступность в нескольких регионах увеличивает расходы, но может требоваться для соблюдения RTO/RPO.

Принципы безопасности на практике:

• Эшелонированная оборона (Defense in depth): Применяйте многоуровневые средства контроля, от идентификации до данных. Используйте Private Link, чтобы трафик не выходил в публичный интернет, NSG и ASG для микросегментации, Azure Firewall Premium для инспекции TLS и WAF на периметре. Включите рекомендации Defender for Cloud и JIT-доступ (just-in-time) к виртуальным машинам.
• Принцип наименьших привилегий: Внедряйте гранулярный RBAC на уровнях групп управления, подписок и групп ресурсов; предпочитайте управляемые удостоверения (managed identities) секретам; управляйте в масштабе с помощью Azure Policy и проводите проверки доступа (access reviews) для групп, корпоративных приложений и привилегированных ролей.
• Принцип «исходите из предположения о взломе»: Требуйте использования MFA и Conditional Access, осуществляйте мониторинг с помощью Sentinel и изолируйте рабочие нагрузки с помощью отдельных целевых зон (landing zones) и подписок. Шифруйте неактивные данные (at rest) с помощью ключей платформы или CMK в Key Vault; используйте двойное шифрование, если этого требуют регуляторы. Используйте SAS для ограниченного по времени доступа к хранилищу и ротируйте ключи согласно политике.
• Классификация данных: Каталогизируйте данные с помощью Microsoft Purview, присваивайте метки конфиденциальности и применяйте политики DLP. Приведите шифрование, хранение и доступ в соответствие с уровнями классификации данных; регистрируйте доступ к PII и поддерживайте требования к конфиденциальности с помощью таких функций, как Dynamic Data Masking и Always Encrypted, где это применимо.

Зоны развертывания Azure и современные архитектурные паттерны

Зоны развертывания Azure (Azure Landing Zones) позволяют внедрить эту концепцию в больших масштабах. Организуйте иерархию групп управления (корень → платформа → бизнес-подразделения) для определения области действия Azure Policy, RBAC и бюджетов. Зоны развертывания платформы предоставляют общие службы: идентификацию (Azure AD), сетевое взаимодействие (концентратор с Azure Firewall, DDoS, DNS), управление (Log Analytics, Automation, Update Management) и безопасность (Defender for Cloud). Зоны развертывания приложений размещают рабочие нагрузки, сегментированные по средам и границам соответствия требованиям, с унаследованными политиками, которые принудительно применяют тегирование, диагностику и разрешенные типы ресурсов. Используйте дизайн Cloud Adoption Framework (CAF) Enterprise-Scale или акселераторы зон развертывания на основе Terraform/Bicep для быстрого и согласованного развертывания начальной конфигурации.

Микросервисы в Azure делают акцент на слабосвязанных командах и независимо развертываемых службах:

• Обнаружение служб (Service discovery): В AKS используйте Kubernetes DNS/CoreDNS для разрешения имен внутри кластера; дополните это сайдкарами Dapr для обнаружения по имени и повторных попыток. Service Fabric предоставляет встроенные средства именования и управления работоспособностью для служб с отслеживанием состояния.
• Паттерн «Шлюз API» (API gateway): Используйте Azure API Management для централизации маршрутизации, версионирования, аутентификации (проверка OAuth 2.0/JWT), квот и кэширования. Разместите перед ним Azure Front Door для глобальной anycast-маршрутизации, терминирования SSL и WAF; направляйте трафик по регионам и безопасно выполняйте канареечные развертывания.
• Взаимодействие на основе событий (Event-driven communication): Используйте Azure Service Bus для упорядоченных транзакционных команд с сессиями; выбирайте Event Hubs для высокопроизводительной телеметрии; и Event Grid для реактивных подписок на события по push-модели. Проектируйте систему с учетом доставки «как минимум один раз» (at-least-once delivery), идемпотентных обработчиков, обработки «отравленных» сообщений (poison message handling) и очередей недоставленных сообщений (DLQs).

CQRS и Event Sourcing разделяют модели записи и чтения для повышения производительности и изоляции сложности. Сохраняйте события в режиме «только добавление» (append-only) в хранилище событий (Cosmos DB, Azure SQL или Event Hubs с уплотнением через последующее хранилище), воспроизводите их для восстановления состояния и проецируйте в модели чтения, оптимизированные для запросов, такие как Azure SQL Database, контейнеры Cosmos DB или Azure Cognitive Search. Канал изменений (change feed) Cosmos DB — ключевой элемент для создания проекций: Azure Functions или Azure Stream Analytics могут обрабатывать изменения для обновления хранилищ чтения практически в реальном времени. Event Hubs буферизует потоки событий большого объема, при этом потребители масштабируются независимо. Используйте итоговую согласованность (eventual consistency) с четкими SLA и паттернами пользовательского опыта (например, подтверждение выполнения команды с последующей синхронизацией модели чтения).

Паттерн «Удушающая фига» (Strangler Fig) обеспечивает инкрементальную модернизацию. Разместите Azure API Management перед монолитом, чтобы направлять запросы к определенным конечным точкам на новые микросервисы, в то время как остальные запросы продолжат поступать на унаследованный бэкенд. Используйте политики для маршрутизации на основе заголовков, преобразования ответов и аутентификации. Синхронизируйте данные с помощью захвата измененных данных (change data capture, например, Azure Data Factory или Database CDC в Event Hubs) и создавайте новые модели чтения с помощью Cosmos DB и канала изменений, постепенно выводя из эксплуатации возможности монолита. Управляйте рисками с помощью флагов функций (feature flags), канареечной маршрутизации (canary routing) на уровне Front Door и комплексной наблюдаемости для сравнения поведения.

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

Компания Starbucks модернизирует свою глобальную платформу заказов, которая в настоящее время представляет собой монолит, размещенный на виртуальных машинах в одном регионе. Им необходимо повысить надежность в разных регионах, уменьшить задержку для мобильных клиентов, внедрить принцип наименьших привилегий и модель «Никому не доверяй» (Zero Trust), а также выполнить инкрементальную миграцию без прерывания бизнес-процессов.

1. Создайте корпоративные зоны развертывания

• Создайте иерархию групп управления с зонами развертывания для платформы и приложений. Примените Azure Policy для тегирования, диагностики, разрешенных SKU и частных конечных точек (private endpoints). Выберите эталонную архитектуру CAF Enterprise-Scale для идентификации, сетевого взаимодействия (концентратор с Azure Firewall Premium, Private DNS) и управления (централизованный Log Analytics). Зачем: Зоны развертывания обеспечивают применение согласованных базовых стандартов безопасности, сетевой конфигурации и управления, благодаря чему рабочие нагрузки наследуют средства контроля по своей архитектуре.

2. Разместите пограничный сервис и фасад API перед монолитом

• Разверните Azure Front Door (Standard/Premium) с WAF для обеспечения глобальной точки входа anycast, терминирования TLS и защиты от DDoS. Разместите Azure API Management в качестве шлюза API, интегрированного с Front Door, для аутентификации клиентов (OAuth 2.0), применения ограничений скорости для каждой группы потребителей и преобразования запросов/ответов. Зачем: Front Door снижает задержку и обеспечивает защиту на границе сети; API Management реализует паттерн «Шлюз API», что позволяет применить подход «Удушающая фига» и регулирование трафика для конкретных клиентов.

3. Реализуйте миграцию по паттерну «Удушающая фига»

• Используйте политики API Management для маршрутизации выбранных конечных точек (например, меню, поиск магазинов) на новые микросервисы, работающие в AKS в двух регионах; все остальные маршруты ведут к унаследованному монолиту за внутренним балансировщиком нагрузки. Зачем: Инкрементальная маршрутизация позволяет избежать единовременных («большим взрывом») переключений и дает командам возможность мигрировать функционал независимо друг от друга.

4. Создавайте микросервисы с использованием отказоустойчивых и производительных паттернов

• В AKS включите HPA с KEDA для автомасштабирования на основе событий. Используйте Dapr для обнаружения служб, повторных попыток с экспоненциальной задержкой и размыкания цепи (circuit breaking) между сервисами. Интегрируйте Azure Cache for Redis для кэширования горячих данных для чтения и выгрузки сессий. Зачем: AKS и Dapr обеспечивают платформонезависимую отказоустойчивость и обнаружение служб; кэширование снижает задержку чтения и нагрузку на бэкенд.

5. Внедрите взаимодействие на основе событий и CQRS

• Публикуйте доменные события в Azure Event Hubs; сохраняйте заказы в Cosmos DB с секционированием по клиенту или магазину. Используйте канал изменений Cosmos DB с Azure Functions для проецирования данных в модели чтения в Azure SQL Database (для отчетности) и Azure Cognitive Search (для поиска по запасам в магазинах). Зачем: Event Hubs обеспечивает слабую связность между производителями и потребителями при высокой пропускной способности; канал изменений позволяет создавать материализованные представления для CQRS почти в реальном времени, не влияя на производительность записи.

6. Усильте безопасность и управление идентификацией

• Принудительно используйте частные конечные точки (private endpoints) для служб данных, NSG/ASG для сегментации и Azure Firewall для контроля исходящего трафика. Используйте управляемые удостоверения для всех рабочих нагрузок, PIM для привилегированных ролей и проверки доступа для подписок на продукты API Management. Включите Conditional Access и MFA для операционного персонала. Зачем: Многоуровневая защита и принцип наименьших привилегий уменьшают радиус поражения и риск компрометации учетных данных; проверки доступа поддерживают гигиену прав доступа.

7. Спроектируйте систему с упором на надежность и наблюдаемость

• Развертывайте ресурсы в зонах доступности (Availability Zones) в каждом регионе, с active-active маршрутизацией Front Door и мультирегиональным развертыванием API Management. Включите мониторинг конечных точек работоспособности с помощью Front Door и проб AKS; настройте канареечные развертывания для новых служб. Инструментируйте код с помощью OpenTelemetry для отправки данных в Application Insights, централизуйте журналы в Log Analytics и создайте панели мониторинга SLO с оповещениями. Реализуйте резервное копирование/аварийное восстановление (backup/DR) для хранилищ с отслеживанием состояния и проводите хаос-инжиниринг (chaos experiments). Зачем: Избыточность на уровне зон и регионов, маршрутизация на основе состояния работоспособности и комплексная наблюдаемость позволяют поддерживать SLA и быстро реагировать на инциденты.

8. Постоянно оптимизируйте затраты

• Оптимизируйте размеры пулов узлов AKS и планов App Service на основе телеметрии; применяйте Reservations/Savings Plans для постоянных вычислительных нагрузок; используйте Spot VMs для некритичных пакетных заданий. Включите автомасштабирование Cosmos DB и оцените уровни обязательств (commitment tiers). Применяйте бюджеты/теги и ежемесячно просматривайте рекомендации Azure Advisor. Зачем: Систематическое управление затратами сохраняет производительность, минимизируя при этом избыточные расходы и стоимость единицы ресурсов.

← Миграция и модернизация · Все домены

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

Просмотреть Microsoft →