本文介绍在 租户级别 为 Microsoft Fabric 工作区执行的战略实施规划，重点介绍 Fabric 中的 Power BI 体验。
备注
本文是 Power BI 实现规划 系列文章的一部分。 本系列重点介绍如何在 Microsoft Fabric 内实现 Power BI 体验。 请参阅 系列简介。
本文主要适用于：
- 结构管理员：负责监督组织中的 Fabric 实现的管理员。
- 卓越中心（CoE）、IT 和商业智能（BI）团队：负责监督组织中数据和 BI 的使用以及在整个组织中支持自助服务用户的团队。
本文可能对在工作区中创建、发布和管理内容的自助服务内容创作者有所帮助。
由于工作区可以采用不同的方式使用，因此大多数战术实现决策是在 工作区级别做出的。 您在租户级别进行一些战略规划决策。
建议尽早做出租户级别的工作区决策，因为这些决策会影响到其他所有内容。 此外，当你清楚总体工作区目标和目标时，更容易做出单个工作区决策。
备注
工作区的概念源自 Power BI。 在 Fabric 中，工作区的用途会扩大。 Fabric 工作区可以包含来自多个 Fabric 体验（也称为 负载）的项目。 尽管内容范围比 Power BI 更广，但你可以应用这些文章中所述的大部分工作区规划活动来规划 Fabric 工作区。
工作区创建权限
允许谁在 Power BI 服务中创建工作区的决定是数据文化和治理决策。
可以使用两个选项：
- 所有（或大多数）用户可以创建新的工作区：此方法通常与其他应用程序的现有决策保持一致。 例如，当允许用户创建其自己的 SharePoint 网站或 Teams 频道时，Fabric采用相同的策略是合理的。
- 工作区创建仅限于一组选定的用户：此方法通常表示治理计划已到位或计划。 可以完全集中管理此过程（例如，仅允许 IT 创建工作区）。 一种更灵活、更实用的做法是将集中式人员和分散型人员进行组合。 在这种情况下，经过培训的 CoE 的具体附属成员、负责人或受信任的用户将代表其业务部门创建和管理工作区。
你应根据允许谁创建工作区的决策，在Fabric 管理门户中设置创建工作区租户设置。 有关详细信息，请参阅治理工作区。
关键决策和行动清单，用于规划谁可以创建工作区：
- 确定并验证用户需求：安排与相关利益干系人和感兴趣的参与方进行协作讨论，以了解用户当前的工作方式。 目标是确保你已明确了解用户需求。
- 确定允许谁创建工作区：确定所有用户、只有集中式团队，还是某些集中式和分散式用户可以创建新的工作区。 确保决策有目的地与您在组织中的数据文化目标保持一致。 请务必获得执行发起人的批准。
- 为允许创建工作区的人员创建安全组：如果用户的子集可以创建工作区，请为这些用户创建安全组。 明确命名组，例如 Fabric 工作区创建者。 将允许创建工作区的成员添加到此安全组。
- 更新租户设置：将新的安全组添加到管理门户中的 “创建工作区租户 ”设置。 除了 Fabric 工作区创建者组，可能分配此租户设置的其他组是 CoE、支持和 Fabric 管理员。
工作区命名约定
工作区命名约定是一种关于如何命名工作区的商定模式。 通常，命名约定是一项要求，而不是建议。
当许多用户有权创建工作区时，很难严格强制执行命名约定。 你可以通过用户教育和培训来解决此问题。 还可以执行审核过程来查找不符合命名约定的工作区。
工作区名称可以传达有关工作区的其他信息，包括：
- 目的：工作区名称应始终包含其内容的说明。 例如，销售季度奖金跟踪。
- 项类型：工作区名称可以包含对它所包含的项类型的引用。 例如，使用 “销售数据” 来指示工作区存储 lakehouse 或语义模型等项。 销售分析 可以指示工作区存储分析报表和仪表板。
- 阶段（环境）：工作区名称可能包括其阶段。 例如，通常会使用单独的工作区来存储开发、测试和生产以进行生命周期管理。
- 所有权和责任：工作区名称可能包括负责管理内容的人员的指示。 例如，使用“SLS”前缀或后缀可以指示销售团队拥有和管理内容。
提示
若要使工作区名称保持短，可以在工作区说明中包含更多详细信息。 但是，请确保工作区名称中包含最相关的信息，特别是如果你预计用户将搜索工作区。 还可以使用工作区映像来扩充工作区名称。 下一篇文章的工作区设置部分将进一步介绍这些注意事项。
保持工作区名称一致对每个人都有益。 用户体验会得到改进，因为用户可以更轻松地查找内容。 此外，当使用可预测的命名约定时，管理员可以更轻松地监督内容。
以下列表介绍了与工作区命名相关的更多注意事项。
使用简短的描述性名称：工作区名称应准确反映其内容，名称开头最重要的部分。 在 Fabric 门户服务中，较长的工作区名称在用户界面中可能会被截断，需要用户将光标悬停在工作区名称上才能在工具提示中显示全名。 下面是简短但具有描述性的名称示例：季度财务。
使用标准前缀：标准前缀可以将类似的工作区一起排列，并进行排序。 例如：FIN-季度财务。
使用标准后缀：可以为其他信息添加后缀，例如，使用不同的工作区进行开发、测试和生产。 建议追加 [开发] 或 [测试] 后缀，但将生产工作区保留为不带后缀的用户友好名称。 例如：FIN-季度财务 [开发]。
与 Power BI 应用名称保持一致：工作区名称和 Power BI 应用可能有所不同，尤其是在它提高应用使用者的可用性或可理解性时。 我们建议使名称保持相似，以避免混淆。
省略不必要的字词：以下字词可能是冗余的，因此请避免在工作区名称中使用这些字词：
- “工作区”一词。
- 单词 Fabric 或 Power BI。 许多 Fabric 工作区包含来自各种工作负载的项。 但是，可以创建一个仅面向特定工作负荷的工作区（例如 Power BI、数据工厂或 Synapse 数据工程）。 在这种情况下，可以选择一个短后缀，以便明确工作区用途。
- 组织名称。 但是，当主要受众是外部用户时，包含组织名称可能会有所帮助。
备注
建议在计划更改工作区名称时通知用户。 在大多数情况下，在 Fabric 门户中重命名工作区是安全的。 GroupID 值（工作区的唯一标识符）不会更改，并且是工作区 URL 的一部分。 但是， XMLA 连接 会受到影响，因为它们使用工作区名称而不是 GroupID 值进行连接。
规划工作区命名约定时需要考虑的关键决策和操作的清单：
- 确定工作区名称的要求或首选项：考虑如何命名工作区。 决定是创建严格的命名约定要求，还是允许以建议和示例为指导的更灵活的要求。
- 查看现有工作区名称：根据需要更新现有工作区名称，以便用户能够遵循这些名称。 当用户看到现有工作区已重命名时，他们会将其解释为要采用的隐含标准。
- 创建工作区命名约定的文档：提供有关工作区命名约定要求和准则的参考文档。 请务必包含展示正确使用首字母缩略词、前缀和后缀的示例。 在集中式门户和培训材料中提供信息。
工作区域
在规划和实施过程中，明确您希望如何拥有和管理内容至关重要。 当创建和管理数据资产的责任分散在许多部门或业务部门之间时，明确性尤其重要。 有时，此方法称为 分布式、 联合或 数据网格 体系结构。
在 Fabric 中支持工作区所有权和管理的一种方法是使用域。 域提供了一种方法，用于对具有相似特征的多个工作区进行逻辑分组。 例如，可以创建一个域来将所有销售工作区组合在一起，并创建另一个域来保存财务工作区。
以下是使用域的主要优势：
- 域将类似的工作区分组到单个管理边界中。
- 域允许在域级别管理特定租户设置。 有关详细信息，请参阅替代租户级设置。
- 域可帮助用户查找相关数据。 例如，他们可以在 OneLake 目录中使用筛选器。
下表列出了组织相关工作区的不同方式：
| 组织工作区的方法 | 示例域 |
|---|---|
| 按主题区域、域或内容类型 | Finance 域包括与财务内容相关的所有工作区。 |
| 由拥有和管理内容的团队或部门 | 企业 BI域包括团队直接负责管理的所有工作区。 |
| 按组织业务部门细分市场 | 欧洲划分域包括与欧洲运营直接相关的所有工作区。 |
| 按项目 | 子公司收购领域包括支持高度敏感项目的所有工作区。 |
下面是在租户中规划 Fabric 域时要考虑的一些问题：
- 每个工作区如何与域映射？ 每个工作区只能分配给一个域，因此请做好一些详细的规划准备。 请考虑创建矩阵关系图，用于列出列中行和域中的工作区，以帮助规划分配工作区的方式。 如果发现需要重新组织工作区，可以在工作区设置或管理门户中重新分配域。
- 谁有权管理域？ 分配有域管理员角色的用户有权管理现有域。 如果可能，请分配直接拥有和管理域内容的域管理员。 域管理员应是熟悉主题领域的内部、区域和政府法规的专家。 他们还应该熟悉所有内部治理和安全要求。 有关详细信息，请参阅域角色。
- 谁有权限向域分配工作区？ 被分配“域贡献者”角色的用户决定哪些工作区管理员可以将工作区分配到域。 如果允许更多用户将工作区分配给域，则应经常审核分配的分组的准确性。 如果仅允许特定用户组或 Fabric 管理员和域管理员，则可以更好地控制域的分配方式。 有关详细信息，请参阅域角色。
- 是否具有特定的合规性需求或限制，例如地理区域？ 请记住，数据存储的地理区域是为每个存储容量设置的，而不是为域设置的。 考虑将工作区分配到领域和容量会如何影响您的规划过程。
有关详细信息，请参阅治理域。
规划工作空间域时的关键决策和清单：
规划工作域时，关键决策和行动包括：
- 验证内容所有权的工作原理：确保你深刻地了解整个组织中内容所有权和管理是如何发生的。 将信息纳入计划，以便将工作区组织到域中。
- 规划工作区域：讨论如何最好地将工作区组织到域中。 请与 CoE 和高管赞助人确认所有关键决策。
- 教育和培训 Fabric 管理员：确保租户管理员熟悉如何创建域，以及如何分配和管理域管理员的职责。
- 教育域管理员：确保域管理员了解管理域时此角色的预期。
- 决定如何处理域参与者：考虑哪些用户应有权将工作区分配给域。
- 创建审核过程：定期验证分配的域分组是否正确。
工作区创建过程
如果决定限制谁可以创建工作区，更广泛的用户群体需要知道请求新工作区的过程。 在这种情况下，建立一个便于用户查找和遵循的请求过程非常重要。
快速响应针对新工作区的请求也至关重要。 服务级别协议（SLA）为 2 到 4 小时是理想的。 如果请求新工作区的过程太慢或负担过重，则人们将使用他们拥有的工作区，以便他们可以继续移动。 如果他们选择跳过创建新工作区，那么他们使用的工作区可能不是最佳选择。 他们可能会选择重复使用不适合新内容的现有工作区，或者可能共享来自其个人工作区的内容。
提示
创建新流程时，目标是使用户能够轻松遵守该过程。 与所有数据治理决策一样，关键是让用户能够轻松地遵循记录的过程。
下表列出了在申请创建新工作区时需要收集的信息。
| 所需信息 | 示例： | 需要验证 |
|---|---|---|
| 工作区名称 | SLS-区域销售分析 | • 名称是否遵循命名约定？ • 是否存在具有相同名称的其他工作区？ |
| 所需的阶段 | SLS-现场销售分析 [开发]、SLS-现场销售分析 [测试] 和 SLS-现场销售分析 | • 是否需要多个工作区才能为内容提供适当的支持？ • 如果是，是否还应创建部署管道？ |
| 说明 | 用于每月、每季度和每年分析的客户销售和订单历史记录。 | • 是否期望将存储敏感数据或管控数据？ • 如果是，这是否将影响工作区的治理方式？ |
| 目标读者 | 全球现场销售组织 | • 内容传递范围有多广泛？ • 该范围将如何影响工作区的治理方式？ |
| 分配给工作区的许可证模式 | 销售团队需要 Fabric 容量，因为许多销售人员只是查看者，并且他们拥有免费许可证 | • 需要哪种级别的 Fabric 容量？ |
| 数据存储要求 | 加拿大的数据驻留 | • 数据驻留需求是否需要 多区域？ • 预期处理和存储的数据量是多少？ |
| 工作区管理员 | FabricContentAdmins-FieldSalesAnalytics | • 管理员（最好）是一个组吗？ • 是否至少分配了两个管理员？ |
| 提交请求的人员 | requestor@contoso.com | • 提交请求的人员是否担任与所提供信息相关的角色或从事相关业务？ |
此表包含设置工作区所需的最小信息量。 但是，它不包括所有可能的配置。 在大多数情况下，工作区管理员负责在创建工作区后完成设置。 有关详细信息，请参阅 工作区级设置。
可以从许多技术选项中进行选择，为工作区创建请求创建联机表单。 请考虑使用 Microsoft Power Apps，这是一种低代码软件选项，非常适合用于生成简单的基于 Web 的表单和应用程序。 选择用于创建基于 Web 的表单的技术取决于负责创建和维护表单的人员。
提示
若要提高效率和准确性，请考虑使用 Power BI REST API 以编程方式创建或更新工作区来自动执行该过程。 在这种情况下，建议包括评审和审批流程，而不是自动处理每个请求。
规划请求新工作区过程中的关键决策和操作清单：
- 建立请求新工作区的过程：确定请求新工作区的具体过程。 请考虑所需的信息、如何捕获信息以及处理请求的人员。
- 创建用于请求新工作区的标准窗体：确定要包含在新工作区的窗体上的信息。 请考虑构建 Power Apps 应用，以从用户处收集信息。 确保表单的链接广泛可用，并且易于在集中式门户和其他常见位置中找到。 还需在正在进行的通信中包含表单的链接。
- 确定谁将响应提交的请求以及请求的速度：确定谁将处理请求。 考虑处理新工作区请求的预期响应时间。 验证你是否可以快速处理请求，以便自助服务用户不会遇到延迟。
- 进行知识转移会话：如果另一个团队将支持工作区请求过程，请与他们进行知识转移会话，以便他们拥有所需的全部信息。
- 创建有关如何批准或拒绝请求的文档：创建针对审核或处理请求人员的批准或拒绝请求的文档。 此外，还需包括请求可能被拒绝的原因，以及应采取的操作。
- 创建有关如何请求工作区的文档：创建有关如何请求新工作区的文档，这些工作区面向无法创建自己的工作区的用户。 需包括所需的信息以及对响应的预期。 确保在集中式门户和培训材料中提供这些信息。
工作区治理级别
并非所有工作区都需要相同级别的监督。 某些工作区可能被视为“受治理”。 受治理的工作区对内容的要求和期望更高。 某些组织使用“受管理”一词，而不是“受治理”。
四个关键决策条件决定了所需的治理级别：
- BI 内容由谁拥有和管理？
- BI 内容交付的范围。
- 什么是数据主体区域？
- 数据或 BI 解决方案是否被视为关键？
备注
有关四个关键决策条件的详细信息，请参阅 Fabric 采用路线图中的治理文章。
你可以从两个级别的工作区入手：受治理和不受治理。 建议尽可能使治理级别保持简单。 但是，根据具体情况，你可能需要细分受治理分类。 例如，企业 Power BI 团队管理的关键内容可能具有一组独特的治理要求。 业务部门拥有和管理的关键内容可能会受到一组略有不同的要求。 在某些情况下，决策是针对单个业务部门定制的。
下表列出了将工作区视为受治理时的一些最常见要求。
| 类别 | 潜在的治理要求 |
|---|---|
| 所有权和支持 | • 分配 所有权 ，明确了技术内容所有者或主题专家的责任。 • 分配用户支持团队/人员，并且用户了解如何请求帮助或提交问题。 • 提供一种用于用户反馈、问题和增强请求的机制。 • 有一个沟通计划用于宣布对工作区中内容的重要更改。 |
| 工作区设置 | • 工作区组织得井然有序，目标明确。 • 使用特定的命名约定。 • 工作区分配给特定域。 • 工作区说明、映像和联系人是必需的。 |
| 精确度 | • 所有内容都经过认证。 • 数据验证是自动化的，以便内容所有者能够及时了解数据质量问题。 |
| 分布 | • Power BI 应用用于分发报表和仪表板。 |
| 安全性和数据保护 | • 使用 安全组（而不是单个帐户）管理工作区角色。 • 使用敏感度标签进行信息保护。 • 仅允许已批准的数据源。 • 所有源文件都驻留在安全的备份位置。 |
| 更改管理 | • 使用单独的开发、测试和生产工作区。 •源代码管理（例如 Git 集成）用于 Fabric 门户中的所有 Power BI Desktop 文件和项。 • 所有数据源文件都使用版本控制或源控制。 • 遵循生命周期管理 和变更管理过程，包括部署管道或 DevOps 流程。 |
| 容量 | • 工作区分配到相应的 Fabric 容量级别。 • Fabric 容量受到管理和监视。 |
| 网关 | • 使用标准模式（非个人）的 数据网关。 • 所有网关数据源凭据都使用已批准的凭据。 |
| 审核和监视 | • 为跟踪采用情况、使用模式和性能，已制定了主动审核和监视流程。 |
提示
治理要求通常不是可选的。 因此，及时审核很重要，并且在某些情况下，有必要强制执行。 例如，如果受治理的工作区要求所有文件都位于安全位置，并在审核期间检测到未经批准的文件位置，则需要更新文件位置。
规划工作区治理级别时，有几个关键决策和行动需要注意，可参见关键决策和行动清单：
- 确定工作区治理级别：确定所需的治理级别。 尽可能简单。
- 确定如何对工作区进行分类的条件：确定用于将工作区分类到特定治理级别的决策条件。
- 确定工作区治理要求是什么：对于每个治理级别，确定具体要求。
- 决定如何指定工作区治理级别：查找最简单的方式来标识工作区的治理级别。 你可以将它记录为名称的一部分、说明的一部分或将它存储在其他位置（例如包含有关每个工作区的详细信息的 SharePoint 列表）。
- 创建工作区治理要求的文档：创建面向内容创建者的有用文档，其中包括管理受管理工作区中的内容的责任。 在集中式门户和培训材料中提供信息。
- 创建工作区审核流程：对于被视为受治理的工作区，请创建一个审核过程，以识别不符合最重要的要求的区域。 确保有人负责联系内容所有者以解决合规性问题。