Розробіть стратегію середовища для орендарів для прийняття Power Platform в масштабі
Шлях кожної організації до впровадження унікальний Microsoft Power Platform . Стратегія середовища для орендарів закладає основу, яка допомагає прискорити використання в керований і безпечний спосіб.
У цьому офіційному документі показано, як узгодити стратегію Power Platform середовища орендарів із можливостями та баченням продукту. Ви дізнаєтеся, як найкраще використовувати найновіші функції платформи для реалізації стратегії, яка може дозволити вам прийняти її Power Platform в масштабі підприємства.
Нотатка
Цей офіційний документ можна зберегти або роздрукувати, вибравши пункт Друк у браузері, а потім вибравши пункт Зберегти як PDF.
Вступ
Power Platform дає змогу організаціям створювати з базовим кодуванням рішень для швидких інновацій. Ці рішення можуть бути зосереджені на продуктивності окремих осіб і невеликих команд або застосовуватися в усій організації. Вони також можуть поширюватися на бізнес-процеси, включаючи зовнішніх клієнтів і партнерів. Ці рішення підтримуються Power Platform середовищами, де створюються, тестуються та використовуються ресурси з базовим кодуванням. У міру того, як організація все частіше приймає її Power Platform, впровадження хорошої стратегії середовища орендарів має важливе значення для того, щоб зробити її керованою та безпечною в міру зростання кількості середовищ.
Щоб допомогти вам досягти більшого успіху, ця стаття допоможе вам зрозуміти, як найкраще використовувати доступні функції для створення вашої першої стратегії середовища або розвитку ваших поточних планів. Ми також окреслюємо наше бачення того, як ці функції мають працювати разом і як вони розвиватимуться для масштабного керування Power Platform . У цьому посібнику ми визначаємо, як правильно спрямовувати нових користувачів до середовищ і групових середовищ, щоб послідовно застосовувати управління, правила безпеки та інші важливі аспекти стратегії середовища клієнта. Ми також надаємо детальні кроки для захисту вашого середовища за замовчуванням, що є критично важливим першим кроком у впровадженні стратегії середовища.
Незважаючи на те, що для управління Power Platform середовищами доступно багато Перспективи, підхід, наведений у цій статті, узгоджується з останнім напрямком продуктів Microsoft і використовує поточні функції та заплановані покращення на найближчу перспективу. Ця оновлена інструкція може допомогти вам переконатися, що ви використовуєте лише функції та параметри середовища, які є стратегічними для того, як Microsoft планує керувати масштабованими середовищами.
Бачення стратегії середовища для орендарів Microsoft
Багато організацій починають свій Power Platform шлях із програм для особистої продуктивності та автоматизацій, створених і запущених у спільному централізованому середовищі, яке називається середовищем за замовчуванням. Ці ресурси часто використовують лише базові можливості, що входять до комплекту Microsoft 365 , і не використовують їх у повній мірі Power Platform. У міру того, як це початкове впровадження прискорюється, Microsoft надає організаціям можливість розробити стратегію навколишнього середовища для використання повних Power Platform можливостей у масштабі підприємства. Ці можливості преміум-управління стають доступними, коли користувачі мають преміум( Power Platform Power Apps, Power Automate,, Microsoft Copilot Studio та Dynamics 365) ліцензію. Модель Power Platform зрілості впровадження може надати більше інформації, яка допоможе організаціям визначити свою дорожню карту для досягнення впровадження в масштабі підприємства за межами стратегії захисту навколишнього середовища. Цей підхід може допомогти організаціям дозріти від базової особистої продуктивності до прийняття в масштабі Power Platform підприємства.
Power Platform Функції адміністрування, керування та безпеки дають організаціям змогу впроваджувати корпоративну продуктивність і масштабувати Power Platform використання корпоративних програм і керувати ними. Використання Керовані середовища активує набір преміум-можливостей, які забезпечують більшу видимість і контроль, а також зменшують ручні зусилля з адміністрування та захисту середовищ. Використовуючи ці можливості, ви можете забезпечити послідовне застосування ваших політик управління та безпеки. За допомогою цих можливостей адміністратори можуть переходити до стратегії середовища корпоративного масштабу. Витрачання меншої кількості часу та зусиль на адміністрування допомагає знизити загальну загальну вартість володіння (TCO) платформи в міру масштабування використання вашою організацією.
Ключовим елементом переходу до масштабу підприємства є вдосконалення стратегії спільного централізованого середовища для виробників, полегшуючи їм використання особистих середовищ розробки. У стратегії спільного централізованого середовища виробники створюють, використовують і діляться програмами в середовищі за замовчуванням. Ця стратегія може призвести до відсутності ізоляції та зазіхань виробників один на одного. Уявіть, OneDrive що кожен співробітник компанії має спільну папку для всіх своїх документів. Натомість ви можете використовувати функції середовища, щоб спрямовувати виробників у власне, особисте середовище, де вони можуть безпечно створювати свої програми, захищені від розробників, які працюють із непов’язаними активами, зі спрощеним керуванням для адміністраторів. Колеги можуть бути додані як більше виробників до цих середовищ для спільної роботи над створенням рішень.
Малюнок: Ілюстрація спільного центрального середовища (ліворуч) та стратегії маршрутизації середовища (праворуч).
Новостворені середовища maker можуть бути автоматично додані до групи, яка застосовує правила для забезпечення узгоджених політик керування та безпеки в середовищах. Адміністратори можуть маркер винятків, перемістивши середовище мейкера в групу з пом’якшеними правилами.
з базовим кодуванням ресурси, створені виробниками, є початковим етапом на шляху до управління життєвим циклом програми ресурсу (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 Support, щоб дозволити інженерам усувати проблеми. Ці середовища не враховуються в місткості вашого орендаря. |
Коли ви складаєте загальну стратегію середовища для орендарів, різні типи мають значення для підтримки рекомендацій щодо стратегії.
Керовані середовища
Середовища мають базовий набір функцій і характеристик залежно від типу середовища. Керовані середовища розширюють базові функції, щоб надати набір преміум-можливостей, які дозволяють адміністраторам легше керувати 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 збільшенням кількості прийняттів у вашому орендарі зростає і кількість середовищ, які потребують адміністрування та управління. Чим більше число середовищ збільшується, тим складніше стає переконатися, що ви застосували узгоджені налаштування та політики управління середовищами. Функція груп середовищ спрощує цей процес, дозволяючи створювати іменовані групи та пов’язувати з ними середовища, наприклад, розміщувати пов’язані документи в папці з файлами.
Розмірковуючи над використанням груп середовищ, пам’ятайте про такі міркування:
Середовищем потрібно керувати, щоб бути включеним у групу.
Середовище може бути тільки в одній групі одночасно.
Середовище можна переміщати з однієї групи в іншу.
Середовища в групі можуть належати до різних географічних регіонів.
Групи не можуть містити інші групи.
Щоб полегшити застосування узгоджених настройок і керування, у групах середовищ може бути настроєно та ввімкнуто одне або кілька з наведених нижче правил.
Елементи керування спільним доступом для програм на полотні
Аналітичні висновки щодо використання
Вміст привітання для розробника
Примусове виконання засобу перевірки рішень
Зберігання резервних копій
Створені ШІ описи
Правило стає активним після публікації. Активні правила застосовуються до всіх середовищ, пов’язаних із групою.
Коли правило групи керує параметром, окремі параметри середовища блокуються. Єдиний спосіб змінити їх – це змінити правило. Якщо середовище видаляється з групи, воно зберігає налаштування групи, але тепер адміністратор середовища може їх змінювати. Це важливо для стратегії середовища, оскільки гарантує, що адміністратор середовища не зможе змінити політики, які ви встановили для групи.
Використання груп середовищ дає змогу впорядковувати середовища логічним чином, подібно до структури організації, ієрархії послуг продуктів або інших фреймворків, які ми розглянемо пізніше. Наступна діаграма є концептуальним прикладом того, як організація Contoso може думати про організацію своїх груп оточення.
Рисунок: Концептуалізація стратегії середовища для клієнта Contoso.
Коли ви плануєте налаштування правил, подумайте, що ви могли б застосувати на кожному рівні концептуальної ієрархії. Хоча ви ще не можете налаштувати ієрархію груп, ви можете використовувати комбінацію правил іменування та конфігурації правил для реалізації вашого концептуального дизайну. Наприклад, враховуючи концептуалізацію клієнта Contoso, показану раніше, на наступній ілюстрації представлені групи середовища, які організація могла б використовувати для реалізації свого дизайну.
Рисунок: Приклад реалізації концептуального середовища груп у фактичного клієнта
Далі в цій статті ми розглянемо інші способи використання груп середовищ у рамках стратегії середовища для клієнтів.
Маршрутизація середовища за замовчуванням
Ключова частина екологічної стратегії, яку ми описуємо в цій статті, полягає в тому, щоб відвести виробників від створення ресурсів у середовищі за замовчуванням. Функція маршрутизації середовищ перенаправляє виробників у їхнє власне, особисте середовище розробки та створює нові середовища розробника, якщо це необхідно.
Малюнок: Під час створення додатків виробник автоматично перенаправляється в особисте середовище для розробників замість середовища за замовчуванням.
Середовища розробника, які створюються за допомогою маршрутизації, керуються за замовчуванням. Користувачі з ліцензіями Developer Plan обмежені створенням і попереднім переглядом ресурсів у середовищі. Щоб запускати ресурси від імені користувача, їм потрібна відповідна ліцензія.
Ви можете використовувати маршрутизацію оточення сама по собі, але рекомендованим способом є використання її з групами середовищ. У такому разі будь-яке створене середовище пов’язується з групою, яку ви визначили як таку, що містить усі нові середовища розробника, що гарантує, що воно негайно підпадає під дію ваших політик керування.
Виробникам автоматично призначається роль безпеки, що робить їх адміністратором середовища свого середовища для розробників. Якщо середовище є частиною групи середовищ, виробник — як адміністратор середовища — не може змінювати параметри середовища, оскільки ними керують правила групи середовищ. Лише адміністратори, які можуть змінювати правила групи, можуть вносити будь-які зміни.
Ви можете накласти ще більший контроль двома способами. По-перше, ви можете заборонити ручне створення оточень розробника в налаштуваннях вашого клієнта. Якщо встановлено цей параметр, виробники не можуть самостійно створювати середовища на порталі адміністрування. Вони також не отримають автоматично, створеного відповідно до політики маршрутизації. По-друге, у політиці маршрутизації можна вказати групу безпеки, щоб обмежити кількість осіб, які можуть автоматично створювати середовище.
Спочатку маршрутизація оточень підтримує маршрутизацію нових та існуючих виробників від стандартного середовища, коли вони використовують make.powerapps.com. З часом інші Power Platform сервіси будуть підтримувати функцію маршрутизації оточення.
Microsoft Dataverse
Dataverse Безпечно зберігає дані, які використовуються програмами, і керує ними. У контексті стратегії середовища функція Dataverse рішення — це те, що ви використовуєте для перенесення програм і компонентів з одного середовища в інше. Виробники створюють свої активи в контейнерах — рішеннях, які відстежують те, що вони створюють. Розчини можна легко перевозити в інші середовища. Використовуючи цей підхід, ви можете відокремити середовища розробників, де виробники створюють ресурси, від виробничих середовищ, де вони використовуються. Від цього виграють як виробники, так і користувачі. Творці можуть продовжувати розвивати свої ресурси, і користувачі не дивуються раптовим змінам. Коли мейкери будуть готові опублікувати свої зміни, вони можуть запросити підвищити рівень оновленого ресурсу у виробничому середовищі.
Dataverse рішення є механізмом для впровадження ALM у Power Platform такі продукти, як Power Apps та. Power Automate Пайплайни в Power Platform використовуються рішення для автоматизації CI/CD активів, які створюють мейкери. Рішення можна експортувати та Dataverse зберігати в інструменті контролю джерел, наприклад Azure DevOps або GitHub. Рішення в контролі вихідного коду стає джерелом істини, якщо вам потрібно відтворити середовище розробки. Наприклад, якщо виробник створив популярну програму, а потім видалив середовище для розробників, експортоване рішення, що зберігається в службі контролю версій, може бути використане для відтворення життєздатного середовища розробки.
Ще одним важливим фактором при створенні середовища за допомогою Dataverse, є те, чи будуть якісь Dynamics 365 програми розгорнуті в цьому середовищі. Якщо потенціал існує, ви повинні увімкнути Dynamics 365 під час створення середовища, інакше ви не зможете встановити програми Dynamics 365 пізніше.
Ми рекомендуємо забезпечити Dataverse у будь-якому середовищі, де виробники створюють активи, якими будуть ділитися з іншими користувачами. Це полегшує готовність активів до ALM.
Бажані рішення
Коли виробник створює Dataverse ресурс у Dataverse середовищі, а не починає з користувацького рішення, він пов’язується з рішенням за замовчуванням і, можливо, також із Common Data Service рішенням за замовчуванням. Рішення за замовчуванням є спільним для всіх виробників, які створюють активи в середовищі. Не існує простого способу визначити, який виробник створив які компоненти або які активи належать до яких додатків. Це може ускладнити підвищення рівня популярного додатка в інше середовище для спільного використання з більшою аудиторією. Вам доведеться підвищувати рівень усіх активів у стандартному рішенні — не ідеальний сценарій.
Щоб підтримати вашу стратегію середовища та спростити роботу з нею, виробники повинні створити кастомне рішення у своєму середовищі розробки, а потім встановити його як бажане рішення в цьому середовищі. Виробники встановлюють бажане рішення в середовищі, щоб вказати, з яким рішенням має бути пов’язаний актив, який вони створили. Бажані рішення можуть допомогти гарантувати, що коли виробники використовують пайплайни для підвищення своїх ресурсів в інших середовищах, рекламоване рішення міститиме всі необхідні активи. Думайте про це як про підготовку активів до готовності до ALM.
Трубопроводи в Power Platform
Як ми вже бачили, ключовий принцип хорошої стратегії середовища полягає в тому, щоб ізолювати місце створення активу від місця його розгортання та використання. Цей поділ гарантує, що користувачі, які намагаються використовувати актив, не зіткнуться з простоєм через те, що мейкер оновлює його. Однак він вимагає, щоб активи були просунуті у виробниче середовище — в ідеалі як частина Dataverse рішення — перш ніж їх можна буде використовувати.
Dataverse Рішення можна вручну переміщати між середовищами. Однак ви можете автоматизувати процес і запровадити політики для забезпечення належного керування змінами за допомогою воронки продажів. Залежно від правил середовища, які ви встановили в засобі перевірки рішень, конвеєри автоматично застосовують усі правила перед розгортанням рішення, запобігаючи подальшим помилкам розгортання. Наступна діаграма ілюструє, як пайплайни можуть автоматизувати просування активу від розробки до виробництва.
Малюнок: Пайплайн автоматизує просування активу, який зберігається в системі контролю джерела від розробки до тестування.
Ви можете налаштувати кількість середовищ і процесів, як-от затвердження, які потрібно включити в воронку продажів.
Пайплайни працюють разом із групами середовищ. Вони можуть бути попередньо налаштовані для середовищ розробки, щоб дозволити виробникам легко розпочати процес просування, реагуючи на підказку, коли вони намагаються поділитися своїми активами з іншими користувачами. У рамках запиту на розгортання за допомогою пайплайнів виробники можуть запропонувати, з ким поділитися своїми активами та необхідні ролі безпеки. Адміністратор конвеєра може схвалити або відхилити запит перед розгортанням, забезпечивши найменші привілеї для виробника, який його створив.
Конвеєри зберігають Power Platform визначення кожного конвеєра в хост-середовищі, яким Microsoft керує за замовчуванням. Однак ви можете визначити кілька хост-середовищ у своєму клієнті, яким ви керуєте, що дозволить вам маркер виконувати унікальні вимоги.
Каталог в Power Platform
Організації, в яких розробники та розробники створюють і діляться компонентами, як-от додатками та потоками, а також шаблонами, які є більш просунутими відправними точками, як правило, отримують більше користі Power Platform. Каталог Power Platform дозволяє виробникам ефективніше обмінюватися своїми компонентами та шаблонами в різних середовищах.
Каталог встановлюється в середовищі і може бути встановлений разом з хостом конвеєра в тому ж середовищі. Також можна маркер задовольнити унікальні вимоги до сегментації ресурсів, маючи кілька середовищ із встановленим каталогом.
Дорожня карта функцій
Оскільки Microsoft продовжує розвивати функції Power Platform , які підтримують управління та адміністрування, ви можете слідкувати за ними в планувальнику випусків. Ви дізнаєтеся, що планується, що чекає на майбутню хвилю релізів і що можна спробувати зараз. Ви навіть можете створити власний план випуску, зберігши елементи, за якими хочете стежити.
Формування стратегії управління навколишнім середовищем в масштабі підприємства
Ми обговорили наше бачення стратегії tenant environment в масштабі підприємства та ключові особливості середовища, які її підтримують. Тепер ми розглянемо, як ви можете використовувати ці функції разом у рамках стратегії захисту довкілля. Ваша стратегія повинна ґрунтуватися на унікальних вимогах вашої організації, тому давайте почнемо з базового прикладу, перш ніж ми перейдемо до того, як адаптувати стратегію відповідно до ваших потреб.
У цьому прикладі керівництво Contoso хоче надати співробітникам можливість скористатися перевагами Power Platform та визначило такі вимоги високого рівня:
Співробітники повинні вміти створювати автоматизовані процеси затвердження документів та інші Power Platform налаштування за допомогою Microsoft 365.
Співробітники повинні вміти будувати Power Apps і Power Automate автоматизувати для підвищення своєї особистої продуктивності.
Творці, які працюють над додатком компанії Compliance Tracker, повинні вміти його розробляти та підтримувати.
Щоб підтримати ці вимоги, команда адміністраторів та управління Contoso розробила наступну топологію оточення:
Малюнок: Запропонована топологія середовища для масштабного проекту Contoso. Power Platform
Давайте детально розглянемо цю діаграму топології середовища.
Середовище за замовчуванням використовується для створення Microsoft 365 налаштувань продуктивності. Політика запобігання втраті даних і обмеження на спільний доступ обмежують інші типи активності мейкерів і встановлюють огорожі навколо того, що мейкери можуть створювати в цьому середовищі.
Лише адміністратори можуть створювати пробні, пісочні та виробничі середовища. Творці використовують спеціальну форму Microsoft або інший процес, щоб запросити нове середовище. Стартовий Microsoft Power Platform набір Center of Excellence (CoE) включає запит на середовище, який можна використовувати.
Створюються чотири групи середовищ: Development, Shared Development, UAT (користувацьке приймальне тестування) та Production.
Політика маршрутизації середовищ, встановлена для групи розробки, спрямовує виробників із стандартного середовища до їхніх власних середовищ розробників. Коли створюються нові середовища розробки, вони автоматично пов’язуються з групою розробників і застосовуються її правила.
Група спільної розробки підтримує середовища, які містять проекти з кількома виробниками.
Група UAT містить середовища, які використовуються для тестування ресурсів перед їх переходом у продакшн.
Група Production містить середовища, у яких розміщуються застосунки, потоки та інші артефакти для промислового використання.
Те, чого не вистачає в цій запропонованій топології, — це конвеєри для автоматизації просування між середовищами розробки, тестування та виробництва. Давайте зараз їх додамо.
Малюнок: Та сама топологія середовища з конвеєрами, що з’єднують хост-середовище конвеєра з середовищами розробки, тестування та виробництва.
У переглянутій діаграмі топології середовища ми додали хост-середовище конвеєра та два конвеєри. Один пайплайн переміщує ресурси з розробки в тестування, а потім у виробничі середовища. Правило конвеєра в групі розробки буде змінено для використання цього конвеєра. Інший пайплайн переміщує ресурси зі спільного середовища розробки на тестування, а потім у продакшн. Правило конвеєра в групі спільної розробки буде змінено для використання цього конвеєра.
Ця базова стратегія середовища забезпечує основу, на яку ви можете спиратися для інших випадків використання, які ми розглянемо далі.
Стратегії середовища для конкретних сценаріїв
Ось кілька поширених випадків використання, які вам, можливо, доведеться включити в стратегію середовища орендарів фонду.
Контролюйте, які мейкери можуть створювати середовища для розробників
За умовчанням будь-хто, хто має Power Platform ліцензію Premium, ліцензію Developer Plan або Power Platform роль адміністратора клієнта, може створити середовище для розробників на порталі адміністрування.
У стратегії базового середовища маршрутизація середовищ гарантує, що виробники будуть спрямовані від стандартного середовища до нового середовища для розробників, створеного у визначеній групі. Однак виробники все одно можуть вручну створювати середовища розробника, які не розміщуються в групі середовищ і до яких не застосовуються її правила.
Щоб уточнити, які виробники мають право на маршрутизацію середовища, укажіть групу безпеки в конфігурації маршрутизації. Коли настроєно групу безпеки, маршрутизуються лише учасники групи безпеки. Усі інші повертаються до середовища за замовчуванням.
Забезпечте більшу гнучкість для просунутих виробників
У стратегії базового середовища всі нові середовища виробників спрямовуються до визначеного середовища для групи розробників. Як правило, ця група середовищ має досить обмежувальний звід правил управління, що застосовуються.
У міру того, як мейкери стають більш просунутими, ви можете дозволити їм запитувати доступ до більшої кількості можливостей. Замість того, щоб видаляти їх із вихідної групи середовищ і вручну керувати винятком, ви можете використовувати іншу групу середовищ для відстеження цих досвідчених виробників.
Малюнок: Додайте більше здібних мейкерів до середовища з пом’якшеними правилами управління.
Упорядкування середовищ для розробників за регіонами або бізнес-одиницями
У поточній реалізації маршрутизації середовищ всі нові середовища розробника створюються в єдиній групі середовищ. Що робити, якщо ви хочете організувати середовище розробників ваших мейкерів за регіонами, наприклад, або бізнес-одиницею?
Використовуйте маршрутизацію, щоб спрямовувати виробників у нове середовище для розробників, створене у визначеній групі. Потім ви можете перемістити його в іншу групу на основі регіону, організаційної одиниці або інших критеріїв, де можна застосувати більш детальні правила управління.
Малюнок: Після того, як маршрутизація середовищ створить середовища розробників у визначеній групі, перемістіть їх до більш структурно специфічних груп.
Переміщення середовищ сьогодні виконується вручну, але ви зможете автоматизувати їх, коли Power Platform з’єднувач адміністратора підтримуватиме функцію групи в майбутньому оновленні.
Розробити додаток для корпоративного використання
Команда у вашій організації може розробляти програму для використання в масштабах усього підприємства. Команда може бути орієнтована на ІТ або включати як IT-користувачів, так і бізнес-користувачів (так звана зведена робоча група).
У найпростішій стратегії середовища команда проекту будує в спільному середовищі, яке є або пісочницею, або продакшн-типом. Tсередовище для розробників не є найкращим способом підтримки співпраці кількох виробників над ресурсом. Однак творцям потрібно спілкуватися один з одним, щоб уникнути зіткнень і конфліктів у спільному середовищі.
Спеціальні середовища для тестування та продакшн не потрібні. Додаток може бути протестований і розгорнутий в тестових і виробничих середовищах всієї організації, які розміщують кілька додатків.
Малюнок: Два корпоративні додатки, які розробляються в спеціальних середовищах, а потім тестуються і розгортаються в середовищах, які є спільними з іншими програмами.
У більш просунутій варіації кожен виробник має індивідуальне середовище для розробників. Перевага цього полягає в тому, що він забезпечує більшу ізоляцію для виробника, але може ускладнити поєднання індивідуальної роботи в інтеграційному середовищі. Хоча ізольована робота може бути корисною для більших і складніших команд, вона може додати непотрібних накладних витрат меншим командам, які можуть бути більш успішними, співпрацюючи в спільному середовищі розробки.
Малюнок: Два виробники, які працюють над одним і тим же додатком в окремих середовищах розробників, повинні об’єднати свою роботу в спільному середовищі інтеграції, перш ніж він перейде до тестування та виробництва.
Цей варіант зазвичай включає стратегію контролю вихідного коду, при цьому кожне середовище розробки представлено як гілка в контролі джерела, яка об’єднується, коли зміни готові до просування. Важливо враховувати, як програма підтримуватиметься після початкового випуску.
Наприклад, версія 1.0 програми може бути на стадії розробки, поки команда переходить до збірки версії 2.0. Ваша стратегія оточення повинна підтримувати вирішення проблеми у версії 1.0, поки триває розробка версії 2.0.
Малюнок: Версія 1.0 повинна бути виправлена, протестована і розгорнута, в той час як версія 2.0 розробляється, тестується і розгортається.
Групи оточень пропонують кілька підходів до обробки цього сценарію корпоративного додатка. Наприклад, це може бути одна група додатків або окремі групи для кожного етапу розробки. У розділі "Найкращі практики" ми розглянемо, як оцінити варіанти.
Мінімізуйте використання середовищ розробника
Індивідуальні середовища розробників є рекомендованим способом надати makers робочий простір для створення з базовим кодуванням рішень. Вони пропонують найвищий рівень ізоляції від інших виробників. Але якщо ваша організація хоче мінімізувати кількість середовищ для розробників, кілька спільних середовищ краще, ніж заохочувати виробників створювати активи в середовищі за замовчуванням.
У цьому сценарії ви обмежите створення середовищ для розробників і створите спільні середовища розробки продакшн-типу. Ви можете організувати ці спільні середовища за структурою організації, регіоном або іншими критеріями. Група оточення може містити їх, щоб переконатися, що до них застосовуються узгоджені правила управління. Грантодавці мають дозвіл на створення активів з базовим кодуванням у призначеному їм середовищі.
Безпека як частина стратегії вашого оточення
Середовища є ключовим компонентом безпечного використання Power Platform . Вони визначають межі безпеки в межах вашого клієнта, які допомагають захистити програми та дані. У рамках стратегії середовища ви повинні враховувати, як ваші вимоги до безпеки впливають на кількість і призначення середовищ у вашому клієнті.
Середовища дають змогу створювати кілька меж безпеки в межах клієнта для захисту програм і даних. Захист, що забезпечується середовищем, можна налаштувати відповідно до необхідного захисту безпеки шляхом застосування налаштовуваного набору функцій безпеки до середовища. Детальне обговорення окремих особливостей безпеки середовища виходить за рамки цієї статті. Однак у цьому розділі ми пропонуємо рекомендації щодо того, як думати про безпеку як частину стратегії вашого tenant середовища.
Безпека на рівні орендаря
Більшість параметрів безпеки, які впливають на середовища, налаштовуються для кожного середовища окремо. Однак ви можете внести деякі зміни на рівні орендаря, щоб підтримати вашу стратегію захисту довкілля.
- Вимкніть функцію «Поділитися з усіма» Power Platform. Лише адміністратори зможуть поділитися активом з усіма.
- Розгляньте можливість безпечної інтеграції з Exchange.
- Застосовуйте ізоляцію між орендарями, щоб мінімізувати ризик витоку даних між орендарями.
- Обмежте створення нових виробничих середовищ для адміністраторів. Обмеження створення середовища корисне для підтримки контролю в цілому: як для запобігання неврахованому споживанню потужності, так і для зменшення кількості середовищ, якими потрібно керувати. Якщо користувачі змушені запитувати середовища в центральному департаменті інформаційних технологій, легше бачити, над чим працюють люди, коли адміністратори є контролерами.
Захист стандартного середовища
Середовище за замовчуванням відіграє важливу роль у підтримці Microsoft 365 налаштувань продуктивності. Однак, в рамках рекомендованої стратегії навколишнього середовища, краще мінімізувати його використання, наскільки це можливо. Замість цього виробники повинні будувати у своїх власних ізольованих середовищах. Хоча ви не можете заблокувати доступ до середовища за замовчуванням, ви можете мінімізувати те, що можна робити в ньому.
По-перше, використовуйте маршрутизацію оточення, щоб спрямувати виробників до власного робочого простору для створення активів з базовим кодуванням.
Перевірте, хто має доступ адміністратора до середовища за замовчуванням, і обмежте його ролями, яким він потрібен.
Розгляньте можливість перейменування середовища за замовчуванням на щось більш описове, наприклад «Особиста продуктивність».
Встановіть політику запобігання втраті даних (DLP) для середовища за замовчуванням, яка блокує нові з’єднувачі та обмежує виробників використанням лише базових з’єднувачів, які не можна розблокувати. Перемістіть усі конектори, які не можна заблокувати, до групи даних компанії. Перемістіть усі заблоковані конектори до групи заблокованих даних.
Створіть правило для блокування всіх шаблонів URL-адрес, які використовуються користувацькими з’єднувачами.
Захист середовища за замовчуванням має бути пріоритетом. Робіть це разом із безпекою на рівні орендаря як частину першого кроку у реалізації стратегії вашого середовища. Без цього мейкери мають більше можливостей додавати активи за замовчуванням. Маючи їх на місці разом із маршрутизацією середовища, виробникам пропонується використовувати власне середовище.
Захист інших середовищ
Якщо ваша організація схожа на більшість, у вас є кілька середовищ на додаток до середовища за замовчуванням. Рівень безпеки, який потрібен кожному з них, може відрізнятися залежно від програм і даних, які він містить. Середовища розробників зазвичай мають більш м’які правила, ніж виробничі. Деякі виробничі середовища вимагають найбільшого захисту.
У рамках розробки стратегії захисту довкілля визначте загальні рівні безпеки для ваших середовищ і функції, які захищають кожен рівень, як у наступному прикладі.
Малюнок: Приклад трьох рівнів безпеки навколишнього середовища та функцій безпеки, які застосовуються до середовищ на кожному рівні.
Включіть визначені рівні безпеки в стратегію групи та, де це можливо, використовуйте правила для ввімкнення функцій безпеки у вашому середовищі. У цьому прикладі правило обмежує спільний доступ у всіх середовищах, які визначено як нормальний або середній рівень безпеки.
Приведіть середовища у відповідність до вашої стратегії запобігання втраті даних
Політики щодо даних є ще однією важливою частиною загальних зусиль з управління для контролю служб, які використовуються ресурсами з базовим кодуванням у середовищі. Групи середовищ не мають правила для застосування політики DLP до середовища. Однак ви можете узгодити свою стратегію DLP з групами оточення. Наприклад, можна створити політику DLP з такою самою або схожою назвою, як група середовищ, і застосувати її до середовищ у цій групі.
Дізнайтеся більше про те, як розробити стратегію DLP.
Малюнок: У цьому прикладі середовища в групі особистих розробників дотримуються політики DLP, яка блокує всі з’єднувачі, що не належать Microsoft.
Адаптуйте стратегію середовища для вашої організації
У попередніх розділах ми описали наше бачення того, як організації можуть керувати масштабними середовищами. Ми розглянули основні функції, як вони сприяють стратегії середовища та як може виглядати топологія базового середовища, яка їх використовує. Ми навели приклади того, як можна будувати на цьому фундаменті, щоб пристосуватися до типових сценаріїв. Оскільки кожна організація унікальна, наступним кроком є адаптація стратегії середовища, яка відповідає потребам вашої організації.
Почніть з того місця, де ви є
Незалежно від того, чи є ваша організація новачком Power Platform або використовує її протягом багатьох років, першим кроком є оцінка вашої ситуації. Оцініть на високому рівні, що знаходиться у вашому середовищі за замовчуванням, які інші середовища у вас є та для чого вони використовуються. Часто стратегія навколишнього середовища розробляється як частина загальних зусиль по встановленню управління в Power Platform організації. Якщо це так, можливо, ви вже сформулювали певне бачення управління, необхідне для адаптації стратегії для вашої організації.
Інформація про організацію, яку ви повинні знати, включає:
Яке бачення того, як Power Platform буде використовуватися в організації?
Хто в організації буде створювати активи з базовим кодуванням?
Вам потрібно прийняти кілька ключових рішень:
Як мейкери отримають нові умови?
Чи будете ви групувати своє оточення, і якщо так, то яким чином?
Які рівні безпеки потрібні для різних середовищ і як середовища класифікуються?
Як ви вирішите, чи буде додаток, автоматизація або Copilot використовувати існуюче середовище або нове?
Чи є прогалини між базовими функціями платформи та вашими вимогами, які вимагають спеціального процесу управління?
Як ви будете маркер з будь-якими існуючими активами в середовищі за замовчуванням?
Чи є у вас стратегія політики DLP для клієнтів і середовищ, і якщо так, то як вона узгоджується зі стратегією середовища, яку ви створюєте?
Ви також можете знайти натхнення в хмарних операційних моделях , які є частиною Cloud Adoption Framework для Azure.
Заповнюйте прогалини за допомогою платформи
Майже завжди ви знайдете вимоги, яким не задовольняють вбудовані можливості платформи. Оцінюючи ці прогалини, розгляньте такі можливі результати оцінювання:
Розрив є допустимим.
Прогалину можна заповнити за допомогою стартового набору Power Platform Center of Excellence.
Прогалину можна заповнити за допомогою можливостей платформи, таких як API, конектори та кастомні додатки, або автоматизації.
Прогалину можна заповнити за допомогою стороннього інструменту або програми.
Стартовий пакет CoE
Стартовий Power Platform набір Center of Excellence — це колекція компонентів та інструментів, які розроблені, щоб допомогти вашій організації прийняти та підтримувати використання Power Platform. Ключовим аспектом стартового набору є його здатність збирати дані про використання платформи у ваших середовищах, що може бути корисним під час розробки та розвитку стратегії середовища.
Наприклад, на приладній дошці "Середовища" Power BI є огляд, який допомагає зрозуміти, які середовища існують у вашому клієнті, хто їх створив і які ресурси вони містять.
Малюнок: Інформаційна панель середовищ в. Power BI
Набір включає відправні точки або натхнення, наприклад, процес, який виробники можуть використовувати для запиту нових середовищ і змін у політиках DLP для своїх середовищ.
Малюнок: Блок-схема, що ілюструє процес управління середовищем у стартовому наборі Ради Європи.
Програмованість і розширюваність платформи
Одна з чудових переваг з базовим кодуванням платформи полягає в тому, що ви можете використовувати її для створення додатків, автоматизацій, порталів і пілотів, які допоможуть вам керувати нею. У вас також є доступ до інструментів нижчого рівня, які можна використовувати для заповнення прогалин у підтримці вашої екологічної стратегії.
Для створення додатків і потоків можна використовувати такі сполучні конектори:
Ви можете використовувати Power Platform інтерфейс командного рядка (CLI) для розробки автоматизацій, які допоможуть вам керувати життєвим циклом середовища та іншими завданнями, пов’язаними з практиками DevOps.
За допомогою PowerShell командлетів для Power Platform творців та адміністраторів ви можете автоматизувати багато завдань з моніторингу та керування.
DLP Power Platform SDK може допомогти вам керувати політикою захисту даних від клієнтів і середовища.
Рекомендації щодо передового досвіду
У цьому розділі статті ми спираємося на рекомендації в розділах «Основа» та «Сценарії».
Нові середовища
Під час розробки стратегії враховуйте, коли ви створюєте середовище для підтримки робочого навантаження. Ваша оцінка має врівноважувати переваги ізоляції, яку надає середовище (наприклад, можливість блокувати певні середовища частіше, ніж інші, корисна з точки зору безпеки), з недоліками, як-от те, що ізоляція створює незручності для користувачів, які намагаються обмінюватися даними між програмами.
Коли ви оцінюєте, чи належить програма або автоматизація до окремого середовища, оцінюйте різні етапи життєвого циклу програми окремо. Під час розробки важлива ізоляція від інших програм. Коли кілька додатків розробляються в одному середовищі, ви ризикуєте створити залежності між додатками.
Як загальна рекомендація, коли це можливо, середовища розробки повинні бути одноцільовими, одноразовими та легко відтворюваними.
Тестування кількох додатків в одному середовищі має сенс, якщо вони працюють разом у продакшн. Насправді, якщо ви не проводите тестування з програмами, які працюватимуть у продакшн, ви ризикуєте не виявити проблем із сумісністю.
Оцінюючи робоче середовище програми, враховуйте наведені нижче міркування.
Чи сумісний додаток з існуючими програмами в середовищі? Наприклад, дві програми, які використовують таблицю контактів Dataverse для різних цілей, можуть бути несумісними. Чи сумісні програми з точки зору політики DLP?
Чи існують спеціальні вимоги до дотримання нормативних вимог щодо поділу даних? Наприклад, чи вимагає чутливість даних ізолювати? Чи існує вимога про те, що дані не можуть бути включені до інших даних?
Чи є дані надзвичайно конфіденційними чи конфіденційними? Чи завдасть ексфільтрація грошової або репутаційної шкоди організації? Ізоляція в окремому середовищі може забезпечити більший контроль над безпекою.
Чи потрібні програмі дані з інших додатків і чи потрібно їх пов’язувати з ними? Наприклад, два додатки, які використовують вашу таблицю клієнтів, мають бути розміщені разом. Їх відокремлення створило б зайві копії даних і створило б проблеми з їх збереженням.
Чи потрібні дані для регіонального зберігання даних? У деяких сценаріях той самий додаток або автоматизація може бути розгорнута в регіональних середовищах, щоб забезпечити відповідну ізоляцію даних і місце проживання.
Чи більшість користувачів знаходяться в тому ж регіоні, що і навколишнє середовище? Якщо середовище розташовано в регіоні EMEA, але більшість користувачів програми проживають у США, спільне використання середовища може забезпечити не найкращу продуктивність.
Чи будуть потрібні нові адміністратори, чи вистачить вже наявних адміністраторів? Якщо новий додаток вимагає більше адміністраторів, чи сумісні вони з існуючими адміністраторами, оскільки всі вони матимуть дозволи адміністратора на всі програми в середовищі?
Яка тривалість життя програми? Якщо програма або автоматизація тимчасова або недовговічна, може бути не найкращою ідея встановлювати її в середовищі з більш постійними програмами.
Чи виникнуть у користувачів труднощі з необхідністю використовувати кілька середовищ для різних програм? Це може вплинути на все: від пошуку програми на мобільному пристрої до звітів про самообслуговування, які мають отримувати дані з кількох середовищ.
Спроможність
Кожне середовище (крім пробного середовища та середовища розробника) споживає 1 ГБ для початкового забезпечення. Місткість розподіляється між орендарем, тому її потрібно розподілити між тими, хто її потребує.
Досягайте економії виробничої спроможності наведеними далі способами.
- Керування спільними тестовими та виробничими середовищами. На відміну від спільних середовищ розробки, дозволи в тестових і виробничих середовищах повинні бути обмежені доступом користувача для тестування.
- Налаштуйте автоматичне очищення тимчасових середовищ розробки й заохочуйте використання ознайомлювальних середовищ для тестування експериментальних робіт.
Групи середовищ
Групи середовищ є гнучкими та дозволяють враховувати різні випадки використання, унікальні для ваших організацій. Ось кілька способів, як можна розглянути групування середовищ як частину стратегії середовища:
За послугою або компонентом; Наприклад, дерево ServiceNow обслуговування
Розробка, тестування та виробництво
Відділи, бізнес-групи або центри витрат
За проектами
За місцем розташування, якщо більшість середовищ у локації мають схожі потреби в управлінні; Це також може допомогти досягти аналогічної відповідності регіональним нормативним і правовим вимогам
Рисунок: Групи оточень для двох різних відділів мають різні правила.
Іменування середовищ і груп
У рамках своєї стратегії подумайте про те, як називаються середовища та групи.
Назви середовищ бачать адміністратори, виробники та користувачі. Групи середовищ зазвичай використовують лише адміністратори, але виробники можуть зіткнутися з ними, якщо вони мають привілеї на створення середовищ.
Середовища розробників, які створюються автоматично, слідують за зразком <> імені користувача; наприклад, «Середовище Ейвері Говарда». Групи середовищ не називаються автоматично.
Назви середовищ і груп середовищ не обов’язково мають бути унікальними. Однак, щоб уникнути плутанини, краще уникати дублювання імен.
Назви обмежені 100 символами. Коротші назви простіші у використанні.
Встановіть єдину угоду про іменування.
Уніфіковані назви допомагають адміністраторам знати, яка мета групи та якими середовищами вона керує, а також можуть спростити автоматизацію та звітування.
Загальноприйнятою практикою є включення етапу життєвого циклу в ім’я середовища; наприклад, Contoso Dev, Contoso Test, Contoso Prod. Мета полягає в чіткому відокремленні середовищ, які мають однаковий контент, але різне призначення.
Іншою поширеною практикою є включення відділу або бізнес-одиниці в назву, коли середовище присвячене цій групі користувачів.
Наприклад, ви можете вирішити, що всі назви середовищ або груп середовища мають відповідати шаблону <етап-регіон-бізнес-одиниця-призначення><><><> (Prod-US-Finance-Payroll).
Нехай імена будуть короткими, змістовними та описовими.
Подумайте про те, як ваші групи будуть розвиватися і рости з часом, і переконайтеся, що ваші правила іменування можуть задовольнити ці мінливі потреби.
Уникайте включення конфіденційної інформації в імена. Їх може бачити кожен, хто має доступ до центру адміністрування.
Об’єкти в середовищі за умовчанням
Ваша стратегія оточення повинна заохочувати (або примушувати) використання особистих середовищ розробки, щоб зменшити те, що створюється в середовищі за замовчуванням. Однак вам слід подивитися, що виробники вже створили в середовищі за замовчуванням, і оцінити, як маркер з кожним випадком використання. Чи доцільно залишати в середовищі за замовчуванням, чи його слід перенести в інше середовище?
Ключовою частиною виконання цих зусиль з гігієни є визначення програм, які широко використовуються у вашій організації та повинні мати власне захищене середовище розробки, відокремлене від виробничого середовища.
У наведеній нижче таблиці наведено приклади випадків використання та дій міграції. Зрештою, ваша організація має визначити власні варіанти використання та фактори ризику, пов’язані з залишенням активів у середовищі за замовчуванням. Докладніше про те, коли переносити об’єкти із середовища за умовчанням.
| Середовище за замовчуванням | Дії щодо міграції |
|---|---|
| Microsoft 365 Особиста продуктивність | Залишайтеся в середовищі за замовчуванням. |
| Об’єкти з одним виробником, які використовувалися нещодавно, але не надавалися спільно | Перехід в індивідуальне середовище розробників для розробників власника. |
| Активи з одним виробником, які використовувалися нещодавно та є спільними | Переходьте в індивідуальне середовище для розробників власника та запускайте зі спільного виробничого середовища. |
| Об’єкти з кількома виробниками, які використовувалися останнім часом і є спільними | Перейдіть у спільне середовище для розробників і працюйте зі спільного робочого середовища. |
| Активи, які останнім часом не використовувалися | Повідомте про це власника і перемістіться на карантин, якщо немає відповіді. |
Активи в Dataverse for Teams середовищах
Microsoft Dataverse for Teams дає змогу користувачам створювати власні програми, ботів і потоки Microsoft Teams за допомогою функцій, Power Apps Microsoft Copilot Studio, та Power Automate. Коли відповідальний за робочу групу додає цю спроможність до своєї робочої групи, створюється середовище Microsoft Power Platform із базою даних Dataverse for Teams, котре пов’язується із робочою групою. Дізнайтеся, як встановлювати політики управління для керування Microsoft Dataverse for Teams середовищем.
Внутрішня стратегія охорони навколишнього середовища на Microsoft
Microsoft вважає себе "нульовим клієнтом", оскільки внутрішньо Power Platform використовує автоматизацію та ефективність серед своїх співробітників. Наведені нижче цифри дають вам ідея масштаб використання у внутрішньому клієнті Microsoft.
50,000-60,000 активних мейкерів щомісяця
Понад 250 000 заявок та понад 300 000 потоків
Понад 20 000 середовищ
Microsoft переходить від своєї попередньої екологічної стратегії до стратегії з використанням новітніх Power Platform функцій управління, включаючи Керовані середовища, групи середовища та правила.
В рамках розширеної стратегії Microsoft планує згрупувати сценарії на основі типу розвитку, форми власності організації та рівня ризику. Оскільки так багато створюється по всій компанії, занадто важко зосередитися на всіх можливих сценаріях і налаштувати їх для кожного випадку використання. Відбувається занадто багато всього, і це потрібно автоматизувати та використовувати якомога більше готових елементів керування.
Microsoft структурує своє Power Platform середовище за трьома ширшими категоріями, які охоплюють сім випадків використання, що відображають різні ступені ризику та контролю: особиста продуктивність, командна співпраця та розвиток підприємства.
Особиста продуктивність – Це для тих, хто просто хоче створити програму або потік для себе. Наприклад, вони не співпрацюють з іншими. Ці користувачі спрямовуються до особистих середовищ розробки, які заблоковані. Ці середовища використовують функції керованого середовища, зокрема обмежують спільний доступ, а також контролюють інші дії, які можна виконувати в цих середовищах. З’єднувачі та доступні дії сильно обмежені в цій групі середовищ. Ці середовища є найменш ризикованими. Використання заблокованих особистих середовищ дозволяє користувачам уникати більш суворого процесу дотримання вимог лише для створення додатків і потоків особистої продуктивності.
Командна співпраця – Це для користувачів, які створюють інструменти, автоматизацію та процеси для своєї команди. Для цього сценарій, Microsoft заохочує використання Dataverse for Teams середовищ. Життєвий цикл, керування доступом і маркування даних контролюються на Microsoft 365 рівні групи, тому нам не потрібно витрачати час на керування цими користувачами з точки зору Power Platform управління. Цей рівень використання є наступним кроком вгору в спектрі ризику.
Рівень розвитку підприємства/виробництва, який використовується всіма співробітниками – це люди, які створюють інструменти або рішення, які використовуються в більш широкому сенсі в компанії. Ці середовища можуть зберігати найбільш конфіденційні дані, використовувати потужніші з’єднувачі та вимагати більшого керування. Це вважається найвищим ризиком, і найбільше зусиль витрачається на управління. Потрібен ALM, оскільки передвиробничі роботи виконуються в середовищах пісочниці, а в виробничих середовищах дозволені лише керовані рішення. Ці середовища мають бути пов’язані з ServiceTree, який забезпечує повторювані перевірки безпеки та конфіденційності. Правила групи оточень налаштовуються на основі метаданих і сигналів ServiceTree. Багато груп середовищ і правил використовуються для керування цими середовищами.
Стратегія управління Microsoft не є статичною. Він плавний і змінюється, щоб адаптуватися до нових викликів і включати нові Power Platform функції.
Розвивайте стратегію середовища для орендарів
У цій статті ми розповіли, як розробити стратегію tenant середовища корпоративного масштабу. Стратегія може розвиватися разом із вашим бізнесом, незалежно від того, з чого ви починаєте свій шлях. Організації будь-якого розміру можуть отримати вигоду від стратегії, яку ми представляємо; Однак для організацій, які вже перебувають на більш високому рівні, вигоди більші.
Розробка стратегії середовища орендарів не є одноразовим заходом. Це подорож. Ви повинні розвивати свою стратегію з часом у міру того, як змінюються ваші потреби. Ваша стратегія також має коригуватися, щоб використовувати нові можливості платформи та вирішувати нові проблеми.
Як і в усіх подорожах, різні організації приєднуються на різних етапах шляху, але всі мають на увазі одне й те саме місце призначення. Нижче наведено можливі настанови, які відображають місце розташування вашої організації сьогодні.
Запуск
Ваша організація знаходиться на початку свого шляху до впровадження 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 може допомогти вам створити більш індивідуальну стратегію середовища клієнта для вашої організації.