自动化与 IaC:把运维写成代码Copy Anchor Link

1. 这一章讲什么Copy Anchor Link

前面各章的每个阶段(CI/CD、测试、监控)背后都是自动化。这一章把它扶正为主角:先给自动化划范围(IT/业务/RPA/工业四类,DevOps 关心第一类),再逐阶段讲自动化做什么、用什么指标度量;然后落到本章的硬核——基础设施即代码(IaC) 和它的代表工具 Ansible(playbook、模块、角色、幂等)。

2. 顶层全景Copy Anchor Link

  DevOps 五阶段 × 自动化: Build(自动拉码/编译/打包) → Test(自动跑测试) → Deploy(自动发布)
                              → Operate(IaC 自动配环境) → Monitor(自动采集/告警)
  IaC 一句话:   声明式(要什么) vs 命令式(怎么做)——Ansible/Terraform 是前者
  Ansible 三件事: 无代理(SSH 就够) + YAML playbook + 幂等(重复跑结果一样)

3. 核心原理Copy Anchor Link

3.1 自动化的收益与代价Copy Anchor Link

书里给了一组有冲击力的数字:Amazon 的自动化让开发者平均每 11.7 秒部署一次、每天超过 10 万次部署¹。四大收益:速度(小时级→分钟级)、伸缩(流量来了自动加机器)、一致性(脚本不会「看心情」)、标准化(全公司同一套模板)²。代价也如实列了:初始投入高、缺人、legacy 难集成、工具选型难、安全合规、脚本维护难、ROI 难量化³。

3.2 五个阶段各自的自动化与度量Copy Anchor Link

这些指标表(表 11.1–11.5)是本章最实用的部分——每个阶段自动化得好不好,都有数可量⁴。

3.3 IaC:声明「要什么」,别说「怎么做」Copy Anchor Link

IaC = 用代码定义基础设施,存进 Git,可审查、可复用、可跨环境重复⁵。它和传统脚本的本质区别是声明式 vs 命令式:

书里对照表(表 11.6)还给了可复用性、可读性、扩展性三行:模块和变量让 IaC 能参数化复用,脚本往往是硬编码⁶。

两条 Ansible/Terraform 代码示例照抄原书:Ansible 在 webservers 组装 Apache⁵;Terraform 在 AWS 起一台 t2.micro EC2⁷。

3.4 Ansible 解剖Copy Anchor Link

来历:2012 年 Michael DeHaan(Red Hat 前工程师)为「简单、无代理、安全」而造,2015 年被 Red Hat 收购⁸。

三特性⁹:

1. 无代理(agentless):目标机器什么都不用装,控制机通过 SSH(Windows 用 WinRM)直接管;
2. YAML playbook:人话写的任务清单;
3. 幂等(idempotent):跑一百遍和跑一遍结果一样。

积木四块¹⁰:

• ad-hoc 命令:一行速查,ansible webservers -m ping;
• playbook:YAML 文件,一组按序执行的任务,ansible-playbook site.yml;
• module:真正干活的积木(apt、service、copy、file……几百个内置);
• roles:把 playbook 按职责拆成可复用的目录结构(roles/webserver/tasks/main.yml),主 playbook 只剩 roles: [webserver, website, database] 三行——书里的完整例子是「装 nginx + 拷网站文件 + 装 MySQL」三角色部署¹¹。
• 还有 collections(ansible-galaxy collection install amazon.aws):模块的打包分发格式¹²。

幂等的正例与反例(书里最诚实的一段¹³):声明 amazon.aws.ec2_instance: state: present 反复跑会重复创建 EC2 实例(AWS 侧不按名字去重);而 OpenStack 的 openstack.cloud.server 反复跑只有一台 VM。结论:幂等是「模块在目标系统支持去重时」的性质,不是所有模块天然如此——选型时要验证。机制:模块动手前先查当前状态,一致就跳过,报告 ok 而非 changed¹³。

push vs pull:push(默认)是控制机主动 SSH 推给目标;pull 是每台目标机跑 ansible-pull 从 Git 拉 playbook 自己执行——超大规模环境 pull 更易伸缩¹⁴。

3.5 落地:从小处开始,别大爆炸Copy Anchor Link

最佳实践四条¹⁵:

1. Start small:先自动化「高频、规则化、耗几分钟、易错」的任务(每天手工建测试库、拷构建产物);书里警告了「大爆炸自动化」——一个冲刺里同时上 K8s+Terraform+Jenkins+安全扫描,团队搞不懂工具间怎么交互,排错无门,比不自动化还糟。
2. 环境一致性:Win 笔记本(Python 3.11 + SQLite)上能跑的脚本,到了 Linux 生产机(Python 3.8 + PostgreSQL)就炸——OS 版本、依赖、环境变量都要对齐;工具就是前面各章的 IaC + 容器 + Git + CI/CD¹⁶。
3. 安全内建:密码/API key 不许写进脚本(用 Ansible Vault、HashiCorp Vault、AWS Secrets Manager);自动化工具别给 root 全权限;推代码时自动跑静态扫描(SonarQube/Snyk/Checkmarx),部署前扫镜像漏洞(Trivy、Clair)¹⁷。
4. 接入 CI/CD 的红线:短命分支勤合并,禁 big-bang 合并;不许绕过评审强推主分支(用受保护分支 + 强制 merge request);构建一次、同一构件逐级晋升,别每个环境重新构建(不一致的温床);secret 不进仓库/镜像/日志;别依赖单一 CI runner¹⁸。

挑战与边界:初始投入(CapEx)、legacy 集成难、技能缺口、变更阻力、运维负担;以及什么时候该停手——过度自动化:为用 IaC 起一台临时测试 VM 搭五层校验、为改两行 HTML 建三阶段流水线,复杂度远超任务价值¹⁹。

未来三词²⁰:AIOps(日志/指标/追踪实时关联)、Policy-as-Code(安全治理规则代码化、每阶段自动执行)、NoOps(运维全自动化——书里的态度是「方向对,但不会适合所有组织」)。

4. 作者的判断与证据Copy Anchor Link

有出处的:Amazon 11.7 秒/次部署的数据有脚注(引用自行业博客,非一手论文,精度存疑);Ansible 各机制与官方文档一致,幂等反例(EC2 vs OpenStack)是难得的诚实教学¹³。

作者的判断:「从小处开始」「防过度自动化」是经验之谈,方向正确;「NoOps 是趋势」是推测,书中自己加了限定。

我们的补充:Terraform 2023 年从 MPL 转为 BSL 许可证引发社区分裂、OpenTofu 分叉——书里只客观陈述了许可证变化(在 7.4.2 节提到 OpenTofu),未展开;声明式配置与 Kubernetes 期望状态模型同源(书里分别讲了,没点破)(补充,不在书里)。

5. 边界与局限Copy Anchor Link

• Chef/Puppet/SaltStack/Terraform 各只有一段定位,实操全押 Ansible。
• Ansible 的变量、handler、template、vault 等进阶机制未展开。
• 安全的合规自动化(DevSecOps)只列工具名。
• 未讨论自动化失败时的回退与人因(Human factors)设计。

6. 可带走的Copy Anchor Link

1. 自动化四收益:速度、伸缩、一致、标准;代价是先花钱花时间²³。
2. 每阶段有各自的度量指标;Operate 阶段看幂等率,Monitor 阶段看告警疲劳指数⁴。
3. IaC 的本质:声明「要什么状态」,工具自己凑;命令式脚本要自己管步骤和防重⁶。
4. Ansible 三特性:无代理、YAML、幂等;四积木:ad-hoc、playbook、module、role⁹¹⁰。
5. 幂等不是所有模块天然成立——AWS EC2 的 state: present 会重复创建,OpenStack 不会;选型要验证¹³。
6. push 控制机说了算,pull 目标机自己拉——超大规模选 pull¹⁴。
7. 落地四原则:小处起步、环境一致、安全内建、接 CI/CD 守红线(构建一次、逐级晋升)¹⁵¹⁸。
8. 过度自动化是真实风险:临时 VM 别配五层校验¹⁹。

7. 原文地图Copy Anchor Link