Автоматическая продажа подписки

2025-04-30

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

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

Почему продажи подписок с помощью автоматов?

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

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

Как внедрить систему продажи подписки

В продаже подписок участвуют три команды. Cloud Center of Excellence (CCoE) устанавливает бизнес-логику и процесс утверждения. Когда все готово, команды приложений выполняют запросы на подписку. Команда платформы использует запрос для создания и настройки подписки перед передачой подписки команде приложений. Команда приложений обновляет бюджет, развертывает рабочую нагрузку и устанавливает операции. В нижеследующем руководстве содержатся более подробные сведения о каждом шаге процесса предоставления подписки. Для получения дополнительной информации см. руководство по внедрению управления подписками.

Команды платформы могут предлагать множество вариантов и типов подписок командам приложений. Эти типы называются линиями продуктов , так как они относятся к принципам и методикам проектирования платформы. Дополнительные сведения о выборе варианта, который лучше всего подходит для ваших потребностей, см. в разделе Common subscription vending product lines.

Установка бизнес-логики и процесса утверждения

Чтобы реализовать модель продажи подписки, необходимо создать процесс утверждения, который собирает важные сведения о подписке. Cloud Center of Excellence (CCoE) должен программировать процесс утверждения и устанавливать бизнес-правила для сбора информации.

Автоматизация процесса. Вы должны автоматизировать процесс сбора и утверждения запросов на подписку для ускорения подготовки и улучшения соответствия требованиям.

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

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

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

С помощью процесса утверждения команды приложений могут начать выполнять запросы на подписку.

Создание запроса на подписку

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

Настройка сети

Автоматизация подписок должна настроить необходимые сетевые компоненты, и она должна быть достаточно гибкой для удовлетворения потребностей каждой команды приложений. В качестве общих рекомендаций никогда не используйте перекрывающиеся IP-адреса в одном домене маршрутизации. Можно добавить или удалить адресное пространство виртуальной сети без простоя при изменении требований к размеру. Дополнительные сведения можно найти здесь

Используйте средство управления IP-адресами (IPAM). Для упрощения назначения IP-адресов следует использовать и интегрировать систему IPAM в процесс vending. Дополнительные сведения и рекомендации по IPAM см. в средствах управления IP-адресами (IPAM).

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

Принудительное управление сетями. Команда платформы должна применять управление виртуальной сетью через (1) политику Azure, назначенную для иерархии групп управления, или (2) Azure Virtual Network Manager и правила администратора безопасности. Дополнительные сведения см. в разделе "Управление на основе политик " и "Как блокировать порты высокого риска".

Определение размещения подписки

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

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

Создание гибкой автоматизации. Автоматизация должна быть достаточно гибкой (1) для развертывания нескольких подписок и (2) адаптироваться к ограничениям службы подписки.

Несколько подписок: Для некоторых рабочих нагрузок требуется несколько подписок. Например, некоторые рабочие нагрузки имеют несколько экземпляров, разделенных подпиской. Кроме того, архитектуры SaaS, использующие выделенные ресурсы для каждого клиента, часто используют десятки подписок.
Ограничения службы подписки: Предприятие с несколькими тысячами подписок должно иметь автоматизацию, которая может развертываться в старой подписке или колокатировать рабочие нагрузки в подписке, чтобы избежать ограничений. Дополнительные сведения см. в статье "Часто задаваемые вопросы о целевых зонах Azure".

После подготовки можно запросить увеличение квоты вручную с помощью портала Azure. Проще автоматизировать этот процесс с помощью доступных API. Однако запрос квоты может завершиться ошибкой, поэтому следует запустить скрипт для обработки любых ошибок. Дополнительные сведения см. в разделе Microsoft.Capacity, Microsoft.Quota и Microsoft.Support

Создание и настройка подписки

Теперь вы можете создать и настроить запрошенную подписку. Цель состоит в создании повторяемого, согласованного процесса. Автоматизируйте столько процесса создания и настройки подписки, сколько можно.

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

Существуют примеры модулей Bicep и Terraform, которые помогут вам внедрить модель продажи подписки независимо от вашего участия в коммерческом соглашении. Для оркестрации автоматизации следует использовать действия GitHub или Azure Pipelines.

Используйте теги для управления затратами. Необходимо автоматизировать согласованное назначение тегов каждой подписке для управления затратами и создания отчетов в Microsoft Cost Management. Хотя вы получаете отчеты о выставлении счетов в рамках коммерческих соглашений, управление затратами предлагает расширенные возможности. Например, можно создавать отчеты для подписок с определенными тегами. Дополнительные сведения см. в разделах "Использование тегов в данных о затратах и использовании" и "Группировка и распределение затрат с помощью наследования тегов".

Используйте рабочие и тестовые подписки. В запросе на новую подписку необходимо указать, предназначена ли рабочая нагрузка для Production или DevTest. Среды DevTest приводят к снижению затрат на ресурсы, но имеют другие условия. Примечание. Предложение DevTest недоступно для MPA. Дополнительные сведения можно найти здесь

Настройка удостоверений и управления доступом на основе ролей (RBACs). Управление доступом к ресурсам в подписке Azure крайне важно для обеспечения безопасной и совместимой среды. Для управления доступом необходимо настроить удостоверения и RBACs. Эта настройка включает назначение владельца подписки, создание групп Microsoft Entra для управления доступом и формирование идентификаторов автоматизации для развертывания рабочих нагрузок.

Назначьте владельца подписки. Автоматизация подписных услуг должна назначить владельца подписки при создании. Запрос подписки должен фиксировать эти сведения на этапе ввода. Владельцы подписок могут быть только пользователями или субъектами-службами в выбранном каталоге подписки. Выбрать пользователей гостевого каталога невозможно. В случае выбора субъекта-службы введите его идентификатор приложения.
Создание групп Microsoft Entra. Помимо владельца подписки, необходимо убедиться, что процесс предоставления услуг использует структуру групп Microsoft Entra для управления доступом к подписке. Для доступа с повышенными привилегиями (например, для записи) рекомендуется использовать PIM для групп. Автоматизация этого процесса создания не должна нарушать рекомендации, такие как ограничение количества владельцев подписок и использование минимального требуемого уровня доступа.
Создайте идентификаторы нагрузки. Идентификаторы рабочей нагрузки (основные службы), используемые для развертывания рабочей нагрузки, часто имеют повышенные разрешения на уровне подписки. Процесс запроса подписки должен собирать потребности в идентификации рабочей нагрузки при приеме. Ваш процесс развертывания должен создать эти идентификационные данные и назначить соответствующий доступ к подписке. Важно отметить, что идентификатор рабочей нагрузки не может использовать PIM и получает постоянный доступ к ресурсам. Мы рекомендуем использовать управляемые удостоверения, чтобы избежать необходимости управления секретами. Дополнительные сведения см. в области проектирования идентичности.

Передать команде приложений. После создания подписки команда платформы должна передать подписку группе приложений.

Обновление бюджета подписки

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

Развертывание вычислительной нагрузки и управление

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

Дальнейшие шаги

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

Создание общих торговых линий для продуктов подписки