IaC 与资源编排
一次基础设施事故很少始于惊天动地的架构决策。更常见的起点是一条没有保存的控制台操作、一份复制自旧项目的脚本、一个选错的 workspace，或者一张只显示“任务成功”却没有说明实际改变了什么的流水线截图。资源最终也许能创建出来，但团队无法回答：期望状态在哪里，谁批准了差异，执行使用了什么身份，真实环境是否发生漂移，失败后怎样恢复，退出时哪些对象会被连带删除。
IaC 的价值不是把控制台点击改写成代码，而是把资源变化变成可审查、可预览、可重复、可归责、可恢复的工程过程。Terraform 与 OpenTofu 用声明式配置和 state 协调资源；Pulumi 用通用编程语言组织资源图，同时仍依赖 stack 和 checkpoint 维持生命周期；Ansible 从 inventory 出发，把模块任务送到目标主机或 API，强调配置收敛，却不拥有与前几者相同的中央资源 state。工具语法不同，团队必须保住的证据链相同。
从现场问题选择入口
| 现场信号 | 建议入口 | 验证重点 |
|---|---|---|
| 云资源主要由声明式配置管理，团队需要稳定的 plan、provider 生态与 state 工作流 | Terraform 与 OpenTofu | 同一配置能初始化、验证、计划、执行、重构和销毁，state 与锁有明确归属 |
| 团队希望用 TypeScript、Python、Go 等语言表达资源关系，并把 IaC 嵌入应用或平台自动化 | Pulumi | stack、Output、配置密文、preview、refresh 和 destroy 的行为可解释 |
| 主要任务是操作系统、软件包、配置文件和服务状态收敛，目标主机已存在 | Ansible | inventory、变量、幂等、check/diff、滚动批次和失败主机能够复核 |
| 已经发生手工改动、并发执行、资源接管、重命名或危险删除 | State、漂移与销毁保护 | 权威状态、漂移分类、锁、导入、重构与 break-glass 都留下证据 |
三种资源模型不能混为一谈
Terraform、OpenTofu 和 Pulumi 都需要维护“配置中的期望”与“provider 返回的现实”之间的映射。资源地址、物理 ID、依赖关系和部分属性会进入 state 或 checkpoint；删除本地配置不等于安全退出，复制 state 也不等于克隆出一个隔离环境。任何能读取这些文件的人，都可能看到资源标识、拓扑和未被 provider 隐藏的敏感属性。
Ansible 的 playbook 则描述一次任务执行怎样尝试把主机推向目标状态。changed=0 只说明当前模块在这次执行中没有报告变化，不证明其他进程没有改动，也不证明所有外部系统都符合期望。需要持续资源生命周期、删除推导和导入映射时，应使用有明确 state 模型的 IaC；需要对已存在主机执行配置收敛时，Ansible 更自然。真实平台经常组合两者，但资源所有权必须唯一。
一次可审查变更怎样流动
先固定 CLI、provider、module、collection 和语言依赖，再把环境身份、目标 stack/workspace/inventory、backend 与允许操作写入流水线输入。静态格式检查和配置验证只证明语法与局部约束；plan 或 preview 才开始回答将创建、修改、替换和删除什么。审批者必须看到机器可读结果对应的资源地址、敏感输出处理、成本变化和销毁数量，而不是只看到一枚绿色状态。
执行阶段使用短期身份和受限并发，把完整日志、计划摘要、state 版本与提交哈希关联起来。执行完成后再次查询真实对象，验证关键不变量，而不是把退出码 0 当成唯一成功标准。随后定期检测漂移；对于合理的紧急手工操作，要么把变化吸收进代码和 state，要么恢复到已批准配置，不能让控制台与仓库长期各自成立。
共享环境必须先约束爆炸半径
开发者在本机跑通最小实验时，可以使用本地 backend、临时目录和无云资源；一旦多人共享环境，state 必须转入具备访问控制、版本、加密和并发保护的后端。生产执行身份不应复用个人长期密钥，CI 应通过受约束的工作负载身份获取短期凭据，并将 plan 与 apply 绑定到同一提交、同一配置输入和可验证的审批结果。
环境隔离不能只靠名称。workspace、stack、inventory group、云账号、订阅、项目、区域、backend key 和身份 scope 要共同指向同一边界。任何一项仍指向生产，都可能让“测试命令”成为真实变更。高风险环境应在 provider、组织策略和资源本身设置多层拒绝：最小权限、删除保护、策略门禁、人工批准、备份和独立恢复入口不能互相替代。
State 是运行资产，不是缓存文件
state、checkpoint、plan 文件和 Ansible diff 都可能含有敏感事实。它们需要独立的 owner、访问策略、保留期限、备份恢复测试和审计入口。遇到锁冲突、漂移或资源地址变化时，先保存当前版本并理解工具提供的 import、moved、alias、refresh 或 state 子命令语义；直接手改 JSON 只能作为受控抢修的最后手段，并且必须有备份、双人复核和恢复演练。
销毁同样是一项设计能力。开发环境要能安全回收，长期环境要能阻止误删，临时例外要有到期时间。prevent_destroy、protect、retainOnDelete、云资源删除锁和 IAM 拒绝的语义并不相同：有的只阻止工具删除，有的保留物理对象却移除管理关系，有的会连紧急恢复也一起阻断。团队需要在演练环境实际证明创建、失败、恢复和退出路径。
团队运行底线
每个资源只有一个权威管理入口，控制台、脚本和多个 IaC 工具不能同时争夺所有权。CLI、provider、module、collection 与语言依赖都有来源、版本锁和升级验证。plan、preview、check 和 diff 是决策证据，不是绝对安全证明；执行后必须核对真实对象与关键不变量。
state 与 checkpoint 使用受控远端后端、版本、加密、锁、备份和最小权限，任何下载副本都有清理责任。个人长期密钥不进入仓库、命令行参数、日志和 plan artifact；自动化优先使用短期工作负载身份。漂移先分类再处理，地址重构优先使用工具提供的迁移语义，危险销毁需要多层拒绝和独立恢复路径。
生产变更、跨账号平台设计、值班接管和灾难恢复进入部署运维的正式流程；IaC 仓库保留可供这些流程执行和审计的工程证据。
当另一位维护者只依赖仓库、受控凭据和运行记录，就能重放一次预览、解释每个差异、执行受限变更、识别漂移并安全退出，资源编排才真正摆脱了个人记忆。