本篇主要描述客户在使用腾讯云上云产品资源时，需从资源命名规范上，进行统一规范化设计。云上资源统一命名目的是：其一，云上资源命名规范化；其二，云上资源统一规范便于后续云上自动化，以增强整体云上运维能力，提升云平台整体运维透明度/资源辨识度，以及从资源管理、云上自动运维管理等维度提升云上管理的高效性。
目标读者
本文档主要适用于如下对象群体：
- 云平台工程师
- 云平台配置工程师
- 云架构师
- 云平台研发人员
1.背景
在服务众多客户的过程中，发现不少客户在使用腾讯云产品资源时，资源命名没有统一的规范，要么没有命名规范，出现"未命名"的现象，即使有了一定的命名，在长期的运维环境下，并未有效的规范起来。随着业务的扩展，资源只会越来越多，再加上人员的更迭，若有没有统一的命名规范，对后期云上资源的管理也是非常不利的，不仅梳理需要大量时间，而且出现故障，不好及时定位到对应的资源，以及云上的风险治理等等都带来不小的麻烦。因此无论是开始使用云的新用户，还是老用户均可参考本篇云上资源命名的规范，再结合企业自身云上资源管理需求进行调整与设计。
1.1. 资源命名目标
本篇主要基于云上常见的云资源情况进行统一命名，便于资源命名规范化，以及后续云上自动化，提升云上运维效率。
1.2. 资源命名范围
本篇资源命名内容范围如下：
资源命名涉及：CVM、VPC、安全组、子网、MySQL、Redis、TKE、CLB等产品
2. 资源命名规范
该文档制定的规范适用于客户云上资源当前及未来的云资源命名和参考。 若有特殊化命名需求，建议结合自身团队的需求，进行统一设计与迭代。（这里命名的间隔用“-”，或“_”均可，命令中文应均可，看各自偏好）
2.1. CVM云服务器命名规则
为了让客户云上运维及基础云管理，增加资源辨识度，现制定以下云服务器命名规则。
CVM云服务器按以下规则命名：
CVM_[区域与可用区]_[部门]_[申请人/负责人]_[平台与环境]_[应用名称与编号]_[到期时间]_[客户侧负责人可选] 如：
CVM_BJ6_IT部_张三_某平台生产环境_storm01_202303
规则标识 | 字段说明 |
|---|---|
【CVM】 | 产品名称可全称或简称 |
【区域与可用区】 | 如：BJ6/GZ1: 北京区域，6：北京六区； GZ：广州区域 1：广州一区 |
【部门】 | IT部 |
【申请人/负责人】 | 张三 |
【平台与环境】 | 平台简称 |
【应用名称与编号】 | Storm01…/其他业务/应用名称; 应用有多个，则通过编号标识 |
【到期时间】 | 202303是指2023年3月份到期 |
【客户侧负责人】 | 可选项, 如：李四 |
2.2. VPC虚拟私有云命名规则
VPC 按照以下规则命名：
VPC_[区域]_[资源属性]_[编号] 如：VPC_BJ_PRD_01
规则标识 | 字段说明 |
|---|---|
[区域] | BJ：北京， GZ：广州 |
[资源属性] | PRD：生产 DEV：开发 TEST：测试 SHA：公共支撑 SEC：安全 |
[编号] | 01: 预留编号，用于今后扩展使用 |
2.3. 子网命名规范
子网 按照以下规则命名：
SN_[VPC]_[子网可用区]_[功能]_[编号] 如：SN_VPC_BJ_PRD_01_BJ1_DB_01
规则标识 | 字段说明 |
|---|---|
[区域] | BJ：北京， GZ：广州 |
[资源属性] | PRD：生产 DEV：开发 TEST：测试 SHA：公共支撑 SEC：安全 |
[子网可用区] | BJ1：北京一区 BJ2：北京二区 |
[功能] | 公共访问子网：INT，其它应用子网：OTH， 管理子网：MGT ，DB子网：DB |
[编号] | 01: 编号，用于今后扩展使用 |
2.4. 安全组命名规则
安全组按照以下规则命名：
SG_[VPC]_[应用]_[用途]_[资源所有者] 如：SG_VPC_BJ_PRD_01_ALL_General
规则标识 | 字段说明 |
|---|---|
[VPC] | VPC_BJ_PRD_01 |
[应用] | ALL：允许所有访问 |
[用途] | General: 通用 |
[资源所有者] | 可选，如：张三 |
2.5. 对等连接命名规则
对接连接按照以下规则命名：
VPR_[所属VPC]_[目标VPC]_[资源所有者] 如：VPR_VPC_BJ_PRD_01-VPC_GZ_PRD_01
规则标识 | 字段说明 |
|---|---|
[所属VPC] | VPC_BJ_PRD_01 |
[目标VPC] | VPC_GZ_PRD_01 |
[资源所有者] | 可选，如：张三 |
2.6. VPN网关命名规则
VPN网关按照以下规则命名：
VGW_[VPC]_[资源所有者] 如：SG_VPC_BJ_PRD_01_Zhangsan
规则标识 | 字段说明 |
|---|---|
[VPC] | VPC_BJ_PRD_01 |
[资源所有者] | 可选，如：张三 |
2.7. NACL命名规则
NACL按照以下规则命名：
NACL_[VPC]_[网段用途]_[资源所有者] 如：NACL_VPC_BJ_PRD_01_Public_Zhangsan
规则标识 | 字段说明 |
|---|---|
[VPC] | VPC_BJ_PRD_01 |
[网段用途] | General: 通用 |
[资源所有者] | 可选，如：张三 |
2.8. CLB负载均衡命名规范
CLB负载均衡按照以下规则命名
CLB_[区域与可用区]_[平台及版本]_[资源属性]_[业务属性]_[编号]_[资源所有者]: 如：
CLB_BJ1_PLATFORM3.0_PRD_01
规则标识 | 字段说明 |
|---|---|
[区域与可用区] | 如：BJ: 北京区域，1：北京一区； GZ：广州区域 1：广州一区 |
[平台及版本] | 平台简称 |
[资源属性] | PRD：生产 SEC：安全 DEV：非生产 SHA：公共支撑 |
[编号] | 集群/其他业务环境编号01.. |
[资源所有者] | 可选，如：张三 |
2.9. MySQL数据库命名规则
MySQL按照以下规则命名:
CDB_[区域与可用区]_[平台及版本]_[资源属性]_[业务属性]_[编号]_[资源所有者], 如:
CDB_BJ1_PLATFORM3.0_PRD_FlinkCluster_01_Zhangsan
规则标识 | 字段说明 |
|---|---|
[区域与可用区] | 如：BJ: 北京区域，1：北京一区； GZ：广州区域 1：广州一区 |
[平台及版本] | 平台简称 |
[资源属性] | PRD：生产DEV：开发 TEST：测试 SHA：公共支撑 SEC：安全 |
[业务属性] | Flink集群/其他业务 |
[编号] | 集群/其他业务环境编号01.. |
[资源所有者] | 可选，如：张三 |
2.10. Redis数据库名规则
Redis按照以下规则命名
CRS_[区域与可用区]_[平台及版本]_[资源属性]_[业务属性]_[编号]_[资源所有者]:
CRS_BJ1_PLATFORM3.0_PRD_Cluster_01_Zhangsan
规则标识 | 字段说明 |
|---|---|
[区域与可用区] | 如：BJ: 北京区域，1：北京一区； GZ：广州区域 1：广州一区 |
[平台及版本] | 平台简称 |
[资源属性] | PRD：生产DEV：开发 TEST：测试 SHA：公共支撑 SEC：安全 |
[业务属性] | 集群/其他业务 |
[编号] | 集群/其他业务环境编号01.. |
[资源所有者] | 可选，如：张三 |
2.11. TKE命名规则
TKE按照以下规则命名
TKE_[区域与可用区]_[平台及版本]_[资源属性]_[编号]_[资源所有者], 如：
TKE_BJ1_PLATFORM4.0_PRD_01_Zhangsan
规则标识 | 字段说明 |
|---|---|
[区域与可用区] | 如：BJ: 北京区域，1：北京一区； GZ：广州区域 1：广州一区 |
[平台及版本] | 平台简称 |
[资源属性] | PRD：生产DEV：开发 TEST：测试 SHA：公共支撑 SEC：安全 |
[编号] | 01: 编号，用于今后扩展使用 |
[资源所有者] | 可选，如：张三 |
2.12. Kafka命名规则
Kafka按照以下规则命名
Kafka_[区域与可用区]_[平台及版本]_[资源属性]_[业务属性]_[编号]_[资源所有者], 如:
Kafka_BJ1_NewC_PRD_MT_01_Zhangsan
规则标识 | 字段说明 |
|---|---|
[区域与可用区] | 如：BJ: 北京区域，1：北京一区； GZ：广州区域 1：广州一区 |
[平台及版本] | 平台简称 |
[资源属性] | PRD：生产DEV：开发 TEST：测试 SHA：公共支撑 SEC：安全 |
[业务属性] | 如：搅拌车/其他业务 |
[编号] | 01: 编号，用于今后扩展使用 |
[资源所有者] | 可选，如：张三 |
3.总结
本篇只提供了常见的云上资源命名规范设计的参考，读者可参考自身云上的业务及部门需求进行调整与设计，来满足企业内部的需求。更好的方式是可采用强制的自动化方式(基础设施即代码/API管理方式/流水线云上资源管理机制)让其命名规范能有效且长期运行才是王道。本篇先介绍到这里~
