Microsoft Fabric 采用路线图：系统监督

注意

本文是 Microsoft Fabric 采用路线图系列文章的一部分。 有关该系列文章的概述，请参阅 Microsoft Fabric 采用路线图。

系统监督（也称为 Fabric 管理）是持续进行的日常管理活动。 特别是涉及到：

• 治理：制定治理准则和策略以支持自助式和企业数据及商业智能 (BI) 方案。
• 用户授权：在遵守组织规定和要求的同时，促进和支持内部流程和系统，尽可能地为内部用户社区提供支持。
• 采用：通过有效的治理和数据管理实践，让组织更广泛地采用 Fabric。

重要

组织数据文化目标为治理决策提供方向，而治理决策又决定了 Fabric 管理活动的执行方式和执行人员。

系统监督是一个广泛而深入的主题。 本文旨在介绍一些最重要的注意事项和措施，以帮助你成功实现组织采用目标。

Fabric 管理员

Fabric 管理员角色是在 Microsoft 365 中定义的角色，可委托一组管理活动。 全局 Microsoft 365 管理员隐式具有 Fabric 管理员身份。 Power Platform 管理员也隐式具有 Fabric 管理员身份。

一个关键治理决策是，将谁分配为 Fabric 管理员。 它是一个影响整个租户的集中式角色。 理想情况下，组织中有 2-4 人能够管理 Fabric。 管理员应与卓越中心 (COE) 密切协作。

高特权角色

Fabric 管理员角色是高特权角色，因为：

• 用户体验：由 Fabric 管理员管理的设置对用户功能和用户体验有重大影响。 有关详细信息，请参阅治理租户设置。
• 完全安全访问权限：Fabric 管理员可以更新租户中工作区的访问权限。 结果是管理员可提供允许查看或下载其认为合适的数据和报表的权限。 有关详细信息，请参阅治理租户设置。
• 个人工作区访问权限：Fabric 管理员可以访问内容并管理任何用户的个人工作区。
• 元数据：Fabric 管理员可以查看所有租户元数据，包括 Fabric 门户中发生的所有用户活动（在下面的审核和监视部分中介绍）。

重要

拥有过多的 Fabric 管理员将面临风险。 这会增加未经批准、意外或不一致的租户管理的可能性。

角色和职责

管理员日常执行的活动类型因组织而异。 在数据文化中，重要事项以及需要优先处理的事项将极大地影响管理员对业务导向型自助式、托管自助式和企业数据及 BI 方案采取的支持措施。 有关详细信息，请参阅内容所有权和管理一文。

提示

最好是让足够了解相关工具和工作负载，并知道自助服务用户所需完成任务的人员担任 Fabric 管理员。 有了这一理解，管理员便可以在用户授权和治理之间进行平衡。

除了 Fabric 管理员，还有其他角色使用术语“管理员”。 下表描述了常见以及经常使用的角色。

角色	范围	描述
Fabric 管理员	租户	管理租户设置和 Fabric 门户中的其他设置。 本文在一般情况下提到的所有“管理员”都指这种类型的管理员。
容量管理员	一个容量	管理工作区和工作负载，并监视 Fabric 容量的健康状况。
数据网关管理员	一个网关	管理网关数据源配置、凭据和用户分配。 还可以处理网关软件更新（或与基础结构团队协作处理更新）。
工作区管理员	一个工作区	管理工作区设置和访问权限。

工作负载的 Fabric 生态系统广泛而深入。 Fabric 可通过多种方式与其他系统和平台集成。 有时，有必要与其他管理员和 IT 专业人员合作。 有关详细信息，请参阅与其他管理员协作。

本文的其余部分概述了 Fabric 管理员最常执行的活动。 这些内容侧重于在采取战略方法来实现组织采用时有效开展的重要活动。

服务管理

监督租户是确保所有用户都在使用 Power BI 时具有良好体验的一个关键方面。 Fabric 管理员的一些关键治理职责包括：

• 租户设置：控制将启用哪些 Power BI 特性和功能，以及为组织中的哪些用户启用。
• 域：将两个或多个具有相似特征的工作区组合在一起。
• 工作区：查看和管理租户中的工作区。
• 嵌入代码：管理哪些报表已在 Internet 上公开发布。
• 组织视觉对象：注册和管理组织视觉对象。
• Azure 连接：与 Azure 服务集成以提供其他功能。

有关详细信息，请参阅租户管理。

用户计算机和设备

Fabric 的采用情况直接取决于内容创建者和使用者是否具有所需的工具和应用程序。 下面是一些重要考虑因素。

• 用户如何请求获取新工具？ 是否提供对许可证、数据和培训的访问权限有助于用户有效地使用工具？
• 内容使用者如何查看其他人发布的内容？
• 内容创建者将如何开发、管理和发布内容？ 决定每个用例应使用哪些工具和应用程序的标准是什么？
• 如何安装和设置工具？ 这是否包括相关的先决条件和数据连接组件？
• 如何管理工具和应用程序的持续更新？

有关详细信息，请参阅用户工具和设备。

体系结构

在 Fabric 的上下文中，体系结构与数据体系结构、容量管理和数据网关体系结构和管理相关。

数据体系结构

数据体系结构是指用于管理和定义所收集数据以及这些数据的引入、存储、管理、集成、建模和使用方式的原则、实践和方法。

需要制定许多数据体系结构决策。 COE 通常会参与数据体系结构设计和规划。 管理员通常也会参与其中，特别是在负责管理数据库或 Azure 基础结构时。

重要

数据体系结构决策会对 Fabric 采用情况、用户满意度和各项目的成功率产生显著影响。

影响采用的一些数据体系结构注意事项包括：

• Fabric 适合组织整个数据体系结构中的哪个位置？ 是否需要将其他现有组件（如企业数据仓库 (EDW) 或数据湖）纳入计划？
• Fabric 是以端到端的方式用于数据准备、数据建模和数据展示，还是仅用于其中某些功能？
• 是否遵循托管的自助服务模式在数据可重用性和报表创建者灵活性之间找到最佳平衡？
• 用户将在何处使用内容？ 通常，传递内容的三种主要方式为：Fabric 门户、Power BI 报表服务器和嵌入自定义应用程序。 此外，对于在 Teams 花费大量时间的用户，Microsoft Teams 是一种简便替代方法。
• 谁负责管理和维护数据体系结构？ 是集中式团队还是分散型团队？ COE 在此团队中是如何体现的？ 是否需要特定的技能集？
• 哪些数据源最为重要？ 我们将获取什么类型的数据？
• 什么语义模型连接模式和存储模式选项（例如 Direct Lake、导入、实时连接、DirectQuery 或复合模型框架）最适合该用例？
• 使用湖屋、仓库和共享语义模型可在多大程度上鼓励数据重用？
• 使用数据管道、笔记本和数据流可在多大程度上鼓励数据准备逻辑和高级数据准备的重用？

在做出体系结构决策之前，管理员必须完全了解 Fabric 的技术功能及其利益干系人的需求和目标。

提示

养成通过完成技术概念证明 (POC) 来验证假设和想法的好习惯。 当目标是提供一个小型工作单元时，一些组织也将它们称为微项目。 POC 的目标是尽早解决未知问题并降低风险。 POC 不一定是一次性的，但应采用较窄的范围。 如启导和用户支持一文中所述，最佳做法评审是另一种可帮助内容创建者制定重要体系结构决策的有用方法。

容量管理

容量包括用于大规模提供分析解决方案的功能。 有两种类型的 Fabric 组织许可证：Premium per User (PPU) 和容量。 有多种类型的容量许可证。 容量许可证的类型决定支持哪些 Fabric 工作负载。

重要

有时本文指的是 Power BI Premium 或其容量订阅 (P SKU)。 请注意，Microsoft 目前正在合并购买选项并停用 Power BI Premium Per Capacity SKU。 新客户和现有客户应考虑改为购买 Fabric 容量订阅 (F SKU)。

有关详细信息，请参阅 Power BI Premium 许可即将进行的重要更新和 Power BI Premium 常见问题解答。

在用于创建、管理、发布和分发内容的策略中，使用容量可以起到重要作用。 投资使用容量的一些主要原因包括：

• 不受限制地将 Power BI 内容分发给大量只读用户。 （仅 Premium 容量中支持用户通过免费 Power BI 许可证使用内容，而 PPU 中不支持）。 F64 Fabric 容量许可证或更高版本也支持免费用户使用内容。
• 访问 Fabric 体验以生成端到端分析。
• 部署管道，用于管理对开发、测试和生产工作区进行的内容发布。 强烈建议将其用于关键内容，以提高发布稳定性。
• XMLA 终结点，这是用于管理和发布语义模型或从任何 XMLA 兼容工具查询语义模型的行业标准协议。
• 提高模型大小限制，包括对大语义模型的支持。
• 提高了刷新数据频率。
• 在不同于主区域的特定地理区域存储数据。

上面的列表并不包含全部信息。 有关完整列表，请参阅 Power BI Premium 功能。

管理 Fabric 容量

对管理员来说，监视 Fabric 容量的运行状况是一项必不可少的持续活动。 每个容量 SKU 都包含一组资源。 容量单位 (CU) 用于测量每个 SKU 的计算资源。

注意

缺乏管理以及始终超出容量资源限制通常会为性能和用户体验带来挑战。 如果管理不当，这两方面的挑战可能对采用工作产生负面影响。

对管理 Fabric 容量的建议：

• 定义负责管理容量的人员。 确认角色和责任，以便明确要执行的操作、执行原因、执行时间以及执行人员。
• 为将发布到容量的内容创建一组特定的条件。 当多个业务部门使用单个容量时，这一点特别重要，因为如果该容量没有得到妥善管理，就有可能干扰其他用户。 在将新内容发布到生产容量之前，请考虑要求进行最佳做法评审（例如合理的语义模型大小和高效计算）。
• 定期使用 Fabric 容量指标应用来了解容量的资源利用率和模式。 最重要的是找到过度使用的一贯模式，过度使用会导致用户中断。 对使用模式的分析还应让你知道容量是否未得到充分利用，表明是否可以从此项投资中获得更多价值。
• 设置租户设置，以便 Fabric 在容量过载或者发生中断或事件时通知你。

自动缩放

自动缩放旨在处理容量使用级别偶尔出现或意外出现的突发。 自动缩放可通过自动增加 CPU 资源来支持增加的工作负载，从而响应这些突发。

自动纵向扩展可以降低性能和用户体验挑战方面的风险，但会使经济成本增加。 如果容量未得到妥善管理，则自动缩放的触发频率可能会高于预期。 在这种情况下，指标应用有助于确定潜在问题并执行容量计划。

分散式容量管理

容量管理员负责向特定容量分配工作区。

请注意，如果工作区管理员拥有 PPU 许可证，则他们还可以将工作区分配至 PPU。 但是这要求所有其他工作区用户都必须具有 PPU 许可证才能在工作区协作处理或查看 Power BI 内容。 其他 Fabric 工作负载不能包含在分配给 PPU 的工作区中。

可以设置多个容量，以促进由不同业务部门进行的分散式管理。 对 Fabric 的某些方面采用分散式管理，可以很好地平衡灵活度和控制力。

以下示例介绍了管理容量的一种方法。

• 通过 Microsoft 365 购买 P3 容量节点。 它包括 32 个虚拟核心。
• 使用 16 个虚拟核心创建第一个容量。 它将由销售团队使用。
• 使用 8 个虚拟核心创建第二个容量。 它将由运营团队使用。
• 使用剩余的 8 个虚拟核心创建第三个容量。 它将用于常规用途。

前面的示例做法有多个优点。

• 可以为每个容量设置单独的容量管理员。 因此，它有利于分散式管理的情况。
• 如果某个容量管理不善，则负面影响也仅限于该容量。 其他容量不会受到影响。
• 对其他业务部门的计费和退款非常简单。
• 可以轻松地将不同工作区分配给单独的容量。

但是，前面的示例做法也有缺点。

• 每个容量的限制都更低。 语义模型允许的最大内存大小并不是已购买的 P3 容量节点的全部大小。 而是托管语义模型的分配容量大小。
• 在某个时间点，其中一个较小的容量更有可能需要纵向扩展。
• 租户中有更多容量要管理。

注意

Power BI Premium per Capacity 的资源称为虚拟核心。 但是，Fabric 容量将它们称为容量单位 (CU)。 对于每个 SKU，CU 和虚拟核心的规模不同。 有关详细信息，请参阅 Fabric 许可文档。

数据网关体系结构和管理

数据网关有助于在组织数据源与 Fabric 服务之间安全高效地传输数据。 当数据源具有以下特点时，需要使用数据网关来建立与本地或云服务的数据连接：

• 位于企业数据中心内。
• 配置在防火墙后。
• 在虚拟网络中。
• 在虚拟机中。

有三种类型的网关。

• 本地数据网关（标准模式）是支持连接到已注册数据源以供多位用户使用的网关服务。 网关软件安装和更新安装在由客户管理的计算机上。
• 本地数据网关（个人模式）是仅支持数据刷新的网关服务。 此网关模式通常安装在内容创建者的电脑上。 仅支持一个用户使用。 不支持实时连接或 DirectQuery 连接。
• 虚拟网络数据网关是一项 Microsoft 托管服务，支持许多用户的连接。 具体而言，它支持存储在分配给 Premium 容量或 Premium Per User 的工作区中的语义模型和数据流的连接。

提示

关于谁能安装网关软件的决策是一项治理决策。 对于大多数组织，强烈建议在标准模式下使用数据网关或虚拟网络数据网关。 它们比个人模式下的数据网关更具可伸缩性、可管理性和可审核性。

分散式网关管理

本地数据网关（标准模式）和虚拟网络数据网关支持可注册的特定数据源类型，以及连接详细信息和存储凭据的方式。 可以向用户授予使用网关数据源的权限，以便他们可以计划刷新或运行 DirectQuery 查询。

可以有效地对网关的某些方面进行分散式管理，从而平衡灵活度和控制力。 例如，操作组可能有一个专用于自助内容创建者和数据所有者团队的网关。

分散式网关管理在如下所示的协同工作中效果最好。

由分散式数据所有者管理：

• 部门数据源连接信息和隐私级别。
• 部门数据源存储的凭据（包括负责更新定期密码更改）。
• 获准使用每个数据源的部门数据源用户。

由集中式数据所有者管理（包括在整个组织中广泛使用的数据源；采用集中式管理以避免重复数据源）：

• 集中式数据源连接信息和隐私级别。
• 集中式数据源存储的凭据（包括负责更新定期密码更改）。
• 获准使用每个数据源的集中式数据源用户。

由 IT 管理：

• 网关软件更新（通常每月发布网关更新）。
• 安装驱动程序和自定义连接器（与在用户计算机上安装的相同）。
• 网关群集管理（管理网关群集中的计算机数，以实现高可用性和灾难恢复，并消除可能导致重大用户中断的单一故障点）。
• 服务器管理（例如操作系统、RAM、CPU 或网络连接）。
• 网关加密密钥的管理与备份。
• 监视网关日志，评估何时需要纵向扩展或横向扩展。
• 在网关计算机上发出停机或持续资源不足警报。

提示

允许分散式团队管理网关的某些方面意味着能提高敏捷性。 分散式网关管理的折衷确实意味着运行更多网关服务器，每个网关服务器都可以专用于组织的特定区域。 如果网关管理完全由 IT 处理，则必须制定良好的流程，以快速处理添加数据源和应用用户更新的请求。

用户许可证

每个用户都需要具有商业许可证，该许可证与 Microsoft Entra 标识集成。 用户许可证可能为免费许可证、Pro 许可证或 Premium Per User (PPU) 许可证。

用户许可证通过订阅获取，订阅可授予一定数量的许可证及开始日期和结束日期。

注意

尽管每个用户都需要许可证，但只有共享 Power BI 内容才需要 Pro 或 PPU 许可证。 拥有免费许可证的用户可以创建和共享 Power BI 项以外的 Fabric 内容。

有两种获取订阅的方法。

• 集中式：Microsoft 365 账单管理员购买 Pro 或 PPU 的订阅。 这是管理订阅和分配许可证最常见的方法。
• 分散式：各部门通过自助购买购买订阅。

自助购买

与允许或鼓励自助购买的程度相关的重要治理决策。

自助购买适用于以下情况：

• 具有分散式业务部门的较大组织，这些业务部门具有购买权限，并且想使用信用卡直接处理付款。
• 希望尽可能轻松地基于每月承诺购买订阅的组织。

请在以下情况考虑禁用自助购买：

• 已制定集中式采购流程以满足法规、安全和治理要求。
• 折扣价格是通过企业协议 (EA) 获得的。
• 已有处理公司间退款的现有流程。
• 已有处理基于组的许可分配的现有流程。
• 获取许可证需要满足一些先决条件，例如审批、论证、培训或治理策略要求。
• 有必要（例如根据法规要求）严密控制访问权限。

用户许可证试用版

另一个重要的治理决策是，是否允许使用用户许可证试用版。 默认情况下，将启用试用。 这意味着，与同事共享内容时，如果收件人没有 Pro 或 PPU 许可证，系统会提示他们开始试用以查看内容（当内容不位于容量支持的工作区中时）。 试用体验能旨在提供便利，使用户能够继续执行其正常工作流。

通常不建议禁用试用。 禁用试用会促使用户寻找替代方法，可能是通过导出数据或在受支持的工具和流程之外工作。

仅在以下情况下考虑禁用试用：

• 存在严重的成本问题，使得在试用期结束时不太可能授予完整的许可证。
• 获取许可证需要满足一些先决条件（例如审批、论证或培训要求）。 在试用期间不足以满足此要求。
• 有必要（例如根据法规要求）密切地控制对 Fabric 服务的访问。

提示

请勿为获得 Fabric 许可证设置太多障碍。 需要完成工作的用户将找到相关方法，该方法可能涉及不理想的替代方法。 例如，如果没有 Fabric 的使用许可，当有明显更好的方法时，人们可能会过于依赖文件系统或通过电子邮件来共享文件。

成本管理

管理和优化云服务（如 Fabric）的成本是一项重要活动。 下面是可以考虑的几个活动。

• 分析谁正在使用（更确切地说是谁没有使用）向其分配的 Fabric 许可证，并做出必要的调整。 使用活动日志分析 Fabric 使用情况。
• 分析容量或 Premium Per User 的成本效益。 除了附加功能外，还执行成本/收益分析，以确定当有大量使用者时，容量许可是否更具成本效益。
• 仔细监视和管理 Fabric 容量。 了解一段时间的使用模式，以便预测购买更多容量的时间。 例如，可以选择将单个容量从 P1 纵向扩展为 P2，或者从一个 P1 容量横向扩展为两个 P1 容量。
• 如果偶尔出现使用级别峰值，建议使用 Fabric 的自动缩放功能，以确保用户体验不会中断。 自动缩放将在 24 小时内纵向扩展容量资源，然后将其纵向缩减到正常水平（如果不存在持续活动）。 通过限制虚拟核心的最大数量和/或在 Azure 中设置支出限制来管理自动缩放成本。 由于定价模型，自动缩放最适合处理偶然出现的意外使用量增加。
• 对于 Azure 数据源，请尽可能将它们与 Fabric 租户置于同一区域。 这将避免产生 Azure 传出费用。 数据传出费用很少，但大规模相加可能会产生相当可观的计划外成本。

安全性、信息保护和数据丢失防护

安全性、信息保护和数据丢失防护 (DLP) 是所有内容创建者、使用者和管理员的共同责任。 这不是一项轻松的任务，因为所有位置都有敏感信息：个人数据、客户数据或客户创作的数据、受保护的运行状况信息、知识产权、专有组织信息等。 政府、行业和合同法规可能会显著影响你所创建的安全性相关治理准则以及策略。

Power BI 安全性白皮书是非常有用的资源，可以帮助我们理解各种考虑事项，包括 Microsoft 管理的一些方面。 本部分将介绍客户负责管理的几个主题。

用户责任

一些组织要求 Fabric 用户接受自助用户确认。 这是一个文档，说明了保护组织数据方面的用户责任和期望。

要自动实现它，一种方法是使用 Microsoft Entra 使用条款策略。 用户需要先查看并同意策略，然后才能获得首次访问 Fabric 门户的权限。 也可以要求定期确认获得权限，例如年度续签。

数据安全

在云共享责任模型中，保护数据始终是客户的责任。 在使用自助数据平台时，自助内容创建者有责任适当地保护与同事共享的内容。

COE 应在相关位置提供文档和培训，以帮助内容创建者采取最佳做法（尤其是处理超敏感数据时）。

管理员可以通过遵循最佳做法来提供帮助。 管理员还可以在发现管理工作区、审计用户活动或管理网关凭据和用户可能出现问题时提出自己的疑虑。 还有一些租户设置通常受到限制（例如发布到 Web 或将应用发布至整个组织的功能），少数用户除外。

外部来宾用户

外部用户（例如合作伙伴、客户、供应商和顾问）在某些组织中常见，但在其他组织中少见。 处理外部用户的方式是治理决策。

外部用户访问权限由租户设置和某些 Microsoft Entra ID 设置控制。 关于外部用户注意事项的详细信息，请查看使用 Microsoft Entra B2B 向外部来宾用户分发 Power BI 内容白皮书。

信息保护和数据丢失防护

Fabric 通过以下方式支持信息保护和数据丢失防护 (DLP) 的功能。

• 信息保护：Microsoft Purview 信息保护（以前称为Microsoft信息保护）包括发现、分类和保护数据的功能。 关键原则是，数据被分类后，可以得到更好的保护。 用于对数据进行分类的关键构建基块是敏感度标签。 有关详细信息，请参阅 Power BI 的信息保护规划。
• Power BI 数据丢失防护：Microsoft Purview 数据丢失防护（以前称为 Office 365 数据丢失防护）支持 Power BI 的 DLP 策略。 通过使用敏感度标签或敏感信息类型，Power BI 的 DLP 策略可帮助组织定位敏感语义模型。 有关详细信息，请参阅 Power BI 的数据丢失防护规划。
• Microsoft Defender for Cloud Apps：Microsoft Defender for Cloud Apps（前称为Microsoft云应用安全）支持帮助保护数据的策略，包括当用户与Power BI 服务交互时实时控制。 有关详细信息，请参阅 Defender for Cloud Apps for Power BI 规划。

数据驻留

对于需要在某个地理区域内存储数据的组织，可以为与 Fabric 租户所在主区域不同的特定区域设置 Fabric 容量。

加密密钥

Microsoft 在 Microsoft 数据中心通过透明服务器端加密和证书自动轮换处理静态数据加密。 对于因为法规要求而必须自行管理 Premium 加密密钥的客户，可将 Premium 容量配置为使用 Azure Key Vault。 使用客户管理的密钥（也称为“创建自己的密钥”或“BYOK”）是一种预防措施，可确保在服务操作员发生人为错误时，不会泄露客户的数据。

请注意，当为整个 Fabric 租户启用 Premium Per User (PPU) 时，仅支持 BYOK。

审核和监视

使用审核数据来分析采用工作、了解使用模式、指导用户、支持用户、降低风险、提高合规性、管理许可证成本以及监视性能，这一点至关重要。 若要详细了解审核数据为什么很有价值，请参阅审核和监视概述。

根据你的角色和目标，可通过不同的方式进行审核和监视。 以下文章介绍了各种注意事项和规划活动。

• 报表级审核：报表创建者可以用来了解哪些用户在使用他们创建、发布和共享的报表的技术。
• 数据级审核：数据创建者可用于跟踪其创建、发布和共享的数据资产的性能和使用模式的方法。
• 租户级审核：管理员在创建端到端审核解决方案时可以采取的关键决策和操作。
• 租户级监视：管理员可采取来监视 Power BI 服务（包括更新和公告）的策略操作。

REST API

Power BI REST API 和 Fabric REST API 提供了有关 Fabric 租户的大量信息。 在管理和治理 Fabric 实现方面，使用 REST API 检索数据应发挥重要作用。 若要详细了解如何针对审核规划对 REST API 的使用，请参阅租户级审核。

可检索审核数据来生成审核解决方案、以编程方式管理内容或提高例行操作的效率。 下表显示了可使用 REST API 执行的一些操作。

操作	文档资源
审核用户活动	用于获取活动事件的 REST API
审核工作区、项和权限	用于获取租户清单的异步元数据扫描 REST API 的集合
审核共享给整个组织的内容	用于检查广泛共享链接的使用情况的 REST API
审核租户设置	用于检查租户设置的 REST API
发布内容	用于从部署管道部署项或将报表克隆到另一个工作区的 REST API
管理内容	用于刷新语义模型的 REST API或接管语义模型的所有权
管理网关数据源	用于更新网关数据源凭据的 REST API
导出内容	用于导出报表的 REST API
创建工作区	用于创建新工作区的 REST API
管理工作区权限	用于为工作区分配用户权限的 REST API
更新工作区名称或说明	用于更新工作区属性的 REST API
还原工作区	用于还原已删除的工作区的 REST API
以编程方式从语义模型检索查询结果	用于对语义模型运行 DAX 查询的 REST API
向容量分配工作区	用于将工作区分配到容量的 REST API
以编程方式更改数据模型	表格对象模型 (TOM) API
在自定义应用程序中嵌入 Power BI 内容	Power BI Embedded 分析客户端 API

提示

还有许多其他的 Power BI REST API。 有关完整列表，请参阅使用 Power BI REST API。

规划更改

Microsoft 每月都会发布新的 Fabric 特性和功能。 为了提高效率，参与系统监督的每个人都必须了解这些更新。 有关详细信息，请参阅租户级监视。

重要

不要低估了解更新的重要性。 如果你在发布几个月后才知道，那么很难适当地管理 Fabric 并为用户提供支持。

注意事项和主要措施

清单 - 针对系统监督的注意事项和可采取的关键操作。

改进系统监督：

• 验证谁可以成为 Fabric 管理员：如果可能，请减少被授予 Fabric 管理员角色的人数（如果人数较多）。
• 为临时管理员使用 PIM：如果有人偶尔需要 Fabric 管理员权限，请考虑在 Microsoft Entra ID 中实现 Privileged Identity Management (PIM)。 PIM 旨在分配会在几小时后过期的实时角色权限。
• 培训管理员：检查关于 Fabric 管理职责的交叉培训和文件的状态。 确保培训后备人员，以便能够以一致的方式及时满足需求。

改进 Fabric 服务的管理：

• 审查租户设置：对所有租户设置进行评审，以确保租户符合数据文化目标以及治理准则和策略。 验证为每个设置分配了哪些组。
• 记录租户设置：创建内部 Fabric 社区租户设置文档并将其发布到集中式门户。 包括用户需要请求哪些组才能使用某项功能。 使用获取租户设置 REST API 使过程更高效，并定期创建设置的快照。
• 自定义“获取帮助”链接：在建立用户资源时，按照启导和用户支持一文中所述，更新租户设置，以对“获取帮助”菜单选项下的链接进行自定义。 该链接会将用户定向到你的文档、社区和帮助。

改进用户计算机和设备管理：

• 创建一致的加入流程：审查自己的流程，查看新内容创造者的加入方式。 确定是否可以将对软件（如 Power BI Desktop）和用户许可证（Free、Pro、PPU）的新请求一起处理。 这样可以简化加入过程，因为新的内容创造者并不总是清楚需要什么。
• 处理用户机器更新：确保实施安装和更新软件、驱动程序以及设置的自动化过程，从而确保所有用户拥有相同的版本。

数据结构规划：

• 评估端到端数据体系结构的外观：确保了解以下内容：
  • 组织中不同业务部门当前使用 Fabric 的方式与你期望的 Fabric 使用方式。 确定是否存在差异。
  • 是否存在应该解决的风险。
  • 是否存在要解决的难以维护的情况。
  • 对于 Fabric 用户非常重要的数据源，以及如何记录和发现这些数据源。
• 查看现有数据网关：了解整个组织正在使用的网关。 验证是否正确设置了网关管理员和用户。 验证各个网关的支持人员，并确保有可靠的流程可将网关服务器保持为最新状态。
• 验证个人网关的使用情况：检查正在使用的个人网关的数量及其使用者。 如果使用量高，请采取相应的步骤转向使用标准模式网关。

改进用户许可证的管理：

• 查看请求用户许可证的过程：阐明用户获取许可证的过程，包括任何先决条件。 确定是否要对流程进行改进。
• 确定如何处理自助许可证购买：阐明是否启用了自助许可购买。 如果设置不符合你购买许可证方式的意图，请更新这些设置。
• 确认如何处理用户试用版：验证用户许可证试用版已启用还是禁用。 请注意，所有用户试用版均为 Premium Per User。 它们适用于注册试用版的免费许可用户，以及注册 Premium Per User 试用版的 Pro 用户。

改进成本管理：

• 确定成本管理目标：考虑如何平衡成本、功能、使用模式和资源有效利用率。 制定评估成本的例行流程（至少一年一次）。
• 获取活动日志数据：确保自己可访问活动日志数据，以协助进行成本分析。 可以借此了解谁正在使用或没有使用分配给他们的许可证。

改进安全性和数据保护：

• 明确对数据保护的期望：确保记录对数据保护的期望（例如如何使用敏感度标签）并传达给用户。
• 确定如何处理外部用户：了解并记录有关与外部用户共享 Fabric 内容的组织策略。 确保 Fabric 中的设置支持外部用户策略。
• 设置监视：调查 Microsoft Defender for Cloud Apps 的使用，以监视 Fabric 中的用户行为和活动。

改进审核和监视：

• 规划审核需求：收集和记录审核解决方案的关键业务要求。 请考虑审核和监视的优先级。 就审核解决方案类型、权限、要使用的技术和数据需求做出关键决策。 咨询 IT 部门，明确了解当前存在的审核流程以及构建新解决方案时存在的需求偏好。
• 考虑角色和职责：确定哪些团队将参与审核解决方案的构建和审核数据的持续分析。
• 提取和存储用户活动数据：如果当前未提取和存储原始数据，请开始检索用户活动数据。
• 提取和存储租户清单数据的快照：开始检索元数据以生成租户清单，其中描述了所有工作区和项。
• 提取和存储用户和组数据的快照：开始检索有关用户、组和服务主体的元数据。
• 创建特选数据模型：执行原始数据的数据清理和转换来创建一个特选数据模型，该模型将支持审核解决方案的分析报告。
• 分析审核数据并处理结果：创建分析报表来分析特选审核数据。 明确谁应该在什么时候执行哪些操作。
• 包含额外的审核数据：随着时间的推移，确定还有哪些审核数据有助于对活动日志数据进行补充，例如安全数据。

提示

有关详细信息，请参阅租户级审核。

使用 REST API：

• 规划 REST API 的使用：考虑从 Power BI REST API 和 Fabric REST API 检索哪些数据最有用。
• 执行概念证明：执行小型概念证明来验证数据需求、技术选择和权限。

应考虑的问题

通过类似于以下示例的问题来评估系统监督。

• 是否启用或禁用了非典型管理设置？ 例如，是否允许整个组织发布到 Web（强烈建议限制此功能）。
• 管理设置和策略是否与用户的工作方式保持一致或禁止该方式？
• 是否有一个流程来严格评估新设置并决定如何设置它们？ 或者，是否仅设置最严格的设置作为预防措施？
• Microsoft Entra 安全组是否用于管理谁可执行什么操作？
• 中心团队是否能够查看有效的审核和监视工具？
• 监视解决方案是否描绘了有关数据资产和/或用户活动的信息？
• 审核和监视工具可操作吗？ 是否设置了明确的阈值和操作，或者监视报告是否只是描述了数据资产中的内容？
• 是否使用（或计划使用）Azure Log Analytics 来详细监视 Fabric 容量？ 决策者是否清楚 Azure Log Analytics 的潜在好处和成本？
• 是否使用了敏感度标签和数据丢失防护策略？ 决策者是否清楚这些内容的潜在好处和成本？
• 管理员是否知道当前的许可证数量和许可成本？ BI 总支出中用于 Fabric 容量、Pro 和 PPU 许可证的比例是多少？ 如果组织仅对 Power BI 内容使用 Pro 许可证，用户数量和使用模式能否保证经济高效地切换到 Power BI Premium 或 Fabric 容量？

成熟度级别

以下成熟度级别有助于评估 Power BI 系统监督的当前状态。

Level	系统监督的状态
100：起步	• 租户设置由一个或多个管理员根据自己的最佳判断独立配置。 • 可以根据需要满足体系结构需求，例如网关和容量。 但是，没有战略规划。 • 未使用 Fabric 活动日志，或有选择地将其用于战术性目的。
200：可重复	• 租户设置有意地与已建立的治理准则和策略保持一致。 定期审查所有租户设置。 • 选择少量的特定管理员。 所有管理员都很好地了解用户在 Fabric 中尝试完成哪些任务，因此他们可以很好地支持用户。 • 用户能通过明确定义的过程来请求许可证和软件。 用户可以轻松找到请求表单。 指定自助购买设置。 • 在 Microsoft 365 中配置敏感度标签。 但是，标签的使用仍然不一致。 用户并没有很好地了解数据保护的优点。
300：已定义	• 租户设置完整地记录在集中式门户中以供用户参考，包括如何请求访问正确的组。 • 已为管理员准备交叉培训和文档，从而保证连续性、稳定性和一致性。 • 敏感度标签被一致地分配给内容。 用户了解使用敏感度标签进行数据保护的优点。 • 已有一个自动化流程能将 Fabric 活动日志和 API 数据导出到安全位置，以进行报告和审核。
400：有效力	• 管理员与 COE 和治理团队密切协作，以提供对 Fabric 的监督。 用户授权与治理的平衡已成功实现。 • 有效地对数据体系结构采取分散式管理（例如网关或容量管理），以平衡灵活度和控制力。 • 在 Microsoft Defender for Cloud Apps 中设置并积极监视自动化策略，以防止数据丢失。 • 主动分析活动日志和 API 数据，以监视和审核 Fabric 活动。 根据数据执行具有前瞻性的措施。
500：高效	• Fabric 管理员与 COE 密切协作，主动保持最新状态。 会经常审查 Fabric 产品团队的博客文章和发布计划，以规划即将进行的更改。 • 定期进行成本管理分析，确保以经济高效的方式满足用户需求。 • 使用 Fabric REST API 定期检索租户设置值。 • 主动使用活动日志和 API 数据来提供信息并改进采用和治理工作。

相关内容

有关系统监督和 Fabric 管理的详细信息，请参阅以下资源。

• 管理 Microsoft Fabric
• 管理 Power BI - 第 1 部分
• 管理 Power BI - 第 2 部分
• 管理员一日培训 - 第 1 天
• 管理员一日培训 - 第 2 天
• Power BI 安全性白皮书
• 外部来宾用户白皮书
• Power BI 实现计划

在 Microsoft Fabric 采用路线图系列文章的下一篇文章中，了解有效的变更管理。