Azure CLI创建存储Blob容器时随机出现‘对象未找到’错误排查

在通过Azure CLI脚本创建存储账户后立即创建Blob容器、文件共享或队列时，常会遇到随机的ResourceNotFound（404）错误——即使存储账户的provisioningState显示为Succeeded、statusOfPrimary为available，甚至设置了固定时长的sleep，问题仍偶发出现。

可靠的就绪验证方案 #

核心思路是同时验证控制平面（ARM）和数据平面的就绪状态，并给存储操作添加重试机制，避免依赖固定时长的等待：

1. 先等待ARM资源部署完成

使用az resource wait命令，确保存储账户在Azure Resource Manager层面完全部署完成：

az resource wait --resource-group $GROUP --resource-type Microsoft.Storage/storageAccounts --name $NAME --provisioning-state Succeeded

2. 轮询验证数据平面服务可用性

ARM状态就绪不代表数据平面（实际存储服务）已完全可用，需直接调用存储服务的操作来验证，比如尝试列出容器（即使为空）：

# 轮询直到存储服务可正常响应
until az storage container list --account-name $NAME --auth-mode login --output none 2>/dev/null; do
    echo "等待存储账户数据平面就绪..."
    sleep 5
done

3. 给存储操作添加内置重试

在创建容器/共享/队列的命令中添加--retries参数，让Azure CLI自动处理偶发的服务延迟：

az storage container create --account-name $NAME --name $container --auth-mode login --output none --retries 3

修改后的完整脚本示例 #

az storage account create -g $GROUP --name $NAME --public-network-access Enabled --location $LOCATION --sku Standard_LRS --output none

# 等待ARM层面存储账户部署完成
az resource wait --resource-group $GROUP --resource-type Microsoft.Storage/storageAccounts --name $NAME --provisioning-state Succeeded

# 轮询验证数据平面服务可用
until az storage container list --account-name $NAME --auth-mode login --output none 2>/dev/null; do
    echo "等待存储账户服务就绪..."
    sleep 5
done

# 创建Blob容器
containers=("container1" "container2" "container3" "container4" "container5")
for container in ${containers[@]}; do
  echo Creating $container blob container in $NAME storage account...
  az storage container create --account-name $NAME --name $container --auth-mode login --output none --retries 3
done

为什么固定sleep不可靠？ #

Azure存储账户的就绪时间受区域负载、资源部署队列等因素影响，固定时长的等待无法适配所有场景——短了仍会遇到未就绪的情况，长了则浪费不必要的时间。通过主动轮询服务可用性，能在服务就绪后立即执行后续操作，同时内置重试机制能应对偶发的网络或服务延迟。

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