Azure DevOps服务
权限检查是许多Azure DevOps服务操作的一部分。 大规模而言，许多显式权限分配、资源级异常和组成员身份可能会降低权限评估和更新速度。 大型访问控制列表还要求服务检索和解析更多权限数据和标识。
使用本文中的建议减少Azure DevOps服务进程的权限数据量。
Tip
可以使用 AI 帮助完成 Azure DevOps 任务。 请参阅 在 Azure DevOps MCP Server 启用 AI 辅助功能 即可入门。
软性能限制
使用以下限制作为大型组织的规划目标。 Azure DevOps服务不会强制实施这些限制或阻止超出这些限制的权限更改。 但是，超过它们会增加权限查询、评估和成员身份更新缓慢的风险。
| Measure | 建议的最大值 |
|---|---|
| 一个安全命名空间中的 ACE | 1,000,000 |
| 一个Microsoft Entra或Azure DevOps组中的成员 | 10,000 |
访问控制项（ACE）存储分配给一个用户或组的权限。 对于嵌套组，在使用组规模准则时，请考虑有效成员总数。
推荐做法
| 练习 | 性能优势 |
|---|---|
| 将权限分配给组而不是单个用户 | 将许多用户访问控制条目（ACE）替换为一个组 ACE。 |
| 使用尽可能广的匹配范围和继承机制 | 避免在子资源上重复相同的 ACE。 |
| 仅在例外情况下使用拒绝 | 限制显式覆盖和对象级 ACE。 |
| 使用大小合适的身份组 | 减少不必要的组成员关系处理。 |
| 跨项目和组织平衡资源 | 限制在一个边界内评估的资源数。 |
| 以增量方式应用权限更改 | 减少由大量或频繁的访问控制更新带来的负载。 |
将权限分配给组
使用内置或自定义Azure DevOps安全组来表示角色、团队和访问队列。 向组分配权限会创建一个 ACE。 直接向许多用户分配相同的权限将为每个用户创建 ACE。
- 当读者、参与者和Project管理员等内置组的权限与所需的访问权限匹配时，首选这些组。
- 当内置组与所需访问权限不匹配时创建自定义组。
- 不要用数百或数千个直接用户分配替换一个组。
使用最广泛的匹配范围和继承
在与访问要求匹配的最高支持范围内设置一次权限。 让子资源继承该权限，并保持继承处于启用状态，除非某个子资源需要不同的访问权限。
例如：
| 访问要求 | 首选范围 |
|---|---|
| 执行组织级任务 | 组织级，在该级别可使用该权限时 |
| 访问项目中受支持类型的所有资源 | 项目级别或资源类型的项目级别父级 |
| 访问项目中的所有 Git 存储库 | 顶层 Git 仓库 条目 |
| 访问存储库中的所有分支 | 存储库级别 |
| 访问一个存储库、分支、管道、区域路径或其他资源 | 对象级别 |
避免在每个存储库、分支、管道或其他子资源上单独设置相同的权限。 对于 Git 存储库， 单个存储库从顶级 Git 存储库条目继承权限。
仅当资源需要与其父资源不同的访问权限时，才禁用继承。 对多个资源禁用继承通常需要更明确的权限分配。
仅将“拒绝”用于例外情况
通过组授予访问权限，对于不应接收授权的标识，将权限保留为“未设置”。 创建具有所需确切权限的组，而不是授予广泛访问权限，然后添加许多 拒绝 条目。
仅当你必须覆盖继承的“允许”以进行特定异常时才使用“拒绝”。 单个 拒绝 条目本质上不是性能问题。 但是，许多异常会添加 ACE，并且通常需要更多的对象级权限分配。
使用大小合适的身份组
使用符合访问要求的组，例如业务部门、项目、产品或作业功能。 Entra 组和Azure DevOps组都没有提供更好的性能。 对两种组类型应用相同的大小和嵌套指南。
- 避免添加租户范围或公司范围的组，例如“所有员工”组。
- 当更简单的组提供相同的访问权限时，请避免深度嵌套或频繁更改的组结构。
- 当其成员不需要相同的访问权限时，将非常大的组拆分为较小的访问队列。
- 如果每个成员都需要相同的访问权限，请在继承的父范围分配一个组，而不是使用单独分配或重复组。
具有 10,000 多个成员的组存在性能风险。 嵌套、频繁的成员资格更改以及对许多有权限资源的访问可能会增加影响。 减少不必要的成员资格，并在可行的情况下将该组拆分为更小的访问群组。
跨项目和组织平衡资源
避免将数千个存储库和大多数受权限保护的资源集中到一个项目中，而其他项目仅包含少量存储库。 用于发现可访问资源的操作可能需要对整个集合中的权限进行评估。
在一个项目中累积过多资源之前，跨项目分发大量存储库和其他资源。 不要为每个存储库创建一个项目;项目计数也有 实际的性能限制。
在极端的企业规模下，多个较小的组织的性能比包含大多数公司资源和权限数据的一个组织更好。 按稳定的产品或业务边界拆分组织，以分配资源和权限负载。 仅当规模优势超过管理单独组织中的资源的开销时，才使用此方法。
减少权限自动化的频繁变更
如果您通过脚本、REST API 或配置即代码工作流管理权限：
- 仅应用达到预期状态所需的更改。 不要清除和重新生成每次运行时未更改的权限分配。
- 在父范围设置权限，而不是为每个子资源生成等效条目。
- 在支持的情况下批量进行更改，并遵循Azure DevOps REST API 最佳实践。
- 避免高频权限协调循环。
- 避免定期创建和删除大量项目或权限资源。
- 删除过时的显式分配项，以减少访问控制列表（ACL）和 ACE 的数量。