本文提供了常见托管 DevOps 池问题的解决方案。
池创建错误
| 错误代码 | 说明 |
|---|---|
PoolProvisioningFailed |
由于 Azure DevOps 组织权限而导致池创建失败 |
UnauthorizedAccessToVirtualNetwork |
由于 VNet 权限导致池创建失败 |
由于 Azure DevOps 组织权限而导致池创建失败
池创建失败，并出现类似于以下错误消息的错误。
未在 Azure DevOps 组织中找到已登录用户
Validation failure "PoolProvisioningFailed": "Failed to provision agent pool. Exception: The logged in user, <your user>, was not found in the Azure DevOps organization provided, <your Azure DevOps organization>."
若要解决问题，请执行以下操作：
- Azure DevOps 组织必须连接到 Microsoft Entra ID，并且已登录的 Azure 用户必须是此租户的成员（而不是来宾）。 请参阅 托管 DevOps 池先决条件 - 将 Azure DevOps 组织连接到 Microsoft Entra ID 并验证成员身份。
登录的用户在 Azure DevOps 组织中没有“管理”权限
Validation failure "PoolProvisioningFailed": "Failed to provision agent pool. Exception: The logged in user, <your user>, does not have Manage permissions in the Azure DevOps organization provided, <your Azure DevOps organization>."
若要解决问题，请执行以下操作：
- 登录的 Azure 用户必须具有适当的 Azure DevOps 权限才能创建池。 请参阅 Azure DevOps 先决条件 - 验证 Azure DevOps 权限。
由于 VNet 权限导致池创建失败
池创建失败，出现UnauthorizedAccessToVirtualNetwork类似于以下错误的错误： Validation failure "UnauthorizedAccessToVirtualNetwork": "DevOpsInfrastructure service principal does not have Read access to virtual network <your VNet> in resource group <your resource group>. Give Reader and Network Contributor access to DevOpsInfrastructure service principal and try again.
若要解决此问题，请执行下列操作：
- 托管 DevOps 池需要访问虚拟网络。 请参阅 授予读者和网络参与者对 DevOpsInfrastructure 服务主体的访问权限。
- 虚拟网络子网需要委托给
Microsoft.DevOpsInfrastructure/pools。 请参阅 将子网委托给 Microsoft.DevOpsInfrastructure/pools。
管道启动延迟
使用托管 DevOps 池时，可能会遇到这样一种情况：在管道被触发后，到其开始运行之间会有很长的延迟。 故障排除指南的此部分介绍可能影响池性能的常见项。 有关详细信息，请参阅 管理成本和性能。
检查并行作业不足
托管 DevOps 池代理被视为 Azure DevOps 的自承载代理，需要自承载并行作业才能运行。 例如，如果组织的自托管并行数为 10，则组织只能同时运行 10 个自托管管道作业。 如果排队的管道超过 10 个，则一次只能运行 10 个。
检查自托管环境中的并行作业数量，以确保有足够的能力满足您的工作负荷对并发管道的需求。 有关详细信息，请参阅配置并行作业并为其付费。
检查最大代理配置
"最大代理"设置用于配置托管 DevOps 池中正在运行的代理的最高数量。 如果 “最大代理 ”设置为 5，则托管 DevOps 池最多可以运行五个并发管道。 如果排队了 5 个以上的管道，则在可用五个可用代理之一之前，其他管道不会启动。
注释
最大代理 配置可以同时预配的最大代理数，但组织自托管并行作业数量指定可以同时运行的作业数。 确保组织中有足够的并行的自托管作业，以便代理能够运行作业。 有关详细信息，请参阅 Azure DevOps Services 并行作业定价。
考虑使用备用代理时间表预先配置代理
如果备用代理模式被禁用，则在管道排队时会按需启动 Managed DevOps 池中的代理，虽然通常一个新代理只需几分钟即可启动，但有时最长可能需要 15 分钟。
启用 备用代理模式 后，可以指定计划和代理计数，以便随时满足工作负荷的需求。
有关详细信息，请参阅 管理成本和性能 - 使用备用代理进行预预配。
新泳池的自动待机模式
DevOps 池管理使用历史池使用情况数据来帮助进行自动待机模式的扩展预测。 新池没有任何历史数据，因此可能会按需创建代理。 为了提高性能，可以在第一个月切换到手动待机模式，并在托管 DevOps 池有时间观察池使用情况后切换到自动待机模式。
如果对多个映像使用备用代理，请检查备用代理百分比
如果对多个映像使用备用代理，请检查每个映像的使用情况历史记录，并将其与映像的 备用代理百分比 设置进行比较，以确保备用比率与使用情况匹配。 例如，如果你有一个 Windows 映像和一个 Ubuntu 映像，并且工作负荷使用 Windows 75% 时间，请确保 Windows 映像配置为备用代理百分比为 75。
考虑使用有宽限期的有状态池，以保持代理联机状态。
在不使用备用代理的情况下提高代理性能的一种选择是使用短宽限期的有状态代理。 当具有宽限期的有状态代理完成作业时，它会在宽限期指定的持续时间内保持联机状态，并等待其他作业。 如果工作负荷突发，则可以配置一个宽限期，该宽限期可在作业稳定时使代理保持联机状态，并在较慢的时间段从头开始启动它们。
查看超时错误代码
如果代理分配超时，可以在“概述”页的“错误代码”部分检查错误代码。
管道无法成功完成
检查是否存在映像更新
如果映像更新后管道开始失败，则可以暂时将管道配置为使用以前的映像版本。 可以将失败的管道配置为单独使用以前的映像版本，或者可以为托管 DevOps 池中所有使用该映像的管道配置以前的映像版本。
若要查看管道是否由于映像版本更改而失败，请将失败的管道运行的映像版本与上次成功的管道运行中的映像版本进行比较。
-
查看要比较的两个管道运行的运行详细信息，然后选择管道作业以查看该作业的诊断信息。 如果管道有多个作业，请选择在托管的 DevOps 池中运行的作业。
选择 “初始化作业”，然后从 “当前映像版本 ”部分检索映像版本。
如果最近失败的管道运行和上一次成功运行之间的映像版本不同，则失败可能是由映像更新引起的。 您有两个选择可以在排查根本原因时暂时还原到以前的映像版本。
- 若要仅使用以前的映像版本运行失败的管道，请向管道添加一个
ImageVersionOverride要求以指定以前的版本。 有关详细信息，请参阅 ImageVersionOverride。 - 若要更新池设置，以便使用映像运行的所有管道都使用以前的版本运行，请更新 映像设置 并指定所需的版本。
- 如果使用 Azure Pipelines 映像，则必须使用 ARM 模板 或 Azure CLI 指定版本，因为使用 Azure 门户配置的 Azure Pipelines 映像始终使用最新版本。
- 如果使用 选定的市场镜像 或 Azure 计算图库映像，则可以使用 Azure 门户以及 ARM 模板和 Azure CLI 指定版本号。
托管的 DevOps 池会保留过去的 20 个映像用于所选市场映像，以及过去的 10 个映像用于 Azure Pipelines 映像。 过去版本的 Azure 计算库映像由这些 Azure 计算库的所有者维护。