Разработайте стратегию среды клиента, чтобы внедрить Power Platform в большом масштабе

Процесс внедрения Microsoft Power Platform в каждой организации уникален. Стратегия среды для работы с арендаторами закладывает основу для ускорения использования платформы управляемым и безопасным способом.

В этой статье показано, как согласовать стратегию среды клиента Power Platform с возможностями продукта и видением. Узнайте, как наилучшим образом использовать новейшие функции платформы для реализации стратегии, которая позволит вам внедрить Power Platform в масштабе предприятия.

Введение

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

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

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

Видение Microsoft стратегии среды для работы с арендаторами

Многие организации начинают использование Power Platform с приложений и средств автоматизации для повышения личной продуктивности, созданных и работающих в общей центральной среде, называемой средой по умолчанию. Эти ресурсы часто используют только основные возможности, включенные в Microsoft 365, и не используют полные возможности Power Platform. По мере ускорения этого первоначального внедрения Microsoft предоставляет организациям возможность перехода к стратегии среды для внедрения всех возможностей Power Platform в масштабе предприятия. Эти возможности управления уровня "Премиум" становятся доступными, когда у пользователей есть лицензия Premium Power Platform (Power Apps, Power Automate, Microsoft Copilot Studio и Dynamics 365). Модель зрелости внедрения Power Platform предоставляет дополнительные аналитические сведения, которые помогут организациям определить свою дорожную карту для внедрения в масштабе предприятия, выходящего за рамки стратегии среды. Этот подход может помочь организациям перейти от базовой личной продуктивности к внедрению Power Platform в масштабе предприятия.

Функции администрирования, управления и безопасности Power Platform позволяют организациям внедрять и управлять Power Platform для повышения производительности предприятия и использования корпоративных приложений в большом масштабе. Использование управляемых сред активирует набор возможностей уровня "Премиум", которые обеспечивают большую видимость и управление и сокращают усилия вручную для администрирования и защиты сред. Используя эти возможности, вы можете обеспечить последовательное применение политик управления и безопасности. Используя эти возможности, администраторы могут перейти к стратегии среды в масштабах предприятия. Затрачивая меньше времени и усилий на администрирование, вы помогаете снизить общую совокупную стоимость владения (TCO) платформы по мере масштабирования ее использования в вашей организации.

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

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

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

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

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

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

Функции, которые поддерживают стратегию среды в масштабе предприятия

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

• Типы сред описывают различные способы использования среды в рамках вашей стратегии.
• Управляемые среды предоставляют набор возможностей уровня "Премиум", упрощающих управление средами в масштабе.
• Автоматическое предоставление лицензий упрощает назначение лицензий, позволяя пользователям получать лицензии Power Apps на каждого пользователя по мере необходимости, вместо того чтобы администратору требовалось заранее определять пользователей, которым они нужны.
• Группы и правила среды объясняют, как управлять средами как группами и применять правила к группам для автоматизации согласованных политик управления.
• Маршрутизация среды по умолчанию автоматически перемещает создателей от создания ресурсов в среде по умолчанию к их собственной, личной среде.
• Microsoft Dataverse обеспечивает повышенную безопасность и ALM.
• Предпочтительные решения помогают создателям гарантировать, что все создаваемые ими активы находятся в решении Dataverse, что облегчает их передачу в другие среды.
• Конвейеры в Power Platform обеспечивают упрощенный процесс перемещения активов из среды разработки в среду тестирования и рабочую среду, делая непрерывную интеграцию и развертывание (CI/CD) доступными для всех создателей.
• Каталог в Power Platform позволяет создателям обмениваться компонентами, такими как приложения и потоки, а также более продвинутыми отправными точками, такими как шаблоны.

Типы сред

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

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

Управляемые среды

Среды имеют базовый набор функций и характеристик в зависимости от типа среды. Управляемые среды расширяют базовые функции, предоставляя набор возможностей уровня "Премиум", которые позволяют администраторам более легко управлять Power Platform в большом масштабе с большим контролем, меньшими усилиями и более подробными сведениями. Эти возможности появляются, когда вы настраиваете среду как управляемую.

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

Автоматическое требование лицензий

Политики Auto-claim автоматизируют назначение лицензий Power Apps и Power Automate пользователям, когда пользователям требуется лицензия для использования определенных приложений или функций. Служба автоматизации может помочь сократить количество используемых лицензий и избежать накладных расходов, связанных с назначением лицензий вручную.

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

• Если пользователь без автономной лицензии Power Apps запускает приложение, требующее премиум-лицензии, система автоматически назначает пользователю лицензию Power Apps на одного пользователя.

• Если пользователь без отдельной лицензии Power Apps запускает приложение в управляемой среде, система автоматически назначает ему лицензию Power Apps на пользователя.

Аналогично, после настройки политики пользователю в организации, которому требуется индивидуальная лицензия Power Automate, она предоставляется автоматически при соблюдении следующих условий:

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

• Пользователь запрашивает лицензию Power Automate premium.

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

Группы сред и правила

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

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

• Для включения в группу необходимо управлять средой.
• Среда может одновременно находиться только в одной группе.
• Среду можно перемещать из одной группы в другую.
• Среды в группе могут относиться к нескольким географическим регионам.
• Группы не могут содержать другие группы.

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

• Элементы управления общим доступом для приложений на основе холста
• Аналитика по использованию
• Содержимое приветствия создателя
• Принудительное использование средства проверки решения
• Хранение резервных копий
• Описания, созданные ИИ

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

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

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

Рисунок: концептуализация стратегии среды для клиента Contoso.

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

Рисунок: пример внедрения концептуальных групп среды в реальный клиент

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

Маршрутизация среды по умолчанию

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

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

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

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

Создателям автоматически присваивается роль безопасности, которая делает их администраторами среды разработки. Если среда является частью группы среды, создатель — как администратор среды — не может изменять параметры среды, поскольку они управляются правилами группы среды. Любые изменения могут вносить только администраторы, имеющие право изменять правила группы.

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

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

Содержимое приветствия создателя

Предоставьте персонализированный приветственный контент, чтобы помочь разработчикам приступить к работе с Power Apps и Copilot Studio. Когда вы добавляете собственное содержимое справки, оно заменяет собой содержимое справки по умолчанию Power Apps для новых создателей. Пользовательское приветственное сообщение может информировать разработчиков о правилах компании и о том, что они могут сделать в каждой среде или группе сред.

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

Среда по умолчанию

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

Например, вы можете уведомить разработчиков о том, что среду по умолчанию следует использовать только для решений, связанных с приложениями Microsoft 365, избегая использования рабочих приложений в этой среде и делясь приложениями Canvas только с ограниченным числом пользователей. В следующем примере показано, как создать такое сообщение в параметрах управляемых сред:

Пример входных данных Markdown:

![Contoso](https://i.ibb.co/SNSTCx3/something.png)
## Welcome to Contoso Personal Productivity Environment

### Before you start, here are some considerations

Use this environment if you plan to build apps that integrate with Office 365.

Before you start, be aware of these limitations:

1. You can't share your apps with more than five users.
1. The data in Dataverse is shared with everyone in the organization.
1. You can only use Office 365 connectors.

If you're not sure you're in the right place, follow **[this guidance](#)**.

Вот показанное приветственное сообщение:

Рабочие среды

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

![Contoso](https://i.ibb.co/SNSTCx3/something.png)
## Welcome to HR Europe Environment

### Before you start, here are some considerations

Use this environment if you're on the HR team and your data is located in Europe.

Before you start, be aware of these limitations:

1. You can only share apps with security groups. [Follow this process](#) to share your apps.
1. The data in Dataverse is stored in Europe.
1. You can only use social media connectors with read actions.
1. If you need more connectors, [submit a request](#).

If you're not sure you're in the right place, follow **[this guidance](#)**.

Ниже приведен пример выходных данных:

Среды разработки

Среды разработчиков — это чаще всего то место, где разработчики создают свои решения. Так как разработчики работают над приложениями, они не находятся в рабочей среде, и масштабируемость ограничена. Как правило, среды разработки имеют более расслабленные политики данных из-за характера создателей. Чтобы избежать использования рабочих ресурсов в средах разработки, ограничьте возможности совместного использования и используйте определенную политику данных для этого типа среды. Ниже приведен пример приветственного сообщения для среды разработки:

![Contoso](https://i.ibb.co/SNSTCx3/something.png)
## Welcome to a Developer Environment

### Before you start, here are some considerations

Use this environment if you're a developer and you're building solutions.

Before you start, be aware of these limitations:

1. You can only share resources with up to two members of your team. If you need to share with more people, [submit a change request](#).
1. Use resources only while you're developing a solution.
1. Be mindful of the connectors and data you're using.
1. If you need more connectors, [submit a request](#).

If you're not sure you're in the right place, follow **[this guidance](#)**.

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

Среды-песочницы

Как правило, среды песочницы используются для тестирования решений. Так как некоторые тесты включают значительное количество пользователей, эти среды масштабируются до определённого предела и имеют большую вместимость, чем среды разработчика. Изолированные среды также часто используются в качестве сред разработки и обычно используются несколькими разработчиками. Ниже приведен пример приветственного сообщения для такой среды:

![Contoso](https://i.ibb.co/SNSTCx3/something.png)
## Welcome to a Test Environment

### Before you start, here are some considerations

Use this environment only if you're testing solutions.

Before you start, be aware of these limitations:

1. You can only share resources with your team. If you need to share with more people, [submit a change request](#).
1. You're not allowed to edit or import solutions directly in this environment.
1. Be mindful of the test data and compliance.
1. If you need help from a security export or IT support, [submit a request](#).

If you're not sure you're in the right place, follow **[this guidance](#)**.

Ниже приведен пример выходных данных для песочницы или тестовой среды:

Ограничение предоставления доступа

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

Администраторы обычно должны контролировать, как разработчики делятся своими приложениями, потоками данных и агентами, когда:

• Общий доступ к ресурсам осуществляется в личной рабочей среде. Если у вас есть среда, в которой пользователи могут создавать ресурсы для своей работы, ресурсов без глобальной бизнес-ценности или ресурсов без поддержки ИТ-отдела, важно, чтобы разработчики не могли совместно использовать их в организации. Если ресурсы изначально предназначены для личной продуктивности, но позже становятся популярными и широко используются, учитывайте предел, который вы устанавливаете на их совместное использование. Общее ограничение составляет от 5 до 50 пользователей.

• Ресурсы используются совместно с группами безопасности или всеми пользователями. Ресурсы, к которым открыт общий доступ для группы безопасности, могут выполняться всеми участниками группы. В среде разработчика может потребоваться, чтобы разработчик мог контролировать общий доступ к ресурсам, а не полагаться на членство в группах. В других сценариях может потребоваться разрешить общий доступ всем пользователям. Если политика вашей организации заключается в том, что ресурсы совместно используются группой безопасности, которая включает всех пользователей, которым разрешено запускать ресурс и управляется ИТ-отделом, может потребоваться ограничить доступ разработчиков к другим группам безопасности.

Ниже приведены общие ограничения общего доступа для каждого типа среды:

• По умолчанию: выберите "Исключить общий доступ с группами безопасности", выберите "Ограничить общий доступ пользователей" и выберите 20 для значения.

• Разработчик: выберите "Исключить общий доступ с группами безопасности", выберите "Ограничить общий доступ пользователей" и выберите 5 для значения.

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

• Продакшн: выберите "Не задавать ограничения" (по умолчанию). Чтобы контролировать общий доступ на основе определенной группы безопасности, выберите "Исключить общий доступ с группами безопасности " и оставьте Ограничить общее число людей, которым можно предоставить доступ, невыбранным.

Microsoft Dataverse

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

Решения dataverse — это механизм реализации ALM в продуктах Power Platform, таких как Power Apps и Power Automate. В конвейерах Power Platform используются решения для автоматизации CI/CD активов, которые создают создатели. Решения можно экспортировать из Dataverse и хранить в средстве управления версиями, например Azure DevOps или GitHub. Решение в системе управления версиями становится источником достоверной информации, если вам нужно воссоздать среду разработки. Например, если создатель создал популярное приложение, а затем удалил среду разработки, экспортированное решение, хранящееся в системе управления версиями, можно использовать для воссоздания жизнеспособной среды разработки.

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

Мы рекомендуем использовать Dataverse в любой среде, где создатели создают активы, которые будут доступны другим пользователям. Такая стратегия упрощает подготовку активов к ALM.

Предпочтительные решения

Когда создатель создает актив Dataverse в среде Dataverse и не начинает с пользовательского решения, этот актив связывается с решением по умолчанию и также может быть связан с решением по умолчанию Common Data Service. Решение по умолчанию используется всеми создателями, создающими активы в среде. Определить, какой создатель создал определенные компоненты или какие активы принадлежат конкретным приложениям, непросто, что затрудняет перемещение популярного приложения в другую среду для обмена с более широкой аудиторией. Для этого необходимо переместить все активы в решении по умолчанию, что не является идеальным решением.

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

Конвейеры в Power Platform

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

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

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

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

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

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

Принудительное использование средства проверки решения

Обычно команда Центра превосходства (CoE) настраивает сторожевые барьеры, чтобы снизить риск импорта несоответствующих решений в среду. Администраторы могут легко применять богатые статические проверки решений в отношении набора правил лучших практик для выявления проблемных шаблонов. Организации с децентрализованными CoEs часто считают необходимым активировать принудительное применение инструмента проверки решений вместе с проактивным обращением к разработчикам по электронной почте, чтобы предложить поддержку.

Принудительная проверка решений предлагает три уровня контроля: "Нет", "Предупреждать" и "Блокировать". Администраторы настраивают эффект проверки, предоставляет ли он предупреждение, но разрешает импорт или блокирует импорт полностью, а также предоставляет результат импорта создателю.

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

• По умолчанию: выберите "Блокировать " и "Отправить сообщения электронной почты".
• Разработчик: выберите «Предупреждать» и оставьте «Отправлять электронные письма» невыбранным.
• Песочница: выберите Предупредить и оставьте Отправка сообщений электронной почты невыбранной.
• Рабочая: выберите Блокировать и Отправлять сообщения.
• Среда Teams: выберите Блокировать и Отправлять сообщения.

Каталог в Power Platform

Организации, в которых разработчики и создатели создают и совместно используют такие компоненты, как приложения, потоки и шаблоны (усовершенствованные отправные точки), как правило, получают больше пользы от Power Platform. Каталог Power Platform позволяет создателям легко обмениваться своими компонентами и шаблонами в разных средах.

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

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

Дорожная карта функций

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

Основа стратегии среды в масштабе предприятия

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

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

• Сотрудники должны иметь возможность создавать автоматизированные процессы утверждения документов и другие настройки Power Platform с помощью Microsoft 365.
• Сотрудники должны иметь возможность создавать автоматизации с помощью Power Apps и Power Automate, чтобы повысить личную продуктивность.
• Создатели, работающие над приложением "Средство отслеживания соответствия нормативным требованиям" компании, должны иметь возможность разрабатывать и поддерживать его.

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

Рисунок: предлагаемая топология среды для масштабного проекта Power Platform компании Contoso.

Давайте подробно рассмотрим эту диаграмму топологии среды.

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

Только администраторы могут создавать пробную, изолированную и рабочую среды. Создатели используют специальную форму Microsoft или другой процесс для запроса новой среды. Начальный набор Microsoft Power Platform Center of Excellence (CoE) включает запрос на создание среды , который можно использовать.

Создаются четыре группы сред: разработка, совместная разработка, UAT (приемочное тестирование пользователями) и рабочая среда.

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

• Группа "Совместная разработка" поддерживает среды, содержащие проекты с несколькими создателями.

• Группа "UAT" содержит среды, которые используются для тестирования ресурсов перед их переводом в рабочую среду.

• Группа "Рабочая среда" содержит среды, в которых размещаются приложения, потоки и другие артефакты для рабочего использования.

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

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

В обновленную диаграмму топологии среды мы добавили среду размещения конвейера и два конвейера. Один конвейер перемещает ресурсы из среды разработки в среду тестирования, а затем в рабочую среду. Правило конвейера в группе "Разработка" будет изменено для использования этого конвейера. Другой конвейер перемещает ресурсы из среды совместной разработки в среду тестирования, а затем в рабочую среду. Правило конвейера в группе "Совместная разработка" будет изменено для использования этого конвейера.

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

Стратегии среды для конкретных сценариев

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

Контролируйте, какие создатели могут создавать среды разработки

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

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

Чтобы уточнить, какие создатели имеют право на маршрутизацию среды, укажите группу безопасности в конфигурации маршрутизации. Если настроена группа безопасности, маршрутизируются только участники группы безопасности. Все остальные возвращаются к среде по умолчанию.

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

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

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

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

Организуйте среду разработки по регионам или бизнес-единицам

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

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

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

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

Разработайте приложение для корпоративного использования

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

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

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

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

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

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

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

Например, версия 1.0 приложения может находиться в разработке, пока рабочая группа переходит к созданию версии 2.0. Ваша стратегия среды должна поддерживать устранение проблемы в версии 1.0, пока ведется разработка версии 2.0.

Рисунок: версия 1.0 должна быть исправлена, протестирована и развернута, пока версия 2.0 разрабатывается, тестируется и развертывается.

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

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

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

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

Безопасность как часть вашей стратегии среды

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

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

Безопасность на уровне арендатора

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

• Рассмотрите возможность отключения функции "Общий доступ для всех" в Power Platform. Только администраторы смогут поделиться активом со всеми.
• Рассмотрите возможность защиты интеграции с Exchange.
• Примените изоляцию между клиентами, чтобы минимизировать риск утечки данных между клиентами.
• Разрешите администраторам создавать новые для сети рабочие среды. Ограничение создания среды полезно для поддержания контроля в целом: как для предотвращения неучтенного потребления емкости, так и для уменьшения количества управляемых сред. Если пользователям приходится запрашивать среды у центрального ИТ-отдела, легче увидеть, над чем работают люди, если администраторы являются сотрудниками безопасности.

Защита среды по умолчанию

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

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

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

• Рассмотрите возможность переименования среды по умолчанию во что-то более информативное, например "Личная продуктивность".

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

  • Создайте правило, чтобы заблокировать все шаблоны URL-адресов, используемые настраиваемыми соединителями.

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

Подробнее: Защита среды по умолчанию

Защитите другие среды

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

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

Рисунок: пример трех уровней безопасности среды и функций безопасности, применимых к средам на каждом уровне.

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

Согласуйте среды с вашей стратегией политики по данным

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

Узнайте больше о том, как реализовать стратегию политики данных.

Рис. В этом примере среды в группе "Личная разработка" соответствуют политике защиты от потери данных (DLP), которая блокирует все соединители, отличные от Майкрософт.

Адаптируйте стратегию среды к вашей организации

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

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

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

Информация об организации, которую вам следует знать, включает в себя:

• Каково видение того, как Power Platform будет использоваться в организации?
• Кто в организации будет создавать малокодовые активы?

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

• Как создатели получат новые среды?
• Будете ли вы группировать ваши среды, и если да, то как?
• Какие уровни безопасности необходимы для различных сред и как среды классифицируются?
• Как решить, будет ли приложение, автоматизация или Copilot использовать существующую среду или новую?
• Есть ли какие-либо расхождения между базовыми функциями платформы и вашими требованиями, требующими специального процесса управления?
• Как вы будете обращаться с любыми существующими активами в среде по умолчанию?
• У вас есть стратегия политики данных клиента и среды, а если да, то как она соответствует создаваемой стратегии среды?

Вы можете найти вдохновение в операционных моделях cloud которые являются частью Cloud Adoption Framework для Azure.

Заполните пробелы с помощью платформы

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

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

Начальный набор центра передовых технологий (CoE)

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

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

Фигуре: панель мониторинга сред в Power BI.

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

Рисунок: блок-схема, иллюстрирующая процесс управления средой в начальном наборе центра передовых технологий.

Возможности программирования и расширяемость платформы

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

Для создания приложений и потоков можно использовать следующие соединители:

• Power Platform for Admins и Power Platform for Admins V2
• Power Apps для администраторов и Power Apps для разработчиков
• Управление Power Automate

Вы можете использовать интерфейс командной строки Power Platform (CLI) для разработки средств автоматизации, которые помогут вам управлять жизненным циклом среды и другими задачами, связанными с практиками DevOps.

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

Пакет SDK DLP в Power Platform поможет вам управлять политиками защиты от потери данных (DLP) на уровне клиента и среды.

Рекомендации по лучшим практикам

В этом разделе статьи мы опираемся на рекомендации из разделов «Основы» и «Специальные сценарии».

Новые среды

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

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

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

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

При оценке рабочей среды приложения учитывайте следующие соображения:

• Совместимо ли приложение с существующими приложениями в среде? Например, два приложения, которые используют таблицу "Контакт" в Dataverse для разных целей, могут быть несовместимы. Совместимы ли приложения с точки зрения политики данных?

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

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

• Требуются ли приложению данные из других приложений и должны ли они размещаться вместе с ними? Например, два приложения, оба из которых используют вашу таблицу "Клиенты", должны размещаться вместе. Их разделение приведет к созданию избыточных копий данных и возникновению проблем с обслуживанием данных.

• Требуется ли обеспечивать рациональность места расположения данных? В некоторых сценариях одно и то же приложение или средство автоматизации можно развернуть в региональных средах, чтобы обеспечить соответствующую изоляцию и постоянное размещение данных.

• Большинство пользователей находятся в том же регионе, что и среда? Если среда находится в регионе EMEA, но большинство пользователей приложения проживают в США, совместное использование среды может не обеспечить наилучшую производительность.

• Потребуются ли новые администраторы или существующих администраторов будет достаточно? Если для нового приложения потребуется больше администраторов, будут ли они совместимы с существующими администраторами (поскольку все будут иметь права администратора для всех приложений в среде)?

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

• Будут ли пользователи испытывать трудности с использованием нескольких сред для разных приложений? Это может повлиять на все: от поиска приложения на мобильном устройстве до отчетов самообслуживания, которые должны получать данные из нескольких сред.

Произв. мощность

Каждая среда (кроме пробной среды и среды разработки) при первоначальном развертывании использует 1 ГБ. Емкость распределяется между арендаторами, поэтому ее необходимо выделить тем, кто в ней нуждается.

Сохраните емкость за счет:

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

Экологические группы

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

• По службе или компоненту; например, дерево служб ServiceNow
• Среды разработки и тестирования, а также рабочая среда
• Отделы, бизнес-группы или места возникновения затрат
• По проектам
• По местоположению, если большинство сред в определенном месте имеют схожие потребности в управлении. Это также может помочь обеспечить соответствие аналогичным региональным нормативным и правовым нормам

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

Именование сред и групп

В рамках своей стратегии продумайте, как будут называться среды и группы.

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

• Среды разработки, создаваемые автоматически, соответствуют шаблону <имя пользователя> среда; например, "Среда Эйвери Ховарда". Группы среды не именуются автоматически.

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

• Имя не должно превышать 100 символов. Более короткие имена проще использовать.

Соглашения об именах

Определите единообразные соглашения об именовании.

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

  • Распространенной практикой является включение стадии жизненного цикла в название среды; например, Contoso Dev, Contoso Test, Contoso Prod. Цель состоит в том, чтобы четко разделить среды, имеющие одинаковое содержание, но разные задачи.

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

  Например, вам может потребоваться, чтобы все имена сред или групп сред соответствовали шаблону <этап жизненного цикла>-<регион>-<подразделение>-<цель> (Prod-US-Finance-Payroll).

• Старайтесь, чтобы имена были короткими, содержательными и описательными.

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

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

Активы в среде по умолчанию

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

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

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

Активы в средах Dataverse for Teams

Microsoft Dataverse для Teams позволяет пользователям создавать пользовательские приложения, боты и потоки в Microsoft Teams с помощью Power Apps, Microsoft Copilot Studio и Power Automate. Когда владелец команды добавляет эту возможность в свою команду, создается среда Microsoft Power Platform с базой данных Dataverse для Teams, связанная с их командой. Узнайте, как разработать политики управления для Microsoft Dataverse в средах Teams.

Стратегия среды внутри Microsoft

Microsoft считает себя "нулевым клиентом", потому что она внедряет Power Platform для автоматизации и повышения эффективности своих сотрудников. Следующие цифры показывают масштаб использования во внутреннем клиенте Microsoft.

• 50 000–60 000 активных создателей каждый месяц
• Более 250 000 приложений и более 300 000 потоков
• Больше 20 000 сред

Microsoft переходит от своей предыдущей стратегии среды к одной с помощью последних функций управления Power Platform, включая управляемые среды, группы среды и правила.

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

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

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

• Совместная работа в группе: для пользователей, которые создают инструменты, автоматизацию и процессы для своей рабочей группы. Для этого сценария Microsoft рекомендует использовать среды Dataverse for Teams. Жизненный цикл, управление доступом и метки данных контролируются на уровне группы Microsoft 365, устраняя необходимость тратить время на управление этими пользователями с точки зрения управления Power Platform. Этот уровень использования является следующим шагом в спектре рисков.

• Корпоративный уровень разработки/производства, используемый всеми сотрудниками: для пользователей, создающих инструменты или решения, применяемые в масштабе всей компании. В этих средах могут храниться наиболее конфиденциальные данные, использоваться более мощные соединители и требоваться более строгие меры управления. Этот уровень несет в себе наибольший риск, поэтому на система управления затрачиваются значительные усилия. Требуется ALM, при этом предпроизводственная работа выполняется в средах песочницы, а в рабочих средах разрешены только управляемые решения. Эти среды должны быть связаны с решением ServiceTree, которое обеспечивает повторяющиеся проверки безопасности и конфиденциальности. Правила группы среды настраиваются на основе метаданных и сигналов ServiceTree. Многие группы сред и правила используются для управления этими средами и контроля над ними.

Стратегия управления Microsoft не статична. Она динамична и меняется, чтобы адаптироваться к новым задачам и реализовывать новые функции Power Platform.

Развитие стратегии среды для работы с арендаторами

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

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

Как и во всех процесса развития, разные организации присоединяются к ним на разных этапах, но все они имеют в виду одну и ту же цель. Ниже приведены возможные пути, которые отражают то, где находится ваша организация сегодня.

Начать с

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

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

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

Align

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

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

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

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

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

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

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

Enhance

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

Четко объясните свою стратегию среды сотрудникам в вашей организации

Вы более успешно реализуете стратегию среды для работы с клиентами, если пользователи Power Platform поймут то, чего вы пытаетесь достичь, и будут согласны с этим. Если вы просто запустите свою стратегию без какого-либо разъяснения, пользователи воспримут изменения как ограничения и будут искать способы их обойти.

В рамках разработки или развития вашей стратегии решите, как вы будете информировать пользователей о ключевых элементах стратегии, влияющих на использование ими Power Platform. Им не нужны все технические детали вашей стратегии — только самое необходимое, что поможет им оставаться продуктивными. Например, сообщите:

• Цель среды по умолчанию
• Где им следует создавать новые малокодовые активы
• Как им следует использовать свою личную среду разработки
• Как запрашивать пользовательские среды для конкретных бизнес-единиц или проектов
• Общие политики использования соединителей и способы запроса дополнительных привилегий соединителей для их сред
• Как поделиться тем, что они создают, с другими пользователями
• Обязанности создателя, например:
  • Держите клиента в чистоте. Удалите свои среды, приложения и потоки, если они больше не нужны. Если экспериментируете, используйте тестовые среды.
  • Делитесь с умом. Остерегайтесь чрезмерного совместного использования ваших сред, приложений, потоков и общих подключений.
  • Защищайте данные организации. Избегайте перемещения данных из строго конфиденциальных или конфиденциальных источников данных в незащищенное или внешнее хранилище.
• Когда ваша стратегия изменится, расскажите, как изменения повлияют на ваших пользователей, чтобы они знали, что делать по-другому

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

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

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

Заключение

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

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

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

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

Связанная информация

• Экологические группы
• Маршрутизация по средам
• Обзор и стратегия безопасности
• Безопасность и администрирование малокодовых активов
• Основные понятия решения в ALM