1. 迁移与重构的驱动力识别

在动手写第一行 Terraform 代码之前，最重要的工作往往不是技术选型，而是把"为什么要迁移"这件事说清楚。基础设施迁移与重构从来不是目的本身，它只是达成业务目标的一种手段。如果驱动力识别不清，团队很容易陷入两种典型困境：一是为了迁移而迁移，把原本运行良好的系统推倒重来，消耗大量人力却换不来实际收益；二是低估了迁移的复杂度，做到一半发现合规要求、成本约束或技术债的规模远超预期，项目被迫停滞。因此，本节的核心任务是建立一套可操作的驱动力识别方法，让迁移决策有据可依。

四类典型驱动力

从工程实践看，触发基础设施迁移与重构的因素通常可以归入四个维度，它们往往同时存在，但权重不同。

业务驱动力关注的是"基础设施能否支撑业务增长"。典型信号包括：新区域上线周期从两周拉长到两个月、大促前扩容需要人工逐台操作、多环境配置漂移导致发布回滚频繁。这类问题的本质是基础设施的交付速度跟不上业务节奏。评估时应量化，例如统计过去半年平均环境交付时长、变更失败率、发布频率，用数据说明瓶颈位置。

成本驱动力关注资源利用率与支出结构。常见现象是云账单持续上涨但业务量并未同步增长，或者存在大量长期闲置的实例、未挂载的磁盘、超额预留。评估时需要区分"必要成本"与"浪费成本"：前者随业务增长而增长，后者是可以通过治理消除的。一个实用的判断指标是资源利用率分布——如果超过三成的计算资源长期利用率低于 10%，就存在明显的优化空间。

合规驱动力通常来自外部约束，例如数据必须留在特定地域、审计要求所有变更可追溯、等保或行业监管要求网络隔离与访问控制。合规驱动的迁移往往没有商量余地，但需要区分"硬性要求"与"最佳实践建议"，避免把建议当成强制项而过度设计。

技术债驱动力关注现有基础设施的可维护性。典型表现是：资源靠控制台手工创建、配置散落在多个脚本和文档中、没有版本控制、故障恢复依赖个别工程师的记忆。技术债的评估可以从"可重复性"入手——能否在空账号中仅凭代码重建整套环境？如果答案是否定的，技术债就已经构成了迁移的充分理由。

现状评估：把"感觉"变成"数据"

驱动力识别之后，需要用现状评估来校准判断。评估不是把所有资源列一遍，而是围绕迁移决策真正关心的几个问题收集证据。

第一是资源清单与归属。统计当前有多少计算实例、数据库、存储桶、负载均衡、网络组件，分别属于哪个业务、哪个环境、哪个团队。很多团队在这一步就会发现大量"无主资源"——没人知道它们为什么存在，也不敢删除。这些资源本身就是技术债的直接证据。

第二是依赖关系。基础设施迁移最怕的不是资源多，而是依赖关系不清。一个看似独立的服务可能依赖某个共享数据库、某个内部 DNS 记录或某个安全组规则。评估时应至少画出关键业务链路，标注哪些依赖是强耦合、哪些可以解耦。

第三是变更频率与失败率。统计过去一个季度的变更次数、回滚次数、平均恢复时间。如果变更频率低但失败率高，说明流程脆弱；如果变更频率高但全靠人工，说明自动化缺口大。这两个指标直接决定迁移后能带来多少收益。

第四是可重复性。这是技术债评估中最关键的一项。可以做一个简单的测试：假设现有环境全部丢失，团队能否在 24 小时内仅凭代码和文档重建？如果答案是否定的，或者需要依赖某个工程师的"记忆"，那么可重复性评分就很低，迁移重构的必要性就很高。

目标与成功标准：从驱动力推导

目标不是"把基础设施迁移到 Terraform"，这是手段而非目标。目标应该从驱动力推导出来，并且可量化、可验证。例如：

• 业务驱动 → 目标：新区域环境交付时间从 10 个工作日缩短到 1 个工作日以内；成功标准：连续三次新环境交付均在一日内完成，且无需人工登录控制台。
• 成本驱动 → 目标：计算资源月支出降低 25%；成功标准：在业务量不下降的前提下，连续两个月账单低于基线值的 75%，且资源平均利用率提升到 40% 以上。
• 合规驱动 → 目标：所有生产数据存储于指定地域，所有变更可追溯；成功标准：审计时能提供完整的变更记录，且数据驻留检查项全部通过。
• 技术债驱动 → 目标：环境可重复重建；成功标准：在空账号中仅凭 Terraform 代码，4 小时内重建完整测试环境并通过冒烟测试。

这些标准有一个共同特点：它们都可以被验证，而不是"感觉好多了"。在项目启动前就把成功标准写下来，还能在项目中期用来判断是否偏离方向。

优先级与范围界定

四类驱动力往往同时存在，但不可能一次全部解决。需要根据"影响面 × 紧迫性 × 可行性"排出优先级。影响面大、合规硬性要求、且技术方案成熟的，优先做；影响面大但依赖关系复杂、短期难以解耦的，可以先做局部治理，等条件成熟再迁移。

范围界定同样重要。迁移重构不等于把所有资源一次性搬完。更务实的做法是选择一条业务链路作为试点，例如"订单查询服务"或"用户注册流程"，把这条链路上的资源用 Terraform 管理起来，验证目标是否达成，再逐步扩大范围。试点链路的选择标准是：依赖相对清晰、业务影响可控、能覆盖主要驱动力中的至少两项。

一个可参考的评估记录示例

下面是一份简化的评估记录示例，用于说明如何把驱动力、现状证据、目标和成功标准对应起来。示例中的数值均为教学假设，实际项目应根据真实数据填写。

驱动力	现状证据（示例）	目标	成功标准	优先级
业务	新区域交付平均 12 个工作日	缩短到 1 个工作日	连续 3 次交付 ≤ 1 日	高
成本	32% 实例月均利用率 < 10%	月支出降低 25%	连续 2 月账单 ≤ 基线 75%	高
合规	2 个存储桶位于非指定地域	数据全部驻留指定地域	审计检查项全部通过	紧急
技术债	环境重建依赖个人记忆	代码化重建完整环境	空账号 4 小时内重建通过冒烟	中