3. 变更影响面分析

在 Terraform 大规模变更中，terraform plan 的输出是风险判断的第一手证据。但很多团队只关注“有多少资源要改”，忽略了 plan 输出中真正决定风险等级的四类信息：资源替换（replace）、依赖链传播、跨模块影响以及隐性破坏性变更。本节的目标是建立一套从 plan 文本到影响面结论的判读方法。

一、先分清 plan 中的动作符号与风险含义

Terraform 用符号前缀表达每个资源的计划动作，理解这些符号是影响面分析的基础：

• + 创建：新增资源，通常风险最低，但可能引入新的依赖或配额消耗。
• ~ 原地更新：属性变更但不重建，风险取决于属性是否触发下游联动。
• - 销毁：资源被删除，需确认是否有数据丢失或外部引用。
• -/+ 或 +/- 替换：先销毁后创建或先创建后销毁，是最高风险动作，尤其涉及有状态资源。
• <= 读取：data source 重新读取，通常无副作用，但可能改变后续引用值。

关键点在于：替换不等于普通更新。当某个属性被标记为 forces replacement 时，Terraform 会重建整个资源。例如修改 AWS RDS 的 identifier、修改安全组的 vpc_id、修改 ECS 集群的 name，都会触发替换。替换意味着资源 ID 变化、IP 变化、端点变化，进而影响所有引用它的对象。

二、从 plan 输出识别资源替换

执行 terraform plan -out=tfplan 后，可以用 terraform show -json tfplan 得到结构化输出，再配合 jq 过滤替换动作：

terraform show -json tfplan | jq -r '
  .resource_changes[]
  | select(.change.actions | index("delete") and index("create"))
  | "\(.address)  \(.change.actions | join(","))"
'

示例输出（教学示例，非实测）：

aws_db_instance.primary  ["delete","create"]
aws_security_group.app    ["delete","create"]
module.network.aws_subnet.private[0]  ["delete","create"]

看到这三行，就要立刻追问：RDS 替换会不会导致连接串变化？安全组替换会不会导致实例失联？子网替换会不会导致路由表、NAT 网关、ENI 全部重算？替换的资源越靠近基础设施底层，传播范围越大。

三、依赖链传播：沿引用关系向上追溯

Terraform 的依赖关系来自属性引用。若资源 A 的某个属性引用了资源 B 的输出，则 A 依赖 B。当 B 被替换时，A 中引用 B 的属性值会变化，可能触发 A 的更新甚至替换。分析依赖链时，重点看三类引用：

• ID 引用：如 subnet_id = aws_subnet.private.id，子网替换后 ID 变化，引用方必然更新。
• 名称/端点引用：如 endpoint = aws_db_instance.primary.endpoint，RDS 替换后端点变化，应用配置需同步。
• 隐式依赖：通过 depends_on 或模块输出间接建立，plan 中不一定直接显示属性变化，但执行顺序会受影响。

可以用 terraform graph 生成依赖图，或从 JSON plan 中提取 depends_on 与属性引用关系。实际判读时，建议按“被替换资源 → 直接引用方 → 间接引用方”逐层展开，标记每一层是否会产生新的替换。

四、跨模块影响：模块边界不是风险边界

大规模工程通常按网络、数据、应用、安全等维度拆模块。模块之间通过 output 与 variable 传递值。当底层模块的资源被替换，其 output 变化会传导到上层模块，触发上层资源的更新或替换。常见场景包括：

• 网络模块的子网 ID 变化 → 应用模块的实例、负载均衡、路由表全部重算。
• 安全模块的安全组 ID 变化 → 数据库模块的入站规则引用失效。
• 数据模块的 RDS 端点变化 → 应用模块的环境变量、配置中心、DNS 记录需同步。

分析跨模块影响时，不能只看单个模块的 plan，而应把各模块 plan 合并观察，或使用 terraform plan 在根模块统一执行，确保依赖顺序和值传递完整可见。

五、隐性破坏性变更：plan 中不显眼但后果严重

有些变更在 plan 中只显示为 ~ 更新，却可能造成服务中断或数据不可逆损失，这类变更称为隐性破坏性变更。典型包括：

• 安全组规则收窄：plan 显示更新，但实际会切断现有流量。
• IAM 策略收紧：更新后应用无法访问依赖服务。
• 数据库参数组变更：某些参数修改需要重启实例。
• 生命周期规则调整：可能触发批量删除或归档。
• DNS TTL 与记录变更：更新后解析切换，缓存未过期时出现流量抖动。

识别隐性破坏性变更，需要结合资源类型语义判断，而不是只看动作符号。建议维护一份“高风险属性清单”，对每个资源类型标注哪些属性变更属于破坏性，并在 plan 评审时逐项核对。

六、把分析结果落成可执行的影响面结论

完成上述四类分析后，应输出一份影响面结论，至少包含：高风险资源清单（替换、销毁、隐性破坏）、传播路径（从哪个资源传到哪些资源）、跨模块影响范围、以及对应的回滚或缓解措施。这份结论直接决定后续是否分批执行、是否增加审批、是否先做备份或快照。

需要强调的是，plan 输出只反映 Terraform 视角的资源变化，不包含外部系统对资源的引用。例如 DNS 缓存、负载均衡健康检查、应用连接池、监控告警规则等，都可能因为资源替换而失效。因此，影响面分析必须结合架构图与外部依赖清单一起看，才能避免“plan 看起来没问题，上线后却出故障”的情况。