1. 课程导入与平台工程全景
在开始搭建任何自动化平台之前，我们需要先回答一个根本问题：RHEL 自动化运维平台到底是什么？它不是某一个开源工具的别名，也不是把 Ansible、GitLab、Prometheus 简单堆在一台服务器上。更准确地说，它是一套以 RHEL 为运行底座、以“声明式描述 + 版本化交付 + 可观测反馈”为主线的运维能力工程化体系。它的目标是把过去依赖个人经验和手工操作的运维动作，转化为可重复、可审计、可回滚、可度量的平台能力。
理解这个定义，可以从三个层次切入。第一层是执行层：所有变更最终都要落到受管节点上，无论是安装软件包、下发配置文件、重启服务，还是滚动升级。第二层是控制层：谁有权发起变更、变更内容从哪里来、经过哪些校验、如何分批推进。第三层是反馈层：变更之后系统处于什么状态，指标、日志、告警是否印证了预期结果。缺少任何一层，平台都会退化成“批量执行脚本的工具”，而不是工程化的运维平台。
核心价值：从“救火”到“可预期”
自动化运维平台的核心价值并不只是“快”。真正重要的是把不确定性压缩到可控范围内。手工操作时，同一批 50 台服务器可能因为执行顺序、环境差异、操作者状态不同而产生 50 种结果；平台化之后，期望状态被写成代码，执行过程被记录，偏差被检测并纠正。具体来说，它带来四类可衡量的收益：
- 一致性：同一份 Playbook 或 Role 在开发、测试、生产环境产生结构相同的配置结果，减少“这台机器和那台不一样”的排查成本。
- 可追溯：每次变更对应一次提交、一个流水线编号、一份执行日志，出问题能定位到“谁在什么时候改了什么”。
- 可回滚：配置和代码一起版本化，回滚不再依赖记忆，而是切换到上一个已知良好版本。
- 可度量：变更成功率、平均恢复时间、配置漂移数量等指标可以被持续采集，用于改进而不是凭感觉判断。
典型场景：平台到底解决什么问题
在 RHEL 环境中，自动化运维平台最常见的落地场景包括：批量基线配置（如统一时区、NTP、YUM 源、内核参数、审计规则）、应用发布与回滚（如 Web 集群的滚动更新）、补丁与合规管理（如按安全公告批量更新并验证）、配置漂移检测与修复（定期比对期望状态与实际状态）、日常巡检与告警联动（采集关键指标并在异常时触发处置流程）。这些场景的共同点是：对象多、步骤重复、对一致性要求高、出错代价大——这正是平台化收益最明显的地方。
技术栈选型：为什么是这些组件
本课程采用的技术栈以 RHEL 9 为底座，围绕“配置管理 + 版本控制 + 流水线 + 可观测”四条主线组织。配置管理选择 Ansible，原因是它基于 SSH、无代理、YAML 描述直观，适合 RHEL 环境快速落地；版本控制选择 Git，所有 Playbook、Role、变量和清单都进入仓库；流水线选择 GitLab CI 或 Jenkins，用于把“提交代码”变成“受控执行”；可观测层使用 Prometheus + Grafana + node_exporter，采集节点指标并可视化；日志与审计可结合 rsyslog / journald 与集中式日志系统。需要强调的是，选型不是绝对的，关键是每条主线都有明确职责，避免工具之间功能重叠导致维护混乱。
整体架构分层
把上述组件放到一张分层图中，可以更清楚地看到数据和控制是如何流动的。下图展示了本课程后续章节会逐步搭建的平台全景：最上层是用户与触发入口，中间是控制与执行核心，底层是受管节点与反馈采集，右侧是贯穿始终的版本与审计支撑。
这张图中有两条方向相反的流需要特别留意。控制流从用户触发开始，经过流水线编排，由 Ansible 下发到受管节点，是“期望状态”的传递方向；反馈流则从节点指标、日志和审计记录出发，回到控制层，用于判断变更是否达到预期、是否需要触发修复或回滚。很多团队只搭了控制流，结果平台变成“能批量改但不知道改完对不对”的半成品。因此从第一天起，就应该把可观测层当作平台的一等公民，而不是事后补丁。
一个最小可用的教学示例
为了把抽象架构落到具体操作，我们给出一个最小示例：用 Ansible 对一组 RHEL 9 节点统一配置 NTP 客户端并确保 chronyd 处于运行状态。假设清单文件 inventory.ini 内容如下：
[web]
web01.example.com
web02.example.com
[db]
db01.example.com
[all:vars]
ansible_user=ops
ansible_ssh_private_key_file=~/.ssh/id_rsa对应的 Playbook 片段可以写成：
- name: 统一 NTP 基线
hosts: all
become: true
tasks:
- name: 安装 chrony
ansible.builtin.dnf:
name: chrony
state: present
- name: 下发 chrony 配置
ansible.builtin.template:
src: chrony.conf.j2
dest: /etc/chrony.conf
owner: root
group: root
mode: '0644'
notify: 重启 chronyd
- name: 确保 chronyd 已启用并运行
ansible.builtin.service:
name: chronyd
state: started
enabled: true
handlers:
- name: 重启 chronyd
ansible.builtin.service:
name: chronyd
state: restarted执行时使用 ansible-playbook -i inventory.ini ntp.yml。观察输出时重点关注三类信息：changed 表示实际发生了变更，ok 表示已符合期望状态，failed 表示执行失败。如果第二次执行时大部分任务显示 ok，说明幂等性生效，平台没有做多余动作。随后可以在节点上执行 chronyc sources -v 查看时间源状态，确认 NTP 同步正常。这个例子虽小，却完整覆盖了“清单定义对象、Playbook 描述期望、执行产生变更、命令验证结果”的闭环，后续章节的复杂场景都是在这个骨架上扩展出来的。