📚 课程目录第1章课程导入与全景认知

1. 课程导入与全景认知

在传统云上运维模式中，工程师通常通过 AWS 管理控制台逐项点击创建 VPC、子网、安全组、EC2、RDS、负载均衡器等资源。这种方式在单套环境、少量资源时看似直观，但当系统扩展到开发、测试、预发、生产四套环境，每套环境又包含几十甚至上百个资源时，问题会迅速暴露：环境之间配置漂移、手工操作遗漏、变更无法审计、故障后难以快速重建、多人协作时互相覆盖。基础设施即代码（Infrastructure as Code，IaC）正是为了解决这些问题而出现的工程实践。

IaC 的核心思想是：把云上基础设施的定义从“控制台里的点击记录”转变为“可版本控制、可评审、可重复执行的代码”。在 AWS 场景中，这意味着 VPC 的网段划分、子网的可用区分布、安全组规则、IAM 角色权限、S3 桶策略、RDS 参数组等，都以声明式或命令式代码的形式保存在 Git 仓库中。任何环境变更都通过代码提交、评审、流水线执行来完成，而不是由某个人在控制台上临时修改。这样，环境不再是“某台机器上某个人记得的配置”，而是“仓库中某个 commit 所描述的状态”。

IaC 带来的四个直接工程价值：

可重复性：同一份代码可以在不同账号、不同区域重建出结构一致的环境；

可审计性：每次变更都有 commit、PR、执行日志，谁在何时改了什么一目了然；

可回滚性：通过 Git 回退到上一个已知良好版本，再重新执行即可恢复；

环境一致性：开发、测试、生产使用同一套模块和参数化差异，减少“在我机器上能跑”的问题。

然而，IaC 并不等于“把控制台操作写成脚本”这么简单。真正落地时会遇到一系列工程挑战。第一是状态管理：Terraform 需要远程后端（如 S3 + DynamoDB）保存 state 文件并加锁，否则多人同时执行会互相破坏；CloudFormation 则由 AWS 托管状态，但栈之间的依赖和导出值需要谨慎设计。第二是环境差异化：开发环境可能只需要单可用区、小规格实例，生产环境需要多可用区、高可用、加密和备份，如何用同一套模块表达差异而不复制粘贴，是模块化设计的核心。第三是密钥与敏感信息：数据库密码、API Key 不能明文写在代码里，需要结合 AWS Secrets Manager、SSM Parameter Store 或 CI/CD 变量注入。第四是漂移检测：有人手动改了安全组，代码状态与真实状态不一致，需要定期执行 plan/diff 并纠正。第五是权限与合规：IaC 执行角色本身权限过大可能带来风险，需要最小权限和审批流程。

为了应对这些挑战，AWS 生态形成了一条相对完整的工具链。最底层是资源定义层：Terraform、AWS CloudFormation、AWS CDK、Pulumi 等，负责把基础设施描述成代码。中间是状态与后端层：S3、DynamoDB、CloudFormation Stack、Terraform Cloud/Enterprise 等，负责保存和锁定状态。再往上是模块与复用层：Terraform Module、CloudFormation Nested Stack、CDK Construct，用于封装可复用的环境单元。然后是CI/CD 与策略层：CodePipeline、CodeBuild、GitHub Actions、Jenkins，配合 IAM、SCP、Config、CloudTrail 实现自动化执行与合规检查。最后是可观测与漂移检测层：AWS Config、CloudTrail、Terraform plan、CloudFormation Drift Detection，用于发现真实环境与代码定义的偏差。

从学习路径来看，建议按“先理解资源模型，再掌握状态管理，然后进入模块化与环境标准化，最后接入 CI/CD 和治理”的顺序推进。第一步，能够用 Terraform 或 CloudFormation 描述一个包含 VPC、子网、安全组、EC2 的最小可用环境，并成功 apply 和 destroy。第二步，把 state 迁移到 S3 + DynamoDB 远程后端，理解锁、版本控制和多人协作。第三步，把重复出现的资源组合抽成模块，例如“标准 VPC 模块”“标准 Web 服务模块”，通过变量控制环境差异。第四步，建立 dev/staging/prod 三套环境的目录结构和参数文件，确保同一模块在不同环境产生结构一致但规格不同的资源。第五步，把 plan/apply 接入 CodePipeline 或 GitHub Actions，加入人工审批、合规检查和漂移检测。

环境标准化的关键不是“所有环境完全一样”，而是“结构一致、差异可控、差异可解释”。例如，开发环境可以只用一个可用区、t3.micro 实例、单节点 RDS；生产环境使用三个可用区、m5.large、多可用区 RDS 并开启加密和自动备份。这些差异应当通过变量和参数文件显式表达，而不是通过复制两套完全不同的代码来维护。标准化带来的直接收益是：新环境可以在几十分钟内从零重建，故障恢复不再依赖“某个人记得怎么配”，安全基线可以通过代码强制实施，审计和合规检查有据可查。

本课程后续章节将围绕这条工具链逐步展开：从 Terraform 与 CloudFormation 的基础语法，到远程状态与锁、模块化设计、多环境参数管理、CI/CD 流水线、策略即代码、漂移检测与成本治理。每一节都会给出可执行的配置片段、示例参数和判断依据，帮助你把“能跑通”推进到“可维护、可审计、可复制”。

需要特别注意的是，IaC 的引入会改变团队协作方式。过去运维人员直接在控制台操作，现在需要走 Git 流程；过去变更可以“先做再补记录”，现在必须先提交代码再执行。这种转变需要配套的权限设计、评审规范和回滚预案。建议在初期就明确：哪些资源允许 IaC 管理，哪些暂时保留手工；state 文件由谁负责、如何备份；生产环境 apply 是否需要双人审批；出现漂移时是自动纠正还是先告警。把这些规则写进团队约定，比单纯引入工具更重要。