基础设施状态把声明配置映射到真实资源并暴露漂移

基础设施即代码用声明文件描述期望资源，但云平台和集群中的真实对象拥有独立生命周期。状态负责把配置中的资源实例与远端对象对应起来，使工具知道下一次计划应创建、修改还是删除什么。没有准确状态，声明与现实之间的差异就无法可靠计算。

声明、状态与真实资源

Terraform 配置表达期望结构，状态保存资源实例与远端标识的绑定，以及规划所需的部分元数据。执行计划前，工具通常刷新远端信息，再比较配置、既有状态和真实对象。三者的差异分别可能来自代码变更、外部修改或上次执行未完整结束。

状态不是资源本身，也不是普通缓存。丢失状态后，远端服务器仍存在，但工具可能准备重复创建；错误绑定则可能修改错误对象。直接手工编辑状态文件会绕过格式和一致性检查，应使用受支持的导入、移动和移除命令，并在操作前备份。

Kubernetes 等系统也使用声明式对象和控制器调和当前状态，不过其权威状态保存在 API 服务中，控制器持续接近目标。不同工具对“状态”的持有方式不同，不能照搬 Terraform 文件模型解释所有声明式平台。

漂移指真实资源与受管理声明不一致。运维人员在控制台紧急修改、防护系统自动调整、云服务默认值变化、其他工具管理同一对象，都可能形成漂移。并非所有差异都是错误：自动伸缩产生的副本变化可能由另一控制器拥有，配置需要明确忽略或分离所有权。

检测漂移通常依赖刷新和计划。刷新失败、权限不足或供应商 API 限流会让观察不完整。计划显示“无变更”只代表当前工具可见字段一致，不证明业务配置和安全策略都正确。还需要独立配置审计和运行验证。

修复漂移前要先判断哪一侧正确。代码落后于经过批准的紧急修复，应把真实变更回写声明；未经授权的手工修改则应由声明恢复。机械地执行 apply 可能撤销必要修复，机械地 import 又可能永久接受错误状态。

个人本地状态不适合团队协作。远端后端提供共享位置，配合锁避免两个执行同时修改同一状态。锁只能协调使用同一后端和锁协议的参与者，无法阻止控制台修改或另一个独立状态管理同一资源。

状态可能包含资源属性、连接信息甚至敏感值。即使配置中标为敏感，状态仍可能保存明文。后端需要加密、最小权限、审计和版本恢复，状态不能提交到普通代码仓库或作为无保护构建产物传递。

工作区和环境的状态应有清晰边界。测试与生产共享状态会放大误操作；把过多无关资源放进一个状态，又会增加锁竞争和影响范围。拆分应沿所有权和变更周期进行，同时处理跨状态引用，不能只按文件数量切分。

已有资源纳入代码管理时，需要把远端标识导入正确地址，再用计划确认声明与现实一致。导入只建立绑定，不会自动生成完整、正确的治理意图。遗漏字段可能在首次 apply 时触发意外替换。

重命名模块或移动资源地址时，应执行受支持的状态移动，让同一远端对象继续绑定新地址。若只改配置路径，工具可能认为旧资源应删除、新资源应创建。重构评审必须同时审查代码差异和计划中的资源动作。

某些字段改变会要求替换资源。计划要显式标记销毁与创建顺序、停机窗口和数据迁移。生命周期选项可以先建后删或阻止销毁，但不能消除配额、唯一名称和外部依赖限制。

成熟流程把格式检查、静态策略、初始化、计划、审批和应用分开。计划产物应绑定代码提交、变量、提供程序版本和状态序列，批准后若状态已变化，应重新计划。不能审核一份计划，却执行另一环境重新生成的内容。

生产应用使用短期身份和最小权限，避免个人长期密钥。高风险删除、网络和身份变更可以增加策略门禁。失败后先保存日志和状态，不要连续盲目重跑；部分资源可能已成功创建，需要从最新状态判断下一步。

提供程序和模块版本必须锁定。升级可能改变默认值、模式和规划结果，应在非生产环境比较。声明文件可回滚不代表基础设施自动回到原状，数据库升级、资源替换和外部副作用需要独立回滚方案。

计划成功只说明语法和可计算差异，应用成功也不说明服务可用。变更后要验证网络连通、身份权限、健康检查、数据持久性和监控。关键资源还应定期执行只读计划，识别长期漂移。

资源所有权登记应回答哪个状态、仓库和团队管理该对象。避免两个状态绑定同一远端对象；这会造成互相覆盖且难以从单次计划发现。紧急手工变更需要工单、时限和回写责任。

基础设施状态是声明与现实之间的账本。保护它、限制并发、审查计划并验证运行结果，才能让基础设施即代码保持可预测；把状态当作附属文件，会使自动化放大而不是降低风险。