Azure资源IaC命名规范：如何区分基础设施阶段与软件阶段？

核心思路 #

把原命名规范里的stage拆成软件环境阶段和基础设施阶段两个独立字段，再补充全局唯一后缀的处理规则——既解决实验性基础设施的归类问题，又能避免全局唯一资源的命名冲突。

优化后的命名格式 #

{productName}-{infraStage}-{softwareStage}-{azureRegion}-{type}-{resourceType}[-{uniqueSuffix}]

各字段说明 #

• productName：保留原产品名称，明确资源归属
• infraStage：标记基础设施的级别，区分稳定生产和实验性环境：
  • prod：生产级稳定基础设施（对应所有软件阶段都跑在生产级基建上的需求）
  • exp：实验型新基础设施（用来测试新架构、Azure新服务特性等）
• softwareStage：对应原规范里的软件环境阶段：
  • dev：开发环境
  • test：测试环境
  • prod：生产环境
• azureRegion：Azure区域缩写（比如eastus、westeurope）
• type：资源分组类型（data/app/shared）
• resourceType：Azure资源类型的标准缩写（比如sql对应SQL数据库、vnet对应虚拟网络）
• uniqueSuffix：针对需要全局唯一的资源（比如存储账户、函数应用），可以加这个后缀：
  • 用随机4位字母数字组合（自动化部署时生成最方便）
  • 或者团队缩写加序号（比如team03）

实际示例 #

1. 生产级基建上的生产环境SQL数据库：

   contoso-prod-prod-eastus-data-sql-01
   

2. 实验性基建上的开发环境虚拟机：

   contoso-exp-dev-westeurope-app-vm-02
   

3. 需要全局唯一的实验基建存储账户：

   contoso-exp-test-eastus-data-storage-xy7z
   

配套建议 #

• 统一资源缩写：提前和团队约定好Azure资源的标准缩写，避免同一个资源类型出现多种写法
• 实验基建标签管理：给exp阶段的资源统一加标签（比如InfraStage: exp），方便后续批量清理、成本统计
• 自动生成唯一后缀：用ARM模板或者Bicep部署时自动生成随机后缀，不用手动想，减少冲突概率

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