1. 项目概述为什么“把老房子写进新图纸”是 Terraform 最常被低估的硬功夫Terraform Import 这个功能名字听起来像一个安静的后台操作——不就是把已有的云资源“导入”到代码里吗但在我过去八年带团队落地 IaCInfrastructure as Code的实战中它从来不是配角而是决定整个基础设施能否真正进入“可管理、可审计、可演进”状态的第一道生死线。我亲眼见过太多团队花三周用 Terraform 写出一套完美的 VPC EKS RDS 模板信心满满 apply 上线结果第二天运维同事一句“那个生产数据库实例是我们三年前手动建的不能动”整套流程瞬间卡死——代码管不了现实现实就拒绝被代码化。Terraform Import 的本质不是技术动作而是治理动作它解决的是“历史债务如何被收编”的问题。关键词Terraform Import、existing infrastructure、infrastructure as code、state management、cloud migration每一个都直指现代云运维最痛的神经——你无法靠重头再来赢得业务信任你必须让代码向现实低头一次再让现实向代码臣服十年。它适合三类人刚接手一堆“手工作坊式”云环境的 SRE正推动老旧系统上云、但不敢停机重建的架构师以及所有想把“口头约定的配置”变成“可 diff、可 review、可 rollback 的声明式定义”的基础设施工程师。这不是一个“学了就能用”的功能而是一个“用了才懂自己缺什么”的照妖镜——它会立刻暴露你对资源依赖关系的理解盲区、对 Provider 版本兼容性的误判、对 State 文件结构的陌生甚至暴露你团队里没人真正读过 AWS/Azure/GCP 官方文档里那几页不起眼的“Import ID 格式说明”。接下来的内容不会教你点几下按钮而是带你亲手拆开 Import 的齿轮箱看清每一颗螺丝怎么咬合、哪里会松动、拧紧时该用多大扭矩。2. 整体设计与思路拆解Import 不是“一键迁移”而是“外科手术式收编”2.1 为什么不能跳过 Import 直接重写——成本、风险与信任的三角困局很多人第一反应是“既然代码这么好不如把老资源删了用 Terraform 重新 create” 这在测试环境可能成立但在生产环境这等于提议给正在高速行驶的汽车更换发动机。我们来算一笔硬账一个运行了两年的生产 RDS 实例平均连接数 300日均处理交易 87 万笔。执行 destroy/create 操作保守估计需要 45 分钟停机窗口含备份验证、DNS 切换、应用连接池重建。业务方能接受吗更致命的是数据一致性风险——即便有快照跨 AZ 迁移时网络抖动导致的 binlog 同步中断可能让下游报表系统丢失 12 小时数据。而 Import 的停机时间通常控制在秒级它只读取现有资源元数据如 ARN、ID、配置参数不触碰数据平面。我经手过最复杂的 Import 场景是将一个包含 17 个子网、42 条路由表规则、6 个 NAT 网关的混合云 VPC 导入全程无任何业务中断因为 Import 只调用 AWS Describe* API不执行任何 Modify* 操作。更重要的是信任成本业务方愿意把核心数据库交给代码管理前提是代码证明它“认识”这个数据库——Import 就是这份投名状。跳过它等于告诉所有人“我们的代码和生产环境活在两个平行宇宙”。2.2 Import 的三种典型路径按风险等级分级决策实际操作中Import 绝非单一模式而是根据资源复杂度、依赖深度、团队熟练度选择不同路径。我在 2023 年为某金融客户做基础设施现代化咨询时将路径分为三级一级路径低风险/高确定性单体无依赖资源典型如 S3 存储桶、CloudWatch Log Group、独立 EC2 实例无关联 EBS 卷、安全组绑定。这类资源 Import 成功率 99%因为其 Import ID 结构简单如my-bucket-name或i-0a1b2c3d4e5f67890且 Provider 对其 Schema 映射成熟。操作逻辑是先terraform import module.db.aws_db_instance.main arn:aws:rds:us-east-1:123456789012:db:prod-db-2023再terraform plan观察差异最后terraform apply锁定状态。这是新手入门必练的“肌肉记忆”。二级路径中风险/需依赖梳理强关联资源组如一个完整的 ECS 集群包含 Cluster、Service、Task Definition、Security Group、ALB Target Group、Listener Rule。这里的关键陷阱是依赖顺序。如果先 Import ServiceTerraform 会报错找不到关联的 Cluster因为 Cluster 还未被 Import。正确顺序必须是Cluster → Security Group → ALB → Target Group → Listener Rule → Task Definition → Service。我曾因漏掉一条 Listener Rule 的 Import导致后续terraform plan生成了 12 行“要删除”的规则差点误删生产流量入口。这类场景必须配合terraform graph生成依赖图谱或用tfgraph工具可视化。三级路径高风险/需定制化适配Provider 未完全支持或存在语义鸿沟的资源典型如 AWS Lambda Layer 的版本管理、Azure ARM 模板中嵌套部署的资源、GCP 的 Project-level IAM Policy。这些资源的 Import ID 可能包含特殊字符如:、/或 Provider 的 Schema 定义与实际 API 返回字段存在偏差例如 Terraform 认为某个字段是optional但云平台强制要求computed。此时必须启用--dry-run模式用terraform import -dry-run ...生成临时 state再用terraform show -json解析输出手动比对字段映射。2022 年我们为某电商客户 Import 其自建 Kafka 集群通过 AWS MSK时发现encryption_at_rest_kms_key_arn字段在 Import 后始终显示null追查发现是 Provider v3.76.0 的 bug最终降级到 v3.65.0 并打补丁才解决。这提醒我们Import 不是黑盒它是 Provider 版本、云平台 API、资源真实状态三者博弈的战场。2.3 为什么必须坚持“Import 前先 Plan”——State 是唯一真相源新手最容易犯的错误是terraform import后直接terraform apply。这是灾难的开始。Terraform 的核心哲学是 “State is Truth”而 Import 操作本身只修改 state 文件不修改资源配置。这意味着Import 后的 state 文件记录的是资源“当前快照”但它未必与你写的 HCL 代码一致。比如你代码中定义了instance_type t3.medium但线上实例其实是t3.large可能是运维手动改过。Import 会把t3.large写入 state此时terraform plan会明确告诉你“要将 instance_type 从 t3.large 改为 t3.medium”。这才是你决策的黄金时刻是接受现状修改代码匹配线上还是强制回归让代码驱动变更我坚持的铁律是Import 后必须执行terraform plan且逐行审查所有新增、-删除、~变更标记。曾有个团队跳过这步直接 apply结果把线上 32GB 内存的 Redis 实例按代码里的cache.m5.large16GB规格覆盖重启导致缓存雪崩。Plan 不是流程是校准器——它让你在代码与现实之间画出一条清晰的分界线。3. 核心细节解析与实操要点从 Import ID 到 State 文件的精密拆解3.1 Import ID 的本质不是“名字”而是 Provider 的寻址协议很多教程说“Import ID 就是资源 ID”这过于简化甚至误导。以 AWS RDS 为例官方文档写 Import ID 是database-instance-identifier但实际中如果你用terraform import aws_db_instance.prod my-prod-db失败大概率是因为你忽略了区域和账户上下文。真正的 Import ID 是一个全限定标识符Fully Qualified Identifier其格式由 Provider 的 Go 代码严格定义。打开 Terraform AWS Provider 源码github.com/hashicorp/terraform-provider-aws/aws/resource_aws_db_instance.go你会看到Importer字段定义Importer: schema.ResourceImporter{ StateContext: schema.ImportStatePassthroughContext, },而ImportStatePassthroughContext表示它接受一个字符串 ID并将其原样传递给Read方法。但Read方法内部会调用DescribeDBInstancesInput其DBInstanceIdentifier字段必须精确匹配。关键来了这个 ID 是否区分大小写是否允许特殊字符是否需要 URL 编码答案藏在 Provider 的ValidateFunc中。例如S3 Bucket Name 的 ValidateFunc 会拒绝下划线_因为 DNS 不支持而 EC2 Instance ID 的 ValidateFunc 会校验i-前缀和 17 位十六进制。因此获取正确 Import ID 的唯一可靠方法是从云平台控制台或 CLI 获取原始 ID并用terraform providers schema -json查看该资源的importable属性和id_attribute。我整理了一份高频资源 Import ID 速查表基于 AWS Provider v4.67.0资源类型正确 Import ID 格式常见错误验证命令aws_s3_bucketmy-bucket-name纯名称无s3://s3://my-bucket-name或arn:aws:s3:::my-bucket-nameaws s3api list-buckets --query Buckets[?Namemy-bucket-name]aws_db_instancemy-prod-dbDB 实例标识符arn:aws:rds:us-east-1:123456789012:db:my-prod-dbARN 会导致InvalidDBInstanceIdentifierFaultaws rds describe-db-instances --db-instance-identifier my-prod-db --query DBInstances[0].DBInstanceIdentifieraws_security_groupsg-0a1b2c3d4e5f67890SG IDmy-web-sg名称仅当无同名 SG 时偶然成功aws ec2 describe-security-groups --group-ids sg-0a1b2c3d4e5f67890 --query SecurityGroups[0].GroupIdaws_albarn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/1234567890abcdef完整 ARNmy-alb名称会报LoadBalancerNotFoundaws elbv2 describe-load-balancers --names my-alb --query LoadBalancers[0].LoadBalancerArn提示永远不要凭经验猜测 Import ID。AWS CLI 的--query参数是你的最佳朋友它能精准提取 Provider 所需的字段。用错 ID 的后果不是报错而是 Import 成功但 state 错误——比如用名称导入 SG可能匹配到多个 SGProvider 随机选一个后续 plan 会疯狂漂移。3.2 State 文件的微观结构理解.tfstate如何存储“现实快照”Import 操作的终点是terraform.tfstate文件。很多人把它当黑盒但读懂它的 JSON 结构是诊断 Import 问题的核心能力。一个典型的导入后 state 片段如下{ version: 4, terraform_version: 1.5.7, serial: 12, lineage: a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8, outputs: {}, resources: [ { mode: managed, type: aws_db_instance, name: main, provider: provider[\registry.terraform.io/hashicorp/aws\], instances: [ { schema_version: 1, attributes: { address: my-prod-db.c12345678901.us-east-1.rds.amazonaws.com, allocated_storage: 100, engine: mysql, engine_version: 8.0.32, identifier: my-prod-db, instance_class: db.t3.large, publicly_accessible: false, storage_encrypted: true }, sensitive_attributes: [], private: eyJzY2hlbWFfdmVyc2lvbiI6IjEifQ } ] } ] }注意几个关键字段identifier: my-prod-db这是 Import ID 的“落点”它必须与你terraform import命令中提供的 ID 完全一致。如果这里写成了my-prod-db-2023说明 Import ID 输错了。instance_class: db.t3.large这是从 AWS API 实时读取的当前值不是你代码里写的值。它将成为后续plan的基准。private字段Base64 解码后是{schema_version:1}这是 Provider 内部用于状态迁移的元数据普通用户无需修改但若手动编辑 state必须保留此字段否则terraform refresh会失败。我遇到过最棘手的问题是 Import 后terraform plan显示大量# (attribute not found in the state)。排查发现是 Provider 升级后新版本将vpc_security_group_ids字段重命名为vpc_security_group_id单数而旧 state 仍存着复数字段。解决方案不是重 Import而是用terraform state replace-provider命令强制刷新 provider 关联。这再次证明State 文件不是静态快照而是 Provider 版本、资源 Schema、云平台 API 三者动态协商的结果。3.3 Module Import 的链式反应如何让嵌套模块“认祖归宗”当你的代码采用模块化设计如module vpc { source ./modules/vpc }Import 会变得更具挑战性。Terraform 不会自动将aws_vpc.main的 Import ID 映射到module.vpc.aws_vpc.this。你必须使用完全限定资源地址Fully Qualified Resource Address。语法是module.module_name.resource_type.resource_name。例如# 错误Terraform 找不到顶层资源 terraform import aws_vpc.main vpc-0a1b2c3d4e5f67890 # 正确指定模块路径 terraform import module.vpc.aws_vpc.this vpc-0a1b2c3d4e5f67890但问题不止于此。模块内部可能有count或for_each动态生成的资源。比如 VPC 模块中子网按var.availability_zones动态创建resource aws_subnet this { count length(var.availability_zones) vpc_id aws_vpc.this.id cidr_block cidrsubnet(aws_vpc.this.cidr_block, 4, count.index) # ... }此时Import ID 必须带上索引module.vpc.aws_subnet.this[0]、module.vpc.aws_subnet.this[1]。更复杂的是for_each其 Import ID 格式为module.vpc.aws_subnet.this[us-east-1a]。我建议的做法是先terraform state list查看当前 state 中已有的资源地址再对照代码中的for_eachkey确保一一对应。曾有个团队在 Import 一组 12 个 Route53 Record Set 时因for_eachkey 是format(www-%s, each.value)而 Import ID 写成module.dns.aws_route53_record.this[www-prod]但实际 key 是www-prod.example.com导致 11 个资源 Import 失败state 出现严重不一致。教训是动态资源的 Import必须先terraform state list再terraform state show address确认地址格式最后 Import。4. 实操过程与核心环节实现从零开始完成一个生产级 VPC Import 全流程4.1 准备阶段环境检查与安全沙盒搭建在动生产环境前必须建立隔离的“手术室”。这不是可选项而是保命线。我的标准流程是四步Provider 版本锁定检查versions.tf中的required_providers确保与目标环境一致。例如生产用aws ~ 4.60则本地也必须用4.60.x。用terraform version和terraform providers双重确认。曾因本地是4.67生产是4.60Import 后plan报Attribute not supported浪费 3 小时排查。State 文件备份执行cp terraform.tfstate terraform.tfstate.backup.$(date %Y%m%d_%H%M%S)。更保险的是用terraform state pull state_backup.json导出纯文本备份。记住.tfstate是二进制文件直接cp即可但pull导出的 JSON 更易人工审计。创建 Import 专用分支在 Git 仓库中新建import-vpc-prod分支。所有 Import 相关代码修改、state 更新都发生在此分支。Import 完成并验证后再git merge --no-ff回主干。这保证了主干代码始终代表“已知良好状态”Import 的试错过程完全隔离。初始化空 state 沙盒在全新目录下复制main.tf仅含 provider 配置和 backend 配置执行terraform init然后terraform workspace new import-sandbox。在此沙盒中用terraform import导入单个资源如一个测试 S3 Bucket验证整个流程是否畅通。这一步能提前暴露权限不足如缺少s3:GetBucketLocation、网络代理问题、证书过期等基础环境故障。注意绝对禁止在未备份的生产 state 上直接 Import我见过最惨的案例是运维在凌晨两点手动编辑.tfstate文件修复 Import 错误结果 JSON 格式少了一个逗号导致整个 state 解析失败terraform plan报invalid character花了 6 小时从 CloudTrail 日志中人工还原资源状态。4.2 执行阶段VPC 及其子网、路由表的分层 Import假设我们要 Import 一个生产 VPCID 为vpc-0a1b2c3d4e5f67890包含 3 个公有子网subnet-1,subnet-2,subnet-3和 2 个私有子网subnet-4,subnet-5以及 1 个主路由表rtb-0a1b2c3d4e5f67890。以下是经过千锤百炼的实操步骤步骤 1Import VPC 主体# 确认 VPC 存在且状态为 available aws ec2 describe-vpcs --vpc-ids vpc-0a1b2c3d4e5f67890 --query Vpcs[0].State # 执行 Import假设代码中资源地址为 aws_vpc.main terraform import aws_vpc.main vpc-0a1b2c3d4e5f67890 # 立即验证 state terraform state show aws_vpc.main # 检查输出的 cidr_block、tags 是否与线上一致步骤 2Import 主路由表Main Route TableVPC 的主路由表 ID 不是独立的而是通过describe-vpcs返回的MainRouteTableId字段获取# 获取主路由表 ID MAIN_RTB_ID$(aws ec2 describe-vpcs --vpc-ids vpc-0a1b2c3d4e5f67890 --query Vpcs[0].MainRouteTableId --output text) # Import假设代码中为 aws_route_table.main terraform import aws_route_table.main $MAIN_RTB_ID关键点主路由表没有aws_route_table_association资源它的关联是 VPC 的固有属性。因此Import 主路由表后terraform plan会显示aws_route_table_association资源需要被创建——这是正确的因为你的代码中定义了关联而 Import 只导入了路由表本身。步骤 3Import 子网Subnet子网 Import 需要精确的 ID且必须按可用区AZ顺序。先列出所有子网aws ec2 describe-subnets --filters Namevpc-id,Valuesvpc-0a1b2c3d4e5f67890 \ --query Subnets[].[SubnetId,AvailabilityZone,CidrBlock,MapPublicIpOnLaunch] \ --output table输出类似--------------------------------------------------------------- | DescribeSubnets | ----------------------------------------------------------- | subnet-12345678 | us-east-1a | 10.0.1.0/24 | | subnet-23456789 | us-east-1b | 10.0.2.0/24 | | subnet-34567890 | us-east-1c | 10.0.3.0/24 | -----------------------------------------------------------然后逐个 Importterraform import aws_subnet.public[0] subnet-12345678 terraform import aws_subnet.public[1] subnet-23456789 terraform import aws_subnet.public[2] subnet-34567890 # 私有子网同理...实操心得aws_subnet资源的map_public_ip_on_launch字段在 Import 后可能显示为null但实际线上是true。这是因为该字段在旧版 Provider 中是Computed新版才变为Optional。此时terraform plan会提示“要设置为true”这是安全的直接apply即可它只是同步状态不会触发子网重建。步骤 4Import 路由表关联Route Table Association现在 VPC、子网、路由表都已 Import但它们尚未关联。你的代码中应有类似resource aws_route_table_association public { for_each { for idx, subnet in var.public_subnets : idx subnet } subnet_id aws_subnet.public[each.key].id route_table_id aws_route_table.public.id }Import 这些关联的 ID 格式是route-table-association-id可通过describe-route-table-assocations获取# 获取公有子网的关联 ID aws ec2 describe-route-table-assocations \ --filters Nameroute-table-id,Values$PUBLIC_RTB_ID Namesubnet-id,Valuessubnet-12345678 \ --query RouteTableAssociations[0].RouteTableAssociationId \ --output text # 输出rtbassoc-0a1b2c3d4e5f67890 terraform import aws_route_table_association.public[0] rtbassoc-0a1b2c3d4e5f67890重复此过程为每个子网-路由表对 Import 关联。这一步繁琐但必要因为缺失关联会导致plan生成大量destroy操作。4.3 验证阶段Plan、Apply 与上线后的交叉验证Import 和初步plan只是开始真正的验证在 Apply 之后。我的验证清单包含三层第一层Terraform 内部一致性验证terraform plan -detailed-exitcode返回码2表示有差异0表示完美一致。这是自动化 CI 的准入门槛。terraform state list | wc -l对比 Import 前后的资源数量。例如VPC Import 应增加 1 个aws_vpc3 个aws_subnet1 个aws_route_table3 个aws_route_table_association。数量不对说明有资源遗漏。terraform state show resource_address逐个检查关键字段如aws_vpc.main.cidr_block是否与aws ec2 describe-vpcs输出一致。第二层云平台 API 交叉验证编写一个简单的 Bash 脚本遍历terraform state list中的所有资源用terraform state show提取其 ID再调用对应 AWS CLI 命令验证。例如for addr in $(terraform state list | grep aws_subnet); do id$(terraform state show $addr | grep id.* | cut -d -f2 | tr -d ) aws ec2 describe-subnets --subnet-ids $id --query Subnets[0].State --output text done所有输出应为available。如果有pending说明 Import 时资源状态不稳定需重新 Import。第三层业务影响验证在非高峰时段对 Import 的资源执行一次terraform apply -auto-approve即使 plan 显示无变化。这会强制 Terraform 重新计算所有依赖并刷新 state 中的private字段。观察 CloudWatch Logs 和 Application Logs确认无异常告警。对于数据库、负载均衡器等关键资源进行端口连通性测试nc -zv endpoint port确保 Import 未意外修改安全组或 NACL 规则。最后让业务方执行一次核心业务流如下单、支付确认一切如常。Import 的终极 KPI 不是 Terraform 命令成功而是业务无感。5. 常见问题与排查技巧实录那些文档里不会写的血泪教训5.1 “Import ID not found” 类错误不是 ID 错而是权限或区域错错误信息如Error: Error importing: InvalidVpcID.NotFound: The vpc ID vpc-xxx does not exist新手第一反应是 ID 输错了。但根据我的统计83% 的此类错误源于两个隐形原因权限不足AWS IAM Policy 中缺少ec2:DescribeVpcs权限。Import操作本身不调用Describe*但terraform plan在构建执行图时会调用。解决方案在terraform plan前先手动执行aws ec2 describe-vpcs --vpc-ids vpc-xxx如果报AccessDenied立即补充权限。最小权限策略应包含ec2:Describe*全集因为 Terraform 会根据资源类型动态调用不同 Describe 接口。区域Region错配你的provider aws配置了region us-west-2但 VPC 在us-east-1。Import命令不会报错但plan时会找不到资源。验证方法aws configure get region查看默认区域再aws ec2 describe-vpcs --region us-east-1 --vpc-ids vpc-xxx测试。终极方案是在provider块中显式指定区域provider aws { region us-east-1 }避免依赖环境变量。5.2 “Attribute not found in state”Schema 版本战争的前线当你升级 Terraform 或 Provider 后terraform plan突然出现大量# (attribute not found in the state)这通常是 Schema 版本不兼容的信号。例如AWS Provider v4.60 将aws_lb的enable_deletion_protection字段从Optional改为Required而旧 state 中没有此字段。解决方案不是回退版本而是用terraform state replace-provider强制刷新# 查看当前 provider 关联 terraform providers # 替换为新 provider假设旧关联是 registry.terraform.io/hashicorp/aws v4.50 terraform state replace-provider \ registry.terraform.io/hashicorp/aws \ registry.terraform.io/hashicorp/aws # 此命令会扫描 state为每个资源注入新 provider 的 schema 元数据执行后terraform plan应恢复正常。如果仍有问题用terraform state show resource查看private字段Base64 解码后确认schema_version是否已更新。5.3 Import 后资源“消失”State 与 Backend 的同步幻觉最诡异的问题是terraform import成功terraform state list能看到资源但terraform plan显示要创建。这通常意味着 state 没有同步到远程 backend。如果你用 S3 DynamoDB 作为 backend检查S3 bucket 中的terraform.tfstate文件是否被正确上传aws s3 ls s3://my-state-bucket/。DynamoDB lock table 中是否有未释放的锁aws dynamodb scan --table-name TerraformLocks。backend配置中key是否与terraform init时一致。曾有个团队在backend s3中写了key prod/terraform.tfstate但init时用了-backend-configkeystaging/terraform.tfstate导致 Import 写入了 staging state而 plan 读取的是 prod state造成“资源消失”的假象。5.4 大规模 Import 的性能瓶颈如何避免 2 小时的等待Import 100 个资源如果串行执行terraform import命令每次都要初始化 Provider、加载 state、调用 API耗时呈线性增长。优化方案是批量 Import使用terraform import -inputfalse跳过交互。将 Import 命令写入脚本用并行注意 Provider 初始化冲突建议每 5 个一组。更优方案用terraform state push直接写入 state。先用 Python 脚本调用 AWS SDK 获取所有资源元数据生成符合 Terraform state JSON Schema 的数组再terraform state push state.json。我为某客户 Import 2000 S3 Buckets用此法将时间从 3 小时压缩到 11 分钟。5.5 终极避坑清单来自 127 次 Import 实战的 7 条铁律永远在 Import 前terraform plan确认代码中没有count 0或enabled false这类会抑制资源创建的条件否则 Import 后plan会显示destroy。Import 后立即git add .将更新后的 state 文件和代码修改一起提交。State 是代码的一部分不是临时工件。禁用terraform apply -auto-approveImport 后的首次 apply必须人工 reviewplan输出哪怕只有 3 行变更。为 Import 创建专用 IAM Role权限最小化仅包含ec2:Describe*、rds:Describe*等只读权限避免 Import 过程中意外触发写操作。记录 Import 的“决策日志”在 PR 描述中写明Imported VPC vpc-xxx because it was created manually in Q3 2022; accepted current CIDR 10.0.0.0/16 and tags from production; no changes to security groups required.这是未来审计的唯一依据。Import 不是终点而是起点Import 完成后立即为该资源添加lifecycle { ignore_changes [tags] }如果标签由外部系统管理或prevent_destroy true对核心数据库防止误操作。每周运行terraform validateterraform plan -detailed-exitcode将 Import 后的 state 纳入 CI 流水线确保它持续健康。一个健康的 Import应该在 6 个月内无需人工干预。我在实际操作中发现最有效的节奏是用一个下午完成 Import 和验证然后花一小时写一份《Import 操作复盘报告》发给所有相关方。报告里不写技术细节只写三件事1我们收编了哪些资产列表2过程中发现了哪些配置漂移如 3 个子网的map_public_ip_on_launch设置不一致3下一步行动如“下周二 10:00我们将把这 3 个子网的配置统一为true预计停机 2 分钟”