本文說明您在租用戶 層級 針對 Microsoft Fabric 工作區執行的策略性實作規劃，並強調 Fabric 內的 Power BI 體驗。
備註
本文是 Power BI 實作規劃 系列文章的一部分。 本系列著重於規劃在 Microsoft Fabric 內實作 Power BI 體驗。 請參閱 系列簡介。
本文主要適用於：
- 網狀架構系統管理員：負責監督組織中 Fabric 實作的系統管理員。
- 卓越中心（CoE）、IT 和商業智慧（BI）小組：負責監督組織中數據和 BI 的使用，以及支援整個組織的自助使用者。
本文可能對於在工作區中進行內容建立、發佈及管理的自助式創作者有幫助。
因為工作區可以用不同方式使用，因此大部分的戰術實作決策都是在 工作區層級進行。 您會在租用戶層級做出一些策略性規劃決策。
建議您儘早做租戶層級工作區決策，因為它們會影響其餘所有事項。 此外，當您清楚瞭解整體工作區目標和目標時，更容易做出個別工作區決策。
備註
工作區的概念源自 Power BI。 在 Fabric 中，工作區的用途會擴大。 Fabric 工作區可以包含來自多個 網狀架構體驗 的專案（也稱為 工作負載）。 雖然內容範圍比 Power BI 更廣，但您可以套用這些文章中所述的大部分工作區規劃活動來規劃您的 Fabric 工作區。
工作區建立權限
在 Power BI 服務中，允許誰建立工作區的決策是 數據文化 和 治理 的決定。
您有兩個選擇：
- 所有 （或大部分） 使用者可以建立新的工作區：這種方法通常與其他應用程式的現有決策一致。 例如，當允許使用者建立自己的 SharePoint 網站或 Teams 頻道時，Fabric 採用相同原則是合理的。
- 工作區建立僅限於選取的使用者集：此方法通常表示治理計劃已就緒或已規劃。 管理此過程可以完全集中管理（例如，如果只允許資訊技術部門建立工作區）。 更有彈性且實用的方法是當它是集中式和分散式個人的組合時。 在此情況下，CoE、冠軍或信任使用者的特定衛星成員會經過訓練，以代表其業務單位建立和管理工作區。
您應該根據允許誰建立工作區的決策，在 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 目錄中使用篩選。
下表列出您可以組織相關工作區的不同方式：
| 組織工作區的方法 | 範例網域 |
|---|---|
| 依主旨區域、網域或內容類型 | Finance 網域包含與財務內容相關的所有工作區。 |
| 由負責擁有及管理內容的小組或部門 | 企業 BI 定義域包含小組直接負責管理的所有工作區。 |
| 依照組織營業單位或部門 | 歐洲部門網域包含與歐洲作業直接相關的所有工作區。 |
| 按專案 | 子公司併購網域包含支援高度敏感專案的所有工作區。 |
以下是在租戶中規劃 Fabric 網域時要考慮的一些問題：
- 每個工作區如何對應至網域？ 每個工作區只能指派給一個網域，因此請準備好進行一些詳細的規劃。 請考慮建立矩陣圖表，以列出數據行中數據列和網域中的工作區，以協助您規劃指派工作區的方式。 如果您發現需要重新組織工作區，您可以在工作區設定或管理入口網站中重新指派網域。
- 誰有權管理網域？ 獲指派網域系統管理員角色的用戶有權管理現有的網域。 可能的話，請指派直接擁有和管理網域內容的網域系統管理員。 定義域管理員也應該是熟悉主題領域之內部、區域和政府法規的專家。 他們也應熟悉所有內部控管和安全性需求。 如需詳細資訊，請參閱定義域角色。
- 誰可以指派工作區給網域？ 指派網域參與者角色的用戶會定義哪些工作區管理員可以將工作區指派給網域。 如果您允許更多使用者將工作區指派給定義域，您應該經常稽核指派群組的正確性。 如果您只允許特定使用者群組或網狀架構系統管理員和網域系統管理員，您可以更充分掌控如何指派網域。 如需詳細資訊，請參閱定義域角色。
- 您是否有特定的合規性需求或限制，例如地理區域？ 請記住，數據記憶體的地理區域會針對每個容量設定，而不是針對網域設定。 請考慮將工作區分配給範疇和容量如何影響您的規劃過程。
如需詳細資訊，請參閱控管定義域。
規劃工作區網域時的重要決策和動作檢查清單：
當您規劃工作區網域時，關鍵決策和動作包括：
- 驗證內容擁有權的運作方式：請確定您深入瞭解整個組織內容擁有權和管理的方式。 將該資訊納入您的計畫，以便將工作區組織到各個域中。
- 規劃工作區網域：討論如何最好地將工作區組織成網域。 向 CoE 和您的執行贊助者確認所有重要決策。
- 教育網狀架構系統管理員：確定您的租用戶系統管理員熟悉如何建立網域，以及如何指派和管理網域管理員。
- 教育網域系統管理員：確定您的網域系統管理員瞭解管理網域中此角色的預期。
- 決定如何處理網域參與者：請考慮哪些用戶應該有權將工作區指派給網域。
- 建立稽核程式：定期驗證指派的網域群組是否正確。
工作區建立程序
如果您決定限制誰可以建立工作區，更廣泛的使用者群體需要了解申請新工作區的流程。 在此情況下，請務必建立方便使用者尋找及追蹤的要求程序。
快速回應新工作區的要求也很重要。 服務等級協定 （SLA） 為 2 到 4 小時是理想的。 如果申請新工作區的流程太慢或繁瑣，人們就會使用他們現有的工作區，以便他們能繼續進行。 如果他們選擇跳過建立新的工作區，則他們使用的替代方案可能不是最佳選擇。 他們可能會選擇重複使用不適合新內容的現有工作區，或可能從其個人工作區共用內容。
提示
當您建立新的程式時，目標是讓人員更容易遵守此程式。 與所有數據控管決策一樣，關鍵是讓用戶能夠輕鬆地遵循記載的程式。
下表列出新工作區要求中要收集的資訊：
| 所需的資訊 | 範例 | 需要驗證 |
|---|---|---|
| 工作區名稱 | SLS-現場銷售分析 | • 名稱是否遵循命名慣例？ • 是否存在另一個具有相同名稱的工作區？ |
| 所需的階段 | SLS-現場銷售分析 [Dev]、SLS-現場銷售分析 [Test]，以及 SLS-現場銷售分析 | • 需要多個工作區才能正確支援內容嗎？ • 如果是的話，是否也應該建立部署管線？ |
| 描述 | 每月、每季和每年分析的客戶銷售額與訂購記錄。 | • 是否預期會儲存敏感數據或受管制的數據？ • 如果是的話，這會影響工作區的控管方式嗎？ |
| 目標對象 | 全域現場銷售組織 | • 內容傳遞範圍有多廣？ • 該範圍將如何影響工作區的控管方式？ |
| 分配給工作區的工作區類型 | 需要適用於銷售團隊的 Fabric 容量，因為大量的銷售人員只是檢視人員，且他們擁有免費授權 | • 需要何種等級的 Fabric 容量？ |
| 資料儲存體需求 | 加拿大的資料駐留 | • 資料存放需求是否需要 多重地理區域? • 您預期要處理和儲存的資料數量為何？ |
| 工作區系統管理員 | FabricContentAdmins-FieldSalesAnalytics | • 系統管理員是否（理想情況下）是一個群組？ • 至少指派兩個系統管理員嗎？ |
| 提交要求的人員 | requestor@contoso.com | • 提交要求的人員是否在與所提供資訊相關的角色或企業營運中工作？ |
下表包含設定工作區所需的最小資訊量。 不過，它不包含所有可能的組態。 在大部分情況下，工作區管理員會在建立工作區之後負責完成設定。 如需詳細資訊，請參閱 工作區層級設定。
您可以從許多技術選項中選擇，為工作區創建請求建立線上表單。 請考慮使用 Microsoft Power Apps，這是一種低程式碼軟體選項，非常適合用來建置簡單的 Web 型表單和應用程式。 您選擇要用來建立網頁型表單的技術取決於負責建立和維護表單的人員。
提示
若要提升效率和正確度，請考慮使用 Power BI REST API 將程序自動化，以程式設計方式建立或更新工作區。 在此情況下，我們建議包括檢閱和核准流程，而不是自動處理每個要求。
當您規劃申請新工作區時，關鍵決策和行動的檢查清單：
- 建立要求新工作區的程序：決定要求新工作區的特定程式。 請考慮您需要的資訊、如何擷取資訊，以及處理要求的人員。
- 建立申請新工作區的標準格式：決定新工作區表單上要包含哪些資訊。 請考慮建置 Power Apps 應用程式，以從使用者收集資訊。 請確定表單的連結可供廣泛使用，且易於在集中式入口網站和其他常見位置中找到。 在進行中通訊中也包含表單的連結。
- 決定誰將回應提交的要求，以及要求的速度：判斷誰將處理要求。 請考慮處理新工作區要求的預期回應時間。 確認您可以快速處理要求，讓自助使用者不會遇到延遲。
- 進行知識轉移研討會：如果另一個小組支援工作區要求程式，請與他們進行知識轉移會話，讓他們擁有所需的所有資訊。
- 建立文件以瞭解如何核准或拒絕要求：建立說明如何核准要求的文件，以提供給那些將要檢閱或處理要求的人士。 其中也包括要求可能遭到拒絕的原因，以及應該採取哪些動作。
- 建立如何要求工作區的檔：建立有關如何要求新工作區的檔，以無法建立自己的工作區的用戶為目標。 包含所需的資訊，以及回應的預期情況。 請確定資訊可在集中式入口網站和訓練教材中使用。
工作區控管等級
並非所有工作區都需要相同的監督層級。 某些工作區可能會被視為受控管。 受控工作區會產生更多其內容的需求和期望。 某些組織會使用「受控」一詞，而不是受控管。
四個主要決策準則會決定所需的治理層級：
- 誰擁有和管理 BI 的內容?
- 傳遞 BI 內容的範圍為何?
- 什麼是資料主體區域？
- 數據或 BI 解決方案是否被視為關鍵？
您可以從兩個層級的工作區開始：受控管和未受控管。 建議您盡可能讓控管等級保持簡單。 不過，視您的特定情況而定，您可能需要細分受控管分類。 例如，企業 Power BI 小組所管理的重要內容可能有一組獨特的治理需求。 業務單位擁有和管理的重要內容可能會受到一組稍微不同的需求。 在某些情況下，決策會針對個別業務單位量身打造。
下表列出當工作區被視為受控管時，一些最常見的需求。
| 類別 | 潛在的治理需求 |
|---|---|
| 擁有權和支援 | • 已指派負責權，明確指定技術內容負責人或主題專家。 • 已指派使用者支援小組/人員，且使用者了解如何要求協助或提交問題。 • 使用者意見反應、問題和增強要求的機制已就緒。 • 溝通計劃存在，可宣佈工作區中內容的重要變更。 |
| 工作區設定 | • 工作區具有妥善定義的用途。 • 使用特定的命名慣例。 • 工作區會指派給特定定義域。 • 需要工作區描述、影像和連絡人。 |
| 正確性 | • 所有內容都經過認證。 • 資料驗證已自動化，讓內容擁有者能夠及時了解資料品質問題。 |
| 分配 | • Power BI 應用程式用於散發報告和儀表板。 |
| 安全性和資料保護 | • 安全性群組用於管理工作區角色 (而不是個別帳戶)。 • 敏感度標籤會用於資訊保護。 • 只允許獲批准 (或已核准) 的資料來源。 • 所有來源檔案都位於安全且備份的位置。 |
| 變更管理 | • 使用個別的開發、測試和生產工作區。 • 原始檔控制 (例如 Git 整合) 用於 Fabric 入口網站中的所有 Power BI Desktop 檔案和項目。 • 版本設定或原始檔控制用於所有資料來源檔案。 • 遵循生命週期管理和變更管理流程，包括部署管道或 DevOps 流程。 |
| 容量 | • 工作區會指派給適當的 Fabric 容量等級。 • Fabric 容量受到管理和監視。 |
| 閘道 | • 使用標準模式(非個人)的數據閘道。 • 所有閘道資料來源認證都使用已核准的認證。 |
| 稽核和監視 | • 主動稽核和監視程序已就緒，可追蹤採用、使用模式和效能。 |
提示
控管需求通常不是選擇性的。 因此，及時的稽核很重要，而在某些情況下，強制執行會變得必要。 例如，如果受控的工作區要求所有檔案都位於安全的位置，而且稽核期間偵測到未核准的檔案位置，則必要的動作是更新檔案位置。
規劃工作區治理層級時的重要決策和動作檢查清單：
- 決定工作區治理層級：決定您需要的治理層級。 盡可能保持簡單。
- 決定如何分類工作區的準則：決定要用來將工作區分類至特定治理層級的決策準則。
- 決定工作區治理需求是什麼：針對每個治理層級，判斷哪些特定需求。
- 決定如何指定工作區治理層級：尋找識別工作區治理層級的最簡單方式。 您可以將它記錄為其名稱的一部分、其描述的一部分，或儲存在其他地方 (例如，包含每個工作區的詳細資訊的 SharePoint 清單)。
- 建立工作區控管需求的檔：建立以內容建立者為目標的實用檔，其中包含其管理受控工作區中內容的責任。 在集中式入口網站和訓練教材中提供資訊。
- 建立工作區稽核程式：針對被視為受控管的工作區，建立稽核程式來識別不符合最重要的需求區域。 請確定有人負責連絡內容擁有者以解決合規性問題。