费率和使用限制
Azure DevOps Services
Azure DevOps Services 使用多租户来降低成本并提高性能。 此设计使用户在他们共享资源的其他用户消耗量激增时，容易受到性能问题和中断的影响。 因此，Azure DevOps 会限制个人可以使用的资源，以及他们可以对某些命令发出的请求量。 超出这些限制后，可能会延迟或阻止将来的请求。
有关详细信息，请参阅 Git 限制 和 避免触及速率限制的最佳实践。
全局消耗限制
Azure DevOps 目前具有全局消耗限制，当共享资源处于不堪重负的危险时，会延迟来自单个用户的请求超出阈值。 当共享资源即将不堪重负时，此限制专门侧重于避免中断。 单个用户通常仅在发生以下事件之一时收到延迟的请求：
- 他们的共享资源之一面临着不堪重负的风险
- 在（滑动的）5 分钟窗口内，他们的个人使用量超过了普通用户的 200 倍
延迟量取决于用户的持续消耗级别。 延迟范围从每个请求的毫秒到 30 秒不等。 一旦消耗量变为零，或者资源不再不知所措，延迟就会在五分钟内停止。 如果消耗量仍然很高，为了保护资源，延迟可能会无限期地持续下去。
当用户请求被大量延迟时，该用户会在 Web 中收到电子邮件和警告横幅。 对于生成服务帐户和其他没有电子邮件地址的帐户，项目集合管理员组的成员将收到电子邮件。 有关详细信息，请参阅使用情况监视。
当单个用户的请求被阻止时，收到 HTTP 代码为 429（请求过多）的响应，消息类似于以下消息：
TF400733: The request has been canceled: Request was blocked due to exceeding usage of resource <resource name> in namespace <namespace ID>.
Azure DevOps 吞吐量单位
Azure DevOps 用户消耗了许多共享资源，消耗取决于以下因素：
- 将大量文件上传到版本控制会在数据库和存储帐户上创建大量负载
- 复杂的工作项跟踪查询根据搜索的工作项数创建数据库负载
- 通过从版本控制下载文件、生成日志输出来生成驱动器负载
- 所有操作都会在服务的各个部分消耗CPU和内存。
为了适应，Azure DevOps 资源消耗以称为 Azure DevOps 吞吐量单位（TSTU）的抽象单元表示。 TSTU 最终包含以下项目的混合：
- Azure SQL 数据库 DTU 作为数据库使用量的衡量标准
- 应用程序层和作业代理 CPU、内存和 I/O 作为计算消耗的衡量标准
- Azure 存储带宽作为存储消耗的度量值
目前，TSTU 主要侧重于 Azure SQL 数据库 DTU，因为 Azure SQL 数据库作为共享资源，经常因过度消耗而超负荷。 单个 TSTU 是预期 Azure DevOps 的典型用户每 5 分钟生成的平均负载。 典型用户还会在负载中生成峰值。 这些峰值通常为每五分钟 10 个或更少的 TSTU。 不太常见的情况是，峰值可达到 100 TSTU。
在五分钟的滚动时间窗口内，全局消耗限制为 200 个 TSTU。
我们建议你至少对 Retry-After 标头做出响应。 如果在任何响应中检测到 Retry-After 标头，请等待一段时间才能发送另一个请求。 这样做可以减少客户端应用程序受到的强制延迟。 请记住，响应为 200，因此无需将重试逻辑应用于请求。
如果可能，我们进一步建议监视 X-RateLimit-Remaining 和 X-RateLimit-Limit 标头。 这样做可以大致了解接近延迟阈值的速度。 客户端可以智能地做出反应，并随着时间的推移分散其请求。
注释
工具和应用程序用来与 Azure DevOps 集成的标识有时可能需要更高的速率和使用量限制，超出允许的消耗限制。 可以通过将 基本 + 测试计划 访问级别分配给应用程序使用的所需标识来增加这些限制。 满足更高的速率限制需求后，可以还原到以前的访问级别。 只有在分配给标识的时间内，你才需为基本 + Test Plans 访问级别付费。
已经被分配 Visual Studio Enterprise 订阅的标识在被移除之前，无法被分配基本 + Test Plans 访问级别。
管道
Azure Pipelines 的速率限制类似。 每个管道都被视为跟踪其自己的资源消耗的单个实体。 即使构建代理是自承载的，它们也会以克隆和发送日志的形式生成负载。
我们在滑动的 5 分钟窗口中对单个管道应用 200 TSTU 限制。 此限制与用户的全局使用量限制相同。 如果管道因速率限制而延迟或阻止，则会在附加的日志中显示一条消息。
API 客户端体验
当请求延迟或阻止时，Azure DevOps 将返回响应标头以帮助 API 客户端做出响应。 虽然未完全标准化，但这些标头 与其他常用服务大致一致。
下表列出了可用的标头及其含义。
除了 X-RateLimit-Delay，所有这些标头都会在请求开始延迟之前发送。
此设计使客户端有机会主动降低请求速度。
标头名称
说明
Retry-After
RFC 6585 指定的标头被发送，用于告知你在发送下一个请求之前需要等待多长时间，以确保低于检测阈值。 单位：秒。
X-RateLimit-Resource
一个自定义标头，指示已达到的服务和阈值的类型。 阈值类型和服务名称可能会随时间而变化，且不会显示警告。 我们建议将此字符串显示给人类，但不依赖它进行计算。
X-RateLimit-Delay
请求被延迟了多久。 单位：最多包含三个小数位数（毫秒） 的秒数。
X-RateLimit-Limit
在强制延迟之前允许的 TSTU 总数。
X-RateLimit-Remaining
延迟前剩余的 TSTU 数。 如果请求已被延迟或阻止，则为 0。
X-RateLimit-Reset
假设所有资源的消耗立即停止，那么在该时刻，累计的使用量将回到 0 个 TSTU。 以 Unix 纪元时间表示。
工作跟踪、流程管理、& 项目限制
Azure DevOps 对组织中可以拥有的项目数以及每个项目中可以拥有的团队数施加限制。 另请注意工作项、查询、积压工作、工作板、仪表板等的限制。 有关详细信息，请参阅 工作跟踪、流程和项目限制。
维基
除了通常的 存储库限制，为项目定义的 wikis 的单个文件大小限制为 25 MB。
服务连接
创建服务连接时，没有对每个项目的限制。 但是，可能会通过 Microsoft Entra ID 实施某些限制。 有关其他信息，请查看以下文章：