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

Источник: https://www.youtube.com/watch?v=5abffC-K40c
Канал: freeCodeCamp.org
Опубликовано: 14.12.2023

---

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

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

### Обзор сертификации AZ-900 и её ценность
[[JUMP:01:08]]

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

Несмотря на статус начального уровня, данный экзамен не стоит недооценивать. Он не подтверждает умение создавать сложные облачные архитектуры на практике [4:13], но закладывает прочный теоретический фундамент для дальнейшей специализации [5:05]. Помимо AZ-900, Microsoft предлагает и другие фундаментальные треки, такие как AI-900 для работы с искусственным интеллектом или DP-900 для баз данных [5:30]. В классическом сценарии развития карьеры после сдачи AZ-900 специалисты переходят к подготовке на статус администратора по курсу AZ-104 [6:09], а затем двигаются в сторону разработки на AZ-204 [6:21] или проектирования сложных систем в качестве сертифицированных архитекторов решений. В последующих главах будут подробнее разобраны такие смежные темы, как управление учетными записями Microsoft Entra ID [1:58] и расчет стоимости Azure [2:00], которые детально проверяются на следующих этапах обучения.

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

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

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

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

Сам экзамен оценивается по шкале от 1 до 1000 баллов, где проходным порогом является оценка в 700 баллов [12:31]. Студентам предлагается ответить на количество вопросов в диапазоне от 35 до 50 штук [12:59], при этом штрафы за неверные ответы отсутствуют [13:39]. В тесте встречаются разнообразные форматы заданий: стандартный одиночный и множественный выбор, перетаскивание элементов (drag-and-drop), интерактивные области (hot areas) и кейс-стади [13:52], [22:33], [22:46]. На прохождение выделяется 45 минут чистого времени, а общее время сессии с учетом заполнения анкет и NDA составляет около 60–65 минут [14:44], [15:12]. Приятным бонусом является то, что все фундаментальные сертификаты Microsoft серии 900 не имеют срока действия и остаются активными навсегда [16:04]. Стоимость регистрации на экзамен составляет порядка 99 долларов США в зависимости от региона проживания кандидата [23:51].

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

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

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

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

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

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

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

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

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

*   Гибкость конфигурирования полноценных виртуальных машин [27:33];
*   Высокую безопасность благодаря надежной виртуальной изоляции ресурсов [27:08];
*   Низкую стоимость за счет распределения затрат между тысячами клиентов [27:21];
*   Практически безграничное масштабирование [27:08].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.  **Публичное облако (Public Cloud).** Инфраструктура полностью создается и функционирует на оборудовании облачного провайдера (например, Azure) [36:06]. В индустрии эту модель также часто называют термином Cloud Native [36:06]. Пример реализации публичного облака — развертывание виртуальной машины и базы данных непосредственно в глобальной сети Azure [36:20]. Эта модель максимально экономична и предлагает надежные стандарты безопасности по умолчанию [37:40]. Однако уровень гибкости низкоуровневых настроек железа здесь ограничен возможностями, которые предоставляет сам провайдер [38:06].
    
2.  **Частное облако (Private Cloud).** Вся инфраструктура разворачивается внутри собственных дата-центров компании (On-Premise) [36:33]. Для эмуляции функционала полноценного облака организации часто применяют специализированное ПО с открытым исходным кодом, такое как OpenStack [36:47]. Главным преимуществом частного облака является абсолютный контроль над конфигурацией аппаратного и программного обеспечения [38:06]. Минусы — чрезвычайно высокая стоимость развертывания [38:20], необходимость содержания штата высококлассных ИТ-специалистов [38:32] и сложность обеспечения безопасности без проработанных автоматизированных систем мониторинга, которые предоставляют публичные CSP [38:32].
    
3.  **Гибридное облако (Hybrid Cloud).** Модель, объединяющая локальные ресурсы компании и мощности публичного облака в единую рабочую среду [37:14]. Для стабильной связи между ними используются специализированные технологии, такие как выделенные оптоволоконные каналы ExpressRoute, прокладываемые напрямую от локального дата-центра в сеть Azure [37:28]. Гибридный подход позволяет крупным игрокам находить баланс между экономической эффективностью публичного облака и жесткими государственными или корпоративными требованиями к хранению конфиденциальных данных в собственном периметре [37:40, 39:11]. Недостатком является максимальная архитектурная сложность, требующая от инженеров глубоких знаний как облачных, так и локальных технологий [39:37].

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

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

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

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

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

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

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

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

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

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

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

В этом блоке лекции автор также затрагивает эволюцию вычислений от выделенных серверов (dedicated bare metal) [57:50] к виртуальным машинам [59:33], контейнерам [1:01:05] и бессерверным функциям (functions) [1:02:12], детальный разбор которых как вычислительных ресурсов Azure будет представлен далее в Главе 5.

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

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

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

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

*   Canada Central парный к Canada East [1:07:29].
*   East US парный к West US [1:07:41].
*   Germany Central парный к Germany Northeast [1:07:41].

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

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

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

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

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

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

Зона доступности (Availability Zone, AZ) — это обособленная физическая локация внутри региона, состоящая из одного или нескольких дата-центров [1:11:45]. Каждый дата-центр представляет собой укрепленное здание со своей системой питания, охлаждения и сетевой инфраструктурой [1:11:58]. «В дата-центрах никогда не должно быть собак», — шутит лектор, демонстрируя фото серверной стойки [1:12:10]. Как правило, регион Azure содержит не менее трех зон доступности [1:12:24]. Они физически изолированы друг от друга, но соединены высокоскоростными линиями связи с ультранизкой задержкой (менее миллисекунды) [1:12:36]. Запуск нагрузок одновременно в трех AZ гарантирует высокую доступность (High Availability) [1:13:01]. К регионам со стопроцентной поддержкой трех AZ относятся Central US, East US 2, West US 2, West Europe, France Central, Northern Europe и Southeast Asia [1:14:21]. Если же регион не поддерживает зоны доступности (например, Brazil South), выбор AZ в веб-интерфейсе блокируется, и пользователю доступен лишь вариант «резервирование инфраструктуры не требуется» [1:14:47].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При создании нового ресурса App Service в панели управления задается уникальное глобальное имя (например, `DeltaFlyer`) [2:19:51]. В качестве программного стека выбирается Python и операционная система Linux [2:20:18], а регионом развертывания указывается Canada East [2:20:31]. Эндрю предупреждает, что тарифные планы Premium V2 стоят около 20 центов в час (что составляет порядка 146 USD в месяц) [2:20:57], и реальные затраты в локальной валюте (например, в канадских долларах) могут незначительно отличаться из-за курсовой разницы [2:21:10]. Для учебных целей автор выбирает более экономный тариф B1 [2:22:12].

Для сборки используется демонстрационный репозиторий из официальных примеров Azure Samples — `python-docs-hello-world` [2:23:16]. Это минималистичный проект на базе Flask, где файл `app.py` содержит один маршрут, отдающий текстовое приветствие [2:23:41], а файл `requirements.txt` содержит единственную зависимость `flask` [2:24:08]. В разделе Deployment Center Эндрю авторизует свой GitHub-аккаунт [2:25:40], делает форк демонстрационного проекта [2:26:06] и запускает деплой приложения из ветки master [2:26:33].

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

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

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

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

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

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

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

*   `Always` (Всегда) — контейнер перезапускается при любых обстоятельствах (режим подходит для веб-серверов) [2:29:55].
*   `Never` (Никогда) — контейнер отрабатывает ровно один раз и завершает выполнение (используется для разовых фоновых задач) [2:29:55].
*   `On Failure` (При сбое) — перезапуск инициируется только в случае некорректного завершения программы с ошибкой [2:30:09].

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

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

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

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

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

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

* Региональный пиринг (Regional peering) — связывает виртуальные сети в пределах одного географического региона Azure [2:36:25].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- **Azure Files**: облачные файловые ресурсы коллективного доступа для виртуальных машин [2:57:27].

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

- **Azure Tables**: NoSQL-хранилище структурированных данных без жесткой схемы [2:57:53].

- **Azure Disks**: блочные тома хранения для виртуальных машин Azure [2:58:06], детальному разбору которых посвящена отдельная глава курса [2:58:40].

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

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

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

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

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

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

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

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

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

- **Избыточность в основном регионе (Primary Region Redundancy)**. Здесь данные копируются трижды внутри одного географического региона [3:06:44]. Локально-избыточное хранилище (LRS) синхронно дублирует данные в одном дата-центре [3:06:59]. Это самый дешевый вариант с уровнем надежности в 11 девяток (99.999999999%), идеально подходящий для сред разработки [3:07:24]. Зонно-избыточное хранилище (ZRS) синхронно распределяет три копии по трем различным зонам доступности (Availability Zones) [3:07:37]. Его надежность составляет уже 12 девяток [3:07:37], гарантируя сохранность данных даже при полном выходе из строя одной из зон [3:07:50].

- **Избыточность во вторичном регионе (Secondary Region Redundancy)**. Данный подход спасает в случае масштабной катастрофы в основном регионе [3:08:17]. Копии автоматически пересылаются в спаренный регион (paired region) [3:08:30]. Геоизбыточное хранилище (GRS) копирует данные синхронно внутри первой зоны, а затем асинхронно передает их во вторичный регион [3:09:10], обеспечивая надежность в 16 девяток [3:09:36]. Геозонно-избыточное хранилище (GZRS) сначала распределяет данные по трем зонам в основном регионе, а затем отправляет асинхронную копию в резервный регион [3:09:50]. Вторичные копии в этих режимах недоступны для чтения и записи до тех пор, пока не будет инициирован процесс аварийного переключения (failover) [3:08:43].

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

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

Azure Blob Storage оптимизировано для хранения колоссальных объемов неструктурированных данных, таких как текст или медиафайлы [3:10:54]. Архитектурно хранилище состоит из трех уровней [3:11:07]: уникального имени учетной записи хранения (которое генерирует публичный домен доступа) [3:11:20], логических контейнеров (выполняющих роль папок) [3:11:33] и самих двоичных объектов — блобов [3:11:46].

Различают три основных типа блобов [3:11:46]:

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

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

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

Для эффективной работы с файлами предусмотрена утилита командной строки **AzCopy** [3:12:53]. Она работает на Windows, Linux и macOS [3:13:07]. Для работы с ней требуются настроенные роли доступа RBAC (Storage Blob Data Reader для скачивания, Data Contributor или Data Owner для загрузки) [3:13:21], а авторизация проходит через Microsoft Entra ID или маркеры совместного доступа SAS (Shared Access Signature) [3:13:48]. Процесс аутентификации запускается командой `azcopy login` [3:14:00], после чего копирование осуществляется простым указанием локального пути и сетевого эндпоинта контейнера [3:14:14]. Для пользователей, предпочитающих графический интерфейс, доступно приложение **Azure Storage Explorer** [3:14:39], позволяющее управлять подписками, дисками и хранилищами с помощью визуального интерфейса на любой ОС [3:14:52].

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

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

Основные сценарии использования Azure Files [3:16:39]:

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

- **Совместное использование ресурсов**: централизованное хранение настроек приложений [3:17:58], общих инструментов разработки [3:18:26] или единого лог-файла для быстрой отладки [3:18:12].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В ситуациях, когда передача терабайтов данных по сети невозможна из-за медленного интернет-соединения, на помощь приходит семейство **Azure Data Box** [3:31:22]. Клиенты заказывают физическое устройство емкостью до 80 ТБ через портал Azure, подключают его к своей локальной сети по протоколам SMB или NFS для копирования данных, а затем отправляют обратно в дата-центр Microsoft через регионального перевозчика [3:31:35]. Этот метод незаменим при разовой миграции архивов [3:31:48], периодической выгрузке данных с удаленных объектов (например, нефтяных платформ) [3:32:03] или для быстрого аварийного восстановления систем [3:32:15].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Базовым элементом защиты учетных записей является многофакторная аутентификация (MFA) [3:56:56]. Ранее в разговоре спикеры касались управления удостоверениями через Microsoft Entra ID [3:46:01], и MFA выступает критически важным дополнением к нему. Суть MFA заключается в подтверждении входа с помощью второго фактора (например, мобильного приложения с одноразовыми кодами) [3:58:04]. Это защищает учетную запись, даже если основной пароль был скомпрометирован злоумышленниками [3:57:22].

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

*   Учетные данные пользователя или его членство в группах (например, обязательное требование MFA для роли Global Administrator) [3:47:16].
*   Географическое положение (ограничение доступа по определенным IP-адресам) [3:47:54].
*   Состояние и платформа устройства (требование использовать только корпоративные или соответствующие политикам безопасности устройства) [3:48:06].
*   Используемое приложение [3:48:06].
*   Уровень риска в реальном времени, вычисляемый с помощью встроенных инструментов защиты [3:48:19].

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

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

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

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

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

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

На прикладном уровне (Layer 7 модели OSI) защиту обеспечивает Web Application Firewall (WAF), развернутый совместно с Azure Application Gateway [4:03:07], [4:05:19]. Application Gateway анализирует HTTP-запросы [4:05:32] и блокирует угрозы вроде SQL-инъекций или межсайтового скриптинга (XSS) [4:02:54]. Он также поддерживает тонкие настройки маршрутизации, SSL-терминацию [4:08:55] и функции плавного отключения серверов (connection draining) при обновлении инфраструктуры [4:09:20].

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

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

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

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

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

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

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

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

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

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

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

* Owner (Владелец) — обладает полным доступом ко всем ресурсам, включая право делегировать доступ другим пользователям [4:13:01].

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

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

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

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

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

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

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

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

* Azure Synapse Analytics (ранее SQL Data Warehouse) — платформа корпоративной аналитики и хранилище больших данных [4:17:36].

* Azure Database Migration Service — инструмент миграции баз данных в облако с минимальным временем простоя [4:18:03].

* Azure Cache for Redis — высокопроизводительное кэширование в оперативной памяти на базе open-source Redis [4:18:03].

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

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

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

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

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

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

* Azure App Service — платформа (PaaS) для развертывания веб-приложений без управления серверами [4:21:23].

* IDE Visual Studio — полноценная среда разработки для создания облачных решений [4:21:49].

* Xamarin — кроссплатформенный фреймворк для мобильных приложений под .NET [4:22:17].

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

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

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

Дальнейшие части лекции касаются сетевой инфраструктуры [4:24:39], концепций интернета вещей (IoT) [4:29:18], инструментов работы с большими данными [4:31:45] и технологий искусственного интеллекта [4:33:30], подробный разбор которых представлен в смежных главах руководства.

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

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

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

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

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

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

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

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

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

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

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

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

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

```javascript
// Тестовый запрос возвращает персонализированное приветствие
"hello Andrew" [4:45:06]
```

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Оценивать стоимость отдельных продуктов в конкретных регионах [5:03:38].
* Моделировать расходы на инфраструктуру без необходимости авторизации в системе [5:03:11].
* Выбирать тип операционной системы, уровень производительности и конфигурацию ресурсов [5:03:38].
* Экспортировать готовые расчеты в формат Excel для демонстрации руководству [5:03:11].

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

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

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

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

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

* **Resource Management:** быстро группировать ресурсы по проектам и окружениям [5:06:52].
* **Cost Management:** отслеживать расходы конкретных команд и точнее распределять бюджеты [5:06:52].
* **Operations:** выделять критически важные системы с жесткими требованиями к SLA [5:07:06].
* **Security:** классифицировать данные по уровню конфиденциальности [5:07:18].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запущенный терминал работает под управлением операционной системы Linux [5:27:40]. Это позволяет администраторам выполнять привычные команды, такие как `PWD` для вывода текущей рабочей директории или `LS` для просмотра списка файлов [5:27:53]. Интерфейс позволяет масштабировать шрифты через настройки для более комфортной работы с кодом [5:28:05]. По умолчанию в окружение интегрирован интерфейс командной строки Azure CLI [5:28:17]. Базовый вызов утилиты осуществляется с помощью короткой команды `az` [5:28:31]. Например, команда `az account list` возвращает структурированную информацию о текущих активных подписках пользователя в формате JSON [5:29:12]. По завершении сессии терминал можно закрыть простым кликом [5:29:26].

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

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

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

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

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

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

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

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

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

* **GA (General Availability)** — стабильные версии функций, которые полностью поддерживаются Microsoft и рекомендуются для промышленной эксплуатации [5:45:50].
* **Preview** — предварительные версии функций, которые проходят тестирование и могут измениться в будущем [5:46:05].
* **Experimental** — экспериментальные возможности, использование которых в продакшене сопряжено с высокими рисками удаления или изменения синтаксиса [5:46:32].

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

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

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

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

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

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

Имена учетных записей хранения в Azure должны состоять только из строчных букв, не содержать пробелов и быть глобально уникальными, так как они фактически формируют URL-адрес для доступа к данным [5:53:58]. Для демонстрации инструктор выбирает уникальное имя `mystorageaccount1234ab` [5:54:26] и указывает регион с помощью флага `-l East us` [5:54:38]. При создании ресурсов через CLI система не выводит предупреждения о лимитах бесплатного уровня, в отличие от интерактивного портала («клик-опс») [5:55:33]. Если опустить необязательный флаг конфигурации SKU, Azure автоматически применит параметры по умолчанию [5:56:00].

После успешного выполнения команды статус можно проверить прямо в консоли или через веб-интерфейс [5:56:39]. Для вывода списка существующих учетных записей применяется команда `az storage account list` [5:57:45]. По умолчанию утилита возвращает данные в формате JSON [5:57:45]. С помощью глобального флага `-o` (output) этот вывод легко переопределить на более читаемый формат YAML (`-o yaml`) [5:58:00] или представить в виде таблицы (`-o table`) [5:58:13]. По окончании работы созданную группу ресурсов удаляют через портал, где для подтверждения операции требуется скопировать и вставить её имя [5:58:52].

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

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

Для программного управления облачной инфраструктурой вместо CLI-команд часто применяются специализированные пакеты разработчика — Azure SDK [6:01:19]. Написание скриптов позволяет автоматизировать рутинные задачи администрирования [6:01:32]. Для подготовки примера создается локальная папка проекта с именем без пробелов (например, `Azure SDK example`) [6:02:23] и открывается в VS Code [6:03:04].

Azure SDK поддерживает широкий стек языков: Android, C#, Go, Java, JavaScript, Python и другие, хотя поддержка некоторых языков (например, Ruby) развита слабее [6:04:25]. Для демонстрации выбирается язык C# [6:05:06]. Чтобы ускорить написание громоздкого кода, инструктор использует ChatGPT для генерации базового шаблона развертывания хранилища [6:05:20]. В сгенерированном коде подключаются ключевые библиотеки: `Azure.ResourceManager` (для управления ресурсами) и `Azure.Storage` (для работы с хранилищем) [6:06:13]. Программа инициализирует клиент управления `ArmClient` [6:06:41], запрашивает подписку по умолчанию, создает группу ресурсов и затем разворачивает в ней хранилище [6:07:08]. Несмотря на некоторую многословность синтаксиса C# [6:07:22], такой подход обеспечивает полный контроль над инфраструктурой.

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

При сохранении файла с расширением `.cs` [6:08:01] локальный VS Code предлагает установить расширение поддержки C# [6:08:13]. Однако для выполнения программы требуется наличие установленного в операционной системе пакета .NET Core SDK [6:08:41]. Чтобы избежать сложностей с локальной установкой зависимостей на разных ОС [6:09:06], инструктор рекомендует перенести процесс в облачную среду разработки [6:09:19]. 

Поскольку в самом Azure нет полноценного встроенного веб-редактора кода (присутствует только Cloud Shell) [6:09:33], в качестве облачной IDE предлагается использовать GitHub Codespaces [6:09:46]. В бесплатном аккаунте GitHub [6:09:58] создается публичный репозиторий `Azure SDK C# example` с файлом README [6:10:24]. На его базе запускается среда Codespace [6:11:03]. Эндрю Браун предпочитает Codespaces аналогам (таким как GitPod) из-за бесшовной интеграции с официальным магазином расширений Microsoft VS Code Marketplace [6:11:29].

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

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

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

*   Идентификатор подписки (Subscription ID), скопированный из портала Azure [6:14:47].
*   Регион развертывания (например, `West US`) [6:14:22].
*   Уникальное имя учетной записи хранения (например, `helloworld123...ab` в нижнем регистре) [6:14:34].
*   Имя целевой группы ресурсов (`mySDKRG`) [6:14:34].

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

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

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

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

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

После завершения установки утилита `az` становится доступной в консоли [6:18:51]. При попытке выполнить авторизацию с помощью стандартной команды `az login` автоматическое перенаправление в браузер завершается неудачей, так как среда разработки запущена в облачном контейнере, а не на локальной машине [6:19:17]. Автор использует альтернативный метод авторизации через код устройства, введя команду с соответствующим флагом: `az login --use-device-code` [6:19:30]. Скопировав сгенерированный одноразовый код и перейдя по ссылке авторизации [6:19:43], он успешно привязывает свою учетную запись Azure к CLI-окружению [6:20:11]. Успешный вход сохраняет сессию в локальном хранилище виртуального воркспейса [6:20:24], что избавляет от необходимости вручную прописывать секреты и ключи доступа в кодовой базе при последующих тестовых запусках.

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

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

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

Поскольку попытка установить общий пакет `Azure` завершается ошибкой отсутствия доступных версий [6:27:25], автор ищет точные имена необходимых библиотек SDK [6:27:51]. Поочередно устанавливаются точечные зависимости: пакет управления учетными данными `Azure.Identity` [6:28:34], библиотека для работы с ресурсами `Azure.ResourceManager` [6:28:48] и пакет для взаимодействия со службами хранения `Azure.Storage.Blobs` [6:29:13]. Это позволяет разрешить базовые импорты компилятора, но впереди ждут более глубокие проблемы совместимости кода.

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

Повторный запуск проекта через `dotnet run` выявляет новые ошибки компиляции, связанные с несовпадением сигнатур методов и устаревшей кодовой базой [6:29:25]. Выясняется, что ИИ-помощник предоставил неактуальный код, ориентированный на старые версии API [6:30:16]. Автор пробует отправить текст ошибок обратно в чат-бот [6:30:44], однако, не получив адекватного ответа, решает обратиться к официальной справочной документации Azure SDK для C# [6:33:44]. 

Анализ документации показывает, что в актуальной версии SDK процесс создания группы ресурсов выглядит иначе: необходимо отдельно инициализировать клиентов и структуру данных. Автор переписывает блок создания группы ресурсов с использованием классов `ArmClient`, `ResourceGroupCollection` и `ResourceGroupData` [6:33:56]. Чтобы упростить отладку в условиях ограниченного времени, он временно исключает из кода логику создания хранилища [6:36:59]. Подобный итеративный процесс отладки и постоянного поиска информации является стандартной рутиной любого облачного инженера [6:37:26].

Тем не менее, код продолжает выдавать ошибки. Компилятор не распознает тип данных `AzureLocation` [6:37:39], несмотря на наличие импортированных пространств имен [6:38:30]. Попытка обойти строгое типизирование путем замены объекта локации на обычную строковую переменную `"West US"` [6:40:43] также приводит к новым сбоям, связанным с отсутствием контекста для клиентов и методов асинхронного ожидания [6:41:22]. Борьба с типами данных C# наглядно иллюстрирует сложность прямой работы с низкоуровневым кодом SDK по сравнению с декларативными инструментами развертывания.

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

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

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

В процессе компиляции также часто возникают несоответствия в именах инициализированных клиентов. Например, замена названия переменной с `armClient` на простое `client` позволяет устранить ошибки контекста [6:44:03]. После исправления всех зависимостей и импорта пространства имен `Azure` код успешно компилируется и выполняется [6:45:10]. 

Перед сохранением проекта в репозиторий необходимо настроить файл `.gitignore` [6:45:51]. В него следует добавить папки сборки `bin/` и `obj/`, чтобы избежать засорения коммита лишними метаданными компилятора [6:46:35]. После успешной фиксации кода в GitHub-репозитории [6:47:02] крайне важно правильно завершить рабочий сеанс. Для предотвращения нежелательных расходов (подробнее о которых говорилось при обсуждении оптимизации затрат) следует остановить текущий контейнер в GitHub Codespaces [6:48:05] и удалить тестовую группу ресурсов через портал Azure [6:48:17].

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

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

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

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

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

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

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

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

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

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

*   Быстрое развертывание и гарантированное уничтожение целых архитектурных сред за считанные минуты [6:53:18].
*   Минимизация человеческого фактора и исключение конфигурационных ошибок [6:53:18].
*   Модульность кода с возможностью повторного использования отдельных блоков [6:54:09].
*   Автоматическое тестирование конфигураций с помощью специализированных утилит вроде ARM TTK [6:54:21].
*   Предварительная валидация шаблонов на стороне Azure до начала фактического развертывания [6:54:34].

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

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

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

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

Экспортированные конфигурации можно сохранять в облаке в виде сущностей **Template Specs (Спецификации шаблонов)** [7:02:43]. При работе с ними важно учитывать характерную для Azure задержку распространения данных (propagation delay) [7:03:48]: созданные шаблоны или ресурсы могут отобразиться в интерфейсе портала лишь спустя 10–15 минут, что требует от администратора терпения [7:04:14]. Также при проведении тестов необходимо внимательно отслеживать оповещения о расходах, так как даже кратковременное развертывание тестовых стендов способно быстро расходовать лимиты бесплатного баланса [7:05:40].

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

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

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

При начале работы с Codespaces в первую очередь создается публичный или приватный репозиторий (например, с именем `Azure bicep example`) в организации или личном аккаунте [7:08:17]. При использовании облачного контейнера важно помнить, что запущенное окружение потребляет вычислительные ресурсы, поэтому по окончании работы сессию необходимо останавливать через командную палитру VS Code [7:09:22]. После настройки темной темы интерфейса (например, GitHub Dark) [7:09:47] ключевым шагом становится установка расширения **Azure Bicep** из встроенного магазина VS Code [7:10:29]. Синергия редактора Visual Studio Code, репозиториев GitHub и специализированных расширений позволяет получить мощные инструменты автодополнения и валидации синтаксиса, что делает процесс написания кода более эффективным, чем конфигурирование ресурсов через графический интерфейс портала Azure [7:10:55].

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

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

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

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

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

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

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

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

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

Основная команда для трансляции Bicep-кода в классический формат ARM-шаблонов звучит как `az bicep build --file main.bicep` [7:25:31]. Если в системе отсутствует необходимый компилятор, его можно быстро доустановить через вызов `az bicep install` [7:25:45]. Результатом компиляции становится файл `main.json` [7:28:08]. Этот сгенерированный документ представляет собой стандартный, готовый к деплою JSON-шаблон Azure Resource Manager [7:28:21]. Таким образом, Bicep функционирует как предметно-ориентированный язык (DSL), выступающий прозрачной синтаксической надстройкой над ARM, компилирующей человекочитаемый код в машиночитаемый JSON-формат [7:29:24]. Для ускорения деплоя прямо из редактора можно также использовать расширение **Azure Resource Manager (ARM) Tools** (находящееся на стадии Preview) [7:31:06]. Оно добавляет в интерфейс VS Code команду `arm deploy`, позволяющую отправлять скомпилированные шаблоны напрямую в облачную инфраструктуру Azure [7:31:47].

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

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

При попытке выполнить развертывание файла конфигурации Bicep непосредственно через командную палитру VS Code и одноименное расширение пользователь сталкивается с непредвиденной ошибкой отсутствия необходимых прав или неполной регистрации типов ресурсов в подписке [7:32:15]. Быстрый запрос в ChatGPT 3.5 не приносит мгновенных результатов [7:33:07]. Чтобы локализовать проблему, спикер переходит в веб-портал Azure в раздел Subscriptions -> Resource Providers для ручной проверки статуса регистрации провайдера `Microsoft.Resources` [7:33:35]. Убедившись, что провайдер активен, он приходит к выводу, что сбой вызван внутренними ограничениями плагина VS Code [7:34:30]. 

Для решения проблемы принимается решение задействовать проверенный интерфейс командной строки Azure CLI [7:34:30]. Для удобства работы создается пустой файл сценария `commands.azcli` [7:34:57], позволяющий задействовать IntelliSense и автодополнение команд. Спикер формирует структуру команды развертывания `az deployment group create` [7:36:17]. Однако процесс приостанавливается из-за временных задержек на стороне API Azure и сбоя интернет-соединения, что вынуждает выполнить повторное подключение к виртуальной среде GitHub Codespaces [7:39:10]. 

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

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

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

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

* Сначала выполняется обновление локальных индексов пакетов `sudo apt-get update` [7:48:10].

* Затем скачивается и верифицируется доверенный GPG-ключ HashiCorp для подтверждения подлинности устанавливаемого ПО [7:48:24].

* В конфигурацию репозиториев операционной системы добавляется официальный источник HashiCorp [7:49:17].

* Запускается финальная команда установки пакета `sudo apt-get install terraform` [7:50:13].

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

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

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

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

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

* Название целевой группы ресурсов переопределяется как `my terraform RG` [7:54:37].

* Регион развертывания меняется на `West US` [7:54:50].

* Для Storage Account задается уникальное имя и убираются избыточные теги [7:55:16].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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