企业级Ansible自动化运维规范核心是工程实践而非技术炫技，强调多人协作可持续、变更可追溯、执行可审计、故障可回滚；需采用roles+site.yml分层结构、分级加密变量、幂等性Playbook编写、Git+CI/CD流程管控及专用账户权限管理。
企业级 Ansible 自动化运维规范不是写一堆 YAML 就完事，核心是让多人协作可持续、变更可追溯、执行可审计、故障可回滚。它本质是一套工程实践约定，而非技术炫技。
目录结构与角色划分要清晰
避免把所有 playbook、变量、脚本堆在同一个目录下。推荐按 Ansible 官方推荐的 roles + site.yml 分层结构组织：
-
inventories/：分环境存放（如
prod/、staging/、dev/），每个环境含hosts、group_vars/、host_vars/，禁止硬编码 IP 或密码 -
roles/：按功能职责拆分，例如
nginx、mysql-server、logrotate，每个 role 包含tasks/、handlers/、defaults/、vars/、templates/、files/ -
playbooks/：顶层编排，如
deploy-webapp.yml、patch-servers.yml，只 include roles，不写具体任务逻辑 -
group_vars/all.yml：放全局共用变量（如
timezone: Asia/Shanghai），但敏感信息必须用ansible-vault加密
变量管理必须分级且加密
变量混乱是企业环境出问题的高发区。规范要求：
- 优先级顺序明确：host_vars > group_vars > playbook vars > role defaults；避免在多个层级重复定义同一变量
- 所有密码、密钥、API Token 必须存入
group_vars/<env>/vault.yml，用ansible-vault encrypt vault.yml加密，解密口令由运维组统一保管 - 使用
{{ lookup('env', 'ANSIBLE_VAULT_PASSWORD_FILE') }}自动读取解密口令文件，禁止交互式输入 - 变量命名带前缀，如
webapp_db_host、webapp_deploy_user，避免冲突和歧义
Playbook 编写要遵循幂等性与防御性
企业环境不允许“试一次看结果”，每条任务必须满足幂等性（多次运行效果一致），并具备安全兜底：
- 禁用
shell和command模块直接执行任意命令；优先用copy、yum、systemd、file等原生模块 - 所有服务启停必须加
state: started/stopped，启动后加enabled: yes控制开机自启 - 关键操作（如重启服务、重载配置）前加
changed_when: false或when: ansible_facts['distribution'] == 'CentOS'做平台判断 - 涉及文件变更的操作必须启用
backup: true，便于快速恢复上一版本 - 每个 playbook 开头声明
gather_facts: true，并用vars_prompt或tags控制高危动作（如ansible-playbook deploy.yml --tags "dangerous"）
执行流程与权限管控要制度化
自动化不是“谁有权限谁乱跑”，需嵌入企业 ITIL 流程：
- 所有 playbook 必须通过 Git 仓库管理（如 GitLab），开启 MR（Merge Request）审批机制，至少 2 人 review 后方可合并到
main分支 - 生产环境执行必须走 CI/CD 流水线（如 Jenkins 或 AWX），禁止人工
ansible-playbook -i prod/hosts ...直连执行 - Ansible 控制节点使用专用服务账户（如
ansible-runner），该账户仅能 SSH 登录被控节点，且无 sudo 免密权限；提权操作统一通过become: true+ 限定become_user实现 - 每次执行记录日志到 ELK 或本地归档，包含时间、操作人、inventory、playbook 路径、commit hash、执行结果摘要
不复杂但容易忽略——真正落地的企业级规范，80% 在结构与流程，20% 在语法细节。先立规矩，再填内容，才能让自动化成为稳定器，而不是放大器。
