Как покорить облако: разбор экзамена AZ-900 и экосистемы Azure

«Вам определенно никогда не стоит держать собаку в своем дата-центре», — иронизирует облачный эксперт Эндрю Браун, намекая на жесткие стандарты безопасности и отказоустойчивости современной ИТ-инфраструктуры. Сегодня переход к облачным моделям позволяет бизнесу сократить капитальные расходы в среднем на 75%, полностью переложив обслуживание физического «железа» на провайдера. Этот фундаментальный гид по экосистеме Microsoft Azure и сертификации AZ-900 предлагает детальный разбор облачной архитектуры, концепций безопасности Zero Trust и практических инструментов автоматизации развертывания кода.

☁️ Введение в облачные вычисления и сертификацию AZ-900 0:00

Обзор сертификации AZ-900 и её ценность 1:08

Сертификация Microsoft Azure Fundamentals, также известная как AZ-900, представляет собой базовую ступень в иерархии облачного обучения Microsoft . Этот экзамен разработан для широкого круга специалистов: от полных новичков без технического бэкграунда до опытных инженеров, которым требуется систематизировать свои знания . Как отмечает инструктор Эндрю Браун , для успешной сдачи не требуется обязательных предварительных условий или навыков программирования, хотя минимальный опыт в IT будет преимуществом . Программа дает так называемый «взгляд с высоты 50 000 футов» , позволяя понять устройство облачной экосистемы Azure, которая на сегодняшний день занимает второе место по популярности в мире после AWS .

Несмотря на статус начального уровня, данный экзамен не стоит недооценивать. Он не подтверждает умение создавать сложные облачные архитектуры на практике , но закладывает прочный теоретический фундамент для дальнейшей специализации . Помимо AZ-900, Microsoft предлагает и другие фундаментальные треки, такие как AI-900 для работы с искусственным интеллектом или DP-900 для баз данных . В классическом сценарии развития карьеры после сдачи AZ-900 специалисты переходят к подготовке на статус администратора по курсу AZ-104 , а затем двигаются в сторону разработки на AZ-204 или проектирования сложных систем в качестве сертифицированных архитекторов решений. В последующих главах будут подробнее разобраны такие смежные темы, как управление учетными записями Microsoft Entra ID и расчет стоимости Azure , которые детально проверяются на следующих этапах обучения.

Особенности экзамена: регламент, форматы вопросов и подготовка 7:00

Подготовка к экзамену требует времени и системного подхода. Для абсолютных новичков Эндрю Браун рекомендует выделить около 30 часов на изучение теории и практику . Для специалистов с опытом работы в других облаках (например, AWS или GCP) это время может сократиться до 6 часов . Оптимальный темп подготовки составляет от 1 до 2 часов занятий ежедневно в течение двух недель . Сам экзамен администрируется через систему Pearson View . Тестирование можно проходить как дома под наблюдением проктора, так и в специализированных очных центрах . Автор курса настоятельно рекомендует выбирать очный формат, поскольку он исключает стресс, связанный с проверкой домашней комнаты и возможными техническими сбоями .

Структура экзамена AZ-900 делится на три основные области знаний:

• Описание облачных концепций (Cloud Concepts) — от 25% до 30% вопросов ;
• Описание архитектуры и служб Azure (Azure Architecture and Services) — от 35% до 40% вопросов ;
• Описание управления и руководства Azure (Azure Management and Governance) — от 30% до 35% вопросов .

Сам экзамен оценивается по шкале от 1 до 1000 баллов, где проходным порогом является оценка в 700 баллов . Студентам предлагается ответить на количество вопросов в диапазоне от 35 до 50 штук , при этом штрафы за неверные ответы отсутствуют . В тесте встречаются разнообразные форматы заданий: стандартный одиночный и множественный выбор, перетаскивание элементов (drag-and-drop), интерактивные области (hot areas) и кейс-стади , , . На прохождение выделяется 45 минут чистого времени, а общее время сессии с учетом заполнения анкет и NDA составляет около 60–65 минут , . Приятным бонусом является то, что все фундаментальные сертификаты Microsoft серии 900 не имеют срока действия и остаются активными навсегда . Стоимость регистрации на экзамен составляет порядка 99 долларов США в зависимости от региона проживания кандидата .

Что такое облачные вычисления и эволюция хостинга 24:33

В основе концепции Azure лежит фундаментальное понимание того, что представляют собой облачные вычисления. Эндрю Браун определяет облачные вычисления как практику использования глобальной сети удаленных серверов, размещенных в интернете, для хранения, управления и обработки данных вместо использования локального физического сервера или персонального компьютера . Главное отличие облака от классической локальной инфраструктуры (on-premises) кроется в распределении рисков и зон ответственности. В локальной среде компания обязана самостоятельно покупать серверное оборудование, нанимать системных администраторов, арендовать и обслуживать недвижимость, а также полностью брать на себя все финансовые риски . В облачной модели физическую инфраструктуру, обслуживание серверов и охрану дата-центров берет на себя провайдер, тогда как клиент отвечает исключительно за конфигурацию служб и написание кода .

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

☁️ Модели обслуживания и развертывания облака 25:12

От выделенного сервера к распределенным вычислениям: эволюция хостинга 25:25

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

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

В середине 2000-х годов благодаря таким провайдерам, как GoDaddy и HostGator, широкое распространение получил виртуальный хостинг (Shared hosting) . Идея заключалась в том, что сотни независимых клиентов делили ресурсы одной физической машины, получая доступ к отдельным изолированным папкам с правами доступа . Такое решение было крайне дешевым, но имело существенный недостаток — практически полное отсутствие гарантированной изоляции ресурсов . Если один из арендаторов резко увеличивал нагрузку на сервер, это приводило к сбоям и замедлению работы сайтов всех остальных клиентов на этой машине .

Решением этих проблем стал облачный хостинг (Cloud hosting), построенный на принципах распределенных вычислений . В этой модели множество физических серверов объединяются в единую скоординированную систему, абстрагированную для пользователя . Облачный хостинг сочетает ключевые преимущества предыдущих подходов:

• Гибкость конфигурирования полноценных виртуальных машин ;
• Высокую безопасность благодаря надежной виртуальной изоляции ресурсов ;
• Низкую стоимость за счет распределения затрат между тысячами клиентов ;
• Практически безграничное масштабирование .

По словам преподавателя курса Эндрю Брауна, облачные провайдеры группируют свои многочисленные сервисы по четырем основным направлениям: вычисления (Compute), хранение данных (Storage), сетевое взаимодействие (Networking) и базы данных (Databases) . При этом термин «облачные вычисления» (Cloud computing) сегодня используется как собирательное понятие, охватывающее все эти категории услуг .

IaaS, PaaS, SaaS: три кита облачного обслуживания 32:10

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

На самой вершине этой пирамиды находится модель «программное обеспечение как услуга» (SaaS — Software as a Service) . В рамках этой модели клиент получает полностью готовый к использованию программный продукт, который работает и обслуживается силами облачного провайдера . Пользователю не нужно беспокоиться о поддержке инфраструктуры, обновлении ПО или его работоспособности . Популярными примерами SaaS-решений, ориентированных на конечных бизнес-пользователей, являются CRM-система Salesforce, почтовый сервис Gmail и офисный пакет Office 365 .

Средний уровень занимает модель «платформа как услуга» (PaaS — Platform as a Service) . Данная концепция фокусируется исключительно на разработке, развертывании и управлении приложениями . Разработчикам больше не требуется тратить время на инициализацию серверов, настройку операционных систем или администрирование физического оборудования . Типичными PaaS-решениями являются хостинг-платформа Heroku (популярная среди начинающих разработчиков), AWS Elastic Beanstalk и Google App Engine . PaaS создана для того, чтобы программисты могли сфокусироваться на написании кода, а не на администрировании инфраструктуры .

В основании пирамиды находится «инфраструктура как услуга» (IaaS — Infrastructure as a Service) . Эта модель предоставляет фундаментальные ИТ-компоненты: виртуальные процессоры, дисковые накопители и сетевые интерфейсы . Клиенты IaaS избавляются от необходимости содержать собственные дата-центры и физическое серверное железо . Крупнейшими IaaS-платформами выступают Microsoft Azure, Amazon Web Services (AWS) и Oracle Cloud . Данный уровень ориентирован на системных администраторов и служит базовым фундаментом, поверх которого могут быть развернуты любые PaaS- и SaaS-решения .

Модель разделенной ответственности: кто за что отвечает? 34:22

Переход от локальной ИТ-инфраструктуры к облачным моделям влечет за собой фундаментальное перераспределение обязанностей по управлению и безопасности . Для четкого разграничения этих зон используется модель совместной ответственности (Shared Responsibility Model) . Эндрю Браун детально разбирает разделение зон влияния между клиентом и облачным провайдером по девяти технологическим слоям .

При использовании локальной инфраструктуры (On-Premise), которая также может выступать в роли частного облака, клиент несет единоличную и стопроцентную ответственность за абсолютно все уровни стека .

В модели IaaS провайдер берет на себя ответственность за физические уровни инфраструктуры и виртуализацию: сетевое оборудование, хранилища данных, физические серверы и гипервизоры . На стороне клиента остается полный контроль и ответственность за операционную систему (OS), промежуточное программное обеспечение (middleware), среду выполнения кода (runtime), а также за безопасность приложений и сохранность данных .

Переходя на уровень PaaS, клиент перекладывает на провайдера администрирование операционной системы, middleware и среды выполнения . В этой схеме зона ответственности заказчика сужается до управления непосредственно бизнес-приложениями и собственными данными .

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

Таким образом, действует ключевое правило облачной инженерии: чем выше вы поднимаетесь по пирамиде облачных услуг (от IaaS к SaaS), тем меньше рутинных инфраструктурных задач и ответственности ложится на плечи вашей организации .

Модели развертывания: публичное, частное, гибридное и мультиоблако 36:06

Помимо архитектуры обслуживания, критически важно правильно выбрать модель развертывания облачной инфраструктуры . Существует три основных подхода, а также набирающие популярность мультиоблачные концепции:

1. Публичное облако (Public Cloud). Инфраструктура полностью создается и функционирует на оборудовании облачного провайдера (например, Azure) . В индустрии эту модель также часто называют термином Cloud Native . Пример реализации публичного облака — развертывание виртуальной машины и базы данных непосредственно в глобальной сети Azure . Эта модель максимально экономична и предлагает надежные стандарты безопасности по умолчанию . Однако уровень гибкости низкоуровневых настроек железа здесь ограничен возможностями, которые предоставляет сам провайдер .

2. Частное облако (Private Cloud). Вся инфраструктура разворачивается внутри собственных дата-центров компании (On-Premise) . Для эмуляции функционала полноценного облака организации часто применяют специализированное ПО с открытым исходным кодом, такое как OpenStack . Главным преимуществом частного облака является абсолютный контроль над конфигурацией аппаратного и программного обеспечения . Минусы — чрезвычайно высокая стоимость развертывания , необходимость содержания штата высококлассных ИТ-специалистов и сложность обеспечения безопасности без проработанных автоматизированных систем мониторинга, которые предоставляют публичные CSP .

3. Гибридное облако (Hybrid Cloud). Модель, объединяющая локальные ресурсы компании и мощности публичного облака в единую рабочую среду . Для стабильной связи между ними используются специализированные технологии, такие как выделенные оптоволоконные каналы ExpressRoute, прокладываемые напрямую от локального дата-центра в сеть Azure . Гибридный подход позволяет крупным игрокам находить баланс между экономической эффективностью публичного облака и жесткими государственными или корпоративными требованиями к хранению конфиденциальных данных в собственном периметре [37:40, 39:11]. Недостатком является максимальная архитектурная сложность, требующая от инженеров глубоких знаний как облачных, так и локальных технологий .

Помимо трех базовых моделей, в крупных корпорациях активно развивается подход Cross-Cloud (или мультиоблако), подразумевающий одновременное использование услуг нескольких независимых облачных провайдеров . Технологии вроде Azure Arc расширяют возможности администрирования, позволяя развертывать и контролировать контейнеры Kubernetes на альтернативных платформах (например, AWS EKS и Google GKE) , объединяя их в общую управляемую сеть .

Ранее в разговоре лекторы кратко затрагивали общую концепцию облачных вычислений и Azure как глобального провайдера. В последующих главах курса Эндрю Браун подробно остановится на финансовых аспектах облака — расчете совокупной стоимости владения (TCO) и разнице между капитальными (CapEx) и операционными (OpEx) расходами , детально разберет ключевые архитектурные свойства отказоустойчивых систем (высокую доступность, масштабируемость и эластичность) , а также углубится в глобальную инфраструктуру регионов и зон доступности Azure .

3. Отказоустойчивость, аварийное восстановление и глобальная инфраструктура Azure 50:12

Концепции отказоустойчивости, эластичности и метрики RTO/RPO 50:12

В современной облачной архитектуре эластичность играет ключевую роль при масштабировании ресурсов под меняющуюся нагрузку. В экосистеме Azure для автоматического горизонтального масштабирования виртуальных машин применяются VM Scale Sets, которые динамически увеличивают или уменьшают количество инстансов на основе заданного расписания или текущих показателей утилизации . Другим примером гибкого распределения нагрузок является технология SQL Server Stretch Database, позволяющая незаметно для приложения переносить «теплые» и «холодные» транзакционные данные из локального SQL Server 2016 в облако Azure .

Отказоустойчивость (Fault Tolerance) определяет способность системы продолжать функционирование при сбое отдельных компонентов, полностью исключая наличие единой точки отказа (single point of failure) . Если высокая доступность (High Availability) фокусируется на минимизации простоев, то отказоустойчивость нацелена на полное предотвращение сбоев за счет механизмов автоматического переключения (failover) . В такой архитектуре создается копия основной базы данных — вторичная система (standby), которая находится в режиме ожидания . Все операции записи на первичной базе синхронизируются со вторичной копией . При аппаратном или программном сбое первичного узла специальный детектор перенаправляет трафик, и резервная база мгновенно берет на себя роль основной . Для реализации подобных отказоустойчивых систем на глобальном уровне DNS в Azure применяется инструмент Azure Traffic Manager .

Высокая надежность и способность восстанавливаться после масштабных катастроф составляют основу аварийного восстановления (Disaster Recovery) . Жизнеспособность бизнеса в кризисных сценариях регламентируется планом непрерывности бизнеса (BCP — Business Continuity Plan) , ключевыми метриками в котором выступают параметры RPO и RTO:

• RPO (Recovery Point Objective) — максимальный объем данных (выраженный во временном интервале), который организация готова безвозвратно потерять в результате незапланированного сбоя .
• RTO (Recovery Time Objective) — максимальное время простоя инфраструктуры, которое бизнес может перенести без критических финансовых и операционных потерь .

Стратегии аварийного восстановления (Disaster Recovery) 55:12

Выбор конкретной стратегии аварийного восстановления всегда представляет собой компромисс между совокупной стоимостью решений и скоростью возврата к штатному режиму работы . Традиционно эти подходы классифицируют по температурной шкале от «холодных» к «горячим» :

1. Backup and Restore (Резервное копирование и восстановление): Наиболее экономичный, но медленный метод, подходящий для низкоприоритетных задач . Данные периодически архивируются, а при аварии инфраструктура разворачивается заново с последующим накатыванием бэкапа . Время восстановления (RTO) измеряется часами .
2. Pilot Light («Дежурный режим»): Данные непрерывно реплицируются в резервный регион, где в минимальном режиме работают лишь базовые службы поддержки репликации данных . Остальные вычислительные ресурсы запускаются и масштабируются только после наступления инцидента . RTO составляет около 10 минут .
3. Warm Standby (Теплый резерв): В резервном регионе развертывается уменьшенная копия рабочей инфраструктуры, готовая к мгновенному масштабированию при аварии основного сайта . Это дорогостоящий метод, обеспечивающий время восстановления в считанные минуты .
4. Multi-site Active-Active (Мультисайтовый активный режим): Полная идентичная копия инфраструктуры работает параллельно в другом регионе . Этот метод гарантирует практически нулевое время простоя и исключает потерю данных, однако удваивает затраты на содержание инфраструктуры .

В этом блоке лекции автор также затрагивает эволюцию вычислений от выделенных серверов (dedicated bare metal) к виртуальным машинам , контейнерам и бессерверным функциям (functions) , детальный разбор которых как вычислительных ресурсов Azure будет представлен далее в Главе 5.

Глобальная инфраструктура Azure: регионы, географии и парные регионы 1:03:34

Microsoft Azure обладает одной из самых разветвленных облачных инфраструктур в мире. Ее базовой единицей является регион — группа дата-центров, расположенных в пределах определенного географического периметра . На момент записи лекции Azure насчитывает 58 регионов в 140 странах .

Несколько регионов объединяются в географические зоны (geographies) — обособленные рынки, созданные для соблюдения требований к локализации данных (data residency) и нормативно-правового соответствия . В качестве примеров географий выделяются США, Канада, Бразилия и Мексика . Например, если канадская компания по закону обязана хранить данные клиентов на территории своей страны, она выбирает географию Canada, гарантируя, что информация никогда не покинет канадскую юрисдикцию . При создании любого ресурса, например виртуальной машины, пользователю необходимо вручную указать целевой регион . Глобальная карта инфраструктуры Azure охватывает все ключевые регионы, включая Австралию, Африку, Южную и Северную Америку, Западную Европу и Азию (включая Японию и Китай) .

Для обеспечения повышенной отказоустойчивости каждый регион Azure имеет своего «партнера» — парный регион (paired region), расположенный на расстоянии не менее 300 миль (около 480 км) . Это гарантирует, что если один регион уходит на плановое обновление, его пара остается полностью доступной . Ряд сервисов Azure автоматически использует парные регионы для аварийного восстановления . Примером служит геоизбыточное хранилище (Geo-redundant storage, GRS), которое автоматически дублирует данные во вторичный регион . Примеры парных регионов:

• Canada Central парный к Canada East .
• East US парный к West US .
• Germany Central парный к Germany Northeast .

Уровни доступности сервисов и зоны доступности (Availability Zones) 1:07:54

Набор доступных облачных служб различается в зависимости от выбранного региона . Azure разделяет регионы на два типа:

• Recommended (Рекомендуемые): Регионы с максимально широким спектром сервисов, изначально спроектированные с поддержкой зон доступности .
• Alternate (Альтернативные): Регионы, расширяющие присутствие Azure в рамках одной географии, но не поддерживающие зоны доступности (в портале Azure они помечаются как "other") .

Когда сервис выходит из стадии тестирования и становится публично доступным для всех клиентов, он переходит в статус General Availability (GA) . По уровню доступности сервисы Azure делятся на три категории:

1. Foundational (Базовые): Доступны сразу во всех рекомендуемых и альтернативных регионах при выходе в GA или в течение 3–12 месяцев после анонса .
2. Mainstream (Основные): Доступны во всех рекомендуемых регионах сразу при выходе в GA (или в течение 12 месяцев), а в альтернативных регионах появляются по мере запросов со стороны клиентов .
3. Specialized (Специализированные): Разворачиваются в рекомендуемых или альтернативных регионах исключительно на основе спроса клиентов .

Для соблюдения жестких юридических норм созданы специализированные регионы. К ним относятся облака для правительства США (US DoD Central, US Gov Virginia, US Gov Iowa, а также еще три секретных региона для оборонных нужд) и регионы в Китае (China East и China North), работающие через уникальное партнерство Microsoft с местным провайдером 21Vianet .

Зона доступности (Availability Zone, AZ) — это обособленная физическая локация внутри региона, состоящая из одного или нескольких дата-центров . Каждый дата-центр представляет собой укрепленное здание со своей системой питания, охлаждения и сетевой инфраструктурой . «В дата-центрах никогда не должно быть собак», — шутит лектор, демонстрируя фото серверной стойки . Как правило, регион Azure содержит не менее трех зон доступности . Они физически изолированы друг от друга, но соединены высокоскоростными линиями связи с ультранизкой задержкой (менее миллисекунды) . Запуск нагрузок одновременно в трех AZ гарантирует высокую доступность (High Availability) . К регионам со стопроцентной поддержкой трех AZ относятся Central US, East US 2, West US 2, West Europe, France Central, Northern Europe и Southeast Asia . Если же регион не поддерживает зоны доступности (например, Brazil South), выбор AZ в веб-интерфейсе блокируется, и пользователю доступен лишь вариант «резервирование инфраструктуры не требуется» .

👤 Управление доступом в облаке: Создание учетных записей и групп в Microsoft Entra ID 1:36:47

Архитектура арендаторов и создание групп безопасности 1:36:47

При администрировании облачных сред Microsoft Azure критически важно понимать структуру логических пространств, в которых вы работаете. Главным таким пространством является арендатор (tenant). Автор курса Эндрю Браун демонстрирует управление доступом на примере своего учебного арендатора под названием «Starfleet» . Для быстрого переключения между различными директориями в Azure можно использовать меню в правом верхнем углу портала , однако классический метод администрирования предполагает переход в раздел Azure Active Directory (ныне Microsoft Entra ID) и использование выделенной кнопки «Switch tenant» . В этом же интерфейсе отображается информация о текущей лицензии — например, в рамках демонстрации используется премиальный тариф Azure AD Premium P2 .

Перед созданием конкретных учетных записей пользователей лучшей практикой считается подготовка групп. Создание групп безопасности позволяет структурировать права и избегать хаотичного назначения ролей . При создании новой группы администратору предлагается выбор между двумя типами:

• Microsoft 365: используется для совместной работы и предоставляет доступ к общим почтовым ящикам, календарям, файлам и сайтам SharePoint .
• Security (Группа безопасности): классический инструмент Azure для централизованного управления доступом к облачным ресурсам .

В рамках практического примера создается группа безопасности с именем «developers» . Важным параметром здесь является тип членства (Membership type). Если вы используете бесплатный тариф, вам будет доступно только ручное управление составом (Assigned) . Однако расширенная лицензия уровня Premium P2 открывает доступ к динамическим группам (Dynamic User) . Этот механизм позволяет автоматически наполнять группу на основе правил. Например, можно составить динамический запрос: «если в профиле пользователя в графе "Страна" указано "Canada", автоматически добавить его в эту группу» .

Создание пользователей, роли и восстановление учетных записей 1:38:44

Процесс добавления нового сотрудника в систему начинается в подразделе «Users» . Для демонстрации Эндрю Браун создает учетную запись для нового пользователя по имени Kevin Uxbridge . При создании профиля Azure автоматически генерирует временный пароль, состоящий из четырех случайных букв и четырех цифр . Эндрю Браун отмечает, что такой формат трудно назвать эталоном безопасности , однако это не критично: политика безопасности Azure по умолчанию требует от нового сотрудника сменить этот временный пароль на собственный при первом же входе в систему .

На этапе создания учетной записи администратор может сразу привязать пользователя к созданным ранее группам и назначить ему конкретные административные роли . После нажатия кнопки «Create» новый профиль мгновенно появляется в общем списке .

Жизненный цикл учетных записей в Entra ID защищен от случайных ошибок администраторов. Если пользователя удалить, его учетная запись не стирается безвозвратно, а перемещается в специальный подраздел «Deleted users» (Корзина) . Удаленные записи хранятся там ровно 30 дней, в течение которых их можно легко восстановить . По истечении этого срока система удаляет их окончательно . В видео показано быстрое восстановление ранее удаленного сотрудника по имени Rishan: достаточно отметить ее профиль галочкой и нажать кнопку «Restore user» . Спустя несколько секунд после обновления страницы восстановленный пользователь снова появляется в списке активных учетных записей .

Безопасность инфраструктуры и переход к MFA 1:40:17

Надежное управление доступом невозможно без внедрения политик строгой аутентификации. Сразу после настройки базовой структуры пользователей и групп логичным шагом становится включение многофакторной аутентификации (MFA) для всех учетных записей . Это позволяет защитить корпоративную среду от компрометации паролей, требуя дополнительного подтверждения входа через мобильное приложение или SMS. Ранее в разговоре авторы уже затрагивали общие принципы создания аккаунта в Azure , а также базовые концепции распределения инфраструктуры по доменам обновления и отказа для обеспечения высокой доступности , однако именно правильное конфигурирование каталога Entra ID является фундаментом для построения безопасной среды.

Стоит помнить, что управление правами пользователей тесно связано с доступностью самих сервисов Azure. Если пользователю с определенной ролью потребуется создать базу данных Cosmos DB или запустить виртуальную машину , соответствующие провайдеры ресурсов (Resource Providers) должны быть предварительно зарегистрированы на уровне вашей подписки . Без этой регистрации даже администратор с полными правами в Entra ID столкновения с ошибками развертывания.

💻 Вычислительные службы Azure: от виртуальных машин до масштабируемых инфраструктур 1:43:59

Прежде чем погрузиться в мир облачных вычислений, спикеры завершают обсуждение безопасности, упомянув настройку многофакторной аутентификации (MFA) в рамках управления учетными записями, о которых подробно шла речь в предыдущих главах. Теперь фокус смещается на один из фундаментальных блоков облака — вычислительные ресурсы. Хотя в Azure существуют другие инструменты для работы с контейнерами (такие как Azure Container Instances и Kubernetes Service) и бессерверные функции , классические виртуальные машины остаются основой облачной инфраструктуры для большинства enterprise-решений.

Архитектура и основы Azure Virtual Machines 1:43:59

Виртуальные машины (Virtual Machines, VM) представляют собой наиболее распространенный тип вычислительных систем при развертывании серверов в облаке . Пользователь получает в свое распоряжение полноценный виртуальный компьютер под управлением операционной системы Windows или Linux . Физическое серверное оборудование при этом делится с другими клиентами Azure, однако архитектура гипервизора обеспечивает полную изоляцию и создает ощущение 100% владения ресурсами .

Основное преимущество виртуализации заключается в том, что клиенту не нужно покупать и обслуживать физическое «железо» . В то же время за ним сохраняется полная ответственность за программный слой: обновление ОС, патчи безопасности и установку системных пакетов . По умолчанию лимит на одну подписку составляет 20 виртуальных машин на один регион . Биллинг ресурса рассчитывается по часам . Одиночный экземпляр ВМ с подключенным диском Premium SSD гарантирует уровень доступности (SLA) не менее 99.9% . Если же требуется повысить отказоустойчивость до 99.95%, необходимо развернуть как минимум две машины в рамках одного набора доступности (Availability Set) .

При создании виртуальной машины Azure автоматически генерирует целый комплекс сопутствующих инфраструктурных компонентов:

• Сетевой интерфейс (NIC), обрабатывающий IP-протоколы и отвечающий за связь с сетью .
• Группа безопасности сети (NSG), выполняющая функцию виртуального межсетевого экрана с правилами для портов .
• Публичный IP-адрес, предоставляющий доступ к машине из внешней сети .
• Виртуальная сеть (VNet), внутри которой изолированно разворачивается инстанс .

Azure поддерживает широкий спектр партнерских и оптимизированных образов операционных систем (Ubuntu, Red Hat, Debian, FreeBSD, Rancher OS) . Также существует возможность загрузить собственный дистрибутив Linux, предварительно упаковав его в виртуальный жесткий диск формата VHD . Стоит учитывать, что Azure работает только с классическим форматом VHD и не поддерживает более современный VHDX .

Масштабируемые наборы виртуальных машин (Scale Sets) 1:52:33

Для автоматического управления емкостью инфраструктуры и оптимизации затрат используются масштабируемые наборы — Azure Virtual Machine Scale Sets . Они позволяют динамически увеличивать (Scale Out) или уменьшать (Scale In) количество идентичных ВМ в зависимости от текущей нагрузки на приложение. С помощью этой службы ИТ-архитекторы могут масштабировать систему от 100 до 1000 машин в рамках одного набора .

Для корректного распределения входящего трафика между экземплярами набора крайне важно использовать балансировщики . В зависимости от архитектуры приложения выбирается один из двух вариантов: Application Gateway для веб-трафика HTTP/HTTPS (работает на 7-м уровне OSI) либо Azure Load Balancer для сетевых протоколов TCP/UDP (4-й уровень OSI) .

Логика автоматического масштабирования базируется на метриках хоста, таких как уровень утилизации CPU, объем входящего/исходящего сетевого трафика или интенсивность дисковых операций . Если стандартных метрик недостаточно, разработчики могут интегрировать пакет Application Insights для отслеживания количества пользовательских сессий либо установить расширение Azure Diagnostic Extension для сбора детальной системной телеметрии .

При уменьшении емкости набора (Scale In) применяется настраиваемая политика удаления . По умолчанию система удаляет ВМ с наибольшим идентификатором инстанса, предварительно балансируя их количество между зонами доступности . Однако можно задать удаление самых новых или самых старых машин . Поведение системы при обновлении ПО регулируется политиками апдейта: автоматической (обновление раскатывается сразу в случайном порядке), ручной или скользящей (Rolling), при которой машины обновляются поочередно небольшими группами . За проверку жизнеспособности приложений отвечает расширение Application Health Extension, пингующее заданный HTTP/HTTPS-путь и ожидающее статус 200 , либо зонды балансировщика . Включение политики автоматического восстановления (Automatic Repair Policy) заставляет Azure мгновенно уничтожать зависшие или неисправные экземпляры и разворачивать на их месте новые .

Azure Virtual Desktop: удаленная работа и безопасность 1:59:33

Azure Virtual Desktop (ранее известный как Windows Virtual Desktop) представляет собой облачный сервис виртуализации рабочих столов и приложений . Пользователи могут подключаться к полноценным рабочим средам Windows 10, Windows 11 или Windows Server с любых устройств под управлением macOS, iOS, Android, Linux, а также через большинство современных веб-браузеров .

Данная технология незаменима в корпоративных сценариях с повышенными требованиями к безопасности: все пользовательские данные остаются на защищенных серверах Azure и физически не могут быть сохранены на локальном устройстве сотрудника . Решение бесшовно интегрируется с пакетом Microsoft 365 для предприятий и клиентом Microsoft Teams .

С точки зрения финансов, Azure Virtual Desktop позволяет существенно снизить затраты за счет использования уже имеющихся у организации лицензий Windows или Microsoft 365 . Защита инфраструктуры от сбоев реализуется с помощью встроенных облачных технологий резервного копирования Azure Backup и аварийного восстановления Azure Site Recovery . ИТ-отделы избавляются от необходимости администрировать физические ПК, фокусируясь только на управлении пользователями, приложениями и образами ОС , в то время как доступ гибко разграничивается через механизм условного доступа Azure Active Directory .

Пошаговый запуск виртуальной машины в облаке 2:01:09

Эндрю Браун демонстрирует практический процесс развертывания виртуального сервера на портале Azure . Для создания машины необходимо воспользоваться глобальным поиском и перейти в раздел «Virtual Machines» . После нажатия кнопки добавления нового ресурса открывается мастер настройки, где в первую очередь выбирается группа ресурсов (Resource Group) , задается имя ВМ (например, myVM) и географический регион размещения (в данном случае — US East) .

Важнейшим шагом является выбор размера виртуальной машины, определяющий количество vCPU, объем RAM и итоговую стоимость . Для демонстрационных целей спикер выбирает наиболее экономичный тариф B1LS (1 vCPU, 0.5 ГБ оперативной памяти) . В качестве способа авторизации для упрощения теста выбирается вход по паролю . Azure предъявляет жесткие требования к сложности пароля: он должен содержать не менее 12 символов, заглавные и строчные буквы, цифры и специальные знаки (для демонстрации используется пароль Testing123!!) .

Входящие сетевые порты на этапе создания полностью блокируются («none») . В разделе дисков по умолчанию оставляется Premium SSD с включенным по умолчанию шифрованием . При переходе во вкладку сетевых настроек портал автоматически связывает ВМ с ранее созданной виртуальной сетью (VNet) и ее дефолтной подсетью . После прохождения финальной валидации конфигурации запускается процесс развертывания, который занимает около двух минут, после чего виртуальная машина переходит в статус полной готовности .

📦 Развертывание приложений в облаке: Azure App Services и Azure Container Instances 2:06:50

Ранее в обучении автор демонстрировал процесс удаления виртуальной машины и обратил внимание на то, что для обновления статуса ресурсов в веб-интерфейсе Azure иногда требуется вручную нажать кнопку перезагрузки из-за задержек синхронизации данных . Для тех случаев, когда ручное администрирование виртуальной инфраструктуры становится неэффективным, Azure предоставляет специализированные инструменты для быстрого и автоматизированного развертывания приложений.

Azure App Services: платформа как услуга (PaaS) для веб-приложений 2:06:50

Azure App Services представляет собой HTTP-службу, предназначенную для хостинга веб-приложений, REST API и мобильных бэкендов . Как объясняет автор курса Эндрю Браун из Exam Pro , эта служба работает по модели «платформа как услуга» (PaaS) и является концептуальным аналогом популярного сервиса Heroku в облачной инфраструктуре Microsoft .

Главное преимущество App Services заключается в том, что облачный провайдер полностью берет на себя рутинные задачи по обслуживанию инфраструктуры: автоматическую установку патчей безопасности ОС, балансировку нагрузки и автоматическое масштабирование ресурсов . Разработчикам доступна бесшовная интеграция с Azure DevOps, GitHub и Docker Hub, а также простые механизмы привязки кастомных доменов и SSL-сертификатов . Платформа позволяет выбирать в качестве целевой операционной системы как Windows, так и Linux . При этом архитектура поддерживает как классический запуск кода (монолитные приложения), так и работу с Docker-контейнерами . Каждому проекту по умолчанию присваивается доменное имя в технической зоне azurewebsites.net .

Важным понятием при работе с этой службой является среда выполнения (runtime) — набор системного ПО и библиотек, необходимых для исполнения кода . В Azure App Services встроены готовые контейнеры для популярных языков программирования:

• .NET и .NET Core
• Java
• Ruby (Эндрю Браун отдельно выражает недовольство тем, что на момент записи видео для Ruby в Azure отсутствовала интеграция с системой мониторинга Application Insights )
• Node.js
• PHP
• Python

Платформа регулярно обновляет доступные версии сред выполнения и выводит устаревшие версии из эксплуатации . Если приложение написано на неподдерживаемом по умолчанию языке (например, Elixir) , разработчик может упаковать его в собственный Docker-контейнер на локальном компьютере, отправить образ в реестр Azure Container Registry и затем развернуть в App Service .

Масштабирование, слои развертывания и тарифные планы 2:11:03

Для гибкого управления релизами в Azure App Services предусмотрен механизм слоев развертывания (deployment slots) . Они позволяют создавать изолированные копии рабочей среды со своими хост-именами (например, staging или QA) . Функция быстрого переключения (swapping) слоев реализует методологию blue-green деплоя: новая версия приложения тестируется на промежуточном слое, после чего мгновенно меняется местами с продакшн-версией .

Для крупных корпоративных клиентов с повышенными требованиями к масштабированию и безопасности предназначена служба App Service Environment (ASE) . Это полностью изолированная среда внутри виртуальной сети клиента, оптимизированная под интенсивные нагрузки с высокой плотностью обращений и большим потреблением памяти . С помощью ASE можно распределять приложения по нескольким регионам для горизонтального масштабирования систем с высокими показателями запросов в секунду (RPS) . Для ASE предусмотрен выделенный тарифный слой Isolated . Безопасность такой архитектуры можно дополнительно усилить upstream-устройствами, например брандмауэром веб-приложений (WAF) , а саму среду развернуть в конкретных зонах доступности с помощью zone pinning . Выделяют два типа ASE:

• External ASE — внешняя конфигурация, где приложения доступны через публичный IP-адрес .
• ILB ASE (Internal Load Balancer) — внутренняя конфигурация, использующая встроенный балансировщик нагрузки для работы в закрытом периметре .

Оба варианта позволяют подключаться к локальным базам данных предприятия через VPN-соединения типа site-to-site или каналы ExpressRoute .

Стоимость использования сервиса напрямую зависит от выбранного плана обслуживания (App Service Plan) . В Azure представлены три основные группы тарифных планов:

1. Shared (Общие ресурсы): включает бесплатный тариф F1 (1 ГБ диска, до 10 приложений на одной общей инстанции, отсутствие SLA и лимит 60 минут процессорного времени в день) , а также платный тариф Shared (до 100 приложений, 240 минут лимита времени, без SLA и без поддержки Linux) .
2. Dedicated (Выделенные инстанции): содержит тарифы Basic (B1–B3 с увеличенным объемом диска) , Standard (масштабирование до 3 инстанций, SLA 99.95%) и Premium (масштабирование до 10 инстанций, более производительное серверное оборудование) .
3. Isolated (Изолированные ресурсы): гарантирует полную сетевую изоляцию, масштабирование до 100 инстанций и SLA 99.95% .

Практический пример: развертывание Flask-приложения из GitHub 2:18:00

Чтобы наглядно показать простоту работы PaaS-модели, Эндрю Браун проводит практическое развертывание веб-приложения . Перед началом работы необходимо убедиться, что в подписке активирован поставщик ресурсов Microsoft.Web (найти его можно в панели Resource Providers) .

При создании нового ресурса App Service в панели управления задается уникальное глобальное имя (например, DeltaFlyer) . В качестве программного стека выбирается Python и операционная система Linux , а регионом развертывания указывается Canada East . Эндрю предупреждает, что тарифные планы Premium V2 стоят около 20 центов в час (что составляет порядка 146 USD в месяц) , и реальные затраты в локальной валюте (например, в канадских долларах) могут незначительно отличаться из-за курсовой разницы . Для учебных целей автор выбирает более экономный тариф B1 .

Для сборки используется демонстрационный репозиторий из официальных примеров Azure Samples — python-docs-hello-world . Это минималистичный проект на базе Flask, где файл app.py содержит один маршрут, отдающий текстовое приветствие , а файл requirements.txt содержит единственную зависимость flask . В разделе Deployment Center Эндрю авторизует свой GitHub-аккаунт , делает форк демонстрационного проекта и запускает деплой приложения из ветки master .

Azure Container Instances (ACI): быстрый запуск контейнеров без управления ВМ 2:27:16

Если для решения задачи не требуется разворачивать полноценный веб-сайт, но необходимо быстро исполнить изолированный код, оптимальным выбором становится Azure Container Instances (ACI) . Этот сервис представляет собой полностью управляемую службу класса «Docker как услуга» (Docker as a Service), избавляющую инженеров от необходимости конфигурировать виртуальные машины для работы контейнеров .

ACI обладает рядом преимуществ перед стандартными виртуальными машинами:

• Контейнеры создаются и запускаются в течение нескольких секунд, в то время как запуск виртуальной машины занимает минуты .
• Оплата за использование ресурсов в ACI начисляется посекундно, тогда как для ВМ действует почасовая тарификация .
• ACI предлагает точечную настройку необходимых лимитов ядер vCPU, памяти и GPU под конкретную задачу вместо фиксированных шаблонов размеров ВМ .

Служба без проблем работает как с Linux-, так и с Windows-контейнерами . Для долгосрочного хранения информации к контейнерам необходимо монтировать внешние тома (Azure Files) . Каждому контейнеру ACI присваивается собственное доменное имя (FQDN) . В качестве источников образов поддерживаются Azure Container Registry, Docker Hub и любые другие приватные реестры контейнеров .

Основной единицей управления в службе является Container Group (группа контейнеров) — коллекция тесно связанных контейнеров, запускаемых на одном хосте и разделяющих общие ресурсы, локальную сеть и дисковые тома . Группы контейнеров в ACI концептуально схожи с подами (Pods) в оркестраторе Kubernetes . Стоит учитывать, что многоконтейнерные группы на данный момент поддерживают запуск только на базе ОС Linux . Описать конфигурацию такой группы можно либо с помощью шаблонов Azure Resource Manager (ARM), либо через простой YAML-файл .

Также разработчик может гибко управлять логикой завершения работы контейнеров с помощью политик перезапуска (Restart Policies) :

• Always (Всегда) — контейнер перезапускается при любых обстоятельствах (режим подходит для веб-серверов) .
• Never (Никогда) — контейнер отрабатывает ровно один раз и завершает выполнение (используется для разовых фоновых задач) .
• On Failure (При сбое) — перезапуск инициируется только в случае некорректного завершения программы с ошибкой .

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

🌐 Сетевые службы Azure и безопасность трафика 2:34:40

Анатомия Virtual Network (VNet): подсети, сетевые интерфейсы и маршрутизация 2:34:40

Прежде чем детально погрузиться в проектирование сетей, Эндрю Браун кратко завершает практический разбор контейнеров ACI, начатый ранее : он демонстрирует пример контейнера Hello World с именем «banana» , обращается к нему через публичный IP и удаляет ресурс для экономии бюджета (подробнее тема контейнеризации раскрыта в Главе 6). Отсюда начинается фундаментальный блок курса, посвященный сетевым технологиям.

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

Для связи нескольких сетей VNet так, чтобы они функционировали как единое целое, используется технология пиринга (VNet Peering) . Автор выделяет два ее типа:

• Региональный пиринг (Regional peering) — связывает виртуальные сети в пределах одного географического региона Azure .

• Глобальный пиринг (Global VNet peering) — объединяет сети, находящиеся в физически разных регионах .

Взаимодействие виртуальных машин с сетью происходит через виртуальные сетевые интерфейсы — NIC (Network Interface Controller) . Каждому облачному серверу необходима хотя бы одна такая плата , но для решения сложных задач маршрутизации к одной машине можно подключить несколько NIC .

Каждая виртуальная сеть делится на подсети (Subnets), которые обеспечивают изоляцию рабочих нагрузок на уровне IP-адресов . При создании подсети ей выделяется определенный пул адресов . Интересно, что в отличие от экосистемы AWS, в Azure нет жесткого предустановленного разделения на «публичные» и «приватные» подсети . По умолчанию любая подсеть имеет доступ к интернету . Однако, если администратор переопределяет стандартную таблицу маршрутов (Route Table) и запрещает исходящий трафик во внешнюю сеть, подсеть становится полностью приватной .

Для фильтрации трафика на уровне подсетей или отдельных интерфейсов NIC используются группы безопасности сети (Network Security Groups, NSGs) . Они работают как виртуальные брандмауэры, где правила прописываются на основе IP-адресов, портов и протоколов . Также выделяется специальный тип подсети — Gateway Subnet, зарезервированный исключительно для развертывания виртуальных сетевых шлюзов .

В практической части Эндрю Браун показывает процесс создания VNet с именем «exam Pro vnet» в группе ресурсов «exam Pro» . Сеть по умолчанию разворачивается с адресным пространством 10.0.0.0/16 и создает стандартную подсеть 10.0.0.0/24 на 256 адресов . При создании сети важно оставить включенной базовую защиту от DDoS-атак (DDoS Protection Basic), так как она предоставляется бесплатно .

Подключение к облаку: VPN-шлюзы, ExpressRoute и обеспечение высокой скорости 2:41:14

Для интеграции локальных дата-центров (on-premises) с облаком Azure применяются технологии шифрованных каналов и выделенных физических линий. Виртуальные частные сети (VPN) позволяют безопасно передавать данные через общедоступный интернет, объединяя удаленные устройства в единую доверенную среду .

Центральным узлом для такой конфигурации выступает виртуальный сетевой шлюз (Virtual Network Gateway) . Это программное VPN-устройство, при создании которого Azure автоматически разворачивает две или более специализированные виртуальные машины в заранее подготовленной подсети Gateway Subnet . Эти машины содержат таблицы маршрутизации и обеспечивают стабильную связь . Пользователю доступен выбор роли шлюза: это может быть либо классический VPN Gateway, либо шлюз ExpressRoute .

Служба Azure ExpressRoute предлагает принципиально иной уровень связи, создавая прямые приватные соединения между локальной инфраструктурой клиента и дата-центрами Azure в обход публичного интернета . Это гарантирует максимальную стабильность, минимальные задержки (latency) и непревзойденный уровень безопасности передачи корпоративных данных .

Подключение настраивается через сертифицированных провайдеров в точках присутствия (colocation facilities) с помощью выделенных Express-цепей (Express circuits) . Чтобы избежать единой точки отказа, на практике всегда организуют резервные каналы для обеспечения высокой отказоустойчивости . Через эти цепи трафик может направляться как к общедоступным сервисам (Office 365, Dynamics 365, публичные IP-адреса Azure) , так и непосредственно в закрытые виртуальные сети через механизм приватного пиринга .

Для компаний с экстремальными требованиями к пропускной способности создано решение ExpressRoute Direct . Оно обеспечивает прямое подключение к глобальной сети Microsoft на скоростях от 50 Мбит/с до колоссальных 10 Гбит/с . Подобная скорость стирает границу между локальными системами и облаком, создавая ощущение, что удаленные ресурсы находятся на соседней стойке в вашем собственном серверном помещении .

Безопасность трафика: Azure DNS и интеграция через Private Link 2:39:41

Разрешение имен и защита внутренних каналов связи — критически важные аспекты безопасности Azure. Глобальная служба Azure DNS обеспечивает надежное и быстрое сопоставление доменных имен с IP-адресами инфраструктуры Microsoft . Служба разделена на два сценария использования:

• Public DNS — внешняя служба, обрабатывающая запросы из интернета для связи ваших доменов с публичными ресурсами Azure или почтовыми серверами . При этом сам сервис Azure DNS не позволяет покупать доменные имена . Домен необходимо приобрести у стороннего регистратора (GoDaddy, Namecheap) либо через службу App Services, а затем делегировать управление зоной в Azure DNS .

• Private DNS — внутренний сервис разрешения имен для ресурсов внутри VNet . Он позволяет использовать красивые локальные домены вместо длинных стандартных ссылок, которые Azure автоматически генерирует для различных служб, например, для учетных записей хранения Azure Storage .

С целью минимизации рисков утечки данных при обращении к PaaS-сервисам Azure была разработана технология Azure Private Link . В стандартном сценарии взаимодействие с облачной базой данных или хранилищем часто идет через публичные точки доступа, что заставляет трафик выходить в интернет, увеличивая затраты на передачу данных и снижая общую безопасность .

Private Link полностью меняет эту схему, предоставляя возможность подключить нужный сервис напрямую к вашей VNet через приватную конечную точку (Private Endpoint) . По сути, Private Endpoint представляет собой сетевой интерфейс, получающий внутренний IP-адрес из диапазона вашей собственной подсети . В результате весь трафик между вашими виртуальными машинами и целевым сервисом гарантированно циркулирует исключительно внутри защищенной магистральной сети Microsoft Azure, никогда не попадая в публичный интернет . Подавляющее большинство сервисов Azure работает с Private Link «из коробки» . При необходимости вы можете сделать совместимым с этой технологией и собственный внутренний сервис, настроив его за балансировщиком нагрузки с помощью Private Link Service .

После разбора сетевых аспектов Эндрю Браун переходит к следующему фундаментальному разделу — сервисам хранения данных в Azure (Azure Storage Services) . Он дает базовую классификацию дисков, файлов, таблиц, архивных решений и концепций репликации данных — все эти вопросы будут детально и глубоко изучены в рамках следующей Главы 8.

📦 Хранилище Azure: Blob, файлы и стратегии репликации 2:55:42

📂 Архитектура Azure Storage: типы учетных записей и типы данных 2:55:42

В инфраструктуре Microsoft Azure хранилище данных организовано вокруг концепции учетных записей хранения (Storage Accounts) . Наиболее гибким и универсальным решением на сегодняшний день является учетная запись общего назначения версии 2 (General Purpose v2), которая поддерживает практически все доступные типы данных и сервисы . В отличие от нее, устаревшие форматы (General Purpose v1 и классический Blob Storage) имеют существенные функциональные ограничения и реже рекомендуются к внедрению . При выборе учетной записи Azure предлагает два уровня производительности: стандартный (Standard) и премиальный (Premium) . При этом для специализированных типов данных, таких как файловые хранилища (File Storage) или блочные объекты премиум-класса (Block Blobs), по умолчанию всегда используется премиальный уровень производительности .

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

• Azure Blob: масштабируемое объектное хранилище для текстовых и двоичных данных, интегрированное с Data Lake Storage Gen2 для аналитики больших данных .

• Azure Files: облачные файловые ресурсы коллективного доступа для виртуальных машин .

• Azure Queues: хранилище сообщений для обмена данными между компонентами приложений . Хотя автор видео отмечает, что эта служба больше напоминает интеграционную базу данных NoSQL, Microsoft традиционно относит её к хранилищам .

• Azure Tables: NoSQL-хранилище структурированных данных без жесткой схемы .

• Azure Disks: блочные тома хранения для виртуальных машин Azure , детальному разбору которых посвящена отдельная глава курса .

⚡ Производительность и уровни доступа: Hot, Cool и Archive 2:58:46

Выбор между стандартным и премиальным уровнями производительности напрямую влияет на скорость чтения и записи, измеряемую в количестве операций ввода-вывода в секунду (IOPS) . Премиальный уровень базируется на твердотельных накопителях (SSD), которые не имеют движущихся частей [2:59:27, 3:00:05]. Это обеспечивает минимальную задержку и высокую пропускную способность, что критически важно для интерактивных рабочих нагрузок, систем аналитики, AI/ML и процессов трансформации данных . Стандартный уровень работает на традиционных жестких дисках (HDD) с подвижной магнитной головкой [2:59:41, 3:00:21]. HDD оптимизированы для последовательного чтения больших объемов данных и отлично подходят для резервного копирования и архивных систем, позволяя существенно сэкономить бюджет [2:59:41, 3:00:49].

Для стандартных хранилищ Azure предлагает три уровня доступа (Access Tiers) :

1. Hot (Горячий): предназначен для часто используемых данных . Характеризуется самыми высокими затратами на хранение, но минимальной стоимостью доступа к файлам .

2. Cool (Холодный): используется для данных, к которым обращаются редко и которые планируется хранить не менее 30 дней . Стоимость хранения здесь ниже, но доступ обойдется дороже . Подходит для краткосрочных бэкапов и неактивного медиаконтента .

3. Archive (Архивный): оптимален для редко запрашиваемых данных с обязательным сроком хранения от 180 дней . Предлагает самую низкую цену за гигабайт, но максимальные тарифы на чтение . Применяется для долгосрочного бэкапа и соблюдения регуляторных требований .

Перевод файлов из архивного уровня обратно в горячий или холодный называется «регидратацией» (rehydration) . Этот процесс может занимать несколько часов . Механизм управления жизненным циклом (Lifecycle Management) позволяет автоматизировать эти переходы с помощью политик на основе правил . Важно учитывать особенности тарификации: при переходе на более холодный уровень операция списывается как операция записи в целевой уровень , а при возврате к горячему — как чтение из исходного источника . Кроме того, при досрочном удалении или перемещении файлов из уровней Cool и Archive до истечения лимитов в 30 и 180 дней взимается штрафная плата за раннее удаление (early detection charges) [3:04:05, 3:04:17].

🔄 Стратегии репликации и избыточность данных 3:04:42

Для защиты информации от сбоев оборудования, отключения электроэнергии, сетевых неполадок или природных катастроф Azure требует обязательного выбора стратегии репликации при создании аккаунта хранения . Эти стратегии делятся на три категории избыточности :

• Избыточность в основном регионе (Primary Region Redundancy). Здесь данные копируются трижды внутри одного географического региона . Локально-избыточное хранилище (LRS) синхронно дублирует данные в одном дата-центре . Это самый дешевый вариант с уровнем надежности в 11 девяток (99.999999999%), идеально подходящий для сред разработки . Зонно-избыточное хранилище (ZRS) синхронно распределяет три копии по трем различным зонам доступности (Availability Zones) . Его надежность составляет уже 12 девяток , гарантируя сохранность данных даже при полном выходе из строя одной из зон .

• Избыточность во вторичном регионе (Secondary Region Redundancy). Данный подход спасает в случае масштабной катастрофы в основном регионе . Копии автоматически пересылаются в спаренный регион (paired region) . Геоизбыточное хранилище (GRS) копирует данные синхронно внутри первой зоны, а затем асинхронно передает их во вторичный регион , обеспечивая надежность в 16 девяток . Геозонно-избыточное хранилище (GZRS) сначала распределяет данные по трем зонам в основном регионе, а затем отправляет асинхронную копию в резервный регион . Вторичные копии в этих режимах недоступны для чтения и записи до тех пор, пока не будет инициирован процесс аварийного переключения (failover) .

• Вторичная избыточность с доступом на чтение (Read Access Secondary Region). Представлена вариантами RA-GRS и RA-GZRS . Основное отличие заключается в том, что вторичная копия постоянно доступна в режиме «только чтение» как полноценная реплика . Это позволяет балансировать нагрузку и читать данные из географически более близкого региона без перегрузки основного канала .

🗂️ Azure Blob Storage: Объекты, контейнеры и инструменты управления 3:10:54

Azure Blob Storage оптимизировано для хранения колоссальных объемов неструктурированных данных, таких как текст или медиафайлы . Архитектурно хранилище состоит из трех уровней : уникального имени учетной записи хранения (которое генерирует публичный домен доступа) , логических контейнеров (выполняющих роль папок) и самих двоичных объектов — блобов .

Различают три основных типа блобов :

1. Block Blobs (Блочные блобы): используются по умолчанию для стандартных файлов (картинок, документов) объемом до 4.7 терабайт .

2. Append Blobs (Добавляемые блобы): оптимизированы для операций дозаписи, что делает их идеальными для ведения журналов и логов .

3. Page Blobs (Страничные блобы): поддерживают произвольный доступ к файлам размером до 8 терабайт и служат основой для виртуальных жестких дисков (VHD) виртуальных машин Azure .

Для эффективной работы с файлами предусмотрена утилита командной строки AzCopy . Она работает на Windows, Linux и macOS . Для работы с ней требуются настроенные роли доступа RBAC (Storage Blob Data Reader для скачивания, Data Contributor или Data Owner для загрузки) , а авторизация проходит через Microsoft Entra ID или маркеры совместного доступа SAS (Shared Access Signature) . Процесс аутентификации запускается командой azcopy login , после чего копирование осуществляется простым указанием локального пути и сетевого эндпоинта контейнера . Для пользователей, предпочитающих графический интерфейс, доступно приложение Azure Storage Explorer , позволяющее управлять подписками, дисками и хранилищами с помощью визуального интерфейса на любой ОС .

🖧 Azure Files и File Sync: Общие диски и гибридные сценарии 3:15:06

Служба Azure Files представляет собой полностью управляемые файловые ресурсы общего доступа в облаке . В отличие от объектных блобов, Azure Files работает как традиционный сетевой диск, к которому могут одновременно подключаться сотни виртуальных машин . Взаимодействие происходит по стандартным протоколам: SMB (Server Message Block, разработка Microsoft) или NFS (Network File System, популярный в Linux) . Подключение общего ресурса к операционной системе называется монтированием (mounting) , что позволяет отображать сетевую папку как локальный диск (например, диск Z: в системе Windows) .

Основные сценарии использования Azure Files :

• Миграция Lift-and-Shift: перенос ИТ-инфраструктуры в облако без переписывания кода . При классическом переносе (classic lift) приложение и его данные полностью мигрируют в Azure , тогда как гибридный вариант (hybrid lift) предполагает перенос только хранилища, оставляя вычисления локально .

• Совместное использование ресурсов: централизованное хранение настроек приложений , общих инструментов разработки или единого лог-файла для быстрой отладки .

• Контейнеризация: обеспечение постоянного состояния (persistent volumes) для изначально лишенных состояния (stateless) контейнеров .

Для построения гибридных систем используется служба Azure File Sync . Она позволяет кэшировать облачные ресурсы Azure Files непосредственно на локальных серверах под управлением Windows Server . Пользователи получают локальный доступ к файлам по протоколам SMB, NFS или FTP с минимальными задержками , в то время как полноценная копия данных надежно хранится и синхронизируется в облаке Azure, высвобождая локальные дисковые пространства .

🏗️ Методологии миграции и основы идентификации в Microsoft Entra ID 3:20:33

Cloud Adoption Framework (CAF): Стратегический путь в облако 3:24:16

Ранее в курсе подробно обсуждалась работа с Azure Blob Storage , и после демонстрации практического развертывания хранилища, Эндрю Браун переходит к критически важным методологиям масштабирования IT-архитектуры.

Переход крупных организаций в облако требует системного подхода. Microsoft предлагает для этого Cloud Adoption Framework (CAF) — комплексное руководство и набор рекомендаций, помогающих компаниям спланировать и успешно реализовать миграцию своих рабочих нагрузок в Azure . Процесс миграции согласно CAF состоит из нескольких ключевых этапов:

• Определение стратегии (Define Strategy): понимание мотивации бизнеса, ожидаемых результатов и финансовое обоснование перехода .

• Планирование (Plan): оценка цифровых активов компании (digital estate), выравнивание организационной структуры, подготовка плана обучения сотрудников и формирование дорожной карты .

• Готовность (Ready): создание так называемой «посадочной зоны» (Landing Zone) — начальной безопасной среды в Azure, подготовленной к развертыванию ресурсов .

• Внедрение (Adopt): непосредственно миграция существующих нагрузок и внедрение инновационных облачных решений .

• Управление (Govern): установка стандартов, методологий контроля и политик безопасности для обеспечения соответствия нормативным требованиям .

• Администрирование (Manage): непрерывное управление операциями в облаке и оценка их эффективности .

Особое место в CAF отведено информационной безопасности . Рамки фреймворка четко распределяют роли: от руководства ИБ (Security Leadership), задающего общую стратегию , до архитекторов безопасности и инженеров платформы . Внедрение ИБ-процессов циклично и включает в себя фазы планирования, непрерывной эксплуатации (Run) и обратной связи для постоянного улучшения .

Инструменты миграции: Azure Migrate и семейство Azure Data Box 3:27:48

Для технической реализации переезда в облако Microsoft предоставляет платформу Azure Migrate, которая упрощает аудит, модернизацию и оптимизацию локальных ресурсов . Это единый портал, объединяющий множество инструментов для различных сценариев миграции :

• Azure Migrate Discovery and Assessment: инструмент для обнаружения локальных серверов (включая среды VMware, Hyper-V и физические серверы) и оценки их готовности к переносу .

• Migration and Modernization: служба для непосредственного переноса виртуальных машин и серверов в облако Azure .

• Data Migration Assistant (DMA): специализированное решение для анализа баз данных SQL Server на предмет совместимости перед их миграцией .

• Azure Database Migration Service (DMS): управляемая служба для бесшовной миграции баз данных с минимальным временем простоя .

• Movere: SaaS-платформа, которая способна за один день предоставить полную и точную картину всей локальной IT-инфраструктуры организации .

В ситуациях, когда передача терабайтов данных по сети невозможна из-за медленного интернет-соединения, на помощь приходит семейство Azure Data Box . Клиенты заказывают физическое устройство емкостью до 80 ТБ через портал Azure, подключают его к своей локальной сети по протоколам SMB или NFS для копирования данных, а затем отправляют обратно в дата-центр Microsoft через регионального перевозчика . Этот метод незаменим при разовой миграции архивов , периодической выгрузке данных с удаленных объектов (например, нефтяных платформ) или для быстрого аварийного восстановления систем .

Терминология Active Directory и управляемые службы Azure AD DS 3:33:08

Рассматривая вопросы авторизации и аутентификации, важно отметить недавний ребрендинг: привычная служба Azure Active Directory (Azure AD) теперь официально называется Microsoft Entra ID . Хотя в документации и интерфейсах все еще сохраняется старое название, суть сервиса не изменилась . В то время как управление учетными записями Microsoft Entra ID детально разбирается в других разделах курса , здесь важно понять концептуальную разницу между классической локальной службой Active Directory (AD) и облачной Entra ID.

Классическая служба Active Directory (AD DS) существует уже более 20 лет, начиная с Windows 2000 . Она оперирует такими понятиями, как:

• Домен (Domain): логическая группа сетевых объектов (пользователей, компьютеров), использующих общую базу данных аутентификации .

• Контроллер домена (Domain Controller): сервер, непосредственно проверяющий учетные данные и авторизующий доступ к ресурсам .

• Групповые политики (GPO) и организационные подразделения (OU): инструменты для централизованного управления конфигурациями и логической структуризации объектов .

Для компаний, которые хотят сохранить преимущества доменных служб (такие как присоединение к домену, поддержка LDAP, Kerberos и NTLM), но при этом избавиться от необходимости развертывать, обновлять и обслуживать физические контроллеры домена, создана служба Azure Active Directory Domain Services (Azure AD DS) . Она предоставляет полностью управляемые доменные службы в облаке, совместимые с вашим локальным окружением .

Технологии единого входа (SSO) в Microsoft Entra ID 3:42:59

Технология единого входа (Single Sign-On, SSO) позволяет пользователям пройти аутентификацию всего один раз и получать доступ к множеству корпоративных приложений без повторного ввода пароля . При входе система генерирует токен безопасности, который используется для авторизации во всех интегрированных сервисах .

Entra ID поддерживает интеграцию как с облачными (Office 365, Salesforce, Dropbox), так и с локальными приложениями . Выбор конкретного метода SSO зависит от архитектуры целевого приложения :

• OpenID Connect и OAuth: современные стандарты аутентификации и авторизации, широко применяемые в облачных веб-приложениях .

• SAML (Security Assertion Markup Language): протокол на базе XML, стандарт для построения федеративного доступа между различными поставщиками услуг .

• Интегрированная проверка подлинности Windows (IWA): позволяет пользователям использовать свои текущие доменные учетные данные ОС Windows .

• Аутентификация на основе заголовков (Header-based) и паролей: применяются для интеграции устаревших локальных систем через прокси-службы приложений .

Понимание этих протоколов критически важно для успешной сдачи экзамена AZ-900, где часто встречаются вопросы о выборе оптимального метода SSO под конкретные требования инфраструктуры .

Глава 10. Безопасность в Azure: Концепция Zero Trust и ключевые службы защиты 3:45:36

Модель нулевого доверия (Zero Trust) и эшелонированная оборона 3:49:42

В современной облачной среде традиционные методы защиты периметра больше не обеспечивают достаточного уровня безопасности. На смену им приходит концепция нулевого доверия (Zero Trust), которая базируется на простом правиле: «никому не доверяй, всегда проверяй» . Как отмечает Эндрю Браун, эта методология сегодня принимается всеми ведущими облачными провайдерами . Модель Zero Trust от Microsoft опирается на три фундаментальных принципа :

• Явная проверка (Verify explicitly): всегда проводить аутентификацию и авторизацию на основе всех доступных точек данных .
• Использование минимальных привилегий (Least privileged access): ограничение доступа пользователей с помощью политик Just-in-Time (JIT) и Just-Enough-Access (JEA) для минимизации рисков .
• Предупреждение о компрометации (Assume breach): минимизация радиуса поражения за счет сегментации доступа, сквозного шифрования и постоянного анализа угроз .

Модель состоит из шести основных «столпов» (pillars): удостоверения (identities), конечные точки или устройства (endpoints), приложения (apps), данные (data), инфраструктура (infrastructure) и сети (networks) . При этом ключевой фокус смещается на управление удостоверениями — это фундамент всей системы безопасности .

Тесно связана с этой концепцией стратегия эшелонированной обороны (Defense in Depth), представляющая собой семь уровней защиты . Чтобы добраться до самого ценного ресурса — данных , злоумышленнику необходимо преодолеть физическую безопасность дата-центра , пройти слой идентификации и контроля доступа , преодолеть сетевой периметр (включая защиту от DDoS-атак ), обойти защиту внутренней сети , вычислительных ресурсов (ВМ, порты) и самих приложений . Контроль доступа и идентификация при этом играют роль «современного периметра» безопасности .

Условный доступ (Conditional Access) и защита учетных записей 3:46:38

Базовым элементом защиты учетных записей является многофакторная аутентификация (MFA) . Ранее в разговоре спикеры касались управления удостоверениями через Microsoft Entra ID , и MFA выступает критически важным дополнением к нему. Суть MFA заключается в подтверждении входа с помощью второго фактора (например, мобильного приложения с одноразовыми кодами) . Это защищает учетную запись, даже если основной пароль был скомпрометирован злоумышленниками .

Однако для более тонкой настройки безопасности применяется технология условного доступа (Conditional Access) . Она работает на основе политик, которые оценивают различные сигналы перед предоставлением доступа к данным . В качестве сигналов могут выступать :

• Учетные данные пользователя или его членство в группах (например, обязательное требование MFA для роли Global Administrator) .
• Географическое положение (ограничение доступа по определенным IP-адресам) .
• Состояние и платформа устройства (требование использовать только корпоративные или соответствующие политикам безопасности устройства) .
• Используемое приложение .
• Уровень риска в реальном времени, вычисляемый с помощью встроенных инструментов защиты .

На основе этих сигналов система принимает решение: заблокировать доступ , предоставить полный доступ или предоставить доступ с дополнительными условиями (например, требование пройти MFA или сбросить пароль) . Данный функционал доступен в рамках лицензий Microsoft 365 Business Premium, E3/E5, а также Entra ID Premium P1/P2 . Для взаимодействия с внешними партнерами и клиентами Azure предлагает механизм внешних удостоверений (B2B и B2C), позволяющий использовать для входа учетные записи сторонних систем, таких как Google или Facebook .

Защита инфраструктуры: Microsoft Defender, Firewall и WAF 3:54:05

Инфраструктурная безопасность Azure централизованно управляется через службу Azure Security Center (в которую интегрирован компонент Azure Defender) . Эта система обеспечивает непрерывный мониторинг гибридных нагрузок в облаке и локальных средах . В зону покрытия Azure Defender входят виртуальные машины, контейнеры Kubernetes, базы данных SQL, хранилища и Key Vault . Программа предлагает продвинутые инструменты защиты, такие как сканирование уязвимостей ВМ, адаптивная защита сетей, контроль целостности файлов и доступ к виртуальным машинам «точно в срок» (JIT VM access) . Кроме того, с помощью Azure Arc функционал Defender можно распространить на защиту ресурсов в других облаках (AWS, GCP) .

Для сетевой безопасности на уровне периметра Azure предлагает встроенную защиту от распределенных атак типа «отказ в обслуживании» (DDoS) . Защита делится на два уровня:

• Basic: бесплатный уровень, включенный по умолчанию во все ресурсы глобальной сети Azure .
• Standard: платный пакет (около $2,900 в месяц), предоставляющий расширенную аналитику, отчеты, защиту от финансовых потерь при масштабировании под атакой и прямую поддержку экспертов Azure .

Для фильтрации входящего и исходящего трафика используется Azure Firewall — управляемый облачный брандмауэр с поддержкой состояния (stateful firewall-as-a-service) . Он обладает встроенной отказоустойчивостью и практически неограниченным масштабированием . Служба интегрирована с Microsoft Threat Intelligence, что позволяет ей автоматически блокировать трафик из известных вредоносных IP-адресов .

На прикладном уровне (Layer 7 модели OSI) защиту обеспечивает Web Application Firewall (WAF), развернутый совместно с Azure Application Gateway , . Application Gateway анализирует HTTP-запросы и блокирует угрозы вроде SQL-инъекций или межсайтового скриптинга (XSS) . Он также поддерживает тонкие настройки маршрутизации, SSL-терминацию и функции плавного отключения серверов (connection draining) при обновлении инфраструктуры .

Защита конфиденциальных данных: Azure Key Vault и стандарты шифрования 3:59:09

Безопасное хранение чувствительной информации — паролей, сертификатов шифрования, API-ключей и токенов доступа — реализуется с помощью службы Azure Key Vault . Key Vault разделяет свои функции на три основных направления:

1. Управление секретами (Secrets Management): безопасное хранение и строгий контроль доступа к паролям и API-ключам .
2. Управление ключами (Key Management): создание, хранение и контроль криптографических ключей, используемых для шифрования данных .
3. Управление сертификатами (Certificate Management): упрощенное развертывание и продление публичных и приватных SSL/TLS-сертификатов для интеграции с ресурсами Azure .

Для обеспечения максимальной физической безопасности ключей и секретов Azure использует аппаратные модули безопасности (HSM) . HSM представляет собой специализированное физическое устройство, предназначенное исключительно для хранения криптографических ключей . Особенность работы HSM заключается в том, что ключи хранятся непосредственно в энергозависимой памяти устройства и никогда не записываются на жесткие диски, что исключает возможность их физического извлечения или кражи .

Эти модули сертифицируются по государственным стандартам США и Канады FIPS 140 . В зависимости от архитектуры выделяют два типа HSM-хранилищ в Azure:

• Мультиарендные (Multi-tenant) HSM: используются несколькими клиентами с виртуальной изоляцией друг от друга и соответствуют стандарту FIPS 140-2 Level 2 .
• Одноарендные (Single-tenant) HSM: выделенные под одного клиента физические модули, соответствующие более жесткому стандарту безопасности FIPS 140-3 Level 3 .

🔐 Управление доступом (RBAC), облачные базы данных и интеграционные инструменты в Azure 4:10:38

Безопасность и контроль доступа: развертывание механизма Azure RBAC 4:10:38

Управление доступом в облаке строится вокруг концепции минимизации привилегий и четкого распределения ролей. Механизм управления доступом на основе ролей Azure RBAC (Role-Based Access Control) служит для точечного назначения прав пользователям, группам и приложениям . Назначение роли (Role Assignment) всегда состоит из трех ключевых элементов: субъекта безопасности (Security Principal), определения роли (Role Definition) и области действия (Scope) .

Субъект безопасности — это объект, запрашивающий доступ к ресурсу . Им может быть индивидуальный пользователь , группа пользователей , сервисный субъект (Service Principal — удостоверение для приложений) или управляемое удостоверение (Managed Identity — автоматически управляемый инстанс в каталоге) . Вторым элементом является область действия (Scope) . Она определяет уровень, на котором применяются права: от корневой управляющей группы (Management Group) до подписки (Subscription), группы ресурсов (Resource Group) или конкретного ресурса . Все подписки, находящиеся внутри определенной группы управления, автоматически наследуют наложенные на нее условия .

Третий элемент — определение роли (Role Definition), представляющее собой набор разрешенных операций (чтение, запись, удаление) . В Azure встроено более 70 ролей , но ключевыми являются четыре фундаментальные роли:

• Owner (Владелец) — обладает полным доступом ко всем ресурсам, включая право делегировать доступ другим пользователям .

• Contributor (Участник) — может создавать и изменять любые типы ресурсов Azure, но не имеет права предоставлять доступ сторонним лицам .

• Reader (Читатель) — может только просматривать существующие ресурсы без возможности вносить изменения .

• User Access Administrator (Администратор доступа пользователей) — управляет правами доступа других учетных записей, но сам не может создавать новые ресурсы .

Помимо RBAC, Azure предлагает инструменты контроля общего состояния облака. Сервис Azure Service Health агрегирует данные о плановом обслуживании и текущих сбоях . Он делится на три уровня: глобальный Azure Status , персонализированный Service Health и точечный Resource Health для отдельных виртуальных машин . Для оптимизации инфраструктуры применяется Azure Advisor — персональный облачный консультант , предоставляющий рекомендации по стоимости , безопасности , отказоустойчивости, производительности и операционному совершенству .

Облачные базы данных Azure: от Cosmos DB до реляционных СУБД 4:16:05

Портфель баз данных Azure спроектирован так, чтобы закрыть любые потребности современного бизнеса — от сверхбыстрого NoSQL до классических реляционных движков. Флагманом этого направления является Azure Cosmos DB — полностью управляемая NoSQL-база данных . Она создана для глобального масштабирования и гарантирует доступность на уровне 99,999% , обеспечивая высочайшую производительность при работе с гигантскими массивами данных .

Для реляционных сценариев Microsoft предлагает Azure SQL Database — интеллектуальный, полностью управляемый сервис на базе движка MS SQL Server с функциями автомасшабирования и встроенной безопасности . Если инфраструктура компании использует другие СУБД, Azure предоставляет аналогичные управляемые сервисы Azure Database для MySQL, PostgreSQL и MariaDB . В случаях, когда необходим простой перенос старых баз данных из локальных дата-центров без переписывания кода (стратегия Lift and Shift), оптимальным выбором становится запуск SQL Server на виртуальных машинах Azure (SQL Server on VMs) . Это дает полный контроль над операционной системой , хотя и требует ручного администрирования.

Дополнительно в экосистему баз данных входят:

• Azure Synapse Analytics (ранее SQL Data Warehouse) — платформа корпоративной аналитики и хранилище больших данных .

• Azure Database Migration Service — инструмент миграции баз данных в облако с минимальным временем простоя .

• Azure Cache for Redis — высокопроизводительное кэширование в оперативной памяти на базе open-source Redis .

• Azure Table Storage — простое хранилище неструктурированных данных в виде таблиц без жесткой схемы .

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

Интеграционные сервисы Azure выступают «клеем» , соединяющим изолированные приложения и микросервисы в единую экосистему. Основу этой группы составляют службы обмена сообщениями и оркестрации. Azure Notification Hubs предоставляет модель «издатель-подписчик» для рассылки push-уведомлений на любые мобильные платформы . Для маршрутизации трафика и публикации программных интерфейсов используются Azure API Apps (служащий облачным API-шлюзом) и Azure API Management, выступающий в роли прокси-сервера для добавления аналитики и безопасности поверх существующих API .

Надежный обмен сообщениями в гибридных средах обеспечивается через корпоративную шину Azure Service Bus и очередь сообщений Azure Queue Storage, гарантирующую доставку данных между распределенными компонентами приложений . Для автоматизации бизнес-процессов и создания визуальных рабочих процессов без написания кода используется инструмент Azure Logic Apps , поддерживающий интеграцию со множеством SaaS-сервисов . Реагирование на события в режиме реального времени от датчиков или пользовательских логов реализуется с помощью службы Azure Stream Analytics .

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

• Azure SignalR Service — сервис для добавления интерактивных веб-функций реального времени (аналог популярного решения Pusher) .

• Azure App Service — платформа (PaaS) для развертывания веб-приложений без управления серверами .

• IDE Visual Studio — полноценная среда разработки для создания облачных решений .

• Xamarin — кроссплатформенный фреймворк для мобильных приложений под .NET .

Экосистема Azure DevOps: комплексное управление разработкой 4:22:45

Azure DevOps представляет собой комплексный набор инструментов для автоматизации жизненного цикла разработки ПО (ALM) и внедрения практик DevOps . Этот зонтичный бренд включает в себя ряд независимых сервисов, тесно интегрированных между собой. Azure Boards предлагает удобные Kanban-доски и agile-инструменты для планирования задач . За непрерывную интеграцию и доставку отвечает Azure Pipelines — мощный инструмент CI/CD, работающий с любыми языками программирования и облачными провайдерами .

Разработчики могут хранить исходный код в Azure Repos, предоставляющем неограниченные приватные Git-репозитории с поддержкой пул-реквестов . Контроль качества кода автоматизируется с помощью Azure Test Plans — встроенной платформы для ручного и исследовательского тестирования приложений . Управление библиотеками и артефактами сборки ложится на Azure Artifacts . Для быстрого развертывания тестовых сред разработчикам доступен инструмент Azure DevTest Labs, позволяющий мгновенно создавать конфигурации виртуальных машин и при этом избегать лишних расходов .

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

🛠️ Бессерверные технологии, гарантии SLA и экономические инструменты Azure 4:35:55

Искусственный интеллект «из коробки»: Azure Cognitive Services 4:35:55

Набор готовых инструментов машинного обучения и искусственного интеллекта Azure Cognitive Services позволяет разработчикам быстро интегрировать сложные интеллектуальные сценарии в свои приложения без необходимости проектировать и обучать собственные нейросети с нуля . Эти сервисы охватывают широкий спектр задач обработки естественного языка, компьютерного зрения и анализа данных.

Эндрю Браун подробно перечисляет ключевые компоненты этой экосистемы:

• Personalizer — отвечает за создание персонализированного пользовательского опыта на основе алгоритмов машинного обучения .
• Translator — обеспечивает мгновенный многоязычный перевод текста в приложениях и на сайтах .
• Anomaly Detector — анализирует массивы данных для быстрого выявления аномалий и автоматического устранения неполадок .
• Azure Bot Service — интеллектуальная бессерверная платформа для развертывания масштабируемых чат-ботов .
• Form Recognizer — автоматически распознает и извлекает текст, таблицы и пары «ключ-значение» из документов .
• Computer Vision — предоставляет настраиваемые модели компьютерного зрения для анализа графического контента .
• Language Understanding (LUIS) — встраивает механизмы понимания естественного языка в приложения, ботов и IoT-устройства .
• Q&A Maker — преобразует статический контент (например, файлы ответов на вопросы) в полноценных диалоговых ботов .
• Text Analytics — извлекает из текстов ключевые фразы, именованные сущности, язык и определяет общую тональность высказываний (sentiment) .
• Content Moderator — автоматически фильтрует нежелательный текстовый и графический контент для повышения безопасности платформ .
• Face — распознает лица людей, сопоставляет их профили и считывает эмоции на изображениях .
• Ink Recognizer — обрабатывает рукописный ввод, цифровые подписи, геометрические фигуры и разметку документов .

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

Бессерверные вычисления (Serverless) и микротарификация 4:37:26

Концепция бессерверных вычислений (Serverless) подразумевает, что управление серверами, операционными системами и базовой инфраструктурой полностью берет на себя облачный провайдер . Для конечного пользователя это обеспечивает автоматическое масштабирование, высокую доступность и экономическую эффективность . Бессерверная архитектура по своей природе является событийно-ориентированной: выполнение кода запускается определенными триггерами . Автор видео сравнивает построение приложений на базе Serverless с игрой в конструктор Lego .

Абстракция от физического оборудования позволяет разработчикам писать код в виде изолированных функций, работающих на разных вычислительных инстансах и написанных на различных языках программирования, таких как Python или JavaScript . Важнейшим преимуществом Serverless является микротарификация (micro-billing) . В отличие от традиционных серверов, где аренда оплачивается по часам или секундам, бессерверные функции тарифицируются с точностью до микросекунды . Вы платите исключительно за то время, когда ваш код действительно выполняется .

Среди ключевых бессерверных сервисов Azure выделяются:

• Azure Functions — небольшие фрагменты кода, запускаемые по событиям и поддерживающие языки C#, Java, JavaScript, Python и PowerShell .
• Blob Storage — бессерверное объектное хранилище (ранее подробно рассматривалось в теме базовых хранилищ Azure), предоставляющее практически неограниченный объем без необходимости администрирования файловых систем .
• Logic Apps — визуальный конструктор бессерверных рабочих процессов, функционирующий как своеобразная машина состояний (state machine) .
• Event Grid / Event Bridge — система обмена сообщениями по модели Pub/Sub, позволяющая реагировать на события и связывать между собой различные облачные сервисы .

В рамках практической демонстрации Эндрю Браун сначала создает группу ресурсов (Resource Group) с именем examPro в регионе East US, поскольку без нее невозможно запустить ни одну службу в Azure . Создание и хранение самих групп ресурсов не несет никаких финансовых затрат для аккаунта .

Затем лектор разворачивает службу бессерверных функций Function App на базе среды выполнения Node.js . Внутри созданного приложения настраивается функция с триггером HTTP (HTTP trigger) . Эндрю добавляет простую строчку логирования console.log("hello world") и тестирует функцию, передавая имя в строке запроса:

// Тестовый запрос возвращает персонализированное приветствие
"hello Andrew" <a class="ts" data-seconds="17106" href="#t=17106" title="Смотреть с 4:45:06" aria-label="Смотреть с 4:45:06"><svg viewBox="0 0 24 24" width="14" height="14" fill="currentColor" aria-hidden="true"><path d="M8 5v14l11-7z"/></svg></a>

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

Соглашения об уровне обслуживания: SLA, компенсации и композитная надежность 4:45:58

Аббревиатура SLA расшифровывается как Service Level Agreement (Соглашение об уровне обслуживания) . Этот документ фиксирует официальные обязательства Microsoft по времени безотказной работы (uptime) и доступности сетевого подключения для конкретных сервисов . Показатели SLA в Azure индивидуальны для каждого отдельного продукта . Они выражаются в виде процентов, которые называют целевыми показателями производительности (performance targets) .

Надежность систем принято описывать количеством «девяток» . Например, показатель «две девятки» означает 99% доступности, а более высокие уровни надежности могут доходить до пяти или даже девяти девяток после запятой . Чем больше девяток содержит SLA, тем выше отказоустойчивость сервиса и тем жестче гарантии провайдера . Важное правило: бесплатные тарифные планы (free tier) и общие вычислительные ресурсы (shared tiers) не защищаются соглашениями SLA, так как предоставляются безвозмездно .

Если Microsoft не справляется с заявленными в SLA обязательствами, клиенты имеют право на компенсацию в виде сервисных кредитов (service credits) — виртуальных средств, которые начисляются на баланс аккаунта для оплаты будущих счетов . Например, для виртуальных машин Azure действуют следующие правила компенсации:

• Если ежемесячный аптайм падает ниже 99,9%, клиент получает скидку 10% от стоимости услуги .
• При падении аптайма ниже 99% размер компенсации увеличивается до 25% .
• Если показатель падает ниже 95%, Microsoft компенсирует полные 100% стоимости затронутого ресурса .

Когда архитектура приложения объединяет несколько независимых облачных служб, для расчета надежности всей системы используется понятие композитного SLA (composite SLA) . Общий показатель надежности рассчитывается путем перемножения индивидуальных SLA входящих в стек компонентов . Например, если веб-приложение с аптаймом 99,95% обращается к базе данных SQL Database с аптаймом 99,99%, их итоговый композитный SLA составит всего 99,94% . Таким образом, общая надежность распределенной системы всегда оказывается ниже надежности ее самого слабого звена .

Для повышения итогового SLA в архитектуру внедряют резервные системы (fallback systems) . Если между веб-интерфейсом и базой данных установить буферную очередь сообщений (Queue) с индивидуальным SLA 99,9%, то временное отключение БД не приведет к отказу всего приложения, так как транзакции будут сохраняться в очереди до момента восстановления сервера . Благодаря такой схеме совокупный композитный SLA системы увеличивается до 99,95% .

Экономические инструменты и типы подписок Azure 4:51:58

Калькулятор совокупной стоимости владения (TCO Calculator) предназначен для демонстрации экономической выгоды от миграции локальной IT-инфраструктуры предприятия в облако Azure . Этот инструмент сопоставляет затраты на содержание собственного дата-центра и аналогичных мощностей в облаке, формируя подробный PDF-отчет для руководства компании . В демонстрационном примере перенос нагрузок позволил гипотетическому предприятию сэкономить более 130 тысяч долларов за 5 лет . Лектор показывает работу калькулятора TCO в реальном времени, задав конфигурацию из 10 серверов Linux и 4 баз данных PostgreSQL — итоговая экономия за пятилетний период превысила 600 тысяч долларов .

Для быстрого развертывания готовых решений от сторонних сертифицированных разработчиков используется Azure Marketplace . В этом каталоге представлены тысячи готовых шаблонов и сервисов (например, преднастроенные серверы WordPress), которые распространяются по различным лицензионным моделям: бесплатно, в рамках ознакомительного периода, по схеме Pay-As-You-Go или BYOL (Bring Your Own License) .

Программа Azure Hybrid Benefit (или HUB) позволяет предприятиям, которые ранее приобрели лицензии для локальных серверов Windows Server или SQL Server, перенести и использовать эти лицензии для облачных виртуальных машин в Azure . Это дает возможность существенно сэкономить на аренде виртуальных машин за счет применения принципа BYOL (принеси свою лицензию) . Данную опцию можно активировать как на этапе развертывания новой виртуальной машины, так и включить для уже существующих серверов в любой момент времени .

Все ресурсы в облаке привязываются к учетной записи через механизм подписок (Azure Subscriptions) . Существует четыре основных модели подписок:

1. Free (Бесплатная подписка) — требует ввода данных банковской карты, предоставляет приветственный лимит в 200 долларов США на 30 дней и доступ к ряду бесплатных сервисов на 12 месяцев . Содержит встроенные лимиты для предотвращения случайного списания реальных средств .
2. Pay-As-You-Go (Оплата по мере использования) — стандартная коммерческая подписка, где списание средств происходит в конце месяца на основании фактического объема потребления облачных мощностей .
3. Enterprise Agreement (Корпоративное соглашение) — индивидуальный долгосрочный контракт для крупных организаций, предусматривающий специальные скидки на лицензии и сервисы при гарантированных объемах потребления .
4. Student Subscription (Студенческая подписка) — не требует привязки банковской карты, предоставляет баланс в размере 100 долларов США на 12 месяцев и требует только подтверждения статуса обучения через действующую студенческую электронную почту .

💰 Управление затратами, политики безопасности и корпоративное управление в Azure 5:00:50

Расчет стоимости Azure и оптимизация расходов: калькуляторы и бюджеты 5:00:50

Контроль и планирование затрат — один из наиболее критичных аспектов при работе с публичными облаками. Вся финансовая активность в Azure привязана к подпискам (Subscriptions) . Между арендаторами (tenants), каталогами и подписками существует прямая связь . Подписка определяет, как именно вы будете платить за ресурсы Azure, при этом внутри одного аккаунта можно создавать несколько подписок для разных отделов или проектов . При создании нового бесплатного аккаунта пользователю предоставляется тестовый баланс в размере $200 на 30 дней . В процессе работы тип подписки можно повышать, выбирая различные уровни технической поддержки — от бесплатного базового (Basic) до платных профессиональных опций .

Для предварительной оценки будущих расходов Эндрю Браун рекомендует использовать бесплатный инструмент Azure Pricing Calculator, доступный по адресу azure.com/pricing-calculator . Этот инструмент позволяет:

• Оценивать стоимость отдельных продуктов в конкретных регионах .
• Моделировать расходы на инфраструктуру без необходимости авторизации в системе .
• Выбирать тип операционной системы, уровень производительности и конфигурацию ресурсов .
• Экспортировать готовые расчеты в формат Excel для демонстрации руководству .

Например, базовая виртуальная машина может обходиться примерно в $12.62 в месяц , в то время как хранилище Blob Storage объемом 1000 ГБ (1 ТБ) в регионе East US на премиум-тарифе с локально-избыточным резервированием (LRS) обойдется около $150 в месяц . Для крупных enterprise-клиентов доступна оптимизация расходов с помощью программы Azure Hybrid Benefit, позволяющей использовать уже имеющиеся лицензии Windows Server и SQL Server для снижения стоимости облачных машин.

Для постоянного мониторинга запущенных ресурсов применяется сервис Azure Cost Management . Он предоставляет наглядную графическую визуализацию трат (Cost Analysis) . Главным инструментом контроля здесь выступают бюджеты (Budgets): пользователь задает финансовый лимит и настраивает пороговые значения, при приближении к которым система автоматически рассылает предупреждающие уведомления .

Маркировка и классификация: теги ресурсов и Microsoft Purview 5:06:12

Для наведения порядка в облачной инфраструктуре используются теги (Tags) . Тег представляет собой пару «ключ-значение», которую можно присвоить практически любому ресурсу Azure на этапе его развертывания .

Примерами полезных тегов могут служить департамент (Department), статус согласования (Status), рабочая группа (Team), окружение (Environment — например, Dev или Prod) или географическая локация (Location) . Маркировка помогает эффективно решать следующие задачи:

• Resource Management: быстро группировать ресурсы по проектам и окружениям .
• Cost Management: отслеживать расходы конкретных команд и точнее распределять бюджеты .
• Operations: выделять критически важные системы с жесткими требованиями к SLA .
• Security: классифицировать данные по уровню конфиденциальности .

На более глубоком корпоративном уровне для защиты конфиденциальных данных применяется комплекс решений Microsoft Purview Information Protection (ранее известный как Microsoft 365 compliance) . Эта платформа помогает обнаруживать, классифицировать и защищать чувствительную информацию в гибридных средах . Она состоит из четырех основных доменов:

1. Знание своих данных (Know your data): анализ ландшафта данных с использованием встроенных или пользовательских регулярных выражений, а также обучаемых классификаторов (trainable classifiers) для выявления конфиденциальных файлов . Сюда же входят инструменты графической визуализации Content Explorer и Activity Explorer .
2. Защита данных (Protect your data): применение шифрования, ограничений доступа и меток конфиденциальности (sensitivity labels) .
3. Предотвращение утечек (Prevent data loss): использование политик Data Loss Prevention (DLP) для контроля обмена информацией в чатах Microsoft Teams и на рабочих станциях пользователей .
4. Управление жизненным циклом данных (Govern your data): настройка политик хранения (retention policies) и архивации почтовых ящиков .

Azure Policy, блокировки ресурсов и управление через шаблоны Blueprints 5:11:13

Для автоматического контроля за соблюдением стандартов организации применяются политики безопасности — Azure Policy . Важно понимать, что политики не ограничивают права доступа напрямую, они лишь фиксируют и оценивают соответствие ресурсов заданным правилам . С их помощью можно быстро проверить инфраструктуру на соответствие международным стандартам, таким как NIST, FedRAMP или HIPAA .

Инструмент Azure Policy состоит из нескольких ключевых элементов:

• Policy Definition: файл в формате JSON, описывающий бизнес-правила и условия проверки .
• Policy Assignment: область действия политики (конкретная подписка, группа ресурсов или группа управления) .
• Policy Parameters: переменные значения, повышающие гибкость применения правил .
• Initiative Definitions: логические группы из нескольких политик для комплексной проверки (например, для стандарта PCI-DSS) .

Для защиты критически важной инфраструктуры от случайного удаления или модификации используются блокировки ресурсов (Resource Locks) . Администратор может установить два уровня блокировки:

• Cannot Delete (Невозможно удалить): пользователи могут читать и изменять конфигурацию ресурса, но не могут удалить его .
• Read-only (Только для чтения): любые изменения и удаление полностью запрещены .

Для масштабного развертывания типовых и сразу защищенных сред используется сервис Azure Blueprints . Он позволяет декларативно описывать наборы артефактов, включая назначения ролей (Role Assignments), назначения политик, шаблоны ARM (Azure Resource Manager) и группы ресурсов .

В отличие от обычных ARM-шаблонов, которые после развертывания теряют связь с исходным кодом, Blueprints сохраняют активную связь между определением шаблона и развернутыми ресурсами . Это позволяет централизованно обновлять и проводить аудит множества подписок одновременно . Сам сервис Blueprints работает на базе распределенной СУБД Azure Cosmos DB, что обеспечивает репликацию шаблонов между регионами .

Порталы управления и риски использования предварительных версий (Preview) 5:15:24

Основным графическим веб-интерфейсом для управления всей облачной инфраструктурой является Azure Portal (portal.azure.com) . Он объединяет в себе функции мониторинга, создания и администрирования любых систем — от простейших веб-приложений до сложных распределенных сетей .

Параллельно существует тестовая площадка — Azure Preview Portal (preview.portal.azure.com) . Она предоставляет разработчикам ранний доступ к бета-версиям функций и новых продуктов, которые еще не перешли в статус общедоступных (General Availability) . Одним из примеров таких новых систем является аналитическая платформа Microsoft Fabric . Включать новые функции можно также непосредственно в настройках своей подписки в разделе "Preview features" путем их регистрации .

Эндрю Браун настоятельно предостерегает от использования любых предварительных функций (Preview) в реальных коммерческих системах (production workloads) . История знает случаи, когда компании инвестировали сотни тысяч долларов и полгода работы в интеграцию перспективного preview-сервиса, а Microsoft в последний момент принимала решение закрыть проект и не выпускать его на рынок .

В завершение лекции автор кратко демонстрирует запуск интерактивной консоли управления Azure Cloud Shell и использование командной строки CLI для автоматизации создания ресурсов . Подробный разбор этих инструментов автоматизации, скриптов и сред развертывания будет представлен далее в главе 15.

🛠️ Практический скриптинг: администрирование ресурсов через PowerShell и Azure CLI

Регистрация поставщиков ресурсов и подготовка среды 5:26:09

При первой попытке запуска интегрированной среды управления пользователи часто сталкиваются с системными предупреждениями о том, что подписка не зарегистрирована для работы с пространством имен облачного хранилища . Это демонстрирует важный архитектурный аспект Microsoft Azure: для доступа к определенным сервисам их необходимо предварительно зарегистрировать и одобрить на уровне конкретной подписки .

Для управления этими правами в меню подписок предусмотрена специальная вкладка «Поставщики ресурсов» (Resource Providers) . В этом разделе администраторы могут вручную регистрировать или отключать доступ к различным API и службам платформы . Ранее в разговоре авторы кратко упоминали основы управления облаком, которые будут подробнее разобраны в теме Cloud Shell и CLI в следующих главах, однако практическое знакомство со средой начинается именно здесь.

Запущенный терминал работает под управлением операционной системы Linux . Это позволяет администраторам выполнять привычные команды, такие как PWD для вывода текущей рабочей директории или LS для просмотра списка файлов . Интерфейс позволяет масштабировать шрифты через настройки для более комфортной работы с кодом . По умолчанию в окружение интегрирован интерфейс командной строки Azure CLI . Базовый вызов утилиты осуществляется с помощью короткой команды az . Например, команда az account list возвращает структурированную информацию о текущих активных подписках пользователя в формате JSON . По завершении сессии терминал можно закрыть простым кликом .

Управление инфраструктурой через Azure PowerShell: особенности синтаксиса 5:29:40

Вторым мощным инструментом автоматизации выступает Azure PowerShell . По определению разработчиков, PowerShell представляет собой не просто командную строку, а полноценную среду автоматизации задач и управления конфигурацией со своим скриптовым языком . Главное преимущество PowerShell перед классическими текстовыми оболочками вроде Bash или Zsh заключается в его архитектуре: он построен поверх общеязыковой среды выполнения .NET (CLR) . В то время как традиционные оболочки принимают и возвращают необработанный текст, PowerShell оперирует полноценными объектами .NET . Это значительно упрощает фильтрацию данных и связывание команд в конвейеры (pipelines).

На локальных компьютерах под управлением Windows PowerShell предустановлен изначально , однако интеграция модулей для взаимодействия с Azure на локальных машинах сопряжена с определенными неудобствами. Установка официального пакета Azure PowerShell на локальную систему может занимать очень много времени . При работе непосредственно из облачного веб-интерфейса аутентификация происходит автоматически . Если же администратор запускает среду локально, ему придется предварительно выполнить команду Connect-AzAccount .

Синтаксис PowerShell базируется на строгом правиле именования командлетов «Глагол-Существительное» (Verb-Noun) с префиксом Az . Пример такой конструкции — New-AzResourceGroup . Найти информацию по доступным модулям можно в официальной документации Microsoft . Интерактивная среда поддерживает автодополнение параметров по нажатию клавиши Tab .

При практическом создании ресурсов через PowerShell важно учитывать строгие ограничения Azure на имена объектов. Например, имя учетной записи хранения (Storage Account) должно быть глобально уникальным, содержать от 3 до 24 символов и состоять исключительно из строчных букв и цифр . Попытка использовать заглавные буквы приведет к ошибке выполнения скрипта .

«Мой бизнес-партнер обожает PowerShell за его предсказуемый и согласованный вывод данных. Его бэкграунд связан с многолетним администрированием Windows-систем, тогда как я больше ориентирован на стек Linux» .

Практическое применение Azure CLI: структура команд и версии функций 5:42:06

Интерфейс командной строки Azure CLI представляет собой кроссплатформенную утилиту, которую можно установить на операционные системы Windows, macOS и Linux . После установки управление ресурсами происходит с помощью отправки текстовых инструкций, начинающихся с префикса az . CLI позволяет программно создавать, обновлять и удалять любые типы облачных ресурсов, исключая необходимость совершать ручные клики в графическом портале .

При поиске команд в официальной справочной документации разработчикам важно обращать внимание на статус стабильности конкретных CLI-модулей . Команды разделены на три основные категории:

• GA (General Availability) — стабильные версии функций, которые полностью поддерживаются Microsoft и рекомендуются для промышленной эксплуатации .
• Preview — предварительные версии функций, которые проходят тестирование и могут измениться в будущем .
• Experimental — экспериментальные возможности, использование которых в продакшене сопряжено с высокими рисками удаления или изменения синтаксиса .

При работе с инфраструктурой Azure все ресурсы должны быть объединены в логические группы — группы ресурсов (Resource Groups) . В отличие от AWS, где ключевой границей изоляции выступает аккаунт, или GCP, где группировка идет по проектам, в Azure первичным контейнером жизненного цикла всегда является группа ресурсов .

Для создания такой группы с помощью интерфейса командной строки используется шаблон az group create . В параметрах необходимо указать регион (флаг -l или --location) и имя группы (флаг -n или --name) . Успешное выполнение команды возвращает JSON-объект со статусом Succeeded , что подтверждает корректность отправленного запроса и готовность облачной инфраструктуры к развертыванию целевых сервисов.

🛠️ Практика в интерфейсе командной строки: от Azure CLI до Azure SDK и облачных сред разработки 5:51:20

Создание и управление ресурсами с помощью Azure CLI 5:51:20

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

Для развертывания новой учетной записи хранения используется базовая команда az storage account create . Инструктор подчеркивает важность работы с документацией: даже при использовании генеративного ИИ необходимо вручную проверять синтаксис флагов . В Azure CLI присутствует некоторая несогласованность сокращений: например, короткий флаг -g обозначает группу ресурсов (Resource Group), а флаг -n — имя создаваемого ресурса (Name) . При этом для других команд назначения буквенных флагов могут меняться .

Имена учетных записей хранения в Azure должны состоять только из строчных букв, не содержать пробелов и быть глобально уникальными, так как они фактически формируют URL-адрес для доступа к данным . Для демонстрации инструктор выбирает уникальное имя mystorageaccount1234ab и указывает регион с помощью флага -l East us . При создании ресурсов через CLI система не выводит предупреждения о лимитах бесплатного уровня, в отличие от интерактивного портала («клик-опс») . Если опустить необязательный флаг конфигурации SKU, Azure автоматически применит параметры по умолчанию .

После успешного выполнения команды статус можно проверить прямо в консоли или через веб-интерфейс . Для вывода списка существующих учетных записей применяется команда az storage account list . По умолчанию утилита возвращает данные в формате JSON . С помощью глобального флага -o (output) этот вывод легко переопределить на более читаемый формат YAML (-o yaml) или представить в виде таблицы (-o table) . По окончании работы созданную группу ресурсов удаляют через портал, где для подтверждения операции требуется скопировать и вставить её имя .

Инструменты разработчика: VS Code и проектирование сценариев через SDK 5:59:18

Помимо работы в терминале Cloud Shell, разработчикам необходим полноценный редактор кода. Инструктор Эндрю Браун рекомендует бесплатный редактор с открытым исходным кодом Visual Studio Code (VS Code) от Microsoft, доступный на Windows, Linux и macOS . Его не следует путать с полноценной интегрированной средой разработки (IDE) Visual Studio, которая гораздо тяжелее и содержит избыточный для повседневных скриптов функционал . В экосистеме Azure также существует сервис Visual Studio Workspaces для запуска сред разработки в облаке . Главная сила VS Code кроется в богатой экосистеме расширений .

Для программного управления облачной инфраструктурой вместо CLI-команд часто применяются специализированные пакеты разработчика — Azure SDK . Написание скриптов позволяет автоматизировать рутинные задачи администрирования . Для подготовки примера создается локальная папка проекта с именем без пробелов (например, Azure SDK example) и открывается в VS Code .

Azure SDK поддерживает широкий стек языков: Android, C#, Go, Java, JavaScript, Python и другие, хотя поддержка некоторых языков (например, Ruby) развита слабее . Для демонстрации выбирается язык C# . Чтобы ускорить написание громоздкого кода, инструктор использует ChatGPT для генерации базового шаблона развертывания хранилища . В сгенерированном коде подключаются ключевые библиотеки: Azure.ResourceManager (для управления ресурсами) и Azure.Storage (для работы с хранилищем) . Программа инициализирует клиент управления ArmClient , запрашивает подписку по умолчанию, создает группу ресурсов и затем разворачивает в ней хранилище . Несмотря на некоторую многословность синтаксиса C# , такой подход обеспечивает полный контроль над инфраструктурой.

Облачные среды разработки: GitHub Codespaces и запуск Azure SDK 6:07:48

При сохранении файла с расширением .cs локальный VS Code предлагает установить расширение поддержки C# . Однако для выполнения программы требуется наличие установленного в операционной системе пакета .NET Core SDK . Чтобы избежать сложностей с локальной установкой зависимостей на разных ОС , инструктор рекомендует перенести процесс в облачную среду разработки .

Поскольку в самом Azure нет полноценного встроенного веб-редактора кода (присутствует только Cloud Shell) , в качестве облачной IDE предлагается использовать GitHub Codespaces . В бесплатном аккаунте GitHub создается публичный репозиторий Azure SDK C# example с файлом README . На его базе запускается среда Codespace . Эндрю Браун предпочитает Codespaces аналогам (таким как GitPod) из-за бесшовной интеграции с официальным магазином расширений Microsoft VS Code Marketplace .

После запуска Codespaces в браузере и настройки темной цветовой темы , C#-файл перетаскивается в рабочую область , а среда автоматически предлагает установить расширение C# Dev Kit .

«Пока ваши облачные среды разработки запущены, они расходуют ресурсы подписки. Если вы отходите на перерыв или за кофе, обязательно закрывайте вкладку браузера, чтобы не тратить бесплатные лимиты» .

Для настройки сценария развертывания в код вносятся следующие данные:

• Идентификатор подписки (Subscription ID), скопированный из портала Azure .
• Регион развертывания (например, West US) .
• Уникальное имя учетной записи хранения (например, helloworld123...ab в нижнем регистре) .
• Имя целевой группы ресурсов (mySDKRG) .

После заполнения всех переменных проект готов к компиляции и первому запуску с помощью команд сборки .NET .

🛠️ Практика в Codespaces: настройка .NET-окружения и отладка скриптов Azure SDK 6:16:31

Настройка окружения и установка Azure CLI в GitHub Codespaces 6:16:31

В процессе развертывания облачной инфраструктуры разработчики часто сталкиваются с необходимостью локальной сборки и проверки кода. Автор пытается запустить сборку .NET-проекта непосредственно из командной палитры VS Code в GitHub Codespaces , однако быстро обнаруживает, что стандартная команда сборки не дает видимого результата . Первоначальная попытка проконсультироваться с ИИ-помощником ChatGPT также оказывается тщетной — предложенные советы не помогают решить проблему напрямую .

Для взаимодействия с облаком требуется установленный интерфейс командной строки. Ранее в курсе подробно рассматривались основы управления через CLI, и автор решает установить Azure CLI в текущую облачную среду разработки . Поскольку Codespaces по умолчанию работает на базе дистрибутивов Linux (Debian/Ubuntu), используется стандартная консольная команда установки в одну строку . По ходу процесса автор увеличивает размер шрифта терминала до 20 пунктов для лучшей читаемости зрителями , попутно подчеркивая, что самостоятельный поиск решений и преодоление мелких трудностей — важнейшая часть обучения любого инженера .

После завершения установки утилита az становится доступной в консоли . При попытке выполнить авторизацию с помощью стандартной команды az login автоматическое перенаправление в браузер завершается неудачей, так как среда разработки запущена в облачном контейнере, а не на локальной машине . Автор использует альтернативный метод авторизации через код устройства, введя команду с соответствующим флагом: az login --use-device-code . Скопировав сгенерированный одноразовый код и перейдя по ссылке авторизации , он успешно привязывает свою учетную запись Azure к CLI-окружению . Успешный вход сохраняет сессию в локальном хранилище виртуального воркспейса , что избавляет от необходимости вручную прописывать секреты и ключи доступа в кодовой базе при последующих тестовых запусках.

Создание проекта .NET и борьба с зависимостями NuGet 6:21:44

После успешной авторизации автор переходит к подготовке рабочей среды для выполнения C#-кода. Чтобы упростить запуск скриптов взаимодействия с API Azure, правильным решением является создание полноценного консольного проекта .NET . Автор обращается к ChatGPT за примером структуры проекта, использующего Azure SDK . В терминале инициализируется новый консольный проект с помощью команды dotnet new console -n package.dotnet с явным указанием фреймворка .NET 6.0 . Использование проверенной версии помогает избежать потенциальных конфликтов совместимости библиотек, которые часто возникают на самых свежих версиях фреймворка .

Файл с исходным C#-кодом переносится в созданную директорию и переименовывается в program.cs . При попытке тестового запуска проекта командой dotnet run компилятор выдает ошибку о том, что пространство имен Azure не найдено . В C#, как и во многих других языках программирования, внешние библиотеки должны управляться специализированным пакетным менеджером — в экосистеме .NET эту роль выполняет NuGet .

Поскольку попытка установить общий пакет Azure завершается ошибкой отсутствия доступных версий , автор ищет точные имена необходимых библиотек SDK . Поочередно устанавливаются точечные зависимости: пакет управления учетными данными Azure.Identity , библиотека для работы с ресурсами Azure.ResourceManager и пакет для взаимодействия со службами хранения Azure.Storage.Blobs . Это позволяет разрешить базовые импорты компилятора, но впереди ждут более глубокие проблемы совместимости кода.

Отладка кода SDK и преодоление нестыковок в API 6:29:25

Повторный запуск проекта через dotnet run выявляет новые ошибки компиляции, связанные с несовпадением сигнатур методов и устаревшей кодовой базой . Выясняется, что ИИ-помощник предоставил неактуальный код, ориентированный на старые версии API . Автор пробует отправить текст ошибок обратно в чат-бот , однако, не получив адекватного ответа, решает обратиться к официальной справочной документации Azure SDK для C# .

Анализ документации показывает, что в актуальной версии SDK процесс создания группы ресурсов выглядит иначе: необходимо отдельно инициализировать клиентов и структуру данных. Автор переписывает блок создания группы ресурсов с использованием классов ArmClient, ResourceGroupCollection и ResourceGroupData . Чтобы упростить отладку в условиях ограниченного времени, он временно исключает из кода логику создания хранилища . Подобный итеративный процесс отладки и постоянного поиска информации является стандартной рутиной любого облачного инженера .

Тем не менее, код продолжает выдавать ошибки. Компилятор не распознает тип данных AzureLocation , несмотря на наличие импортированных пространств имен . Попытка обойти строгое типизирование путем замены объекта локации на обычную строковую переменную "West US" также приводит к новым сбоям, связанным с отсутствием контекста для клиентов и методов асинхронного ожидания . Борьба с типами данных C# наглядно иллюстрирует сложность прямой работы с низкоуровневым кодом SDK по сравнению с декларативными инструментами развертывания.

🏗️ Анатомия Azure Resource Manager (ARM) и шаблоны ARM Templates 6:41:22

Завершение практической работы: отладка C# SDK и очистка окружения 6:41:22

Практическая работа с C# SDK наглядно демонстрирует, с какими трудностями разработчики часто сталкиваются при ручной настройке окружения. Одной из главных проблем при копировании примеров кода из документации часто становится отсутствие необходимых директив using . Для решения этой проблемы и поиска недостающих пространств имен эффективным инструментом выступает ИИ-ассистент . В частности, при работе с ресурсами Azure критически важно импортировать пакеты Azure.Core и Azure.ResourceManager .

В процессе компиляции также часто возникают несоответствия в именах инициализированных клиентов. Например, замена названия переменной с armClient на простое client позволяет устранить ошибки контекста . После исправления всех зависимостей и импорта пространства имен Azure код успешно компилируется и выполняется .

Перед сохранением проекта в репозиторий необходимо настроить файл .gitignore . В него следует добавить папки сборки bin/ и obj/, чтобы избежать засорения коммита лишними метаданными компилятора . После успешной фиксации кода в GitHub-репозитории крайне важно правильно завершить рабочий сеанс. Для предотвращения нежелательных расходов (подробнее о которых говорилось при обсуждении оптимизации затрат) следует остановить текущий контейнер в GitHub Codespaces и удалить тестовую группу ресурсов через портал Azure .

Архитектура Azure Resource Manager (ARM) и четыре уровня областей управления (Scopes) 6:48:30

Azure Resource Manager (ARM) представляет собой не отдельный изолированный инструмент, а комплексную службу, формирующую единый уровень управления (management layer) для всех ресурсов облака . Через этот интерфейс выполняются любые операции создания, обновления, удаления и защиты систем, включая настройку тегов, блокировок и прав доступа .

ARM функционирует как строгий «привратник» (gatekeeper) . Абсолютно любой запрос к облаку — отправленный через графический портал, сценарии PowerShell, интерфейс CLI или напрямую через REST API и SDK — сначала проходит проверку в ARM . Служба работает в тесной интеграции с системой идентификации Microsoft Entra ID, проверяя подлинность и полномочия пользователя .

Для эффективного администрирования в ARM применяется строгая иерархия областей управления (scopes), определяющая границы контроля ресурсов :

• Управляющие группы (Management Groups): Логические контейнеры для объединения нескольких подписок под едиными правилами управления .
• Подписки (Subscriptions): Границы биллинга и технической поддержки, к которым привязаны соглашения об использовании услуг .
• Группы ресурсов (Resource Groups): Контейнеры для совместного развертывания и мониторинга связанных сервисов .
• Ресурсы (Resources): Конечные экземпляры служб, такие как виртуальные машины или хранилища .

Понимание этой иерархии критично для корректного наследования политик безопасности и ролевого доступа RBAC .

Философия Infrastructure as Code (IaC): чем шаблоны ARM отличаются от императивных сценариев 6:52:15

Методология «Инфраструктура как код» (IaC) совершила революцию в управлении дата-центрами, заменив ручную настройку физического оборудования машиночитаемыми файлами конфигурации . Подходы к IaC разделяют на две основные категории: декларативный (где детально описывается конечный желаемый результат) и императивный (определяющий последовательность шагов для достижения цели) . Шаблоны ARM относятся к исключительно декларативному типу .

Главное отличие использования IaC-шаблонов от выполнения команд через CLI-интерфейсы или SDK заключается в свойстве идемпотентности . Если выполнить скрипт CLI для создания виртуальной машины дважды, система попытается развернуть дублирующий ресурс и выдаст ошибку . Инструменты же IaC проверяют текущее состояние инфраструктуры: если целевой объект уже создан и соответствует описанию, они просто проигнорируют команду или обновят измененные параметры .

Применение декларативных шаблонов обеспечивает организации целый ряд преимуществ :

• Быстрое развертывание и гарантированное уничтожение целых архитектурных сред за считанные минуты .
• Минимизация человеческого фактора и исключение конфигурационных ошибок .
• Модульность кода с возможностью повторного использования отдельных блоков .
• Автоматическое тестирование конфигураций с помощью специализированных утилит вроде ARM TTK .
• Предварительная валидация шаблонов на стороне Azure до начала фактического развертывания .

Разбор JSON-структуры ARM, экспорт шаблонов и концепция Template Specs 6:55:16

На базовом уровне шаблоны ARM представляют собой документы в формате JSON . Azure не предоставляет встроенную поддержку разметки YAML для ARM, поэтому любые конфигурации описываются строго в синтаксисе JSON . Типовая структура шаблона состоит из нескольких ключевых разделов :

1. Schema ($schema): Описывает версию и формат используемого файла разметки .
2. Metadata: Содержит дополнительную служебную информацию о шаблоне .
3. Parameters: Входные переменные, которые делают шаблон универсальным и применимым для разных сред .
4. Variables: Служебные значения, используемые для оптимизации сложных вычислений внутри конфигурации .
5. Resources: Описание самих разворачиваемых компонентов Azure с указанием их типов, свойств и взаимных зависимостей .

Уникальной особенностью Azure является то, что любое ручное действие на портале («кликопс») автоматически генерирует под капотом соответствующий ARM-шаблон . Это позволяет легко экспортировать готовую конфигурацию работающей системы для её последующего тиражирования .

Экспортированные конфигурации можно сохранять в облаке в виде сущностей Template Specs (Спецификации шаблонов) . При работе с ними важно учитывать характерную для Azure задержку распространения данных (propagation delay) : созданные шаблоны или ресурсы могут отобразиться в интерфейсе портала лишь спустя 10–15 минут, что требует от администратора терпения . Также при проведении тестов необходимо внимательно отслеживать оповещения о расходах, так как даже кратковременное развертывание тестовых стендов способно быстро расходовать лимиты бесплатного баланса .

🛠️ Инфраструктура как код: эволюция от ARM-шаблонов к Azure Bicep 7:07:25

Развертывание среды разработки в GitHub Codespaces и настройка VS Code 7:07:25

Написание сложных JSON-шаблонов Azure Resource Manager (ARM) вручную — задача трудоемкая, неэффективная и подверженная синтаксическим ошибкам . В качестве современной альтернативы Microsoft предлагает декларативный язык Azure Bicep, который значительно упрощает процесс описания инфраструктуры как кода (IaC) . Для работы с кодом Bicep не обязательно устанавливать весь стек разработки на локальный компьютер. Гораздо удобнее использовать облачную среду GitHub Codespaces . Поскольку Microsoft владеет платформой GitHub, интеграция с Codespaces выглядит естественным решением, компенсирующим отсутствие аналогичного встроенного веб-редактора непосредственно в портале Azure .

При начале работы с Codespaces в первую очередь создается публичный или приватный репозиторий (например, с именем Azure bicep example) в организации или личном аккаунте . При использовании облачного контейнера важно помнить, что запущенное окружение потребляет вычислительные ресурсы, поэтому по окончании работы сессию необходимо останавливать через командную палитру VS Code . После настройки темной темы интерфейса (например, GitHub Dark) ключевым шагом становится установка расширения Azure Bicep из встроенного магазина VS Code . Синергия редактора Visual Studio Code, репозиториев GitHub и специализированных расширений позволяет получить мощные инструменты автодополнения и валидации синтаксиса, что делает процесс написания кода более эффективным, чем конфигурирование ресурсов через графический интерфейс портала Azure .

Для полноценной работы с экосистемой Microsoft рекомендуется установить расширение Azure Tools . Этот пакет объединяет инструменты для управления базами данных, функциями, ресурсами и учетными записями Azure . С его помощью и при помощи плагина Azure Accounts можно пройти авторизацию в облаке прямо из редактора через палитру команд (Azure: Sign In) . Процесс авторизации задействует одноразовый код устройства (device code) и браузер . После успешного входа в боковой панели VS Code появится полноценное дерево ресурсов вашей подписки Azure, позволяющее наглядно просматривать активные службы, включая группы ресурсов и системные хранилища .

Написание кода на языке Bicep: синтаксис и структура ресурсов 7:15:03

Разработка инфраструктуры начинается с создания файла с расширением .bicep (например, main.bicep) . Описание любого элемента облачной архитектуры строится на объявлении блоков, начинающихся с ключевого слова resource . Синтаксис языка спроектирован так, чтобы быть лаконичным и читаемым в отличие от классического ARM JSON .

Типовое объявление ресурса в Bicep включает следующие обязательные компоненты:

• Ключевое слово resource в начале строки .
• Внутреннее логическое имя (например, storageAccountAB), которое используется для связи и ссылок на этот ресурс внутри самого Bicep-кода .
• Тип ресурса и его версия API (например, Microsoft.Storage/storageAccounts@2021-04-01), которые строго регламентируют, какую именно службу мы разворачиваем .
• Блок свойств (properties), в котором задаются параметры конфигурации, такие как расположение (location) и SKU .

Полный перечень обязательных и опциональных параметров для каждого облачного компонента можно найти в официальной справочной документации Microsoft — Azure Resource Reference . При написании кода для служб, требующих глобально уникальных имен на уровне всего облака Azure (например, для учетных записей хранения), разработчики часто сталкиваются с коллизиями . Язык Bicep изящно решает эту проблему с помощью встроенных строковых функций. Конструкция uniqueString(resourceGroup().id) позволяет сгенерировать детерминированный уникальный хэш на основе уникального идентификатора текущей группы ресурсов . Добавляя полученную строку в качестве суффикса к базовому имени ресурса, можно гарантировать уникальность имени при развертывании в любой подписке . При этом область действия (scope) для развертывания автоматически определяется контекстом текущей целевой группы ресурсов .

Компиляция шаблонов и интеграция с Azure CLI 7:18:56

Хотя язык Bicep значительно упрощает написание кода, под капотом Azure по-прежнему оперирует стандартными ARM-шаблонами. Чтобы скомпилировать Bicep-файл или развернуть инфраструктуру в облаке, разработчику требуется установить консольный инструмент управления — Azure CLI . Ранее в курсе уже затрагивались основы работы с командной строкой Azure, однако в изолированном контейнере Codespaces CLI необходимо установить с нуля, используя официальный скрипт для Linux-систем на базе Ubuntu/Debian .

После инсталляции утилиты полезно понимать архитектуру хранения авторизационных данных. Все файлы конфигурации, параметры сессий и профили облаков CLI сохраняет локально в скрытой директории пользователя ~/.azure . Внутри этой папки находятся такие файлы, как clouds.config, содержащий информацию о типе используемого облака и параметрах подписки по умолчанию . Для активации терминальной сессии в консоли выполняется знакомая команда входа с флагом авторизации через устройство: az login --use-device-code .

Основная команда для трансляции Bicep-кода в классический формат ARM-шаблонов звучит как az bicep build --file main.bicep . Если в системе отсутствует необходимый компилятор, его можно быстро доустановить через вызов az bicep install . Результатом компиляции становится файл main.json . Этот сгенерированный документ представляет собой стандартный, готовый к деплою JSON-шаблон Azure Resource Manager . Таким образом, Bicep функционирует как предметно-ориентированный язык (DSL), выступающий прозрачной синтаксической надстройкой над ARM, компилирующей человекочитаемый код в машиночитаемый JSON-формат . Для ускорения деплоя прямо из редактора можно также использовать расширение Azure Resource Manager (ARM) Tools (находящееся на стадии Preview) . Оно добавляет в интерфейс VS Code команду arm deploy, позволяющую отправлять скомпилированные шаблоны напрямую в облачную инфраструктуру Azure .

🛠️ Практикум по IaC: отладка Bicep и первый запуск Terraform 7:32:01

Практическая отладка и деплой Azure Bicep через CLI 7:32:15

При попытке выполнить развертывание файла конфигурации Bicep непосредственно через командную палитру VS Code и одноименное расширение пользователь сталкивается с непредвиденной ошибкой отсутствия необходимых прав или неполной регистрации типов ресурсов в подписке . Быстрый запрос в ChatGPT 3.5 не приносит мгновенных результатов . Чтобы локализовать проблему, спикер переходит в веб-портал Azure в раздел Subscriptions -> Resource Providers для ручной проверки статуса регистрации провайдера Microsoft.Resources . Убедившись, что провайдер активен, он приходит к выводу, что сбой вызван внутренними ограничениями плагина VS Code .

Для решения проблемы принимается решение задействовать проверенный интерфейс командной строки Azure CLI . Для удобства работы создается пустой файл сценария commands.azcli , позволяющий задействовать IntelliSense и автодополнение команд. Спикер формирует структуру команды развертывания az deployment group create . Однако процесс приостанавливается из-за временных задержек на стороне API Azure и сбоя интернет-соединения, что вынуждает выполнить повторное подключение к виртуальной среде GitHub Codespaces .

Чтобы исключить любые конфликты области действия (scopes) при автоматическом создании ресурсов, спикер переходит в портал и вручную создает целевую группу ресурсов с именем my bicep RG . Затем команда в CLI окончательно корректируется: из нее исключаются невалидные параметры локации и лишние аргументы . Итоговый запуск команды az deployment group create --resource-group my bicep RG --template-file main.json успешно завершает деплой ресурсов . После проверки успешного появления ресурсов в портале созданная группа удаляется , изменения фиксируются в Git, а рабочий контейнер Codespaces останавливается во избежание лишних трат .

Установка и настройка Terraform в среде Codespaces 7:45:20

Ранее в разговоре они детально разбирали концепцию инфраструктуры как кода (IaC) на примере Bicep и Terraform. Хотя Bicep является нативным решением для облака Microsoft, на практике самым популярным мультиоблачным инструментом автоматизации остается Terraform от компании HashiCorp . Спикер переходит к демонстрации работы с ним, создавая публичный репозиторий azure-terraform-example на GitHub и разворачивая новую чистую среду GitHub Codespaces .

Для работы в терминале требуется установить дистрибутив Terraform CLI. Спикер переходит на официальный сайт HashiCorp в раздел загрузок для Linux и последовательно копирует официальный стек команд для пакетного менеджера APT :

• Сначала выполняется обновление локальных индексов пакетов sudo apt-get update .

• Затем скачивается и верифицируется доверенный GPG-ключ HashiCorp для подтверждения подлинности устанавливаемого ПО .

• В конфигурацию репозиториев операционной системы добавляется официальный источник HashiCorp .

• Запускается финальная команда установки пакета sudo apt-get install terraform .

Сразу после установки в корне проекта создается рабочий файл конфигурации main.tf . Для корректного форматирования, подсветки синтаксиса и подсказок спикер устанавливает официальное расширение HashiCorp Terraform для VS Code . Он отдельно отмечает вклад Антона Бабенко — ключевого контрибьютора модулей Terraform сообщества, чьи наработки активно используются разработчиками по всему миру .

Написание конфигурации и инициализация провайдера AzureRM 7:51:06

Для трансляции декларативного кода Terraform в реальные вызовы API Azure необходимо подключить и настроить соответствующий провайдер. Спикер открывает публичный каталог Terraform Registry и копирует код инициализации официального провайдера azurerm . Он поясняет, что в реальных коммерческих проектах для аутентификации системы в облаке принято создавать выделенный Service Principal с клиентским секретом (Client Secret) . Однако для быстрого демонстрационного запуска проще всего использовать сквозную авторизацию через локально установленный Azure CLI .

В Codespaces запускается установка утилиты Azure CLI с помощью универсального скрипта установки для систем Ubuntu . Из базы примеров документации копируется базовый шаблон развертывания, описывающий создание группы ресурсов и классического хранилища Storage Account .

Спикер адаптирует пример под свои параметры:

• Название целевой группы ресурсов переопределяется как my terraform RG .

• Регион развертывания меняется на West US .

• Для Storage Account задается уникальное имя и убираются избыточные теги .

Чтобы дать Terraform доступ к подписке Azure, в терминале выполняется команда интерактивного входа az login --use-device-code . Спикер переходит по указанной ссылке и активирует сессию с помощью сгенерированного одноразового кода . После успешной авторизации сессии в терминале запускается команда terraform init , которая скачивает бинарные файлы провайдера azurerm и подготавливает директорию к применению конфигурации.

🛠️ Наблюдаемость систем и комплексный мониторинг с Azure Monitor 8:12:06

Ранее в разговоре авторы детально разобрали управление инфраструктурой как код через Terraform и bicep, включая развертывание и очистку тестовых ресурсов . Также вскользь затрагивался анализ стоимости подписки в Azure, управление бюджетом и отслеживание лимита бесплатных кредитов в размере $200 . В завершающей части курса фокус смещается на обеспечение непрерывного контроля за состоянием развернутых систем с помощью мониторинга.

Три столпа наблюдаемости и анатомия Azure Monitor 8:12:06

Azure Monitor представляет собой комплексное облачное решение для сбора, детального анализа и оперативного реагирования на телеметрию, поступающую как из облачных ресурсов, так и из локальных (on-premise) ИТ-сред. Сервис предоставляет администраторам визуальные панели мониторинга , интеллектуальные оповещения, глубокое логирование и автоматизацию ответных действий. Многие системные службы Azure по умолчанию интегрированы с платформой и отправляют свои данные в Azure Monitor автоматически.

В современной практике DevOps концепция наблюдаемости (observability) системы базируется на трех обязательных компонентах :

• Метрики (Metrics): Числовые показатели, измеряемые и агрегируемые за определенные промежутки времени . Примером служит средняя загрузка процессора (CPU) виртуальной машины.
• Логи (Logs): Текстовые записи событий, происходящих в системе . Каждая строка лога содержит данные о событии и точную временную метку.
• Трассировки (Traces): Сквозная история запросов, проходящих через несколько распределенных приложений и микросервисов , позволяющая быстро локализовать узкие места в производительности.

Архитектура Azure Monitor построена на сборе телеметрии из различных источников данных: от прикладного ПО и операционных систем до журналов активности на уровне подписок и тенанта Active Directory. Собранная информация направляется в два основных типа хранилищ — базу данных метрик и базу данных логов . На основе этих данных работают встроенные функции анализа, визуализации в PowerBI, автоматического масштабирования ресурсов при росте нагрузок и интеграции с внешними системами через API .

Log Analytics, язык запросов KQL и рабочие области 8:15:09

Основным инструментом для исследования логов в Azure Monitor является Log Analytics . Этот интерфейс во многом напоминает классическую систему управления базами данных, так как хранит собираемую телеметрию в структурированном виде — в виде таблиц со строками и столбцами . Для написания поисковых запросов и фильтрации данных используется специализированный декларативный язык KQL (Kusto Query Language) . С его помощью инженеры могут быстро агрегировать миллионы строк логов для поиска конкретных аномалий.

Для полноценной работы с аналитикой логов требуется развернуть рабочую область — Log Analytics Workspace . Она представляет собой изолированное логическое окружение со своим собственным хранилищем данных, конфигурацией безопасности и политиками хранения . Создание выделенных рабочих областей является стандартной практикой проектирования инфраструктуры . Это позволяет гибко разграничивать права доступа сотрудников к логам различных сред и систем , а также избегать смешивания чувствительных данных .

Умные оповещения (Azure Alerts) и реагирование на инциденты 8:16:39

Служба оповещений Azure Alerts помогает ИТ-специалистам выявлять и устранять неполадки до того, как они начнут влиять на бизнес-процессы пользователей . Платформа поддерживает три основных типа алертов: метрические (metric alerts), лог-оповещения (log alerts) и оповещения журналов активности (activity log alerts) .

Каждое правило оповещения состоит из нескольких логических блоков :

1. Целевой ресурс (Target Resource): Конкретный объект инфраструктуры (например, виртуальная машина), испускающий сигналы телеметрии .
2. Критерий (Criteria): Логическое правило оценки данных (например, если загрузка процессора превышает 70% в течение пяти минут).
3. Группа действий (Action Group): Набор автоматизированных шагов, выполняемых при срабатывании правила . Это может быть как простая отправка письма администраторам, так и запуск Azure Functions, сценариев автоматизации Azure Automation или отправка вебхуков .

После срабатывания алерта его жизненный цикл отслеживается с помощью двух параметров. Состояние мониторинга (Monitor Condition) рассчитывается платформой автоматически на основе текущих метрик . В то же время состояние оповещения (Alert State) управляется инженером вручную — например, переводя инцидент в статус «Закрыто» (Closed) после успешного исправления сбоя .

Глубокий анализ производительности с Application Insights 8:18:20

Application Insights представляет собой специализированный сервис класса APM (Application Performance Management) , входящий в семейство инструментов Azure Monitor. Его основная задача — мониторинг доступности и диагностика проблем производительности веб-приложений. Программа автоматически выявляет аномалии и предоставляет разработчикам детальные инструменты анализа .

Официальная поддержка интеграции доступна для приложений на платформах .NET, Node.js, Java и Python . Также существуют поддерживаемые сообществом библиотеки для других языков, включая Ruby . Чтобы начать сбор телеметрии, приложение необходимо инструментировать — установить специальный SDK или активировать встроенного агента мониторинга непосредственно на хостинге Azure . Взаимосвязь приложения и облачного ресурса мониторинга обеспечивается с помощью уникального ключа инструментирования (Instrumentation Key / I Key) .

Application Insights собирает внушительный объем метрик :

• Частоту и время отклика входящих запросов;
• Количество и структуру системных исключений (exceptions) ;
• Показатели производительности внешних зависимостей (баз данных, внешних API);
• Поведение пользователей (активность сессий, просмотры страниц, AJAX-вызовы).

Для визуализации этих данных инженерам доступны такие инструменты, как интерактивная карта приложения (Application Map) , профилировщик, живой поток метрик (Live Metrics) и отладчик Snapshot Debugger в среде Visual Studio . Использование APM-решений является критически важным стандартом при эксплуатации любых коммерческих веб-приложений .