在Terraform外手动调整AWS/GCP实例组配置后恢复有哪些风险？

1、该操作是否会损坏Terraform state？ #

不会直接损坏Terraform state。Terraform state文件仅存储你在Terraform代码中定义的资源的期望状态和最后一次同步的实际属性，你手动在云侧修改ASG/实例组属性的操作不会主动触发state文件的变更，只要你不主动运行terraform import或者错误执行terraform state相关的修改命令，state文件本身不会被损坏。

2、操作完成后是否属于配置漂移？ #

分两个阶段判断：

• 你手动把实例组配置调整为最小0/最大0、移除健康检查的阶段：属于标准配置漂移，此时云侧实际资源属性和Terraform state里存储的期望属性已经不一致。
• 你后续手动把所有配置改回原有值的阶段：只要你改回的配置和Terraform代码里定义的配置完全一致，漂移就会消失，此时Terraform不会检测到任何差异。

3、Terraform能否正常处理该场景，是否会产生僵尸资源？ #

可以正常处理，不会产生僵尸资源：

• 如果你改完配置又完全改回原值，运行terraform plan不会输出任何变更，完全不影响后续的Terraform操作。
• 如果你没有完全改回原值就运行terraform apply，Terraform会自动把实例组的配置修正回代码定义的状态，不会遗留无法管理的资源。另外ASG/实例组内的实例本身就不属于Terraform管理的范围，实例的销毁和创建由云侧的实例组逻辑控制，和Terraform无关，不会产生Terraform管理范围外的僵尸资源。

4、该操作是否属于反模式？ #

属于典型的反模式，核心原因如下：

• 手动修改Terraform管理的资源属性本身就违反了基础设施即代码的核心原则，很容易出现人为操作失误，比如改回配置的时候漏了某个参数，导致后续Terraform运行时出现非预期变更。
• 如果你只是需要临时销毁实例组内的所有实例，完全可以直接修改Terraform代码里的min_size、max_size参数为0，运行terraform apply，需要恢复的时候再把参数改回去重新apply即可，整个过程可追溯、可审计，不会有配置漂移的风险。
• 极端情况下如果手动操作过程中有人误运行了terraform apply，会直接把你改到一半的配置覆盖掉，可能导致实例意外启动或者配置异常。

内容的提问来源于stack exchange，提问作者knt5784