4. 口径漂移的成因

口径漂移并非单一因素导致，而是多个工程与管理环节长期积累的结果。理解其根本成因，是制定有效校准策略的前提。本章从五个核心维度拆解漂移的根源。

4.1 五大成因全景

下表汇总了五种主要成因及其典型表现、影响范围和严重程度，便于快速建立全局认知。

4.2 人为操作失误

这是最常见的漂移诱因，通常发生在紧急故障处理或临时验证场景中。操作者绕过 IaC 流程，直接在控制台或通过命令行修改资源，导致实际状态与代码定义产生偏差。

• 临时热修复：线上问题未走变更流程，手动修改后未同步回代码仓库。
• 参数误配：手动输入时写错实例规格、安全组规则或存储容量。
• 资源遗漏：手动创建资源后忘记在 IaC 代码中声明，导致后续自动化覆盖失败。

4.3 自动化脚本缺陷

IaC 脚本本身的质量问题会系统性产生漂移。这类缺陷往往在特定条件下才暴露，排查难度较高。

• 幂等性不足：脚本重复执行时产生不同结果，例如每次运行都追加安全组规则而非合并。
• 状态未收敛：脚本执行中途失败后，资源处于“半创建”状态，下次执行无法正确恢复。
• 依赖未声明：资源创建顺序依赖隐式逻辑，当底层 API 响应变化时导致配置错乱。

# 幂等性不足的示例：每次执行都追加规则
resource "aws_security_group_rule" "example" {
  count = length(var.allowed_ips)
  # 缺少对已有规则的检查，导致重复添加
}

4.4 环境不一致

开发、测试、预发布、生产环境之间的配置差异是漂移的温床。即使代码相同，底层环境差异也会导致实际状态偏离预期。

4.5 配置管理混乱

当配置项散落在多个文件、环境变量、参数存储服务中，且缺乏统一基准时，口径漂移几乎必然发生。

• 配置散落：部分配置在 terraform.tfvars，部分在 CI/CD 变量，部分在手动维护的 JSON 文件。
• 无统一基准：缺少“单一事实来源”，不同团队对同一配置的理解不一致。
• 手动覆盖：运维人员通过控制台修改配置后，未同步回代码仓库，导致代码与实际脱节。

4.6 版本控制缺失

没有版本控制的 IaC 如同没有日志的生产系统。变更无法追溯、无法回滚、无法审计，漂移成为常态而非异常。

• 无变更记录：无法知道谁在何时修改了什么配置。
• 无法回滚：出现漂移后，无法快速恢复到上一个已知正确状态。
• 多人覆盖：多人同时修改同一资源文件，未使用分支管理导致相互覆盖。

4.7 成因关联与漂移传导

五种成因并非孤立存在，它们之间存在传导与放大关系。下图展示了典型的漂移传导路径。

4.8 成因识别清单

在日常巡检中，可以使用以下清单快速识别漂移成因，以便针对性制定校准策略。