为什么需要给自动化脚本“建档案”

运维自动化往往是从一个个临时脚本开始的：有人写 Shell 批量重启服务，有人用 Python 拉取监控数据，有人把重复操作整理成 Ansible Playbook。脚本数量增长后，常见问题随之出现——同名脚本散落在不同主机、同一功能存在多个版本、交接时无人说得清哪一份才是最新。把这些资产分门别类归档，本质上是把“个人经验”转化为“团队可复用的运维资产”。

三类工具的分工边界

归档之前，先明确每一类工具更适合解决什么问题，避免出现“一个脚本什么都干”的情况。

Ansible：配置管理与批量编排

Ansible 以无代理方式通过 SSH 连接目标主机，使用 YAML 描述任务，模块具备幂等特性，适合标准化配置下发、软件部署、多主机批量执行等场景。它更适合承载“稳定的、需要反复执行”的流程。

Shell：贴近系统层与应急操作

Shell 脚本直接调用系统命令，启动快、依赖少，适合系统巡检、日志清理、进程健康检查以及故障现场的一次性处置。需要注意的是，Shell 脚本通常不具备幂等性，环境差异也会影响执行结果，因此更适合短小、职责单一的场景。

Python：复杂逻辑与接口集成

当任务涉及结构化数据处理、调用 HTTP 接口、操作数据库或需要较完善的异常处理时，Python 脚本比 Shell 更合适。Python 脚本也可以被封装为 Ansible 的自定义模块，让编排能力与复杂逻辑结合起来。

推荐的归档目录结构

目录结构不必复杂，但要保证“看到路径就知道脚本干什么”。以下结构可作为起点，团队可按实际规模调整：

• ansible/：存放 Playbook、Role、Inventory 与变量文件，按业务或系统分组。
• shell/：存放系统巡检、清理、启停类脚本，按操作系统或中间件分组。
• python/：存放数据处理、接口对接类工具，按功能模块划分包目录。
• docs/：存放脚本清单、参数说明、变更记录与依赖说明。
• tests/：存放脚本的自检用例或验证脚本，用于上线前确认。

分类归档的四个维度

只按语言分类远远不够，建议叠加业务维度，形成可检索的多级结构。

1. 按用途：部署发布、配置变更、巡检采集、备份恢复、故障处置、数据清理。
2. 按对象：主机系统、数据库、中间件、网络设备、容器平台、云资源。
3. 按环境：开发、测试、预发布、生产，通过变量或配置文件区分，而不是复制多份脚本。
4. 按生命周期：在用、待验证、已废弃。已废弃脚本建议移入归档目录并标注停用原因，而不是直接删除。

命名与元数据规范

命名前置清晰，可以显著降低沟通成本。

• 统一使用小写字母与连字符或下划线，避免中文文件名与空格。
• 名称中包含“对象 + 动作”，例如主机巡检、日志清理等含义明确的组合。
• 每个脚本头部注明用途、负责人、创建与修改日期、依赖组件、执行权限要求。
• Ansible 变量与 Python 配置项集中管理，不把环境相关参数硬编码在逻辑中。

版本管理与变更评审

自动化脚本应当与业务代码同等对待，纳入 Git 等版本控制系统。建议按主干加分支的方式管理，提交信息写明变更目的；涉及生产环境的脚本修改，走一次简单评审，确认影响范围、回滚方式与执行窗口。历史版本保留，便于出现问题时快速比对与回退。

安全与权限

脚本中容易出现敏感信息，归档时需要额外注意：

• 禁止在脚本中明文写入密码、密钥、令牌，改用 Ansible Vault、环境变量或密钥管理服务。
• 为脚本设定最小可用权限，避免长期使用高权限账号执行日常任务。
• 涉及删除、重启、批量变更的操作，加入确认参数或二次校验逻辑。
• 对执行记录进行留痕，便于事后追溯。

文档、索引与检索

再规范的目录，如果缺少索引也难以被找到。建议维护一份清单，记录脚本名称、用途、适用对象、依赖环境、负责人与最近更新日期。文档与脚本放在同一仓库，随代码一起更新，避免文档与实现脱节。

测试、灰度与回收

自动化脚本一旦批量执行，错误也会被批量放大。上线前至少在一台非生产主机验证；条件允许时先在小范围灰度，观察输出与系统状态，再逐步扩大范围。定期清理长期未使用、依赖已下线组件的脚本，保持资产库的有效性。

落地建议

分类归档不是一次性整理，而是持续维护的机制。可以从现有脚本盘点入手，先统一命名与目录，再补充文档与版本控制，最后把常用流程沉淀为标准 Role 或工具模块。随着资产库逐步完善，新成员上手更快，重复工作更少，自动化投入的回报也更清晰。