共用方式為

Power BI 實作規劃：租用戶層級工作區規劃

  • 發行項

注意

本文是 Power BI 實作規劃系列文章的其中一篇。 此系列主要著重於 Microsoft Fabric 中的 Power BI 體驗。 如需有關此系列的簡介，請參閱 Power BI 實作規劃。

本文涵蓋租用戶層級 Fabric 工作區規劃，強調 Power BI 體驗。 本文的主要目標讀者為：

  • Fabric 管理員：負責監督組織中 Fabric 的管理員。
  • 卓越中心、IT 和 BI 小組：負責監督資料和 BI 並在整個組織中支援自助使用者的小組。

其次，本文也可能讓需要建立、發佈和管理工作區中內容的自助建立者感興趣。

因為工作區可以透過不同的方式來使用，因此大部分的策略性決策都會在工作區層級進行 (在下一篇文章中說明)。 不過，租用戶層級也有一些策略性規劃決策。

建議您盡早做出租用戶層級工作區決策，因為它們會影響其他所有項目。 此外，當您清楚了解整體工作區目標和目標時，更容易做出個別工作區決策。

注意

工作區的概念源自 Power BI。 使用 Fabric 時，工作區的用途已變得更加廣泛。 結果是工作區現在可以包含來自一或多個不同 Fabric 體驗的項目 (也稱為工作負載)。 雖然內容範圍已比 Power BI 更廣，但這些文章中所述的大部分工作區規劃活動都可以套用至 Fabric 工作區規劃。

工作區建立權限

允許誰可以在 Power BI 服務中建立工作區的決策屬於資料文化和控管決策。 一般而言，有兩種方式可處理此決策：

  • 所有 (或大部分) 使用者都可以建立新的工作區：這種方法通常與其他應用程式的現有決策一致。 例如，當允許使用者建立自己的 SharePoint 網站或 Teams 頻道時，Fabric 採用相同原則是合理的。
  • 僅限於允許建立新工作區的一組選擇性使用者：此方法通常表示控管計劃已就緒或已規劃。 管理此程序可能是完全集中處理 (例如，只允許 IT 建立工作區)。 更有彈性且實用的方法是當它是集中式和分散式個人的組合時。 在此情況下，卓越中心 (COE) 的特定附屬成員、風雲人物，或受信任使用者已接受訓練，可代表其營業單位建立和管理工作區。

您應該根據允許誰建立工作區的決策，在 Fabric 管理入口網站中設定 [建立工作區] 租用戶設定。 如需詳細資訊，請參閱控管工作區。

檢查清單 - 考慮誰可以建立工作區的權限時，關鍵決策和動作包括：

  • 判斷及驗證使用者需求：排程與相關專案關係人和相關各方的共同作業討論，以了解使用者目前的工作方式。 目標是要確保您清楚了解使用者需求。
  • 決定允許誰建立工作區：判斷是否允許所有使用者、僅限集中式小組，或特定集中式和分散式使用者，才能建立新的工作區。 請確定此決策有目的地與您的資料文化目標保持一致。 請務必從您的執行發起人取得核准。
  • 為允許建立工作區的人員建立安全性群組：如果要允許一部分使用者建立工作區，則需要安全性群組。 明確命名群組，例如「Fabric 工作區建立者」。 將允許建立工作區的成員新增至此安全性群組。
  • 更新租用戶設定：將新的安全性群組新增至管理入口網站中的 [建立工作區] 租用戶設定。 除了「Fabric 工作區建立者」群組之外，此租用戶設定可能也允許的其他群組包含 COE、客戶支援和 Fabric 系統管理員。

工作區命名慣例

工作區命名慣例是一種同意模式，適用於工作區的命名方式。 通常，命名慣例比建議更需要。

當許多使用者擁有建立工作區的權限時，很難嚴格第強制執行命名慣例。 您可以透過使用者教育和訓練來減輕這種顧慮。 您也可以進行稽核程序，以尋找不符合命名慣例的工作區。

工作區名稱可以傳達關於工作區的其他資訊，包括：

  • 目的：工作區名稱應一律包含其內容的描述。 例如，「每季銷售額獎金追蹤」。
  • 項目類型：工作區名稱可以包含其所包含項目類型的參考。 例如，使用 Sales Data 來指出工作區會儲存 Lakehouse 或語意模型等專案。 銷售額分析可能表示工作區會儲存分析報告和儀表板。
  • 階段 (環境)：工作區名稱可能包含其階段。 例如，在生命週期管理中，通常會有個別工作區 (開發、測試和生產環境)。
  • 擁有權和責任：工作區名稱可能包含負責管理內容人員的指示。 例如，使用 SLS 前置詞或尾碼可以指出銷售小組擁有和管理內容的銷售小組。

提示

若要讓工作區名稱保持簡短，您可以在工作區描述中包含其他詳細資料。 不過，請確定工作區名稱中包含最相關的資訊，特別是如果您預期使用者會搜尋工作區的情況。 您也可以使用工作區影像來增強工作區名稱。 下一篇文章的工作區設定一節會進一步說明這些考量。

擁有一致的工作區名稱對所有人都有幫助。 使用者體驗已改善，因為使用者可以更輕鬆地找到內容。 此外，當使用可預測的命名慣例時，系統管理員可以更輕鬆地監督內容。

建議您在集中式入口網站和訓練教材中包含工作區命名慣例。

下列清單說明更多與工作區命名相關的考量。

  • 使用簡短但具有描述性的名稱：工作區名稱應該準確地反映其內容，且名稱開頭包含最重要的部分。 在 Fabric 入口網站中，使用者介面中可能會截斷過長的工作區名稱，要求使用者將游標停留在工作區名稱上方，以在工具提示中顯示完整名稱。 以下是簡短但具有描述性的名稱範例：「每季財務」。
  • 使用標準前置詞：標準前置詞可以在排序時將類似的工作區排列在一起。 例如：「FIN-每季財務」。
  • 使用標準尾碼：您可以新增尾碼以代表其他資訊，例如當您使用不同的工作區進行開發、測試和生產環境時。 建議您附加 [Dev] 或 [Test] 尾碼，但將生產環境保留為使用者易記名稱，而不加上尾碼。 例如：「FIN-每季財務 [Dev]」。
  • 與 Power BI 應用程式名稱一致：工作區名稱和其 Power BI 應用程式可能不同，特別是當它改善應用程式取用者的可用性或可理解性時。 建議您保留類似的名稱，以避免混淆。
  • 省略不必要的單字：下列單字可能是多餘的，因此請避免在工作區名稱中使用這些單字：
    • workspace 單字。
    • Fabric 或 Power BI 單字。 許多 Fabric 工作區包含來自各種工作負載的項目。 不過，您可以建立只以特定工作負載為目標的工作區 (例如 Power BI、Data Factory 或 Synapse Data Engineering)。 在此情況下，您可以選擇簡短的尾碼，讓工作區的用途清楚明瞭。
    • 組織的名稱。 不過，當主要對象是外部使用者時，包括組織的名稱可能會很有幫助。

注意

建議您在工作區名稱將變更時通知使用者。 在大多數情況下，在 Fabric 入口網站中重新命名工作區是安全的，因為 GroupID 是工作區的唯一識別碼，並不會變更 (在工作區 URL 中找到)。 不過，XMLA 連線會受到影響， 因為它們會使用工作區名稱而不是 GroupID 進行連線。

檢查清單 - 考慮建立工作區命名慣例時，關鍵決策和動作包括：

  • 決定工作區名稱的需求或喜好設定：請考慮您要如何為工作區命名。 決定您想要嚴格的命名慣例需求，還是建議和範例所引導的更彈性需求。
  • 檢閱現有的工作區名稱：適當地更新現有的工作區名稱，讓使用者能夠遵循這些名稱。 當使用者看到現有的工作區重新命名時，他們會將其解釋為要採用的隱含標準。
  • 建立工作區命名慣例的文件：提供工作區命名慣例需求和喜好設定的參考文件。 請務必包含範例，其中顯示縮寫、前置詞和尾碼的正確用法。 在您的集中式入口網站和訓練教材中提供資訊。

工作區定義域

釐清內容的擁有和管理方式一直都很重要。 當建立和管理資料資產的責任分散在許多部門或營業單位之間時，這種明確性就特別重要。 有時候，這種方法稱為分散式、同盟或資料網格架構。

在 Fabric 中支援工作區擁有權和管理的其中一種方式是使用定義域。 定義域提供一種邏輯方式將具有類似特性的多個工作區分組。 例如，您可以建立一個定義域將所有銷售工作區分組在一起，而財務工作區則使用另一個定義域。

以下是使用定義域的主要優點。

  • 它們會將類似的工作區分組為單一管理界限。
  • 它們允許在定義域層級管理特定租用戶設定。 如需詳細資訊，請參閱覆寫租用戶層級設定。
  • 其可協助使用者尋找相關資料。 例如，他們可以使用 OneLake 資料中樞中的篩選。

下表列出您可能會選擇用來組織相關工作區的不同方式。

組織工作區的方法 範例定義域
依主體區域/定義域/內容類型 財務定義域包含與財務內容相關的每個工作區。
依照擁有和管理內容的小組/部門 企業 BI 定義域包含小組直接負責管理的所有工作區。
依照組織營業單位或部門 歐洲部門定義域包含與歐洲作業直接相關的所有工作區。
依專案 子公司收購定義域包含高度敏感專案的所有工作區。

以下是規劃租用戶中 Fabric 定義域時的一些考量。

  • 如何將每個工作區對應至定義域？ 每個工作區只能指派給一個定義域 (而不是多個定義域)，因此請準備好進行一些規劃。 請考慮使用資料列中的工作區和資料行中的定義域來建立矩陣圖，以協助您規劃指派工作區的方式。 如果您發現需要重新組織工作區，則可以在工作區設定或管理入口網站中重新指派定義域。
  • 將授權誰來管理定義域？ 定義域管理員角色的成員有權管理現有的定義域。 可能的話，請指派直接擁有和管理定義域內容的定義域系統管理員。 定義域管理員也應該是熟悉主題領域之內部、區域和政府法規的專家。 他們也應熟悉所有內部控管和安全性需求。 如需詳細資訊，請參閱定義域角色。
  • 應允許誰將工作區指派給定義域？ 定義域參與者角色的成員會定義哪些使用者 (也是工作區系統管理員) 可以將工作區指派給定義域。 如果您允許更多使用者將工作區指派給定義域，您應該經常稽核指派群組的正確性。 如果您只允許特定使用者群組或 Fabric 系統管理員和定義域系統管理員，您將能更充分掌控其指派方式。 如需詳細資訊，請參閱定義域角色。
  • 是否有特定的合規性需求或限制，例如地理區域？ 請記住，資料儲存體的地理區域是針對每個容量而設定的 (而不是針對定義域)。 請考慮如何將工作區指派給定義域，以及指派給容量，這會影響您的規劃程序。

如需詳細資訊，請參閱控管定義域。

檢查清單 - 規劃工作區定義域時，關鍵決策和動作包括：

  • 驗證內容擁有權的運作方式：確定您深入了解整個組織的內容擁有權和管理方式。 將資訊納入計劃，以將工作區組織到定義域中。
  • 規劃工作區定義域：討論如何最好地將工作區組織到定義域中。 向卓越中心以及您的執行發起人確認所有重要決策。
  • 教導 Fabric 系統管理員：確定您的租用戶系統管理員熟悉如何建立定義域，以及如何指派和管理定義域系統管理員。
  • 教導定義域系統管理員：確定您的定義域系統管理員在管理定義域方面了解此角色的預期情況。
  • 決定如何處理定義域參與者：請考慮哪些使用者應該有權將工作區指派給定義域。
  • 建立稽核程序：定期驗證指派的定義域群組是否正確。

工作區建立程序

如果您已決定限制誰可以建立工作區，則更廣泛的使用者擴展必須知道要求新工作區的程序為何。 在此情況下，請務必建立方便使用者尋找及追蹤的要求程序。

快速回應新工作區的要求也很重要。 2-4 小時的服務等級協定(SLA) 是理想的。 如果要求新工作區的程序太慢或負擔過重，人員會使用他們擁有的工作區，以便可以繼續工作。 如果他們選擇跳過建立新的工作區，則他們改用的方法可能是次佳。 他們可能會選擇重複使用不適合新內容的現有工作區，或可能從其個人工作區共用內容。

提示

建立新程序時的目標是讓人員更容易遵守此程序。 如同所有資料控管決策，關鍵是讓使用者輕鬆執行正確的動作。

下表列出要在新工作區要求中收集的資訊。

所需的資訊 範例 需要驗證
工作區名稱 SLS-現場銷售分析 • 名稱是否遵循命名慣例？

• 是否存在另一個具有相同名稱的工作區？
所需的階段 SLS-現場銷售分析 [Dev]、SLS-現場銷售分析 [Test]，以及 SLS-現場銷售分析 • 需要多個工作區才能正確支援內容嗎？

• 如果是的話，是否也應該建立部署管線？
描述 每月、每季和每年分析的客戶銷售額與訂購記錄。 • 是否預期敏感性資料或受管制的資料會儲存？

• 如果是的話，這會影響工作區的控管方式嗎？
目標對象 全域現場銷售組織 • 內容傳遞範圍有多廣？

• 這將如何影響工作區的控管方式？
指派給工作區的授權模式 需要適用於銷售團隊的 Fabric 容量，因為大量的銷售人員只是檢視人員，且他們擁有免費授權 • 需要何種等級的 Fabric 容量？
資料儲存體需求 加拿大的資料落地 • 是否有要求多地理位置的資料落地需求？

• 預期的資料量為何？
工作區系統管理員 FabricContentAdmins-FieldSalesAnalytics • 系統管理員 (理想) 是否為群組？

• 是否至少有兩位系統管理員？
提交要求的人員 requestor@contoso.com • 提交要求的人員是否在與所提供資訊相關的角色或企業營運中工作？

上表包含設定工作區所需的最小資訊量。 不過，它不包含所有可能的組態。 在大部分情況下，工作區系統管理員會在建立工作區之後負責完成設定。 如需詳細資訊，請參閱工作區層級設定一文。

有許多技術選項可用來建立工作區建立要求的線上表單。 請考慮使用 Microsoft Power Apps，這是一種低程式碼軟體選項，非常適合用來建置簡單的網頁型表單和應用程式。 您選擇要用來建立網頁型表單的技術取決於誰將負責建立和維護表單。

提示

若要提升效率和正確度，請考慮使用 Power BI REST API 將程序自動化，以程式設計方式建立或更新工作區。 在此情況下，我們建議包括檢閱和核准流程，而不是自動處理每個要求。

檢查清單 - 考慮要求新工作區的程序時，關鍵決策和動作包括：

  • 建立要求新工作區的程序：決定要求新工作區的特定程序。 請考慮您需要的資訊、如何擷取資訊，以及誰將處理要求。
  • 建立標準表單以要求新的工作區：決定新工作區表單上將包含哪些資訊。 請考慮建置 Power Apps 應用程式，以從使用者收集資訊。 請確定表單的連結可供廣泛使用，且易於在集中式入口網站和其他常見位置中找到。 在進行中通訊中也包含表單的連結。
  • 決定誰將回應提交的要求，以及要求的速度：判斷誰將處理要求。 請考慮處理新工作區要求的預期回應時間。 確認您可以快速處理要求，讓自助使用者不會遇到延遲。
  • 進行知識轉移研討會：如果另一個小組將支援工作區要求程序，請與他們進行知識轉移研討會，讓他們擁有所需的所有資訊。
  • 建立文件以了解如何核准或拒絕要求：建立有關如何核准要求的文件，以檢閱或處理要求為目標。 其中也包括要求可能遭到拒絕的原因，以及應該採取哪些動作。
  • 建立如何要求工作區的文件：建立有關如何要求新工作區的文件，以無法建立自己工作區的使用者為目標。 包含所需的資訊，以及回應的預期情況。 確保在您的集中式入口網站和訓練教材中提供該資訊。

工作區控管等級

並非所有工作區都需要相同的監督層級。 某些工作區可能會被視為受控管。 受控管工作區表示其內容有更多需求和預期情況。 某些組織會使用「受控」一詞，而不是受控管。

判斷控管等級有四個主要決策準則：

  • 誰擁有和管理 BI 的內容?
  • 傳遞 BI 內容的範圍為何?
  • 什麼是資料主體區域？
  • 資料和/或 BI 解決方案是否重要？

注意

如需四個主要決策準則的詳細資訊，請參閱構成 Fabric 採用藍圖一部分的控管文章。

您可以從兩個層級的工作區開始：受控管和未受控管。 建議您盡可能讓控管等級保持簡單。 不過，視您的特定情況而定，您可能需要細分受控管分類。 例如，由企業 BI 小組管理的重要內容可能會有一組控管需求。 而由營業單位直接擁有和管理的重要內容可能會受限於一組稍微不同的需求。 在某些情況下，決策會針對個別營業單位量身打造。

下表列出當工作區被視為受控管時，一些最常見的需求。

類別 潛在的控管需求
擁有權和支援 • 擁有權是指派給技術內容擁有者和/或主題專家的明確責任。

• 已指派使用者支援小組/人員，且使用者了解如何要求協助或提交問題。

• 使用者意見反應、問題和增強要求的機制已就緒。

• 溝通計劃存在，可宣佈工作區中內容的重要變更。
工作區設定 • 工作區具有妥善定義的用途。

• 使用特定的命名慣例。

• 工作區會指派給特定定義域。

• 需要工作區描述、影像和連絡人。
正確性 • 所有內容都經過認證。

• 資料驗證已自動化，讓內容擁有者能夠及時了解資料品質問題。
Distribution • Power BI 應用程式用於散發報告和儀表板。
安全性和資料保護 • 安全性群組用於管理工作區角色 (而不是個別帳戶)。

• 敏感度標籤會用於資訊保護。

• 只允許獲批准 (或已核准) 的資料來源。

• 所有來源檔案都位於備份的安全位置。
變更管理 • 使用個別的開發、測試和生產工作區。

• 原始檔控制 (例如 Git 整合) 用於 Fabric 入口網站中的所有 Power BI Desktop 檔案和項目。

• 版本設定或原始檔控制用於所有資料來源檔案。

• 遵循生命週期管理和變更管理程序，包括部署管線和/或 DevOps 程序。
Capacity • 工作區會指派給適當的 Fabric 容量等級。

• Fabric 容量受到管理和監視。
閘道 • 使用標準模式 (非個人) 的資料閘道。

• 所有閘道資料來源認證都使用已核准的認證。
稽核和監視 • 主動稽核和監視程序已就緒，可追蹤採用、使用模式和效能。

提示

控管需求通常不是選擇性的。 因此，及時的稽核很重要，而在某些情況下，強制執行會變得必要。 例如，如果受控的工作區要求所有檔案都位於安全的位置，而且稽核期間偵測到未核准的檔案位置，則應該採取動作來更新檔案位置。

檢查清單 - 考慮工作區控管等級時，關鍵決策和動作包括：

  • 決定工作區控管等級：決定您需要的控管等級。 請嘗試盡量保持簡單。
  • 決定如何分類工作區的準則：決定將工作區分類至特定控管等級的決策準則。
  • 決定工作區控管需求為何：針對每個控管等級，判斷將有哪些特定需求。
  • 決定如何指定工作區控管等級：尋找識別工作區控管等級的最簡單方式。 您可以將它記錄為其名稱的一部分、其描述的一部分，或儲存在其他地方 (例如，包含每個工作區的詳細資訊的 SharePoint 清單)。
  • 建立工作區控管需求的檔：建立以內容建立者為目標的實用文件，其中包含其管理受控工作區中內容的責任。 在您的集中式入口網站和訓練教材中提供資訊。
  • 建立工作區稽核程序：針對被視為受控管的工作區，建立稽核程序來識別不符合最重要需求的區域。 請確定有人負責連絡內容擁有者以解決合規性問題。

相關內容

在本系列中的下一篇文章中，了解工作區層級規劃。