優化權限以提升效能

Azure DevOps 服務

權限檢查是許多 Azure DevOps 服務作業的一部分。 在大規模上，許多明確的權限指派、資源層級例外以及群組成員資格會拖慢權限評估與更新速度。 大型存取控制清單也要求服務取得並解析更多權限資料與身份。

請參考本文的建議，減少 Azure DevOps Services 處理的權限資料量。

軟性性能限制

對大型組織而言，請使用以下限制作為規劃目標。 Azure DevOps Services 不會強制執行這些限制，也不會阻擋超出限制的權限變更。 然而，超過這些標準會增加權限查詢、評估和會員更新緩慢的風險。

存取控制條目（ACE）儲存分配給單一使用者或群組的權限。 對於巢狀群組，使用群組大小指引時，請考慮總有效成員數。

建議的做法

指派權限給群組

使用內建或自訂的 Azure DevOps 安全群組來代表角色、團隊和存取群組。 指派權限給群組會產生一個 ACE。 直接將相同權限分配給多個使用者，為每位使用者建立一個 ACE。

• 當內建群組如讀者、貢獻者和 Project 管理員的權限與所需存取權限相符時，則可優先使用。
• 當內建群組不符合所需的存取權限時，建立自訂群組。
• 不要用數百甚至數千個直接指派給使用者的項目來取代一個群組。

使用最廣泛的匹配範圍與繼承

在符合存取需求的最高支援範圍層級設定一次權限。 讓子資源繼承該權限，並維持啟用繼承，除非子資源需要不同的存取權限設定。

例如：

避免在每個儲存庫、分支、管線或其他子資源上分別設定相同的權限。 對於 Git 倉庫， 個別倉庫會繼承頂層 Git 倉庫條目的權限。

只有當資源需要與其父資源不同的存取權時，才停用繼承。 要在多個資源中停用繼承，通常需要更明確的指派。

僅在例外情況下使用拒絕

透過群組授權存取權限，對於不該獲得授權的身份則保持 權限為「未設定 」。 與其先授予廣泛存取權再加入大量 拒絕 條目，不如建立一個擁有精確權限的群組。

只有在必須覆蓋繼承的允許特定例外時才使用拒絕。 單一的 拒絕 條目本身並不代表效能問題。 然而，許多例外會加入 ACE，且通常需要更多物件層級的權限指派。

使用大小適當的身分識別群組

使用與存取需求相符的群組，例如業務單位、專案、產品或職務職能。 Entra 群組和 Azure DevOps 群組都沒有提供更好的效能。 將相同的大小與巢狀結構指引套用至兩種群組類型。

• 避免新增租戶或全公司群組，例如 全體員工 群組。
• 避免深度巢狀或頻繁變動的群組結構，當較簡單的群組提供相同存取時。
• 當成員不一定需要相同的存取時，可以將一個非常大的團體分成較小的群組。
• 如果每個成員都需要相同的存取權限，請在繼承的父範圍指派一個群組，而不是使用個別指派或重複群組。

超過一萬名成員的團體存在績效風險。 巢狀結構、成員資格的頻繁變更，以及可存取許多受權限控管的資源，都可能增加其影響。 減少不必要的會員，並在可行的情況下將團體拆分為較小的入學群組。

平衡專案與組織間的資源

避免將數千個資料庫和大部分權限保護的資源集中在一個專案中，而其他專案只包含少數資源。 發現可存取資源的操作可能需要評估整個資源集的權限。

在資源累積到單一專案前，將大量資源庫及其他資源分散到各專案之間。 不要在每個儲存庫只建立一個專案;專案數量也有 實際的效能限制。

在極端企業規模下，多個較小組織的表現可能優於擁有大部分公司資源與權限資料的組織。 沿著穩定的產品或業務邊界劃分組織，以分配資源與權限負擔。 只有當規模效益超過管理不同組織資源的額外負擔時，才可使用此方法。

減少權限自動化的頻繁變動

如果你透過腳本、REST API 或配置即程式碼工作流程來管理權限：

• 只套用達到預期狀態所需的變更。 不要每次執行都清除並重建未更改的權限分配。
• 在父級範圍內設定權限，而不是為每個子資源產生等效的條目。
• 批次變更已支援，並遵循 Azure DevOps REST API 最佳實務。
• 避免高頻的權限對帳迴圈。
• 避免經常建立和刪除大量專案或已授權資源。
• 移除過時的明確指派，以減少存取控制清單（ACL）與 ACE 磁碟量。

參見

• 關於權限和安全群組
• 關於專案與組織擴展
• 工作追蹤、處理序和專案限制
• Azure DevOps REST API best practices