Microsoft Fabric 採用藍圖：系統監督

  • 發行項

注意

本文構成 Microsoft Fabric 採用藍圖系列文章的一部分。 如需系列的概觀，請參閱 Microsoft Fabric 採用藍圖。

系統監督，也稱為網狀架構管理，是正在進行的日常管理活動。 它特別關心：

  • 治理： 制定治理指導方針和原則，以支援自助和企業數據和商業智慧 （BI） 案例。
  • 使用者授權： 在遵守組織的法規和需求的同時，協助和支持內部使用者社群儘可能賦予內部使用者社群權力的內部程式與系統。
  • 採用： 使用有效的治理和數據管理做法，允許更廣泛的組織採用 Fabric。

重要

您的組織數據文化目標會為您的治理決策提供方向，進而決定網狀架構管理活動的發生方式，以及由誰來決定。

系統監督是一個廣泛而深入的主題。 本文的目標是介紹一些最重要的考慮和動作，以協助您在 組織採用 目標中取得成功。

網狀架構系統管理員

Fabric 系統管理員角色是 Microsoft 365 中定義的角色，其會 委派管理活動的子集 。 全域 Microsoft 365 系統管理員是隱含網狀架構系統管理員。 Power Platform 系統管理員也是隱含網狀架構系統管理員。

關鍵治理決策是要將誰指派為網狀架構系統管理員。 這是會影響整個 租使用者的集中式角色。 在理想情況下，組織中有兩到四個人能夠管理 Fabric。 您的系統管理員應與 卓越中心（COE）密切合作。

高許可權角色

網狀架構系統管理員角色是高許可權角色，因為：

  • 用戶體驗：由網狀架構系統管理員管理的 設定 對使用者功能和用戶體驗有顯著的影響。 如需詳細資訊，請參閱 控管租用戶設定。
  • 完整安全性存取： 網狀架構管理員可以更新租使用者中工作區的訪問許可權。 結果是系統管理員可以允許檢視或下載數據與報表的許可權，視需要檢視或下載報表。 如需詳細資訊，請參閱 控管租用戶設定。
  • 個人工作區存取： 網狀架構管理員可以存取內容，並控管 任何用戶的個人工作區 。
  • 元數據： 網狀架構管理員可以檢視所有租用戶元數據，包括網狀架構入口網站中發生的所有用戶活動（如下的 稽核和監視 一節所述）。

重要

擁有太多網狀架構系統管理員是風險。 這會增加租使用者未核准、非預期或不一致管理的可能性。

角色和責任

系統管理員會每天執行的活動類型會有所不同。 數據文化特性中的重要事項和優先順序，將嚴重影響 系統管理員支援 商務導向自助、受控自助和企業數據和 BI 案例的功能。 如需詳細資訊，請參閱 內容擁有權和管理 一文。

提示

身為 Fabric 系統管理員的最佳人員類型，是一個對工具和工作負載有足夠的知識，以瞭解自助使用者需要完成的工作。 透過這項了解，系統管理員可以平衡使用者授權和控管。

除了網狀架構系統管理員之外，還有其他角色會使用系統管理員一詞。 下表描述常用且經常使用的角色。

Role 範圍 說明
網狀架構系統管理員 租用戶 管理網狀架構入口網站中的租用戶設定和其他設定。 本文中系統管理員的所有一般參考都會參考這種類型的系統管理員。
容量管理員 一個容量 管理工作區和工作負載，並監視網狀架構容量的健康情況。
數據閘道管理員 一個閘道 管理閘道數據源組態、認證和使用者指派。 也可能處理閘道軟體更新（或與基礎結構小組共同作業以取得更新）。
工作區管理員 一個工作區 管理工作區設定和存取。

工作負載的網狀架構生態系統廣泛且深入。 網狀架構與其他系統和平臺整合有許多方式。 不時需要與其他系統管理員和IT專業人員合作。 如需詳細資訊，請參閱 與其他系統管理員共同作業。

本文的其餘部分提供網狀架構系統管理員最常執行之活動的概觀。 它著重於在採取組織採用策略性方法時有效執行的活動。

服務管理

監督租用戶是確保所有用戶都具備Power BI良好體驗的重要層面。 網狀架構系統管理員的一些主要治理責任包括：

  • 租用戶設定： 控制已啟用哪些 Power BI 功能，以及組織中哪些使用者。
  • 網域： 將具有類似特性的兩個或多個工作區分組在一起。
  • 工作區： 檢閱和管理租使用者中的工作區。
  • 內嵌程序代碼： 控管哪些報告已在因特網上公開發佈。
  • 組織視覺效果： 註冊和管理組織視覺效果。
  • Azure 連線： 與 Azure 服務整合以提供其他功能。

如需詳細資訊，請參閱 租使用者管理。

用戶電腦和裝置

Fabric 的採用直接取決於內容建立者和取用者擁有所需的工具和應用程式。 以下是需要考慮的一些重要問題。

  • 使用者如何要求存取新工具？ 取得授權、數據和訓練的存取權，是否可協助使用者有效地使用工具？
  • 內容取用者將如何檢視其他人發佈的內容？
  • 內容建立者會如何開發、管理及發佈內容？ 決定哪些工具和應用程式適合哪些使用案例的準則為何？
  • 您要如何安裝和設定工具？ 這是否包含相關的必要條件和數據聯機組件？
  • 您要如何管理工具和應用程式的持續更新？

如需詳細資訊，請參閱 使用者工具和裝置。

架構

在 Fabric 的內容中，架構與數據架構、容量管理和數據閘道架構和管理有關。

數據架構

數據架構 是指管理及定義所收集數據的原則、做法和方法，以及其內嵌、儲存、受控、整合、模型化及使用方式。

有許多數據架構決策需要做出。 COE 經常參與數據架構設計和規劃。 系統管理員也經常參與其中，尤其是在管理資料庫或 Azure 基礎結構時。

重要

數據架構決策會對網狀架構採用、用戶滿意度和個別專案的成功率產生重大影響。

影響採用的一些數據架構考慮包括：

  • Fabric 適合組織整個數據架構的位置？ 是否有其他現有的元件，例如企業數據倉儲（EDW）或數據湖，對於考慮計劃很重要？
  • 網狀架構是端對端用於數據準備、數據模型化和數據呈現，還是只用於其中一些功能？
  • 是否 遵循受控自助 模式，以找出數據重複使用性和報表建立者彈性之間的最佳平衡？
  • 用戶會在哪裡取用內容？ 一般而言，傳遞內容的三個主要方式包括：網狀架構入口網站、Power BI 報表伺服器，以及內嵌在自定義應用程式中。 此外，Microsoft Teams 是一個方便的替代方案，適用於在 Teams 中花費大量時間的使用者。
  • 神秘 負責管理和維護數據架構？ 是集中式小組還是分散式小組？ 此小組中的 COE 代表方式如何？ 需要某些技能集嗎？
  • 什麼是 最重要的數據源 ？ 我們將取得哪些類型的數據？
  • 哪些 語意模型連線模式 和 儲存模式 選項（例如 Direct Lake、import、live connection、DirectQuery 或複合模型架構）最適合使用案例？
  • 使用 Lakehouse、倉儲和共用語意模型所鼓勵的數據重複使用程度為何？
  • 使用數據管線、筆記本和數據流所鼓勵的數據準備邏輯和進階數據準備的重複使用程度為何？

系統管理員在做出架構決策之前，請務必充分瞭解 Fabric 的技術功能，以及其項目關係人的需求和目標。

提示

進入完成技術概念證明（POC）的好習慣，以測試假設和想法。 有些組織在目標是提供小型工作單位時，也會將其稱為 微專案 。 POC 的目標是要儘早解決未知問題並降低風險。 POC 不必拋出工作，但範圍應該很窄。 最佳做法檢閱，如指導和用戶啟用一文所述，是協助內容建立者做出重要架構決策的另一個實用方式。

產能管理

容量 包含大規模提供分析解決方案的功能。 網狀架構組織授權有兩種類型：每個使用者 進階版 （PPU） 和容量。 有數種類型的 容量授權。 容量授權的類型會決定支援哪些 Fabric 工作負載。

重要

本文有時是指 Power BI 進階版 或其容量訂用帳戶（P SKU）。 請注意，Microsoft 目前正在合併購買選項，並淘汰每個容量 SKU 的 Power BI 進階版。 新的和現有的客戶應該考慮改為購買網狀架構容量訂用帳戶（F SKU）。

如需詳細資訊，請參閱 Power BI 進階版 授權和 Power BI 進階版 常見問題的重要更新。

容量的使用在建立、管理、發佈及發佈內容的策略中扮演重要角色。 投資容量的幾個主要原因包括：

上述清單並非全含。 如需完整清單，請參閱Power BI 進階版功能。

管理網狀架構容量

監督網狀架構容量的健康情況是系統管理員不可或缺的持續活動。 每個容量 SKU 都包含一組資源。 容量單位 （SU） 可用來測量每個 SKU 的計算資源。

警告

缺乏管理，且持續超過容量資源的限制，通常會導致效能挑戰和用戶體驗挑戰。 如果無法正確管理，這兩項挑戰都可能導致對採用工作的負面影響。

管理網狀架構容量的建議：

  • 定義誰負責管理容量。 確認角色和責任，以便清楚將採取哪些動作、原因、時機和誰。
  • 建立將發佈至容量之內容的特定準則集。 當多個業務單位使用單一容量時，它特別相關，因為如果容量管理不佳，可能會中斷其他使用者。 請考慮在將新內容發佈至產能之前，先進行 最佳做法檢閱 （例如合理的語意模型大小和有效率的計算）。
  • 定期使用 Fabric 容量計量應用程式 來瞭解容量的資源使用率和模式。 最重要的是，尋找過度使用量的一致模式，這會導致用戶中斷。 使用模式的分析也應該讓您知道容量是否使用量過低，表示可以從投資中獲得更多價值。
  • 設定租用戶設定，讓 Fabric 會在容量超載，或發生中斷或事件時通知您。

Autoscale

自動調整 的目的是處理容量使用層級偶爾或非預期的高載。 自動調整可以自動增加 CPU 資源以支援增加的工作負載，以回應這些高載。

自動化相應增加可降低效能和用戶體驗挑戰的風險，以換取財務影響。 如果容量無法妥善管理，自動調整可能會比預期更頻繁地觸發。 在此情況下， 計量應用程式 可協助您判斷基礎問題並執行容量規劃。

分散式容量管理

容量管理員負責 將工作區 指派給特定容量。

請注意，如果工作區管理員擁有 PPU 授權，工作區系統管理員也可以將工作區指派給 PPU。 不過，它需要所有其他工作區用戶也必須有 PPU 授權，才能在工作區中共同作業或檢視 Power BI 內容。 其他網狀架構工作負載不能包含在指派給 PPU 的工作區中。

可以設定多個容量，以方便不同業務單位的分散管理。 網狀架構特定層面的分散管理是平衡靈活度和控制的絕佳方式。

以下範例說明您可以管理容量的一種方式。

  • 在 Microsoft 365 中購買 P3 容量節點。 它包含 32 個虛擬核心（v 核心）。
  • 使用16個 v核心來建立第一個容量。 銷售小組將使用它。
  • 使用8個 v核心來建立第二個容量。 作業小組將使用它。
  • 使用其餘8個 v核心來建立第三個容量。 其將支援一般用途。

上述範例有數個優點。

  • 您可以為每個容量設定個別 的容量管理員 。 因此，它有助於分散的管理情況。
  • 如果容量無法妥善管理，效果只會限制在該容量內。 其他容量不會受到影響。
  • 其他業務單位的計費和退款很簡單。
  • 不同的工作區可以輕鬆地指派給不同的容量。

不過，上一個範例也有缺點。

  • 每個容量的限制較低。 語意模型允許的最大記憶體大小不是購買的整個 P3 容量節點大小。 而是裝載語意模型的指派容量大小。
  • 它更有可能在某個時間點相應增加其中一個較小的容量。
  • 租使用者中有更多容量可管理。

注意

每個容量的 Power BI 進階版 資源稱為 v 核心。 不過，網狀架構容量會將它們稱為容量單位（OU）。 每個 SKU 和 v 核心的規模都不同。 如需詳細資訊，請參閱 網狀架構授權 檔。

數據閘道架構和管理

數據閘道可協助組織數據源與網狀架構服務之間安全且有效率地傳輸數據。 當數據源為時，需要數據閘道才能連線到內部部署或雲端服務：

  • 位於企業數據中心內。
  • 設定在防火牆後方。
  • 虛擬網路內。
  • 在虛擬機內。

閘道有三種類型。

  • 內部部署數據閘道（標準模式） 是一種閘道服務，可支援連線到已註冊數據源供許多使用者使用。 閘道軟體安裝和更新會安裝在客戶所管理的電腦上。
  • 內部部署資料閘道 （個人模式） 是僅支持資料重新整理的閘道服務。 此閘道模式通常會安裝在內容建立者的電腦上。 它僅支援由一位使用者使用。 它不支援即時連線或 DirectQuery 連線。
  • 虛擬網路數據閘道 是 Microsoft 受控服務，可支援許多用戶的連線。 具體來說，它支援針對儲存在指派給 進階版 容量或每位使用者 進階版 工作區中的語意模型和數據流連線。

提示

誰可以安裝閘道軟體的決定是治理決策。 對大多數組織而言，應強烈建議以標準模式或虛擬網路數據網關使用數據網關。 它們比個人模式中的數據網關更具可調整性、可管理性及可稽核性。

分散式閘道管理

內部部署數據閘道（標準模式）和虛擬網路數據閘道支援可註冊的特定數據源類型，以及連線詳細數據以及認證儲存方式。 用戶可以獲得使用閘道數據源的許可權，以便排程重新整理或執行 DirectQuery 查詢。

網關管理的某些層面可以有效地在分散的基礎上完成，以平衡靈活度和控制。 例如，Operations 群組可能有專用於其自助內容建立者和數據擁有者小組的閘道。

分散式閘道管理在共同努力時效果最佳，如下所示。

由分散式數據擁有者管理：

由集中式數據擁有者管理（包括廣泛用於整個組織的數據源;管理是集中式，以避免重複的數據源）：

由 IT 管理：

  • 閘道軟體更新（閘道更新通常每月發行）。
  • 安裝驅動程式和自定義連接器（與安裝在用戶機器上的相同連接器）。
  • 網關叢集管理（閘道叢集中用於高可用性、災害復原的機器數目，以及消除單一失敗點，這可能會導致嚴重的使用者中斷）。
  • 伺服器管理（例如作業系統、RAM、CPU 或網路連線能力）。
  • 閘道加密金鑰的管理與備份。
  • 監視閘道記錄，以評估何時需要相應增加或相應放大。
  • 警示閘道電腦上的停機時間或持續性低資源。

提示

允許分散式小組管理閘道的某些層面，表示他們可以更快速地移動。 分散式閘道管理的取捨意味著執行更多閘道伺服器，讓每個伺服器都能夠專用於組織的特定區域。 如果閘道管理完全由 IT 處理，就必須有良好的程式，以便快速處理要求以新增數據源並套用使用者更新。

使用者授權

每個使用者都需要與 Microsoft Entra 身分識別整合的商業授權。 用戶授權可以是免費、專業版或 進階版 每位使用者 （PPU）。

使用者授權是透過訂用帳戶取得，該訂用帳戶授權具有開始和結束日期的特定授權數目。

注意

雖然每個使用者都需要授權，但只需要 Pro 或 PPU 授權才能共用 Power BI 內容。 具有免費授權的使用者可以建立及共用Power BI專案以外的 Fabric 內容。

採購訂閱的方法有兩種。

  • 集中式： Microsoft 365 計費管理員購買 Pro 或 PPU 的訂用 帳戶。 這是管理訂用帳戶並指派授權的最常見方式。
  • 分散式： 個別部門會透過 自助購買購買來購買訂用帳戶。

自助式購買

重要的 治理 決策與允許或鼓勵自助購買的程度有關。

自助式購買對於：

  • 具有購買授權單位且想要直接使用信用卡處理付款的分散式業務單位的大型組織。
  • 想要盡可能輕鬆地在每月承諾用量上購買訂閱的組織。

請考慮在下列情況下停用自助式購買：

  • 集中式採購程式已就緒，以符合法規、安全性和治理需求。
  • 折扣定價是透過 Enterprise 合約 （EA） 取得的。
  • 現有的進程已就緒，可處理公司間退款。
  • 現有的程式已就緒，可處理 群組型 授權指派。
  • 取得授權的必要條件，例如核准、理由、訓練或治理原則需求。
  • 有有效的需求，例如法規需求，以密切控制存取。

用戶授權試用版

另一個重要的治理決策是是否允許使用者授權試用版。 根據預設，會啟用試用版。 這表示當內容與同事共用時，如果收件者沒有 Pro 或 PPU 授權，系統會提示他們開始試用以檢視內容（如果內容不在容量支援的工作區內）。 試用體驗旨在方便用戶繼續進行其一般工作流程。

一般而言，不建議停用試用版。 它可鼓勵使用者尋求因應措施，也許是藉由匯出數據或在支援的工具和程式之外運作。

只有在下列情況下，才請考慮停用試用版：

  • 有嚴重的成本考慮，將使它不太可能在試用期結束時授與完整的授權。
  • 取得授權的必要條件（例如核准、理由或訓練需求）。 在試用期間滿足這項需求是不夠的。
  • 有有效的需求，例如法規需求，可密切控制網狀架構服務的存取。

提示

請勿引入太多障礙來取得網狀架構授權。 需要完成工作的使用者會找到一種方法，而這種方式可能牽涉到不理想的因應措施。 例如，若沒有使用 Fabric 的授權，當有明顯更好的方法可用時，人們可能依賴太多內容來共用文件系統上的檔案，或透過電子郵件共用檔案。

成本管理

管理及優化雲端服務的成本，例如 Fabric，是一項重要的活動。 以下是您可以考慮的數個活動。

  • 分析正在使用的人員，並更進一步地分析其配置的網狀架構授權，並進行必要的調整。 使用 活動記錄分析網狀架構使用量。
  • 分析容量或每位使用者的 進階版 成本效益。 除了 其他功能，請執行成本/權益分析，以判斷當大量取用者時，容量授權是否更具成本效益。
  • 仔細 監視和管理網狀架構容量。 瞭解一段時間的使用模式可讓您預測何時購買 更多容量。 例如，您可以選擇將單一容量從 P1 相應增加至 P2，或從一個 P1 容量相應放大至兩個 P1 容量。
  • 如果使用量層級偶爾出現尖峰，建議使用 自動調整 與 Fabric，以確保用戶體驗不會中斷。 自動調整將相應增加容量資源 24 小時，然後將其縮減為正常層級（如果不存在持續的活動）。 藉由限制 v 核心數目上限和/或 Azure 中設定的消費限制，來管理自動調整成本。 由於定價模式，自動調整最適合處理偶爾非計劃性使用量增加的問題。
  • 針對 Azure 數據源，請盡可能將它們共置於與網狀架構租使用者相同的區域中。 這可避免產生 Azure 輸出費用。 數據輸出費用最低，但大規模可能會增加相當多的非計劃性成本。

安全性、資訊保護和數據外洩防護

安全性、資訊保護和數據外洩防護（DLP）是所有內容建立者、取用者和系統管理員的共同責任。 這並不小的工作，因為無處不在有敏感性資訊：個人資料、客戶數據或客戶撰寫的數據、受保護的健康情況資訊、智慧財產權、專屬組織資訊，只是為了命名一些。 政府、產業和合約法規可能會對 您所建立與安全性相關的治理 指導方針和原則產生重大影響。

Power BI 安全性白皮書是了解考慮範圍的絕佳資源，包括 Microsoft 管理的各個層面。 本節將介紹客戶負責管理的數個主題。

用戶責任

某些組織會要求 Fabric 使用者接受自助使用者通知。 這是一份文件，說明使用者保護組織數據的責任和期望。

自動化實作的其中一 種方式是使用 Microsoft Entra 使用規定原則。 用戶必須先檢視並同意原則，才能第一次造訪網狀架構入口網站。 您也可以要求定期認可，例如年度續約。

資料安全性

在雲端共同責任模型中，保護數據一律是客戶的責任。 透過自助數據平臺，自助內容建立者必須負責妥善保護他們與同事共享的內容。

COE 應提供 相關文件和訓練 ，以協助內容建立者採用最佳做法（特別是處理超敏感數據的情況）。

管理員 istrators 可以遵循最佳做法本身來協助。 管理員 istrators 也會在看到管理工作區、稽核用戶活動或管理網關認證和使用者時可能發現的問題時，引發疑慮。 除了少數使用者之外，也有數個租用戶設定通常受到限制（例如，發佈至 Web 的能力，或將應用程式發佈至整個組織的能力）。

外部來賓使用者

外部使用者，例如合作夥伴、客戶、廠商和顧問，是某些組織的常見情況，對其他組織而言很少見。 您如何處理外部使用者是治理決策。

外部使用者存取是由 租用戶設定 和特定 Microsoft Entra ID 設定所控制。 如需外部使用者考慮的詳細數據，請參閱 使用 Microsoft Entra B2B 白皮書將 Power BI 內容散發給外部來賓使用者。

信息保護和數據外洩防護

Fabric 支援下列方式的信息保護和數據外洩防護功能。

  • 信息保護：Microsoft Purview 資訊保護（先前稱為 Microsoft 資訊保護）包含探索、分類和保護數據的功能。 主要原則是，一旦數據分類后，數據可以得到更好的保護。 分類數據的關鍵建置組塊是 敏感度標籤。 如需詳細資訊，請參閱 Power BI 規劃的信息保護。
  • Power BI 的數據外洩防護：Microsoft Purview 資料外洩防護（先前稱為 Office 365 數據外泄防護）支援 Power BI 的 DLP 原則。 藉由使用敏感度標籤或敏感性資訊類型，Power BI 的 DLP 原則可協助組織找出敏感性語意模型。 如需詳細資訊，請參閱 Power BI 規劃的數據外洩防護。
  • 適用於雲端的 Microsoft Defender 應用程式：適用於雲端的 Microsoft Defender Apps（先前稱為 Microsoft 雲端 App 安全性）支援可協助保護數據的原則，包括當使用者與 Power BI 服務 互動時即時控制。 如需詳細資訊，請參閱 適用於雲端的 Defender Apps for Power BI 規劃。

資料落地

對於需要將數據儲存在地理區域內的組織，可以 針對與 Fabric 租使用者主區域不同的特定區域 設定 Fabric 容量。

加密金鑰

Microsoft 會使用透明伺服器端加密和自動輪替憑證，處理 Microsoft 數據中心待 用數據的加密。 對於具有管理 進階版 加密密鑰本身的法規需求的客戶，可以將 進階版 容量設定為使用 Azure 金鑰保存庫。 使用客戶管理的金鑰，也稱為 自備密鑰 或 BYOK，是一種預防措施，可確保在服務操作員發生人為錯誤時，客戶數據無法公開。

請注意，進階版 每個使用者 （PPU） 只有在針對整個網狀架構租用戶啟用 BYOK 時才支援 BYOK。

稽核和監視

請務必使用稽核數據來分析採用工作、瞭解使用模式、教育使用者、支援使用者、降低風險、改善合規性、管理授權成本，以及監視效能。 如需稽核數據為何有價值的詳細資訊，請參閱 稽核和監視概觀。

視您的角色和目標而定，有不同的方式可以進行稽核和監視。 下列文章說明各種考慮和規劃活動。

  • 報表層級稽核： 報表建立者可用來瞭解哪些使用者正在使用他們建立、發佈和共享的報表。
  • 數據層級稽核： 數據建立者可用來追蹤其建立、發佈和共用之數據資產的效能和使用模式的方法。
  • 租用戶層級稽核： 系統管理員可以採取的重要決策和動作來建立端對端稽核解決方案。
  • 租用戶層級監視：系統管理員可以採取戰術動作來監視 Power BI 服務，包括更新和公告。

REST API

Power BI REST API 和網狀架構 REST API 提供您網狀架構租使用者的大量資訊。 使用 REST API 擷取數據應該在管理和控管網狀架構實作方面扮演重要角色。 如需規劃使用 REST API 進行稽核的詳細資訊，請參閱 租用戶層級稽核。

您可以擷取稽核數據來建置稽核解決方案、以程序設計方式管理內容，或提高例行動作的效率。 下表提供您可以使用 REST API 執行的一些動作。

動作 檔案資源（s）
稽核用戶活動 用來取得活動事件的 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
以程式設計方式變更數據模型 表格式物件模型 （TOM） API
在自定義應用程式中內嵌Power BI內容 Power BI 內嵌式分析用戶端 API

提示

還有其他許多Power BI REST API。 如需完整清單，請參閱 使用Power BI REST API。

規劃變更

Microsoft 每個月都會發行新的 Fabric 特性和功能。 要有效，參與系統監督的每個人都必須保持最新狀態。 如需詳細資訊，請參閱 租用戶層級監視。

重要

不要低估保持最新狀態的重要性。 如果您在公告上落後幾個月，可能會變得難以正確管理網狀架構並支援您的使用者。

注意事項和關鍵措施

檢查清單 - 您可以針對系統監督採取的考慮和重要動作。

改善系統監督：

  • 確認誰是網狀架構系統管理員： 如果可能的話，請減少超過少數人時授與網狀架構系統管理員角色的人數。
  • 針對偶爾的系統管理員使用 PIM：如果您有偶爾需要網狀架構系統管理員許可權的人員，請考慮在 Microsoft Entra ID 中實作 Privileged Identity Management （PIM）。 其設計目的是指派在幾個小時后到期的 Just-In-Time 角色許可權。
  • 訓練系統管理員： 檢查交叉訓練的狀態和檔，以處理網狀架構系統管理責任。 請確定已訓練備份人員，以便以一致的方式及時滿足需求。

改善網狀架構服務的管理：

  • 檢閱租用戶設定： 對所有租用戶設定進行檢閱，以確保它們符合 數據文化 特性目標和 治理 指導方針和原則。 確認已為每個設定指派哪些群組。
  • 記錄租用戶設定： 為內部 Fabric 社群建立租用戶設定的檔，並將其張貼在集中式入口網站中。 包含使用者需要要求哪些群組才能使用功能。 使用取得租使用者 設定 REST API 讓程式更有效率，並定期建立設定的快照集。
  • 自定義取得說明連結：建立用戶資源時，如指導和使用者啟用一文所述，更新租用戶設定以自定義 [取得說明] 功能表選項下的連結。 它會將用戶導向至您的檔、社群和說明。

改善使用者機器和裝置的管理：

  • 建立一致的上線程式： 檢閱您的程式，以瞭解如何處理新內容建立者。 判斷是否可同時處理軟體的新要求，例如 Power BI Desktop 和使用者授權（免費、專業版或 PPU）。 它可以簡化上線，因為新的內容建立者不一定知道要問什麼。
  • 處理使用者電腦更新： 確定已就地安裝及更新軟體、驅動程式和設定的自動化程式，以確保所有使用者都有相同的版本。

資料架構規劃：

  • 評估端對端資料架構的外觀： 請確定您已清楚：
    • 您組織中的不同業務單位目前如何使用 Fabric，以及您想要使用 Fabric 的方式。 判斷是否有間距。
    • 如果有應解決的任何風險。
    • 如果有任何要解決的高維護情況。
    • 哪些數據源對於網狀架構使用者很重要，以及其記錄和探索方式。
  • 檢閱現有的數據網關： 了解組織中正在使用哪些閘道。 確認閘道管理員和使用者已正確設定。 確認誰支援每個閘道，而且有可靠的程式可讓閘道伺服器保持在最新狀態。
  • 確認個人閘道的使用方式： 檢查使用中的個人閘道數目，以及由誰使用。 如果有顯著的使用方式，請採取步驟以使用標準模式閘道。

改善使用者授權的管理：

  • 檢閱要求使用者授權的程式： 釐清程序是什麼，包括任何必要條件，讓使用者取得授權。 判斷是否要對程序進行改進。
  • 決定如何處理自助式授權購買： 釐清是否啟用自助式授權購買。 如果這些設定不符合您購買授權的方式，請更新這些設定。
  • 確認使用者試用版的處理方式： 確認使用者授權試用版已啟用或停用。 請注意，所有使用者試用版都會 進階版 每位使用者。 他們適用於註冊試用版的免費授權使用者，以及註冊每位使用者試用版 進階版 Pro 使用者。

改善成本管理：

  • 決定成本管理目標： 請考慮如何平衡成本、功能、使用模式，以及資源的有效使用率。 排程例行程式，至少每年評估成本。
  • 取得活動記錄數據： 請確定您可以存取活動記錄數據，以協助進行成本分析。 它可以用來瞭解誰是或不是使用指派給他們的授權。

改善安全性和資料保護：

  • 釐清數據保護 的預期：確定數據保護的預期，例如如何使用敏感度標籤，會記錄並傳達給使用者。
  • 決定如何處理外部使用者： 瞭解並記錄與外部用戶共用 Fabric 內容的組織原則。 請確定 Fabric 中的設定支援外部用戶的原則。
  • 設定監視：調查如何使用 適用於雲端的 Microsoft Defender Apps 來監視 Fabric 中的使用者行為和活動。

改善稽核和監視：

  • 規劃稽核需求： 收集和記錄稽核解決方案的主要商務需求。 請考慮您的稽核和監視優先順序。 做出與稽核解決方案類型、許可權、使用技術及數據需求相關的重要決策。 請洽詢 IT，以釐清目前存在的稽核程式，以及建置新解決方案的需求喜好設定。
  • 請考慮角色和責任： 識別哪些小組將參與建立稽核解決方案，以及持續分析稽核數據。
  • 擷取和儲存使用者活動數據： 如果您目前未擷取和儲存原始數據，請開始擷 取使用者活動數據。
  • 擷取和儲存租使用者清查數據的快照集： 開始擷取元數據以建 置租使用者清查，其中描述所有工作區和專案。
  • 擷取和儲存使用者和群組數據的快照集：開始擷取使用者、群組和服務主體的相關元數據。
  • 建立策劃的數據模型： 執行原始數據的數據清理和轉換，以建立可支援稽核解決方案分析報告的策劃數據模型。
  • 分析稽核數據並處理結果： 建立分析報告以分析策劃的稽核數據。 釐清預期要採取哪些動作、由誰和何時採取。
  • 包含其他稽核數據： 經過一段時間后，判斷其他稽核數據是否有助於補充活動記錄數據，例如 安全性數據。

提示

如需詳細資訊，請參閱 租用戶層級稽核。

使用 REST API：

  • 規劃 REST API 的使用： 請考慮從 Power BI REST API 和網狀架構 REST API 擷取哪些數據最有用。
  • 進行概念證明： 執行小型概念證明，以驗證數據需求、技術選擇和許可權。

要思考的問題

使用下面找到的問題來評估系統監督。

  • 啟用或停用非典型系統管理設定嗎？ 例如，整個組織都允許發佈至 Web（我們強烈建議限制此功能）。
  • 系統管理設定和原則是否與用戶的運作方式保持一致或禁止？
  • 是否有一個程式可大幅評估新的設定，並決定如何設定它們？ 或者，只有最嚴格的設定會設定為預防措施嗎？
  • Microsoft Entra 安全組是否用來管理誰可以做什麼？
  • 中央小組是否能夠看到有效的 稽核和監視 工具？
  • 監視解決方案是否描述數據資產、用戶活動或兩者的相關信息？
  • 稽核和監視工具是否可採取動作？ 是否已設定明確的閾值和動作，或監視報告只會描述數據資產中的內容嗎？
  • Azure Log Analytics 是否使用 （或計劃使用）來詳細監視網狀架構容量？ Azure Log Analytics 的潛在優點和成本是否對決策者清楚？
  • 是否使用敏感度標籤和數據外洩防護原則？ 這些的潛在優點和成本是否對決策者清楚？
  • 系統管理員是否知道目前的授權數目和授權成本？ BI 總費用的哪個比例會移至網狀架構容量，以及 Pro 和 PPU 授權？ 如果組織只針對Power BI內容使用 Pro授權，那麼使用者和使用模式的數目是否保證對Power BI 進階版 或 Fabric 容量具有成本效益的切換？

成熟度等級

下列成熟度層級可協助您評估Power BI系統監督的目前狀態。

等級 系統監督狀態
100：初始 • 租用戶設定是根據其最佳判斷，由一或多個系統管理員獨立設定。

• 視需要滿足架構需求，例如閘道和容量。 不過，沒有策略性計劃。

• 網狀架構活動記錄未使用，或選擇性地用於戰術用途。
200：可重複 • 租用戶設定的目的是要與已建立的治理指導方針和原則保持一致。 所有租用戶設定都會定期檢閱。

• 已選取少量特定系統管理員。 所有系統管理員都充分了解使用者在 Fabric 中嘗試完成的工作，因此他們處於支持使用者的良好位置。

• 使用者有定義完善的程式，可要求授權和軟體。 使用者很容易找到要求表單。 已指定自助式購買設定。

• 敏感度標籤是在 Microsoft 365 中設定。 不過，標籤的使用仍然不一致。 用戶無法充分了解數據保護的優點。
300：已定義 • 租用戶設定已完整記載在集中式入口網站中供用戶參考，包括如何要求存取正確的群組。

• 跨訓練和檔可供系統管理員使用，以確保持續性、穩定性和一致性。

• 敏感度標籤會一致地指派給內容。 用戶瞭解使用敏感度標籤進行數據保護的優點。

• 自動化程式已就緒，可將網狀架構活動記錄和API數據匯出至安全的位置以進行報告和稽核。
400：能力 • 管理員 管理人員與 COE 和治理小組密切合作，以提供網狀架構的監督。 用戶授權與治理的平衡已成功實現。

• 數據架構的分散式管理（例如閘道或容量管理）可有效處理，以平衡靈活度和控制。

• 自動化原則會在 適用於雲端的 Microsoft Defender Apps 中設定並主動監視數據外洩防護。

• 會主動分析活動記錄和 API 數據，以監視和稽核網狀架構活動。 主動式動作是根據數據採取的。
500：高效率 • 網狀架構系統管理員與 COE 密切合作，主動保持最新狀態。 網狀架構產品小組的部落格文章和發行方案會經常檢閱，以規劃即將進行的變更。

• 定期進行成本管理分析，以確保以符合成本效益的方式滿足使用者需求。

• 網狀架構 REST API 可用來定期擷取租用戶設定值。

• 活動記錄和 API 數據會主動用來通知和改善採用和治理工作。

相關內容

如需系統監督和網狀架構管理的詳細資訊，請參閱下列資源。

在 Microsoft Fabric 採用藍圖系列中的 下一篇文章 中，瞭解有效的變更管理。