一、问题的本质：从"脚本散落"到"基础设施即代码"当你在几十上百台物理机上维护rc.local、/usr/local/bin下的自定义脚本、手工systemctl enable的单元文件时，你会遇到三个系统性问题：不可追溯：某台机器上的挂载脚本为什么多了一行sleep 30？没人知道。不可复现：新机器上线时，靠"老张记得那台机器要改哪里"。不可审计：磁阵挂载失败、Koji 构建节点掉线、虚拟机没起来时，无法快速定位是哪份配置、哪个版本导致的。这本质上和"应用代码散落在生产服务器上"是同一类问题。解决方案也一致：把开机服务当作代码来管理（Infrastructure as Code）。这要求我们把 systemd 单元、脚本、配置、部署逻辑全部纳入版本控制，并用统一的目录结构组织起来。关键概念——单一事实来源（Single Source of Truth）：任何一台机器的开机行为，都应当能从 Git 仓库中的某一份声明推导出来，而不是依赖机器上的历史残留。关键概念——幂等性（Idempotency）：所有开机脚本必须可以重复执行而不产生副作用。挂载脚本重复执行不应重复挂载或报错退出，启动虚拟机的脚本重复执行应识别"已在运行"状态。这是把脚本纳入自动化管理的前提。二、设计原则：五条铁律在给出目录结构之前，先明确管理这些服务时应遵循的原则：原则说明关注点分离systemd 单元、执行脚本、业务配置、主机差异，四者分开放置，不混在一个文件里声明式优先能用 systemd 的Requires/After/Wants表达依赖的，不要在脚本里用sleep硬编码单一职责一个 service 只做一件事。挂载磁阵、启动虚机、连接 Jenkins 应是独立单元，而非一个巨型脚本主机差异外置主机名、IP、磁阵 IQN、虚拟机清单等差异项放入host_vars，不写死在脚本中可验证单元文件必须能通过systemd-analyze verify，脚本必须能通过shellcheck，纳入 CI三、目录结构设计：一套可直接落地的仓库布局推荐采用Ansible 角色为中心 + 分层目录的结构。Ansible 是 RHEL 生态（CentOS / Anolis / openEuler）中最自然的配置管理工具，且其角色目录天然实现了关注点分离。boot-services/ ├── README.md # 仓库说明、快速上手、部署流程 ├── .gitignore # 排除 secrets、retry 文件、临时产物 ├── Makefile # 统一入口：make lint / make deploy / make verify ├── ansible.cfg # Ansible 全局配置 │ ├── inventory/ # 【主机清单与差异】 │ ├── production/ │ │ ├── hosts.yml # 主机分组：storage_nodes / koji_builders / virt_hosts │ │ ├── group_vars/ │ │ │ ├── all.yml # 全局变量（NTP 服务器、DNS 等） │ │ │ ├── storage_nodes.yml # 磁阵挂载组通用变量 │ │ │ ├── koji_builders.yml # Koji 构建节点通用变量 │ │ │ └── virt_hosts.yml # 虚拟化物理机通用变量 │ │ └── host_vars/ │ │ ├── node01.example.com.yml # 单机差异：磁阵 IQN、虚机清单 │ │ └── node02.example.com.yml │ └── staging/ # 预发环境，结构与 production 一致 │ ├── roles/ # 【核心：每个开机服务一个角色】 │ ├── common/