技能介绍

问题：基础设施变成"雪花服务器"

当团队靠控制台手动开通云资源，每套环境都会悄悄长出自己的脾气：生产里有一条谁也不敢删的安全组规则，开发环境的 VPC 是某位同事两年前在 console 里随手建的，没人记得为什么那台 EC2 还挂着早已下线的 AMI。变更没有 review、操作没有记录、环境无法复现，出事时只能靠翻聊天记录和截图。IaC 技能要对付的就是这种"漂移基础设施"。

技能如何工作

这个技能把基础设施管理拆成一条可审计的流水线：

收集需求：确认云厂商、资源清单、规格与性能要求、安全约束以及目标环境（dev/staging/production），并梳理资源间依赖顺序。
选工具并初始化项目：多云与云无关场景优先 Terraform，偏好通用编程语言的团队用 Pulumi，AWS 原生组织选 CloudFormation 或 CDK；项目按 modules、environments、共享配置分目录。
生成模块化代码：网络（VPC、子网、安全组）、计算（EC2、ECS、Lambda）、数据（RDS、S3、DynamoDB）拆成独立模块，输入输出明确，变量参数化以便跨环境复用。
配置状态管理：远程状态后端（如 S3 + DynamoDB）加锁，状态文件永不入库，静态加密并收紧访问控制。
Plan → Review → Apply：先跑 terraform plan 或 pulumi preview 产出 diff，确认没有意外销毁或重建后再执行 apply。
漂移检测：定期对比实际状态与声明配置，控制台或 CLI 手动改过的资源要么回滚，要么用 terraform import 纳入状态。

适用边界与注意点

技能覆盖 Terraform、Pulumi、CloudFormation/CDK 与 Ansible 等主流工具，不涉及物理机房的裸机编排。
状态锁争用：上一次 apply 崩溃后锁可能残留，需确认无其他进程在跑，再执行 terraform force-unlock。
循环依赖：Terraform 无法处理互相引用的安全组，需拆成 aws_security_group + aws_security_group_rule 两步。
Provider 大版本升级：资源 schema 变化可能导致 plan 失败，应在 required_providers 中锁版本，并走完整测试。
大状态文件：基础设施膨胀后 plan/apply 会变慢，可按网络、计算、数据拆成多个 root module，各自维护状态并用 terraform_remote_state 共享输出。