规划环境和差异

  • 12 分钟

环境设计高度依赖组织设计。 注意事项包括大小、位置、监管环境和采用意愿。 环境设计依赖组织，但以下建议有助于为组织设计正确的环境。

注意

Power Automate 安全与治理模块简介探讨了默认环境。 回想一下，租户中的每个用户都自动拥有访问本环境的权限。 不存在删除本环境访问权限的方法，因此通常将该环境重命名为个人生产力，表示该环境是通用环境。 管理员还应了解本环境的位置，从数据隐私角度确保避免出现问题。

另一个重要的注意事项是集中化方面。 例如考虑贵组织是否采用集中式 IT 功能。 您还应确定组织是否负责 Microsoft Power Platform 环境的管理和治理。 另外，贵组织可能采用分散式组织，其中某些技术方面在 IT 部门以外托管。 建立环境设计时，需要考虑其他重要参数。

示例配置

以下部分概述可根据组织设计和目标使用的示例配置。

单区域组织（集中式）

在单区域组织（集中式）中，环境集中管理并且包括用于个人生产力、开发、测试和生产目的的隔离。 个人生产力环境可用于支持各种应用场景，例如电子邮件通知、基于团队的审批、临时数据收集以及与 Office 365 服务集成。 管理环境的中心团队还将提供对非默认环境的访问权限。

由于本组织在单区域中运营，因此不存在数据驻留问题，也不需要与其他区域进一步隔离。

集中式单区域组织屏幕截图。

单区域组织（分散式）

在单区域组织（分散式）中，环境独立管理，管理责任分配给各个业务部门进行管理。 该组织在单区域中运营，默认环境已重命名为个人生产力。 已为人力资源、财务、运营和 IT 等各个业务部门创建其他环境。

分散式单区域组织屏幕截图。

多区域组织（集中式）

对于多区域组织（集中式），您可以采用集中方式来管理环境。 这些环境用于各种目的，例如个人生产力、开发、测试和生产。 个人生产力环境可以非常方便地处理电子邮件通知、团队审批、快速收集数据以及与 Office 365 服务链接等事务。 负责监督这些环境的中央团队还可授予对非默认环境的访问权限。

由于我们的组织在全球范围内运营，因此您可以在运营所在的特定区域创建环境。 为了满足此需求，您已在组织成立的区域设置了默认环境。 此默认环境现在名为“个人生产力（默认）”。此外，您在此总部区域（北美）拥有开发 (Dev)、测试 (Test) 和生产环境。 为了保持一致性，您在亚洲和欧洲区域复制了相同的环境。

在默认环境中，所有许可用户都被视为应用制作者，您无法将他们从此环境中删除。 但是，为了给用户提供一个空间，以便快速创建应用和流，而无需担心从总部区域移出数据，您还在亚洲和欧洲也创建了个人生产力环境。

区域团队可以使用其 IT 变更管理实践来确保重要的应用和流在这些环境间移动时遵守必要的规则。 这一切都是为了跨区域顺畅工作，同时遵循最佳做法。

集中式多区域组织屏幕截图。

多区域组织（分散式）

对于多区域组织（分散式），每个区域独立管理自己的环境。 管理职责由各个业务单位承担。

工作原理如下：在您的主要区域（北美），已将默认环境重命名为“个人生产力”。它与我们的主要办事处位于同一区域。 在这个区域，您已为人力资源、财务、运营和 IT 等业务单位创建了另外的环境。 这样，每个单位都可以按照自己的方式运营。

现在，默认环境使每个人都成为应用制作者，您无法改变这种情况。 但您有了自我保障。 您还在亚洲和欧洲创建了个人生产力环境。 这样一来，即使您远离家乡，也可以构建应用和流，而不必担心数据丢失。

还不止于此， 您也为亚洲和欧洲的业务单位创建了环境。 他们可以独立构建自己的应用和流，无需等待中央团队。 这一切都是为了给予每个人完成工作所需的自由。

分散式多区域组织屏幕截图。

管理例外情况

前面的示例展示了组织可以用来平衡生产力和治理的不同设置。 但每个组织都是独一无二的，可能会出现例外情况。

例如，假设您有一条规则，禁止在应用或流中同时使用 SharePoint 和 Twitter 连接器。 对于大多数角色来说，此规则是合理的，因为在 SharePoint 和 Twitter 之间共享数据通常不是必需的任务。 但对于像公司通信这样的小组来说，这可能是合理的应用场景。

因此，如果有人需要使用 Twitter，但您想限制使用人员，可以在默认规则的基础上添加更多治理工具。 您可以将 Twitter 连接器与 SharePoint 放在同一组中，但控制其使用。

实现方式是：如果有人使用这种连接器组合创建或编辑流时，系统可以进行标记。 然后管理员可以介入并进行治理。 他们可以限制特定组的 Twitter 连接器访问权限，或者可以向流中添加审批步骤。 如果拒绝请求，甚至可以使用以管理员身份禁用流操作使流无法运行，该操作是流管理连接器的一部分。 他们还可以向创建该流的人员发送电子邮件，让他们知道流被停止的原因。 这一切都是为了保持控制力，同时根据需要提供灵活性。 有关类似治理应用场景的详细演练，请参阅自动执行 Microsoft Power Automate 治理博客文章。