规范要解决什么
自动化资产数量增长后，最大的成本往往不是编写而是查找与判断：哪条剧本负责发布、哪个变量控制连接数、这份脚本还有没有人用。命名与目录规范的价值在于让这些判断不需要问人。好的规范通常只有几条硬规则：目录按用途而不是按作者划分，剧本名表达目标动作，角色名等于被管理的组件名，变量名带业务或组件前缀。
基本信息
| 目录划分 | 按用途分层：清单、角色、剧本、变量、模板 |
|---|---|
| 剧本命名 | 动词加对象，如 deploy-web、rollback-db |
| 角色命名 | 被管理的组件名，如 nginx、mysql |
| 变量命名 | 组件前缀加含义，避免通用名冲突 |
常用约定
- 不使用「临时」「测试」等含义模糊的名字作为长期资产命名。
- 同名文件在不同环境中不重复出现，环境差异由变量承担。
- 剧本名与对应变更类型一致，便于从工单反查资产。
- 目录不按人划分，避免人员变动后资产无人接手。
- 归档目录单独设置并写明有效期，避免废弃资产混在主线里。
- 命名长度适中，避免出现靠缩写猜含义的文件名。
命名对照
| 对象 | 推荐形式 | 应避免 |
|---|---|---|
| 剧本 | 动作加对象，如 patch-linux | test2、新建剧本 |
| 角色 | 组件名，如 nginx | nginx-v2-final |
| 变量 | 组件加含义，如 nginx_worker_processes | count、value |
| 模板 | 目标文件名加模板后缀 | a.conf、tmp.conf |
| 清单 | 按环境命名，如 prod-hosts | hosts-new、hosts2 |
| 归档 | 加日期与前缀标记 | 无标记的 old 目录 |
规范要靠评审执行：提交时检查命名与目录位置，比事后写一篇规范文档有效得多。规范条数越少越容易坚持。
改名要连带更新引用：剧本、流水线配置与文档都引用资产名时，重命名要一次改完，否则会出现执行到旧名字才报错的情况。