Azure DevOps发布管道部署Azure ML模型遇‘操作冲突’报错

这个报错不是DevOps层面的并发问题，是Azure ML工作空间对目标部署实体挂了未释放的状态锁——哪怕你查遍DevOps所有运行记录、确认没有正在执行的管道，只要这个锁没释放，新的部署请求就会被直接拦下。

1. 优先清理工作空间内的残留操作锁 #

• 登录Azure ML工作空间控制台，找到本次部署目标的对应服务（对应命令里的命名规则），检查是否存在卡在“部署中”“更新中”的异常残留状态，对这类卡住的任务手动执行取消操作，强制释放实体锁
• 如果控制台看不到异常残留任务，可以通过Azure CLI手动查询并清理：
  • 先查询目标服务的关联操作ID：az ml service show -g <RG> -w <WS> -n <SN>
  • 拿到返回结果里的operationId字段后，执行操作取消命令强制释放锁：az ml operation cancel -g <RG> -w <WS> --operation-id <上一步获取的operationId值>

2. 修正管道任务的顺序错位问题 #

当前配置的任务执行顺序存在逻辑倒置，是触发这类锁残留的高频诱因：

• 现有顺序把部署命令放在了依赖安装步骤之前，执行az ml model deploy时如果因为环境缺包半路超时中断，会在Azure ML侧留下等待完成的操作锁，等下次管道触发时就会直接触发冲突报错
• 调整后的正确执行顺序为：
  • 指定Python版本任务
  • Bash任务先执行依赖安装（注意修正拼写错误：原命令写的requirments实际对应文件为requirements.txt，拼写错误会导致依赖根本无法安装）
  • Azure CLI任务安装ml扩展
  • Azure CLI执行部署命令

3. 调整部署命令的重试规则规避偶发冲突 #

• 注意--overwrite参数的实际作用：它仅用于部署完成后覆盖同名称的旧服务，完全不具备抢占正在运行的操作锁的能力，不要指望靠这个参数解决冲突
• 给部署类的Azure CLI任务配置退避重试规则：设置最多3次重试，每次重试间隔60秒——Azure ML侧的操作锁默认超时时间为15分钟，短时间间隔的重试基本可以等到残留锁自动释放
• 微软托管代理没有跨任务的状态共享，不需要额外清理代理侧的缓存残留，核心冲突源基本都来自Azure ML工作空间的锁状态

4. 链路验证 #

• 锁清理完成、任务顺序调整后，先单独触发单任务测试部署命令，确认可以正常拿到部署完成的状态返回后，再跑全量发布管道
• 后续的集成测试、测试结果发布任务要放在部署完成后再执行，不要和部署环节的环境依赖混淆

内容的提问来源于stack exchange，提问作者Almostapha