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


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

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

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

Вступ

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

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

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

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

Багато організацій починають свій Power Platform шлях із програмами для особистої продуктивності та автоматизацією, створеними та запущеними в спільному централізованому середовищі, яке називається середовищем за замовчуванням. Ці ресурси часто використовують лише базові можливості, що входять до комплекту Microsoft 365 , і не використовують їх у повній мірі Power Platform. У міру того, як це початкове впровадження прискорюється, корпорація Майкрософт надає організаціям можливість перейти до стратегії середовища для використання повних Power Platform можливостей у масштабі підприємства. Ці можливості преміум-керування стають доступними, коли користувачі мають ліцензію Premium Power Platform (Power Apps, Power Automate,і Microsoft Copilot Studio Dynamics 365). Модель Power Platform зрілості впровадження надає більше інформації, яка допомагає організаціям визначити свою дорожню карту для досягнення масштабу корпоративного впровадження за межами стратегії захисту навколишнього середовища. Цей підхід може допомогти організаціям дозріти від базової особистої продуктивності до прийняття в масштабі Power Platform підприємства.

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

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

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

Малюнок: Ілюстрація спільного центрального середовища (ліворуч) та стратегії маршрутизації середовища (праворуч).

Новостворені середовища розробників можна автоматично додавати до групи, яка застосовує правила, щоб забезпечити узгодженість політик управління та безпеки середовищ. Адміністратори можуть обробляти винятки, переміщуючи середовище розробника до групи з пом’якшеними правилами.

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

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

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

Функції, що підтримують стратегію корпоративного середовища

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

Типи середовищ

У наступній таблиці описано типи середовищ, які ви можете створити, їхні характеристики та цільове використання.

Тип Характеристики та використання
За замовчуванням Атмосфера, яка притаманна кожному орендарю. Багато середовищ використовують це середовище для налаштування та автоматизації. 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 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.

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

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

Рисунок: Приклад реалізації концептуального середовища груп у фактичного клієнта

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

Маршрутизація середовища за замовчуванням

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

Діаграма творця автоматично перенаправляється в особисте середовище розробника замість стандартного середовища під час створення програм.

Малюнок: Під час створення додатків творець автоматично перенаправляється в особисте середовище розробника замість стандартного.

Середовища розробника, які створюються за допомогою маршрутизації, керуються за замовчуванням. Користувачі з ліцензіями Developer Plan обмежені створенням і попереднім переглядом ресурсів у середовищі. Щоб запускати ресурси від імені користувача, їм потрібна відповідна ліцензія.

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

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

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

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

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

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

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

  • Співробітники повинні вміти створювати автоматизовані процеси затвердження документів та інші Power Platform налаштування за допомогою Microsoft 365.
  • Співробітники повинні вміти будувати Power Apps і Power Automate автоматизувати для підвищення своєї особистої продуктивності.
  • Творці, які працюють над додатком компанії Compliance Tracker, повинні вміти його розробляти та підтримувати.

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

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

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

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

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

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

Створено чотири групи середовищ: Розробка, Спільна розробка, UAT (тестування прийняття користувачем) та Продукція.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надайте більше гнучкості досвідченим виробникам

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

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

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

Рисунок: Додайте більше кваліфікованих виробників до середовища з пом’якшеними правилами управління.

Організуйте середовища розробників за регіоном або бізнес-одиницею

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

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

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

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

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

Розробити застосунок для корпоративного використання

Можливо, команда у вашій організації розробляє застосунок для використання в масштабах усього підприємства. Команда може бути керована ІТ-фахівцями або включати як ІТ-користувачів, так і бізнес-користувачів (так звана об’єднана команда).

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

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

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

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

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

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

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

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

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

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

Рисунок: Версія 1.0 має бути виправлена, протестована та розгорнута, поки версія 2.0 розробляється, тестується та розгортається.

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

Мінімізуйте використання середовищ розробника

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

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

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

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

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

Безпека на рівні орендаря

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

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

Захист стандартного середовища

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

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

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

  • Розгляньте можливість перейменування середовища за замовчуванням на щось більш описове, наприклад, «Особиста продуктивність».

    • Встановіть політику запобігання втраті даних (DLP) для середовища за замовчуванням, яка блокує нові конектори та обмежує розробників використанням лише базових, неблокованих конекторів. Перемістіть усі з’єднувачі, які не можна заблокувати, до групи бізнес-даних. Перемістіть усі блокувані з’єднувачі до групи заблокованих даних.

    • Створіть правило для блокування всіх шаблонів URL-адрес, що використовуються користувацькими конекторами.

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

Дізнайтеся більше: Захистіть середовище за замовчуванням

Безпечні інші середовища

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

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

Діаграма, що показує три рівні безпеки середовища: нормальний, середній та високий, а також функції безпеки, що захищають кожен з них, такі як політики DLP та Customer Lockbox.

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

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

Узгодьте середовища відповідно до вашої стратегії запобігання втратам даних

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

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

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

Рисунок: У цьому прикладі середовища в групі Personal Dev дотримуються політики DLP, яка блокує всі конектори, що не належать Microsoft.

Розробіть стратегію екологічної політики для вашої організації

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

Почніть там, де ви є

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок: Панель інструментів «Середовища» в Power BI.

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

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

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

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

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

Ви можете використовувати такі конектори для створення програм і потоків:

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

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

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

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

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

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

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

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

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

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

Під час оцінювання робочого середовища для програми пам’ятайте про такі моменти:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Діаграма, що показує групу середовища «Фінанси» та групу середовища «HR» з різними правилами.

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

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

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

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

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

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

  • Імена обмежені 100 символами. Коротші імена легше використовувати.

Правила іменування

Встановіть узгоджені правила іменування.

  • Узгоджені імена допомагають адміністраторам зрозуміти призначення групи та якими середовищами вона керує. Узгоджені назви також спрощують автоматизацію та звітність.

    • Поширеною практикою є включення етапу життєвого циклу до назви середовища; наприклад, Contoso Dev, Contoso Test, Contoso Prod. Мета полягає в чіткому розділенні середовищ, які мають однаковий вміст, але різні призначення.

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

    Наприклад, ви можете вирішити, що всі назви середовищ або груп середовищ повинні відповідати шаблону <етап життєвого циклу>-<регіон>-<підрозділ>-<призначення> (Виробництво-США-Фінанси-Заробітна плата).

  • Робіть імена короткими, змістовними та описовими.

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

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

Активи в середовищі за замовчуванням

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

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

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

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

Вирівняти

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

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

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

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

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

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

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

Покращити

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

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

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

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

  • Мета середовища за замовчуванням
  • Де їм слід створювати нові low-code-ресурсів
  • Як їм слід використовувати своє особисте середовище розробника
  • Як запитувати користувацькі середовища для певних бізнес-підрозділів або проектів
  • Загальні політики використання конекторів та як запитувати додаткові права конекторів для їхніх середовищ
  • Як поділитися тим, що вони створюють, з іншими
  • Обов’язки виробника, наприклад:
    • Забезпечувати очищення клієнта. Видаліть свої середовища, програми та потоки, якщо вони більше не потрібні. При експериментуванні використовувати тестові середовища.
    • Надавати спільний доступ помірковано. Стежити за надмірним наданням доступу до середовищ, програм, циклів і спільних підключень.
    • Організаційні дані проекту. Уникайте переміщення даних із висококонфіденційних або конфіденційних джерел даних до незахищених або зовнішніх сховищ.
  • Коли ваша стратегія змінюється, поділіться тим, як ці зміни впливають на ваших користувачів, щоб вони знали, що робити по-іншому

Гарним початком буде **увімкнути привітальний контент для творців** у групі середовища, де додаються нові творці. ...

Знімок екрана вітального контенту для творців Power Platform.

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

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

Висновок

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

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

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

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