Разработайте стратегию среды для работы с арендаторами, чтобы внедрить Power Platform в большом масштабе
Путь каждой организации к внедрению Microsoft Power Platform является уникальным. Стратегия среды для работы с арендаторами закладывает основу для ускорения использования платформы управляемым и безопасным способом.
В этом техническом документе показано, как согласовать стратегию среды для работы с арендаторами Power Platform с учетом возможностей и видения продукта. Узнайте, как наилучшим образом использовать новейшие функции платформы для реализации стратегии, которая позволит вам внедрить Power Platform в масштабе предприятия.
Заметка
Вы можете сохранить или распечатать этот технический документ, выбрав в браузере элемент Печать, затем выбрав Сохранить как PDF.
Введение
Power Platform дает организациям возможность создавать малокодовые решения для быстрого внедрения инноваций. Эти решения могут быть ориентированы на повышение производительности отдельных лиц и небольших рабочих групп или применяться во всей организации. Они также могут распространяться на бизнес-процессы, включая внешних клиентов и партнеров. Поддерживают эти решения среды Power Platform, в которых создаются, тестируются и используются малокодовые ресурсы. По мере того как организация увеличивает масштабы внедрения Power Platform, реализация хорошей стратегии среды для работы с арендаторами необходима для того, чтобы сделать ее управляемой и безопасной по мере роста числа сред.
Чтобы помочь вам добиться большего успеха, в этой статье рассказывается, как лучше всего использовать доступные функции для разработки вашей первой стратегии среды или развития текущих планов. Мы также изложим наше видение того, как эти функции будут работать вместе и как они будут развиваться для управления Power Platform в большом масштабе. В этом руководстве вы узнаете, как правильно направлять новых пользователей в среды и групповые среды, чтобы последовательно применять управление, правила безопасности и другие важные аспекты стратегии среды для работы с арендаторами. Мы также предоставим подробные инструкции по обеспечению безопасности вашей среды по умолчанию, что является важным первым шагом в реализации стратегии среды.
Хотя для управления Power Platform средами доступно множество Точки зрения, подход, представленный в этой статье, соответствует последнему направлению развития продукта Microsoft и использует текущие функции и запланированные на ближайшее время улучшения. Это обновленное руководство поможет вам убедиться, что вы используете только те функции и параметры среды, которые имеют стратегическое значение для того, как вы планируете управлять средами в больших масштабах. Microsoft
Microsoftвидение стратегии среды арендатора
Многие организации начинают использование Power Platform с приложений и средств автоматизации для повышения личной продуктивности, созданных и работающих в общей центральной среде, называемой средой по умолчанию. Эти ресурсы часто используют только базовые возможности, включенные в Microsoft 365, и не используют все возможности Power Platform. По мере ускорения первоначального внедрения Microsoft организации получают стратегию перехода к среде для внедрения всех Power Platform возможностей в масштабах предприятия. Эти премиум-возможности управления становятся доступными, когда у пользователей есть премиум-лицензия на 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 решении, что упрощает их повысить уровень перенос в другие среды.
Pipelines в Power Platform обеспечивает упрощенный процесс продвижения активов из среды разработки в среду тестирования и производства, делая непрерывную интеграцию и развертывание (CI/CD) доступными для всех производителей.
Каталог Power Platform позволяет разработчикам обмениваться компонентами, такими как приложения и потоки, а также более продвинутыми отправными точками, такими как шаблоны.
Типы сред
В следующей таблице описаны типы сред, которые вы можете создать, их характеристики и предполагаемое использование.
| Тип | Характеристики и применение |
|---|---|
| По умолчанию. | Среда, которая поставляется с каждым арендатором. Многие функции Microsoft 365 используют эту среду для работы с настройками и средствами автоматизации. Эта среда не предназначена для долгосрочной или постоянной работы за пределами личных сценариев продуктивности в Microsoft 365. |
| Производственный экземпляр | Эта среда предназначена для постоянной работы в организации. Рабочие среды поддерживают расширенное хранение резервных копий — от семи до 28 дней. |
| Песочница | Эти нерабочие среды поддерживают действия среды, такие как копирование и сброс. Песочницы лучше всего использовать для сред тестирования и сборки ALM. |
| Среда разработки | Эти специальные среды предназначены для использования в качестве личных рабочих пространств разработчиков, которые изолируют малокодовые ресурсы от пользователей и других создателей. Создатели могут иметь до трех сред разработки. Они не отражаются негативно на емкости вашего арендатора. Среды разработки, которые не использовались в течение 90 дней, автоматически отключаются, а затем удаляются из вашего арендатора, если владелец не отвечает на уведомления. Приложения Dynamics 365 недоступны в средах разработки. |
| Пробная версия | Эти среды предназначены для поддержки краткосрочного тестирования и проверки концепции. Они ограничены одной средой на пользователя. Пробные среды автоматически удаляются из вашего арендатора через короткий период времени. |
| Microsoft Dataverse for Teams | Эти среды создаются автоматически, когда вы создаете приложение в Teams или устанавливаете приложение из каталога приложений. Модель безопасности для этих сред соответствует рабочей группе, с которой они связаны. |
| Поддержка | Это специальные среды, созданные службой поддержки, чтобы инженеры могли устранять неполадки. Microsoft Эти среды не отражаются негативно на емкости вашего арендатора. |
Когда вы составляете общую стратегию среды для работы с арендаторами, различные типы подходят для поддержки рекомендаций по стратегии.
Управляемые среды
Среды имеют базовый набор функций и характеристик в зависимости от типа среды. Управляемые среды расширяют базовые функции, предоставляя набор возможностей премиум-класса, которые позволяют администраторам легче управлять Power Platform в большом масштабе, обеспечивая больший контроль, меньшие усилия и больше аналитики. Эти возможности появляются, когда вы настраиваете среду как управляемую.
В следующей таблице перечислены функции управляемых сред, доступные на момент написания этой статьи. Новые функции добавляются часто, поэтому актуальный список можно найти в этой документации. Хотя все функции могут помочь вам разработать стратегию среды, функции, выделенные курсивом, более актуальны для стратегии, описанной в этой статье.
| Больше видимости | Больше контроля | Меньше усилий |
|---|---|---|
| Информация об использовании Административный дайджест Отчеты о лицензиях Просмотр политики данных Экспорт данных в Azure Application Insights Описания для всех приложений, созданные искусственным интеллектом |
Ограничения на совместное использование Политики данных для потоков рабочего стола Проверка решения Приветственный контент создателя IP-брандмауэр Привязка IP-cookie Ключи, управляемые клиентом Ящик для хранения вещей клиентов Расширенные резервные копии |
Простая активация Power Platform трубопроводы Маршрутизация среды Группы и правила окружающей среды Power Platform консультант |
Автоматическое требование лицензий
Политики автоматического получения автоматизируют назначение Power Apps и Power Automate лицензий пользователям, когда им требуется использовать определенные приложения или функции. Служба автоматизации может помочь сократить количество используемых лицензий и избежать накладных расходов, связанных с назначением лицензий вручную.
После настройки политики любому пользователю в организации, которому необходима индивидуальная лицензия Power Apps, она автоматически предоставляется при следующих условиях:
Если пользователь без отдельной лицензии Power Apps запускает приложение, требующее премиум-лицензии, система автоматически назначает пользователю лицензию Power Apps на пользователя.
Если пользователь без отдельной лицензии Power Apps запускает приложение в управляемой среде, система автоматически назначает пользователю лицензию Power Apps на пользователя.
Подобным образом, после настройки политики любому пользователю в организации, которому необходима индивидуальная лицензия Power Automate, она автоматически предоставляется при следующих условиях:
Пользователь запускает, сохраняет или включает облачный поток премиум-класса с помощью RPA с сопровождением (роботизированной автоматизации процессов).
Пользователь запрашивает премиум-лицензию на Power Automate.
Мы рекомендуем настроить автоматическое требование лицензий, если ваша стратегия среды включает управляемые среды. Пользователи приложений и потоков будут сталкиваться с наименьшими трудностями при лицензировании, и вы будете использовать лицензии только для пользователей, которые активно запускают приложения или используют Power Automate.
Группы и правила среды
Так как внедрение Power Platform в вашем арендаторе развивается, может увеличиваться количество сред, требующих администрирования и управления. По мере увеличения количества сред становится все сложнее обеспечить применение согласованных настроек и политик управления в средах. Функция групп сред упрощает эту задачу, позволяя создавать именованные группы и связывать с ними среды, например размещать связанные документы в папке с файлами.
При обдумывании использования групп сред учитывайте следующие соображения:
Для включения в группу необходимо управлять средой.
Среда может одновременно находиться только в одной группе.
Среду можно перемещать из одной группы в другую.
Среды в группе могут относиться к нескольким географическим регионам.
Группы не могут содержать другие группы.
Чтобы помочь вам применять согласованные параметры и управление, в группах сред можно настроить и включить одно или несколько из следующих правил:
Элементы управления общим доступом для приложений на основе холста
Аналитика по использованию
Содержимое приветствия создателя
Принудительное использование средства проверки решения
Хранение резервных копий
Описания, созданные ИИ
Правило становится активным после публикации. Активные правила применяются ко всем средам, связанным с группой.
Когда групповое правило управляет параметром, отдельные параметры среды блокируются. Единственный способ изменить их — изменить правило. Если среда удаляется из группы, настройки группы сохраняются, но теперь администратор среды может их изменить. Это важно для стратегии среды, поскольку гарантирует, что администратор среды не сможет переопределить политики, которые вы установили для группы.
Использование групп сред позволяет вам логически организовать ваши среды, подобно вашей организационной структуре, иерархии услуг и продуктов или другим структурам, которые мы рассмотрим позже. Следующая диаграмма представляет собой концептуальный пример того, как организация Contoso может организовать группы своей среды.
Рисунок: Концептуализация стратегии защиты окружающей среды для арендатора Contoso.
Планируя настройку правил, подумайте, что можно применить на каждом уровне концептуальной иерархии. Хотя вы пока не можете настроить иерархию групп, вы можете использовать комбинацию соглашений об именах и конфигурацию правил для реализации концептуального проекта. Например, учитывая представленную ранее концепцию арендатора Contoso, на следующем рисунке показаны группы сред, которые организация может использовать для реализации своего проекта.
Рисунок: Пример внедрения концептуальных групп среды в фактического арендатора
Далее в этой статье мы рассмотрим дополнительные способы использования групп сред в рамках стратегии среды для работы с арендаторами.
Маршрутизация среды по умолчанию
Ключевая часть стратегии среды, которую мы описываем в этой статье, — отучить создателей от создания ресурсов в среде по умолчанию. Функция маршрутизации среды перенаправляет создателей в их собственную среду разработки и по мере необходимости создает новые среды разработки.
Рисунок: Создатель автоматически перенаправляется в персональную среду среда разработки вместо среды по умолчанию при сборке приложений.
Среды разработки, созданные путем маршрутизации, управляются по умолчанию. Пользователи с лицензиями плана разработчика ограничены в создании и просмотре ресурсов в среде. Для запуска ресурсов от имени пользователя им необходима соответствующая лицензия.
Маршрутизацию среды можно использовать отдельно, но рекомендуется использовать ее с группами среды. При таком использовании любая созданная среда связывается с группой, которую вы назначаете для размещения всех новых сред разработки, что гарантирует немедленное попадание в нее ваших политик управления.
Создателям автоматически присваивается роль безопасности, которая делает их администраторами среды разработки. Если среда является частью группы среды, создатель — как администратор среды — не может изменять параметры среды, поскольку они управляются правилами группы среды. Любые изменения могут вносить только администраторы, имеющие право изменять правила группы.
Вы можете установить еще больший контроль двумя способами. Во-первых, вы можете запретить создание сред разработки вручную в настройках арендатора. Если этот параметр установлен, создатели не могут сами создавать среды на портале администрирования. Они также не получат среду, автоматически созданную политикой маршрутизации. Во-вторых, вы можете указать группу безопасности в политике маршрутизации, чтобы ограничить круг лиц, которые могут автоматически создавать среду.
Первоначально маршрутизация среды поддерживает маршрутизацию новых и существующих создателей из среды по умолчанию, когда они используют make.powerapps.com. Со временем другие службы Power Platform будут поддерживать функцию маршрутизации среды.
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 управляется по умолчанию. Однако вы можете определить несколько сред размещения в своем арендаторе, которым вы управляете, что позволит вам удовлетворить уникальные требования.
Каталог в Power Platform
Организации, в которых разработчики и создатели создают и совместно используют компоненты, такие как приложения, потоки и шаблоны, которые являются более продвинутыми отправными точками, как правило, получают больше пользы от Power Platform. Power Platform Каталог позволяет производителям более эффективно обмениваться своими компонентами и шаблонами в разных средах.
Каталог устанавливается в среде и может быть установлен вместе с узлом конвейера в той же среде. Также можно удовлетворить уникальные требования к сегментации ресурсов, имея несколько сред с установленным каталогом.
Дорожная карта функций
Поскольку Microsoft функции Power Platform поддержки управления и администрирования продолжают развиваться, вы можете следить за ними в планировщике выпусков. Вы будете знать, что запланировано, что будет в предстоящей волне выпусков и что вы можете попробовать уже сейчас. Вы даже можете создать свой собственный план выпуска, сохранив элементы, которые вы хотите отслеживать.
Основа стратегии среды в масштабе предприятия
Мы обсудили наше видение стратегии среды для работы с арендаторами в масштабе предприятия и ключевые функции среды, которые ее поддерживают. Теперь мы рассмотрим, как вы можете использовать эти функции вместе в рамках стратегии среды. Ваша стратегия должна основываться на уникальных требованиях вашей организации, поэтому давайте начнем с простого примера, прежде чем перейти к тому, как адаптировать стратегию для удовлетворения ваших потребностей.
В этом примере руководство компании Contoso хочет предоставить сотрудникам возможность воспользоваться преимуществами Power Platform и определило следующие общие требования:
Сотрудники должны иметь возможность создавать автоматизированные процессы утверждения документов и другие настройки Power Platform с помощью Microsoft 365.
Сотрудники должны иметь возможность создавать приложения Power Apps и средства автоматизации Power Automate для повышения личной продуктивности.
Создатели, работающие над приложением «Средство отслеживания соответствия нормативным требованиям» компании, должны иметь возможность разрабатывать и поддерживать его.
Для поддержки этих требований рабочая группа администраторов и управления Contoso разработала следующую топологию среды:
Рисунок: Предлагаемая топология среды для масштабного проекта Contoso Power Platform .
Давайте подробно рассмотрим эту диаграмму топологии среды.
Среда по умолчанию используется для создания настроек повышения производительности 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. Однако в рамках рекомендуемой стратегии среды лучше всего свести к минимуму его использование. Вместо этого создателям следует создавать свои собственные изолированные среды. Хотя вы не можете заблокировать доступ к среде по умолчанию, вы можете свести к минимуму действия, которые в ней можно делать.
Во-первых, используйте маршрутизацию среды, чтобы направить создателей в их собственное рабочее пространство для создания малокодовых ресурсов.
Проверьте, у кого есть доступ администратора к среде по умолчанию, и ограничьте его ролями, которым он необходим.
Рассмотрите возможность переименования среды по умолчанию во что-то более информативное, например «Личная продуктивность».
Установите политику предотвращения потери данных (DLP) для среды по умолчанию, которая блокирует новые соединители и ограничивает создателей использованием только базовых, неблокируемых соединителей. Переместите все соединители, которые нельзя заблокировать, в группу бизнес-данных. Переместите все соединители, которые могут быть заблокированы, в группу заблокированных данных.
Создайте правило для блокировки всех шаблонов URL, используемых пользовательскими коннекторами.
Защита среды по умолчанию должна быть приоритетом. Обеспечьте это вместе с безопасностью на уровне арендатора как часть первого шага в реализации стратегии вашей среды. Без этого у создателей будет больше возможностей добавлять активы по умолчанию. Когда это реализовано вместе с маршрутизацией среды, создателям предлагается использовать свою собственную среду.
Защитите другие среды
Если ваша организация похожа на большинство других, у вас есть несколько сред в дополнение к среде по умолчанию. Уровень безопасности, который требуется для каждой из них, может варьироваться в зависимости от приложений и содержащихся в них данных. В средах разработки обычно действуют более мягкие правила, чем в рабочих средах. Некоторые рабочие среды требуют максимально возможной защиты.
В рамках разработки стратегии среды определите общие уровни безопасности для ваших сред и функции, защищающие каждый уровень, как показано в следующем примере.
Рисунок: Пример трех уровней безопасности среды и функций безопасности, применяемых к средам на каждом уровне.
Включите определенные вами уровни безопасности в стратегию вашей группы и, где это возможно, используйте правила для включения функций безопасности в ваших средах. В этом примере правило ограничивает общий доступ во всех средах, имеющих нормальный или средний уровень безопасности.
Согласуйте среду с вашей стратегией предотвращения потери данных
Политики данных — еще одна важная часть общих усилий по управлению службами, используемыми малокодовыми ресурсами в среде. В группах среды нет правила применения политики DLP к среде. Однако вы можете согласовать свою стратегию DLP с группами среды. Например, вы можете создать политику DLP с тем же или похожим именем, что и группа среды, и применить ее к средам в этой группе.
Узнайте больше о том, как разработать стратегию DLP.
Рисунок: В этом примере среды в группе Personal Dev следуют политике DLP, которая блокирует все не-Microsoft коннекторы.
Адаптируйте стратегию среды к вашей организации
В предыдущих разделах мы описали наше видение того, как организации могут управлять средой в большом масштабе. Мы рассмотрели основные функции, их вклад в стратегию среды и то, как может выглядеть топология базовой среды, в которой они используются. Мы привели примеры того, как опираться на эту основу для реализации распространенных сценариев. Поскольку каждая организация уникальна, следующим шагом будет адаптация стратегии среды, отвечающей потребностям вашей организации.
Начинайте работу на том этапе технологического развития, на котором вы находитесь
Независимо от того, является ли ваша организация новичком в использовании решения Power Platform или использует его уже много лет, первым шагом является оценка вашей ситуации. Оцените в целом, что находится в вашей среде по умолчанию, какие еще среды у вас есть и для чего они используются. Часто стратегия среды разрабатывается как часть общих усилий по установлению управления Power Platform в организации. Если это так, возможно, вы уже сформировали некоторое видение управления, необходимое для адаптации стратегии для вашей организации.
Информация об организации, которую вам следует знать, включает в себя:
Каково видение того, как Power Platform будет использоваться в организации?
Кто в организации будет создавать малокодовые активы?
Вам необходимо принять несколько ключевых решений:
Как создатели получат новые среды?
Будете ли вы группировать ваши среды, и если да, то как?
Какие уровни безопасности необходимы для различных сред и как среды классифицируются?
Как вы решите, будет ли приложение, средство автоматизации или Copilot использовать существующую среду или новую?
Есть ли какие-либо расхождения между базовыми функциями платформы и вашими требованиями, требующими специального процесса управления?
Как вы будете обращаться с любыми существующими активами в среде по умолчанию?
Есть ли у вас стратегия политики защиты от потери данных для арендатора и среды, и если да, то как она согласуется со стратегией среды, которую вы создаете?
Вы также можете найти вдохновение в облачных операционных моделях, которые являются частью Cloud Adoption Framework для Azure.
Заполните пробелы с помощью платформы
Почти всегда вы обнаружите требования, которым не удовлетворяют встроенные возможности платформы. Оценивая эти пробелы, рассмотрите следующие возможные результаты вашей оценки:
Пробел допустим.
Пробел можно заполнить с помощью начального набора центра передовых технологий Power Platform.
Этот пробел можно заполнить, используя возможности платформы, такие как API, соединители и пользовательские приложения, а также средства автоматизации.
Этот пробел можно заполнить с помощью стороннего инструмента или приложения.
Начальный набор центра передовых технологий (CoE)
Начальный набор центра передовых технологий Power Platform представляет собой набор компонентов и инструментов, которые призваны помочь вашей организации внедрить и поддержать использование Power Platform. Ключевым аспектом начального набора является его способность собирать данные об использовании платформы в ваших средах, которые могут быть полезны при разработке и развитии стратегии вашей среды.
Например, панель мониторинга «Среды Power BI» предлагает обзор, который поможет вам понять, какие среды существуют в вашем арендаторе, кто их создал и какие ресурсы они содержат.
Рисунок: Панель инструментов «Окружения» Power BI.
В набор входят отправные точки или источники вдохновения, например, процесс, который создатели могут использовать для запроса новых сред и внесения изменений в политики DLP для их сред.
Рисунок: Блок-схема, иллюстрирующая процесс управления окружающей средой в стартовом наборе CoE.
Возможности программирования и расширяемость платформы
Одна из замечательных особенностей малокодовой платформы заключается в том, что вы можете использовать ее для создания приложений, средств автоматизации, порталов и помощников, которые помогут вам управлять ею. У вас также есть доступ к инструментам более низкого уровня, которые можно использовать для заполнения пробелов при поддержке вашей стратегии среды.
Для создания приложений и потоков можно использовать следующие соединители:
Вы можете использовать интерфейс командной строки 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).
Старайтесь, чтобы имена были короткими, содержательными и описательными.
Подумайте о том, как ваши группы будут развиваться и расти с течением времени, и убедитесь, что ваше соглашение об именовании соответствует этим меняющимся потребностям.
Избегайте включения конфиденциальной информации в имена. Они могут быть видны любому, у кого есть доступ к центру администрирования.
Активы в среде по умолчанию
Ваша стратегия среды должна поощрять (или обеспечивать) использование персональных сред разработки, чтобы уменьшить количество того, что создается в среде по умолчанию. Однако вам следует проверить, что создатели уже создали в среде по умолчанию, и оценить, как обрабатывать каждый вариант использования. Целесообразно ли оставить среду по умолчанию или ее следует перенести в другую среду?
Ключевой частью выполнения этих гигиенических мер является определение приложений, которые широко используются в вашей организации и должны иметь собственную защищенную среду разработки, отдельную от рабочей среды.
В следующей таблице приведены примеры вариантов использования и действий по миграции. В конечном итоге вашей организации необходимо определить собственные варианты использования и факторы риска, связанные с оставлением активов в среде по умолчанию. Узнайте больше о том, когда следует перемещать активы из среды по умолчанию.
| Среда по умолчанию | Миграционные действия |
|---|---|
| Личная продуктивность Microsoft 365 | Остается в среде по умолчанию. |
| Активы одного создателя, которые недавно использовались, но не используются совместно | Переместите в индивидуальную среду разработки владельца. |
| Активы одного создателя, которые недавно использовались и используются совместно | Переместите в индивидуальную среду разработки владельца и выполните запуск из общей рабочей среды. |
| Активы разных создателей, которые недавно использовались и используются совместно | Переместите в общую среду разработки и выполните запуск из общей рабочей среды. |
| Активы, которые в последнее время не использовались | Уведомите владельца и переместите активы в карантин, если не будет ответа. |
Активы в средах Dataverse for Teams
Microsoft Dataverse for Teams позволяет пользователям создавать собственные приложения, ботов и потоки с помощью Microsoft Teams , Power Apps, Microsoft Copilot Studio и Power Automate. Когда владелец рабочей группы добавляет эту возможность в свою рабочую группу, среда Microsoft Power Platform с базой данных Dataverse for Teams создается и связывается с их рабочей группой. Узнайте, как разработать политику управления для управления Microsoft Dataverse for 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. Часто это называется новым проектом. Вы начинаете свой путь с самого удобного этапа, поскольку вам не нужно беспокоиться о существующих средах или о влиянии новых политик на то, как люди в вашей организации используют Power Platform. Это лучшее время для реализации стратегии среды в масштабах предприятия, соответствующей функциям продукта и передовым практикам.
Изучите ключевые особенности и стратегии среды, описанные в этой статье. Разберитесь в ключевых темах, а также соображениях и решениях, необходимых для разработки и реализации стратегии среды для работы с арендаторами, которая наилучшим образом соответствует вашим требованиям.
Создание прочного фундамента сейчас является важным, чтобы избежать выхода из-под контроля ситуации, которая может возникнуть позже, если вы начнете без определенной стратегии. Запланируйте быстрое ускорение использования Power Platform, но избегайте искушения перепроектировать свою стратегию среды, повышая сложность без необходимости в этом. Помните, что это путь, и вы можете продолжать развивать свою стратегию по мере изменения ваших потребностей.
Align
Ваша организация имеет и реализует стратегию среды, которую необходимо изменить, чтобы она соответствовала новым функциям и передовым практикам Power Platform. Часто это называется модернизацией существующего проекта. В отличие от организаций, которые только начинают свою деятельность, вам необходимо учитывать влияние изменения стратегии среды на вашу организацию.
Изучите ключевые особенности среды и стратегии, описанные в этой статье, и оцените, что необходимо для развития вашей стратегии, чтобы она соответствовала ей. Обычно все, что необходимо, — это добавочные корректировки. По возможности планируйте развертывание изменений, чтобы минимизировать влияние на ваших пользователей.
Следующие предложения представляют собой типичные добавочные изменения, которые вы можете реализовать:
Чтобы начать согласование, не затрагивая существующие среды, создайте группу сред, содержащую новые среды разработки, и установите правила управления ими. Включите маршрутизацию среды, чтобы все новые среды разработки создавались в назначенной группе.
Оцените свою стратегию группирования и, при необходимости, создайте группы для поддержки существующих сред. Установите правила для тех групп, которые соответствуют существующим ограничениям и исключениям. Переместите существующие среды в эти группы.
Определите широко популярные приложения, которые создаются и используются в среде по умолчанию. Используйте конвейеры для публикации их в рабочей среде, где пользователи вашей организации смогут их запускать. Затем приступайте к переносу разработки этих приложений либо в индивидуальную среду разработки, либо в выделенную среду разработки.
Создайте план по выявлению, помещению в карантин и удалению неиспользуемых активов в среде по умолчанию.
Улучшить
Стратегия среды, которую вы реализуете, уже соответствует новейшим функциям и лучшим практикам, но ваша организация хочет добавить больше элементов управления или функций.
Четко объясните свою стратегию среды сотрудникам в вашей организации
Вы более успешно реализуете стратегию среды для работы с арендаторами, если пользователи Power Platform поймут то, чего вы пытаетесь достичь, и будут согласны с этим. Если вы просто запустите свою стратегию без какого-либо разъяснения, пользователи воспримут изменения как ограничения и будут искать способы их обойти.
В рамках разработки или развития вашей стратегии решите, как вы будете информировать пользователей о ключевых элементах стратегии, влияющих на использование ими Power Platform. Им не нужны все технические детали вашей стратегии, а только самое необходимое, что поможет им оставаться продуктивными, например:
Цель среды по умолчанию
Где им следует создавать новые малокодовые активы
Как им следует использовать свою личную среду разработки
Как запрашивать пользовательские среды для конкретных бизнес-единиц или проектов
Общие политики использования соединителей и способы запроса дополнительных привилегий соединителей для их сред
Как поделиться тем, что они создают, с другими пользователями
Обязанности создателей. Например:
Держите клиента в чистоте. Удалите свои среды, приложения и потоки, если они больше не нужны. Если экспериментируете, используйте тестовые среды.
Делитесь с умом. Остерегайтесь чрезмерного совместного использования ваших сред, приложений, потоков и общих подключений.
Защищайте данные организации. Избегайте перемещения данных из строго конфиденциальных или конфиденциальных источников данных в незащищенное или внешнее хранилище.
Когда ваша стратегия изменится, расскажите, как изменения повлияют на ваших пользователей, чтобы они знали, что делать по-другому
Хорошее начало — это включить приветственное содержимое для создателей в группе среды, куда добавляются новые создатели.
Рисунок: Используйте приветственный контент, чтобы помочь новым создателям добиться успеха.
Еще один эффективный подход к общению с вашими пользователями — создание внутреннего центра Power Platform. Этот центр может быть местом, где люди могут сотрудничать над проектами, делиться идеями и открывать новые способы применения технологий для достижения большего. В центре вы можете делиться более подробной информацией о стратегии вашей среды, актуальной для ваших пользователей. Узнайте, как создать внутренний Power Platform хаб.
Заключение
В этой статье мы рассмотрели функции, которые помогут вашей организации управлять средами Power Platform в масштабе предприятия и добавить их в свою стратегию среды для работы с арендаторами.
По мере того как ваша организация будет внедрять решение Power Platform и ускорять его использование, потребность в средах может быстро меняться. Вам нужен гибкий подход, который поможет вашей стратегии среды идти в ногу с изменениями и продолжать соответствовать меняющимся требованиям системы управления вашей организации.
Ключевым фактором успеха стратегии создания среды для работы с арендаторами является общение с создателями и пользователями и получение их поддержки. Убедитесь, что люди, создающие малокодовые приложения и средства автоматизации, знают, как соблюдать стратегию среды вашей организации и где им следует создавать свои малокодовые активы.
Путь каждой организации к внедрению Power Platform является уникальным. Мы представили несколько идей, которые помогут вам начать работу правильно. Ваша Microsoft команда по работе с клиентами или Power Platform партнер могут помочь вам создать более индивидуальную стратегию среды арендаторов для вашей организации.