Поділитися через


Розробіть стратегію середовища орендарів, яку потрібно впровадити Power Platform в масштабі

Шлях кожної організації до впровадження Microsoft Power Platform унікальний. Стратегія середовища орендарів закладає основу, яка допомагає прискорити використання в керований і безпечний спосіб.

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

Нотатка

Цей офіційний документ можна зберегти або надрукувати, вибравши пункт Друк у браузері, а потім вибравши Зберегти як PDF.

Вступ

Power Platform дає змогу організаціям створювати з базовим кодуванням рішення для швидких інновацій. Ці рішення можуть бути зосереджені на продуктивності окремих осіб і невеликих команд або застосовуватися в усій організації. Вони також можуть поширюватися на бізнес-процеси, включаючи зовнішніх клієнтів і партнерів. Ці рішення підтримуються Power Platform середовищами, де створюються, тестуються та використовуються з базовим кодуванням ресурси. У міру того, як організація все частіше приймає її Power Platform, впровадження хорошої стратегії середовища орендарів має важливе значення для того, щоб зробити її керованою та безпечною зі зростанням кількості середовищ.

Щоб допомогти вам досягти більшого успіху, ця стаття допоможе вам, як найкраще використовувати доступні функції для створення вашої першої екологічної стратегії або розвитку ваших поточних планів. Ми також виклали наше бачення того, як ці функції мають працювати разом і як вони розвиватимуться для масштабного керування Power Platform . У цьому посібнику ми визначаємо, як правильно спрямовувати нових користувачів до середовищ і групових середовищ, щоб послідовно застосовувати управління, правила безпеки та інші важливі аспекти стратегії середовища клієнта. Ми також надаємо детальні кроки для захисту вашого середовища за замовчуванням, що є критично важливим першим крок у реалізації екологічної стратегії.

Незважаючи на те, що для керування Power Platform середовищами доступно багато Перспективи, підхід, наведений у цій статті, узгоджується з останніми напрямками продуктів корпорації Майкрософт і використовує поточні функції та заплановані вдосконалення на найближчу перспективу. Ці оновлені вказівки можуть допомогти вам переконатися, що ви використовуєте лише ті функції середовища та параметри, які є стратегічними для того, щоб корпорація Майкрософт мала намір керувати середовищами в масштабі.

Бачення стратегії середовища орендарів Microsoft

Багато організацій починають свій Power Platform шлях із програм для особистої продуктивності та автоматизацій, створених і запущених у спільному центральному середовищі, яке називається середовищем за замовчуванням. Ці ресурси часто використовують лише базові можливості, що входять до комплекту Microsoft 365 , і не використовують повні можливості Power Platform. У міру того, як це початкове впровадження прискорюється, корпорація Майкрософт надає організаціям можливість розробити стратегію середовища для впровадження повних 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 in 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

Описи, створені штучним інтелектом для всіх додатків
Обмеження на спільний доступ

Політики даних для потоків робочого столу

Перевірка рішень

Вітальний контент Maker

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 збільшенням кількості орендарів зростає і кількість середовищ, які потребують адміністрування та управління. Зі збільшенням кількості середовищ тим складнішим стає забезпечення того, щоб ви застосували узгоджені налаштування та політики керування середовищами. Функція груп середовища спрощує це, дозволяючи створювати іменовані групи та пов’язувати з ними середовища, наприклад розміщувати пов’язані документи в папці з файлами.

Роздумуючи про використання груп середовища, пам’ятайте про такі міркування:

  • Для включення в групу потрібно керувати середовищем.

  • Одночасно середовище може бути лише в одній групі.

  • Середовище можна переміщувати з однієї групи в іншу.

  • Середовища в групі можуть належати до кількох географічних регіонів.

  • Групи не можуть містити інші групи.

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

  • Спільне керування для програм canvas

  • Аналітичні висновки щодо використання

  • Вміст привітання для розробника

  • Застосування засобу перевірки рішень

  • Резервне утримання

  • Описи, які створює ШІ

Правило стає активним після публікації. Активні правила застосовуються до всіх середовищ, пов’язаних із групою.

Коли групове правило керує параметром, індивідуальні параметри середовища блокуються. Єдиний спосіб змінити їх – це змінити правило. Якщо середовище буде видалено з групи, воно збереже налаштування групи, але тепер адміністратор середовища може їх змінити. Це важливо для стратегії середовища, оскільки це гарантує, що адміністратор середовища не зможе замінити політики, які ви встановили для групи.

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

Концептуалізація стратегії середовища для орендаря 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 визначення кожного конвеєра в хост-середовищі, яким корпорація Майкрософт керує за промовчанням. Однак ви можете визначити кілька хост-середовищ у своєму клієнті, яким ви керуєте, що дозволить вам маркер унікальні вимоги.

Каталог в Power Platform

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

Каталог встановлюється в середовищі і може бути встановлений разом з хостом конвеєра в тому ж середовищі. Також можна маркер унікальні вимоги до сегментації ресурсів, маючи кілька середовищ, у яких встановлено каталог.

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

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

Обґрунтування екологічної стратегії в масштабі підприємства

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

У цьому прикладі керівництво Contoso хоче надати співробітникам можливість скористатися перевагами Power Platform та визначило такі вимоги високого рівня:

  • Співробітники повинні вміти будувати автоматизовані процеси узгодження документів та інші Power Platform налаштування за допомогою Microsoft 365.

  • Співробітники повинні вміти будувати Power Apps і Power Automate автоматизувати для підвищення своєї особистої продуктивності.

  • Виробники, які працюють над додатком Compliance Tracker компанії, повинні вміти його розробляти та підтримувати.

Щоб підтримати ці вимоги, команда адміністраторів і управління Contoso розробила наступну топологію середовища:

Діаграма топології середовища з чотирма групами середовищ: Розробка, спільна розробка, UAT і Production, з логотипами для додатків, Power Platform які кожна з них повинна підтримувати

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

Давайте детально розглянемо цю діаграму топології середовища.

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

Лише адміністратори можуть створювати пробні, пісочні та виробничі середовища. Виробники використовують спеціальну форму Microsoft або інший процес, щоб надіслати запит на нове середовище. Стартовий Microsoft Power Platform набір Center of Excellence (CoE) включає запит на середовище, який можна використовувати.

Створюється чотири групи середовищ: Development, Shared Development, UAT (приймальне тестування користувача) і Production.

  • Політика маршрутизації середовищ, встановлена для групи розробки, спрямовує творців із середовища за замовчуванням у їхні власні, середовища розробників. Коли створюються нові середовища розробки, вони автоматично пов’язуються з групою розробників і застосовуються її правила.

  • Група «Спільна розробка» підтримує середовища, які містять проєкти з кількома виробниками.

  • Група UAT містить середовища, які використовуються для тестування ресурсів перед їх переходом у виробництво.

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

Те, чого не вистачає в цій запропонованій топології, — це конвеєри для автоматизації просування між середовищами розробки, тестування та виробництва. Давайте зараз їх додамо.

Діаграма однієї топології середовища з додаванням хост-середовища конвеєра та пайплайнів між хостом і розробкою, UAT та продакшн-середовищами

Малюнок: Та сама топологія середовища з конвеєрами, що з’єднують хост-середовище конвеєра з середовищами розробки, тестування та виробництва.

У переглянутій діаграмі топології середовища ми додали хост-середовище конвеєра та два конвеєри. Один конвеєр переміщує ресурси з розробки в тестування, а потім у виробничі середовища. Правило конвеєра в групі «Розробка» буде змінено для використання цього конвеєра. Інший пайплайн переміщує ресурси зі спільного середовища розробки для тестування, а потім у продакшн. Правило воронки продажів у групі «Спільна розробка» буде змінено для використання цього конвеєра.

Ця базова стратегія середовища забезпечує основу, на яку ви можете спиратися для інших варіантів використання, які ми розглянемо далі.

Екологічні стратегії для конкретних сценаріїв

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

Контролюйте, які виробники можуть створювати середовища для розробників

За умовчанням будь-хто, хто має Power Platform ліцензію Premium, ліцензію плану розробника або 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-політики та Customer Lockbox

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

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

Узгоджуйте середовище зі своєю стратегією запобігання втраті даних

Політика щодо даних є ще однією важливою частиною загальних зусиль з управління для контролю за послугами, які використовуються з базовим кодуванням ресурсами в навколишньому середовищі. Групи середовищ не мають правила для застосування політики DLP до середовища. Однак ви можете узгодити свою стратегію DLP з групами оточення. Наприклад, можна створити політику DLP з такою самою або подібною назвою, що й група середовищ, і застосувати її до середовищ у цій групі.

Дізнайтеся більше про те, як створити стратегію DLP.

Діаграма, що ілюструє взаємозв’язок між групами середовищ і політиками запобігання втраті даних з подібними назвами, які до них застосовуються

Малюнок: У цьому прикладі середовища в групі особистих розробників дотримуються політики DLP, яка блокує всі з’єднувачі, що не належать Microsoft.

Адаптуйте екологічну стратегію для вашої організації

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

Почніть з того місця, де ви зараз

Незалежно від того, чи є ваша організація новачком Power Platform або використовує її роками, перше, крок – оцінити свою ситуацію. Оцініть на високому рівні, що знаходиться у вашому середовищі за замовчуванням, які інші середовища у вас є і для чого вони використовуються. Часто екологічна стратегія розробляється як частина загальних зусиль по встановленню управління в Power Platform організації. Якщо це так, можливо, ви вже сформулювали певне бачення управління, необхідне для розробки стратегії для вашої організації.

Інформація про організацію, яку ви повинні знати, включає:

  • Яке бачення того, як Power Platform буде використовуватися в організації?

  • Хто в організації буде нарощувати з базовим кодуванням активи?

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

  • Як мейкери отримають нове середовище?

  • Чи будете ви групувати своє оточення, і якщо так, то яким чином?

  • Які рівні безпеки необхідні для різних середовищ і як середовища класифікуються?

  • Як ви вирішите, чи буде програма, автоматизація або допоміжний використовувати існуюче середовище або нове?

  • Чи є якісь прогалини між базовими функціями платформи та вашими вимогами, які вимагають індивідуального процесу управління?

  • Як ви будете маркер наявні активи в середовищі за замовчуванням?

  • Чи є у вас стратегія DLP для орендарів і середовищ, і якщо так, то як вона узгоджується зі стратегією середовища, яку ви створюєте?

Ви також можете знайти натхнення в хмарних операційних моделях , які є частиною Cloud Adoption Framework for Azure.

Заповніть прогалини за допомогою платформи

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

  • Розрив допустимий.

  • Прогалину можна заповнити за допомогою стартового набору Power Platform Center of Excellence.

  • Прогалину можна заповнити за допомогою можливостей платформи, таких як API, конектори та кастомні додатки або автоматизації.

  • Прогалину можна заповнити за допомогою стороннього інструменту або програми.

Стартовий пакет CoE

Стартовий Power Platform набір Center of Excellence — це колекція компонентів та інструментів, які розроблені, щоб допомогти вашій організації прийняти та підтримати використання Power Platform. Ключовим аспектом стартового набору є його здатність збирати дані про використання платформи у ваших середовищах, що може бути корисним під час розробки та розвитку вашої екологічної стратегії.

Наприклад, приладна дошка «Середовища Power BI » пропонує огляд, який допоможе вам зрозуміти, які середовища існують у вашому клієнті, хто їх створив і які ресурси вони містять.

Скріншот інформаційної панелі огляду середовищ із Power BI зображенням числових плиток, діаграм і фільтрів звітів

Малюнок: Інформаційна панель середовищ в. Power BI

Набір включає відправні точки або натхнення, такі як процес, який виробники можуть використовувати для запиту нових середовищ і змін у політиках DLP для своїх середовищ.

Блок-схема, що ілюструє ролі адміністраторів і мейкерів, а також дії в процесі запиту нового середовища або змінення політики DLP, застосованої до середовища

Малюнок: Блок-схема, що ілюструє процес управління середовищем у стартовому наборі Ради Європи.

Програмованість і розширюваність платформи

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

Для створення додатків і ланцюжків можна використовувати такі сполучники:

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

За допомогою командлетів PowerShell для Power Platform творців і адміністраторів можна автоматизувати багато завдань моніторингу та керування.

DLP Power Platform SDK може допомогти вам керувати політикою захисту даних клієнтів і середовища.

Рекомендації щодо передової практики

У цьому розділі статті ми спираємося на рекомендації в розділах «Основа» та «Сценарії».

Нові середовища

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

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

Як загальна рекомендація, коли це можливо, середовище розробки має бути одноцільовим, одноразовим і легко відтворюватися.

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

Оцінюючи робоче середовище програми, пам’ятайте про наведені нижче міркування.

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

  • Чи існують особливі вимоги до відповідності або нормативним вимогам до розділення даних? Наприклад, чи вимагає чутливість даних їх ізоляції? Чи є вимога, згідно з якою дані не можуть бути включені до інших даних?

  • Чи є дані дуже конфіденційними чи чутливими? Чи завдасть ексфільтрація грошової або репутаційної шкоди організації? Ізоляція в окремому середовищі може забезпечити більший контроль над безпекою.

  • Чи потрібні програмі дані з інших програм і чи потрібно їх розміщувати разом? Наприклад, два додатки, які використовують вашу таблицю клієнтів, мають бути розміщені разом. Їх відокремлення створило б зайві копії даних і створило б проблеми з їх підтриманням.

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

  • Чи більшість користувачів знаходяться в тому ж регіоні, що і навколишнє середовище? Якщо середовище розташоване в регіоні EMEA, але більшість користувачів додатка проживають у США, спільне використання середовища може не забезпечити найкращу продуктивність.

  • Чи будуть потрібні нові адміністратори, чи вистачить наявних адміністраторів? Якщо новий додаток потребує більше адміністраторів, чи сумісні вони з існуючими адміністраторами, оскільки всі вони матимуть права адміністратора на всі програми в середовищі?

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

  • Чи виникнуть у користувачів труднощі з необхідністю використовувати кілька середовищ для різних програм? Це може вплинути на все: від пошуку програми на мобільному пристрої до звітів про самообслуговування, які мають отримувати дані з кількох середовищ.

Спроможність

Кожне середовище (крім тестових середовищ і середовищ розробників) споживає 1 ГБ для початкового забезпечення. Місткість розподіляється між орендарями, тому її потрібно розподілити між тими, хто її потребує.

Досягайте економії виробничої спроможності наведеними далі способами.

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

Групи середовищ

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

  • За послугою або компонентом; Наприклад, дерево ServiceNow обслуговування

  • Розробка, тестування та виробництво

  • Відділи, бізнес-групи або центри витрат

  • За проектами

  • За місцем розташування, якщо більшість середовищ у локації мають схожі потреби в управлінні; Це також може допомогти досягти аналогічної відповідності регіональним нормативним і юридичним вимогам

Діаграма, на якій показано групу фінансового середовища та групу HR-середовища з різними правилами

Рисунок: Групи оточення для двох різних відділів мають різні правила.

Іменування середовищ і груп

У рамках своєї стратегії подумайте про те, як називаються середовища та групи.

  • Назви середовищ видимі адміністраторам, виробникам і користувачам. Групи середовищ зазвичай використовують лише адміністратори, але виробники можуть зіткнутися з ними, якщо мають привілеї на створення середовищ.

  • Середовища розробників, які створюються автоматично, слідують за взірцем <> Середовище імені користувача, наприклад «Середовище Ейвері Говарда». Групи середовищ не називаються автоматично.

  • Назви середовищ і груп середовища не обов’язково мають бути унікальними. Однак, щоб уникнути плутанини, краще уникати повторюваних імен.

  • Кількість імен обмежена 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 .

Стратегія захисту навколишнього середовища всередині корпорації Майкрософт

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

  • 50,000-60,000 активних мейкерів щомісяця

  • Понад 250 000 заявок та понад 300 000 потоків

  • Понад 20 000 середовищ

Корпорація Майкрософт переходить від своєї попередньої екологічної стратегії до стратегії, яка використовує найновіші Power Platform функції управління, включаючи Керовані середовища, групи середовища та правила.

У рамках розширеної стратегії корпорація Майкрософт планує згрупувати сценарії на основі типу розробки, організаційної власності та рівня ризику. Оскільки так багато всього створюється в компанії, занадто важко зосередитися на всіх можливих сценарій і налаштувати їх для кожного випадку використання. Відбувається занадто багато всього, і його потрібно автоматизувати та використовувати якомога більше готових елементів керування.

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

  • Особиста продуктивність – Це для тих, хто просто хоче створити програму або потік для себе. Наприклад, вони не співпрацюють з іншими. Ці користувачі спрямовуються до середовища особистісного розвитку, які заблоковані. Ці середовища використовують функції керованого середовища, зокрема обмежують спільний доступ, а також контролюють інші дії, які можна робити в середовищах. Доступні з’єднувачі та доступні дії сильно обмежені в цій групі середовищ. Ці середовища є найменш ризикованими. Використання заблокованих персональних середовищ дозволяє користувачам уникнути більш суворого процесу дотримання вимог лише для створення додатків і потоків особистої продуктивності.

  • Командна співпраця – Це для користувачів, які створюють інструменти, автоматизацію та процеси для своєї команди. Для цього сценарій корпорація Майкрософт заохочує використання Dataverse for Teams середовищ. Життєвий цикл, керування доступом і маркування даних контролюються на Microsoft 365 рівні групи, тому нам не потрібно витрачати час на керування цими користувачами з точки зору Power Platform управління. Цей рівень використання є наступним крок у спектрі ризику.

  • Розвиток підприємства/рівень виробництва, який використовується всіма співробітниками – це люди, які створюють інструменти або рішення, які використовуються в більш широкому сенсі в компанії. Ці середовища можуть зберігати найконфіденційніші дані, використовувати потужніші з’єднувачі та вимагати більшого керування. Це вважається найвищим ризиком, і найбільше зусиль витрачається на управління. Потрібен ALM, оскільки підготовчі роботи виконуються в середовищах пісочниці, і лише керовані рішення дозволені у виробничих середовищах. Ці середовища мають бути пов’язані з ServiceTree, який забезпечує повторювані перевірки безпеки та конфіденційності. Правила груп середовищ налаштовуються на основі метаданих і сигналів ServiceTree. Для керування цими середовищами та керування ними використовується багато груп середовищ і правил.

Стратегія управління Microsoft не є статичною. Він плавний і змінюється, щоб адаптуватися до нових викликів і включати нові Power Platform функції.

Розвивайте свою стратегію середовища орендарів

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

Розробка стратегії середовища орендарів не є одноразовим заняттям. Це подорож. Ви повинні розвивати свою стратегію з часом, коли ваші потреби змінюються. Ваша стратегія також повинна коригуватися, щоб впроваджувати нові можливості платформи та вирішувати нові виклики.

Як і всі подорожі, різні організації приєднуються на різних етапах шляху, але всі мають на увазі однакові місце призначення. Нижче наведено можливі пандуси, які представляють те, де сьогодні знаходиться ваша організація.

Запуск

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

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

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

Вирівняти

Ваша організація має і реалізує стратегію середовища, яку потрібно змінити, щоб вона відповідала новим Power Platform функціям і найкращим практикам. Це часто називають браунфілдом. На відміну від організацій, які тільки починають свою діяльність, вам потрібно враховувати вплив на вашу організацію стратегії зміни навколишнього середовища.

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

Наведені нижче пропозиції є поширеними поступовими змінами, які ви можете впровадити:

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

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

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

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

Покращити

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

Повідомте свою екологічну стратегію своїй організації

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

Під час розробки стратегії вирішіть, як ви інформуєте користувачів про ключові елементи стратегії, які впливають на їхнє використання Power Platform. Їм не потрібні всі технічні деталі вашої стратегії, а лише найнеобхідніше, що допомагає забезпечити їхню продуктивність, наприклад:

  • Призначення середовища за замовчуванням

  • Де будувати нові з базовим кодуванням активи

  • Як вони повинні використовувати свої особисті середовище для розробників

  • Як надіслати запит на користувацькі середовища для конкретних бізнес-підрозділів або проєктів

  • Загальні правила використання з’єднувачів і як запросити більше привілеїв з’єднувачів для їхніх середовищ

  • Як ділитися тим, що вони створюють, з іншими

  • Обов’язки мейкера; наприклад:

    • Забезпечувати очищення клієнта. Видаліть оточення, додатки та ланцюжки, якщо вони більше не потрібні. При експериментуванні використовувати тестові середовища.

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

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

  • Коли ваша стратегія змінюється, розкажіть, як зміни впливають на користувачів, щоб вони знали, що робити по-іншому

Хорошим початком є ввімкнення вітального вмісту для мейкера у групі середовища, до якої додаються нові виробники.

Скріншот вітального контенту для мейкерів у Power Platform

Малюнок: Використовуйте вітальний контент, щоб допомогти новим мейкерам досягти успіху.

Ще одним ефективним підходом до комунікації з користувачами є створення внутрішнього Power Platform хабу. Хаб може стати місцем, де люди можуть співпрацювати над проєктами, ділитися Ідеї та відкривати нові способи застосування технологій для досягнення більшого. Центр може бути місцем, де ви ділитеся більш детальною інформацією про свою екологічну стратегію, яка є актуальною для ваших користувачів. Дізнайтесь, як створити внутрішній Power Platform хаб.

Висновок

У цій статті ми розглянули функції, які допомагають вашій організації керувати Power Platform середовищами в масштабі підприємства та включати їх у стратегію середовища клієнта.

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

Ключовим фактором успіху стратегії tenant environment є спілкування з вашими мейкерами та користувачами та отримання їхньої підтримки. Переконайтеся, що люди, які створюють з базовим кодуванням програми та автоматизації, знають, як дотримуватися екологічної стратегії вашої організації та де вони повинні створювати свої з базовим кодуванням активи.

Шлях кожної організації до впровадження унікальний Power Platform . Ми представили кілька Ідеї, які допоможуть вам почати правильний підсумувати стовпці. Команда або Power Platform партнер Microsoft може допомогти вам створити більш персоналізовану стратегію середовища клієнта для вашої організації.

Ресурси