развертывание Microsoft Foundry в моей организации

Структурированный план развертывания помогает избежать пробелов в безопасности, перерасхода затрат и расширения доступа при внедрении Microsoft Foundry в масштабе. Используйте это руководство, чтобы определить границы рабочей нагрузки, выбрать топологию ресурсов и установить управление для групп самообслуживания.

Необходимые условия

Прежде чем приступить к планированию, убедитесь, что у вас есть:

• Понимание базовой структуры подписки Azure вашей организации и групп ресурсов.
• Исходные данные о требованиях вашей организации к безопасности сетевой инфраструктуры, шифрованию и изоляции данных.
• Начальный план региона на основе модели и доступности функций. Дополнительные сведения см. в статье о доступности компонентов в облачных регионах.
• Соглашение о требованиях к безопасности для сети, шифрования и изоляции данных в организации.
• Инвентаризация функций и API-интерфейсов foundry, которые вы планируете использовать в команде.

Определение границ изоляции

Начните с Cloud Adoption Framework руководства по принятию решений по совместному использованию платформ ИИ, а затем примените эти решения к Foundry:

• Определение границ общего доступа к платформе ИИ

Хотя каждая ситуация уникальна, для общей организации мы рекомендуем следующую последовательность:

1. Определите неизменяемые границы общего доступа между подразделениями, доменами данных, владением продуктами и уровнями среды.
2. Задайте политику prod, которая по умолчанию используется для изоляции, если документированное исключение не разрешает совместное размещение.
3. Задайте политику экспериментирования, которая по умолчанию предполагает совместное размещение для ускорения экспериментов, если только требования соответствия или валидация не требуют изоляции.
4. Назначьте ответственных для каждой границы ответственности, включая ответственность за безопасность, затраты и реагирование на инциденты.

Определение возможностей и требований к доступу

Определите, какие функции и API-интерфейсы Foundry требуются для каждой рабочей нагрузки, прежде чем завершить топологию.

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

Большинство новых, ориентированных на агента API Foundry, поддерживают разрешение на область проекта. Некоторые традиционные API Foundry Tools (ранее Azure AI Services), такие как преобразование речи в текст, по-прежнему требуют доступа с областью действия родительского ресурса. Планируйте границы и RBAC, чтобы все необходимые возможности были доступны в выбранной области управления доступом.

Выбор топологии ресурсов Foundry

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

Планирование базовых показателей безопасности

Используйте эту справочную таблицу в качестве контрольного списка для принятия решений по проектированию безопасности.

Планирование модели, региона и стратегии емкости

Для каждой рабочей нагрузки определите следующее:

• Семейства моделей и типы развертываний, необходимые для варианта использования.
• Требования к обработке данных (например, глобальные или региональные ограничения).
• Целевые показатели пропускной способности и задержки для интерактивных и пакетных сценариев.
• Требования к квотам и выделенной мощности при стабильной и пиковой нагрузке.

Используйте следующие ссылки:

• Модели продаются непосредственно через Azure
• Модели от партнеров
• Квота в Foundry
• Квоты и ограничения для моделей Foundry

Планирование подключения и интеграции данных

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

• Источники данных и хранилища данных.
• Внутренние API и бизнес-системы.
• Инструменты SaaS, не относящиеся к Azure, необходимые агентам или потокам оркестрации.
• Требования к сети, включая частные конечные точки, разрешение DNS, элементы управления исходящего трафика и требуется ли управляемая сеть или виртуальная сеть BYO.

Используйте добавление подключений в Foundry , чтобы стандартизировать настройку подключения.

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

Планирование автоматизации и операций

Определите, как команды создают ресурсы и управляют ими согласованно в разных средах.

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

Для шаблонов автоматизации и начальных реализаций используйте:

• Quickstart: развертывание ресурса Microsoft Foundry с помощью файла Bicep
• Terraform в Azure
• Примеры конфигураций безопасности

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

Настройте ограничения самообслуживания

Включите самообслуживание только в четких ограничениях:

• Определите, какие роли могут создавать проекты, развертывать модели и подключать внешние средства.
• Примените элементы управления политикой для развертывания модели и поведения среды выполнения, включая поставщиков моделей и разрешенные подключения к инструментам.
• Настройка элементов управления затратами и оповещений бюджета для общих и изолированных сред.
• Включите журналирование трассировки в централизованную систему наблюдаемости в Microsoft Foundry, Microsoft Copilot Studio и Microsoft 365.

Используйте следующие ссылки:

• Политика развертывания модели в Foundry
• Управление затратами в Foundry
• Интеграция агента 365

Назначение владельца и управления

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

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

Foundry разграничивает доступ по следующим категориям:

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

Рекомендации по сопоставлению ролей и необходимые сочетания ролей см. в разделе "Управление доступом на основе ролей" в Foundry.

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

• Мониторинг по паркам в Литейном
• Интеграция агента 365
• Microsoft Defender для облака
• Политика Azure

Пример развертывания платформы

ИТ-организация в Компании Contoso должна поддерживать несколько команд при балансировке двух приоритетов:

• Быстрые инновации, где разработчики могут тщательно тестировать новейшие технологии ИИ с помощью непроизводственных данных.
• Полностью изолированные среды разработки/тестирования и промышленной эксплуатации для проверенных сценариев использования, которые получают финансирование для внедрения в эксплуатацию.

На схеме показано, как Contoso размещает общий экземпляр Foundry для экспериментов, доступный всем командам, с ограниченной ёмкостью и заранее подключёнными данными и инструментами. Пример невыполненной работы отражает распространенные корпоративные функции, такие как поддержка клиентов, служба технической поддержки сотрудников, финансовые операции, закупки и продажи. Исторически лишь немногие варианты использования доходят до стадии подтверждения осуществимости или получают финансирование для развертывания в средах разработки и тестирования. Из них в продакшен попадает ещё меньшее подмножество. На схеме также показаны два связанных сценария использования в продажах, которые остаются в одном контуре на этапах исследования и разработки/тестирования, поскольку используют одни и те же данные CRM, пользовательские роли и подключённые системы. По мере развития сценариев использования командам выделяются среды со всё более строгой изоляцией, вплоть до полного выделения на уровне production там, где это необходимо.

Подробнее

• Защита среды Foundry

  • Проверка подлинности и RBAC: управление доступом на основе ролей в Foundry
  • Сеть. Использование виртуальной сети с Foundry
  • Ключи, управляемые клиентом (CMK): ключи, управляемые клиентом в Foundry
  • Пример инфраструктуры: репозиторий шаблонов с примерами шаблонов инфраструктуры
  • Восстановление или очистка удаленных ресурсов Foundry

• Установка подключения к другим службам Azure

  • Общие сведения о подключениях. Добавление нового подключения в Foundry

Следующий шаг