1 云迁移要回答什么
云迁移是把应用及其运行所需的能力，从现有环境转移到目标云环境，并确认业务仍然成立。它搬动的不只是程序文件，还包括数据、身份、网络连接、运行配置和操作责任。程序成功启动只是中间结果；用户能下单、订单没有丢失、值班人员能发现故障，才接近迁移完成。
设想一家零售企业有订单 API：门店提交订单，应用校验商品和库存，把订单写入数据库，再通知仓库。现在它运行在机房里的虚拟机上，图片保存在文件服务器，员工通过内部账号维护系统。企业希望减少硬件维护，并让促销期间扩容更方便。这是迁移动机，但还不是可以执行的迁移目标。
目标需要同时描述收益和约束。例如，硬件到期前完成订单服务迁移；允许在事先公告的窗口暂停写入 20 分钟；已经确认成功的订单不得丢失；迁移后由原业务团队负责应用告警。这些条件让团队知道何时可以切换，也让“不适合现在迁”的判断有依据。没有业务条件，技术人员容易把机器迁完误当成项目完成。
理解运行能力，可以沿着 1 次请求走。门店先通过域名找到入口，经网络规则到达应用；应用使用自己的身份访问数据库和图片存储；监控系统记录延迟、错误和资源状态。在云上，这些能力可能由虚拟机、托管运行平台、IAM、VPC、托管数据库和对象存储提供。名称变了，业务链路仍要完整。
这里的身份有 2 类：人用什么权限发布、查日志和处理故障；应用用什么权限访问数据。原机房里“内网就能连”的习惯，不能直接成为云上的授权规则。网络能到达只说明存在通路，身份被允许才说明可以执行操作。迁移清单必须分别记录这 2 件事。
云也不会自动承接全部责任。使用托管数据库可以减少部分主机维护，但账号权限、数据保留、业务查询和恢复验证仍需要有人负责。选用虚拟机时，操作系统维护通常还在团队手中。迁移方案要写出责任变化，否则原来有人做的工作可能落在双方之间。
本课围绕 4 个问题展开：为什么迁、先迁什么、采用什么策略、怎样证明能够安全接管。所谓“成功上云”，应当落实为可观察的业务结果，而不是某个控制台里新增了多少资源。先把这些问题问清楚，后面的评估、排期和切换才有共同尺度。
2 评估、优先级与波浪
评估先做资产盘点，但盘点单位不能只有服务器。对订单 API，要记录业务负责人、部署位置、运行时版本、数据规模、每日忙闲时段、访问入口、上下游依赖，以及维护合同和许可条件。某个信息暂时未知时，应标记“待验证”并指定负责人，不能把空白解释为没有风险。
接着建立依赖关系。订单 API 可能调用机房库存服务，库存服务又依赖内部身份系统；夜间对账程序可能直接读取订单数据库。访谈能发现设计中的关系，访问日志、连接记录和定时任务配置能补充实际关系。只观察工作日白天，容易遗漏月底结算和夜间批处理，因此观察窗口需要覆盖相关业务周期。
盘点结果要区分事实和假设。“库存接口地址写在配置文件中”是事实，“迁移后还能访问”是假设，需要从目标网络发起连接、完成授权并执行测试来验证。评估的价值就在于把含糊的担心变成可检查的条件，而不是给每项应用贴上“简单”或“复杂”的标签。
优先级通常同时考虑业务价值、迁移风险和准备程度。硬件即将到期能提高紧迫性，但不代表高依赖的核心交易系统适合做第 1 个试点。较好的试点应有真实用户、明确负责人、可代表后续应用的运行方式，并且故障影响可控。完全没有代表性的演示页面虽然容易成功，却可能没有验证身份和数据迁移能力。
可以为每项候选应用给出简短判断：迁移价值高不高，业务中断代价大不大，依赖是否清楚，目标平台是否支持，团队是否有接手能力。数字评分可帮助排序，但不能消除硬约束。许可证不允许在目标环境运行时，即使综合评分很高，也必须先解决授权或更换方案。
“波浪”是按时间组织的迁移批次。1 个波浪不是机械地装入固定数量的服务器，而是把能够共同准备、共同切换或共享学习成果的应用放进同一批。数据库与紧密依赖它的应用可能需要协同迁移；共享身份系统则可能先作为基础能力完成准备，再支持后续多个波浪。
波浪之间要有退出条件。试点完成后，团队应拿到网络可达证据、部署记录、恢复演练结果、业务验收和实际费用基线，再决定是否扩大范围。如果这些证据不足，后续波浪可以调整。计划中的日期是协调工具，不应压过未解决的业务风险。
还要防止波浪把所有能力塞给同一批人。数据库管理员、网络工程师和业务验收人员都有容量限制。把 3 个需要同一位专家全程参与的切换安排在同一晚，并不会因为应用彼此独立就变得可行。排期必须同时检查应用依赖和人员依赖。
3 搬迁、重构与替换边界
迁移策略描述“为了达到目标，应用需要改变到什么程度”。不同资料会采用不同数量的分类，本课只使用便于讨论的几种：直接搬迁、调整平台、重构、替换，以及暂时保留或退役。标签本身不是答案；重要的是写清哪些东西改变、为什么改变，以及如何验收。
直接搬迁是在尽量少改应用代码的前提下，把现有运行环境搬到云上的相近环境。例如把订单 API 从机房虚拟机迁到云虚拟机，保留原运行时和部署包。它可能较快满足机房退出期限，但原有单机瓶颈、补丁工作和扩容方式也可能一起保留，不能把搬迁等同于架构升级。
调整平台是在保留主要业务逻辑的同时，改变部分运行基础。例如应用仍处理同样的订单接口，但数据库改用兼容的托管数据库，图片改放对象存储。这里“兼容”需要验证驱动、字符排序、扩展功能、连接方式和备份恢复行为。产品都支持同一种查询语言，不代表所有使用方式都能无差别迁移。
重构则改变应用内部结构或关键交互方式。例如为了让多个实例共同处理订单，把只保存在进程内的登录状态迁到共享存储，并调整失败后的重试处理。这样的改动可能支持弹性运行，却扩大了代码、测试和发布范围。应由明确的业务目标驱动，而不是为了让方案看上去更像云架构。
替换是采用另一套产品或服务承接原有功能，例如停用自建的非核心报表工具，改用满足需求的现成服务。它省去的可能是长期开发维护，却增加了数据导出、权限映射、接口适配和用户培训。对订单核心流程，替换还涉及业务规则是否吻合，不能只比较订阅价格。
保留与退役同样属于评估结果。短期无法满足许可条件的系统可以留在原环境，并明确复审时间和连接需求；无人使用、无保留义务且已获业务确认的旧服务，可以安排退役。保留不是无限期搁置，退役也不是看到访问量低就直接删除，必须确认数据、合同和隐藏消费者。
策略可以按组件分别选择。订单 API 先搬到虚拟机，图片迁往对象存储，库存系统暂时留在机房，是可讨论的组合。但每条跨环境连接都会引入延迟、可用性和排障成本。把组件拆开选择策略后，需要重新检查端到端链路，而不能只说每个组件各自都通过了测试。
边界最好写成明确句子：“本波浪调整数据库承载方式，保持订单接口和业务规则不变；会话共享改造在后续版本完成。”这使团队能区分迁移必要工作与后续优化。遇到新增需求时，先判断它是否影响本次验收，避免迁移项目无边界地吸收日常产品开发。
4 动手：为一项应用选迁移策略
现在为订单 API 做一次纸面迁移决策。已知应用有 2 个实例，连接 1 个关系数据库，图片位于共享文件目录，还要调用机房库存接口。团队将在 8 周后退出当前应用服务器，允许停写 20 分钟，数据库仍可暂留机房。订单接口不能改版，且没有预算在本期重写库存系统。
第 1 步，把目标与限制分开写。目标是退出应用服务器并建立云上运行能力；限制是时间、停写窗口、接口兼容和库存依赖。数据丢失上限也必须单独确认：这里约定已向门店返回成功的订单不能丢失。停写 20 分钟不等于允许丢失 20 分钟的数据，这 2 个指标约束的是不同事情。
第 2 步，画出最小依赖图：门店入口、应用实例、数据库、图片目录、库存接口和运维身份。给每条边补上目标地址、访问身份、网络方向和测试方式。尤其检查共享目录是否被当作本地磁盘使用；如果应用依赖文件锁或固定路径，直接换成对象存储会超出“只改配置”的范围。
第 3 步，列出候选方案。方案 A 先把应用搬到云虚拟机，数据库和库存暂留机房；方案 B 同时把数据库调整到托管平台；方案 C 重构订单和库存交互。现有条件下，C 的范围明显超出本期目标。A 的应用改动少，但必须验证跨环境链路；B 可减少后续数据库搬动，却需要额外兼容性和数据切换验证。
第 4 步，先做会改变决策的小实验。用脱敏测试数据部署应用，从目标环境调用库存测试接口，记录端到端延迟、超时与错误；再对数据库执行代表性读写，检查连接数、事务行为和恢复流程。测试应使用接近实际的网络路径与访问身份，笔记本上的连通结果不能替代目标应用的结果。
假设实验发现，A 的跨环境读写延迟使结账超出业务约定，而 B 的数据库兼容测试通过。此时可优先评估 B，并把库存接口的跨环境访问列为切换前置条件。这个结论依赖实验事实；如果 B 的数据同步或恢复演练无法在期限内完成，就需要调整时间或范围，不能靠策略名称宣布风险已经消失。
第 5 步，把准备、演练和切换拆开。准备时建立身份、网络、日志和目标资源；演练时验证部署、数据导入、业务流程与回退；正式切换时按批准的窗口冻结相关变更，暂停旧端写入，完成最后数据同步，核对记录，再开放新端写入。迁移工具显示完成，只能证明它负责的环节完成。
第 6 步，明确回退的分界。新端还没接受业务写入时，可以在确认旧端完整后恢复旧入口；新端已经写入后，旧库可能已经落后，不能简单改回域名。此时要按预先演练的数据回退方案处理，或者保持单端写入并向前修复。对入门迁移，优先避免同时向新旧 2 套数据库写入。
最后留下简短决策记录：选择什么策略、舍弃其他方案的原因、依据哪些测试、尚有哪些前置条件、谁有权决定切换和回退。它不是事后包装材料，而是让业务、开发和运维在同一组事实下行动的操作依据。
5 速度与改造深度取舍
改得少，通常意味着初期代码工作较少；改得多，通常意味着需要更多设计和回归测试。但这不是“搬迁必然便宜、重构必然昂贵”的公式。老系统可能因为镜像不兼容而难以直接搬迁，边界清楚的小型无状态服务也可能较容易调整平台。策略与速度之间只能建立有条件的判断。
可以把成本分成迁移投入和迁移后的运行投入。前者包括兼容性验证、数据传输、演练、人员培训，以及新旧环境并行期间的费用；后者包括计算、存储、请求、网络传输、许可证和日常维护。只比较虚拟机单价，会漏掉临时双份资源，也会忽略跨环境访问持续产生的成本。
滑块展示的是任务范围随改造深度如何变化，并不预测真实工期或费用。从直接搬迁移到调整平台，会增加服务兼容与运行责任检查；继续移到重构，会增加业务行为和发布策略验证。每次拖动都应问：新增工作解决了哪个本期目标，现有团队能否完成验证。
迁移速度还受数据约束。几百 GB 的数据库可以先做初始复制，再在切换窗口处理增量；但能否按时完成，取决于实际可用带宽、持续写入量和工具能力。不要把链路标称带宽直接当成复制速度。先用代表性数据演练，记录复制耗时和追平所需时间，再安排窗口。
降低改造深度可以缓解本期时间压力，却可能把工作推到后面。例如先保留固定容量的虚拟机，再补自动化部署和弹性运行，是合理的阶段安排；前提是给后续工作指定负责人、预算和复审日期。如果只是写“未来优化”，团队很容易长期维持昂贵的临时状态。
同样，观察指标不能只看机器 CPU。迁移后 CPU 更低，可能是配置更大，也可能是请求根本没有到达。应把成功订单数、错误率和延迟放在资源指标之前，再检查数据库连接、网络超时和存储状态。只有业务流量、错误和账单一起对照，才知道迁移后的运行方式是否符合预期。
做取舍时，先固定业务不可接受的情况，再在可行范围内选择投入。若订单不能丢失，就不能为了缩短窗口跳过写入冻结和数据核对；若当前目标只是硬件退出，也无需把每个组件都改造成全新的架构。迁移策略服务于约束，而不是替代约束。
6 常见坑：先搬再发现许可墙
许可墙是指技术上能运行，合同或授权条件却不允许按当前方式使用。例如某数据库按处理器或核心数量计费，虚拟化部署有特定规则；某组件绑定原设备，换环境后需要重新授权；某支持合同只覆盖规定的系统版本。资源已经创建，不能证明软件使用权已经随之转移。
最容易遗漏的是间接使用的软件。应用团队知道主数据库有许可证，却未必知道报表驱动、图像处理库或备份代理也有授权条件。应从应用安装清单、采购记录和实际部署包共同核对，而不是只问“主程序是否自研”。无法确认的条款，要交给采购、法务或授权负责人核实。
许可检查应前置到候选方案评估。记录软件及版本、现有授权范围、目标运行形态、续费和支持条件、核实来源与日期。对含糊表述，拿目标配置向有权解释合同的一方确认。不能用网上某个相似案例，推断自己的合同也允许相同部署。
遇到许可限制，可以比较补充授权、更换兼容组件、改用其他承载服务，或暂时保留原系统。每条路都要重新检查技术影响和成本。托管服务的价格是否包含相应软件权利，也应以适用条款为准。不要因为页面写着“托管”，就默认所有第三方许可已经包含。
另一个常见坑是把网络迁移当成复制地址。原机房中的固定 IP、内部域名解析、代理出口和白名单，在新环境里可能失效。数据库能从管理员电脑连接，不代表应用身份能从目标子网连接。验证必须从实际运行位置发起，并同时检查解析、路由、访问规则、认证和应用请求。
数据与密钥也不能分开遗漏。备份文件复制成功，如果解密密钥、证书或恢复权限没有准备，仍然无法恢复。对订单数据至少演练一次从备份到可查询服务的过程，并确认恢复后账号与网络规则正确。备份存在是资源事实，恢复成功才是能力证据。
还有一种坑是过早释放旧环境。新入口能打开，不代表夜间对账、退货和退款都已验证。旧资源应在约定观察期、数据保留要求和业务验收满足后再退役，并同步处理旧账号、域名、证书和账单项。否则可能出现应用已下线，长期磁盘和许可费用仍持续产生的情况。
这些问题的共同点是：迁移前没有把运行条件写成清单，迁移后才用故障补齐。有效清单不追求条目越多越好，而是每项都关联负责人、检查动作和证据；确实不适用的条目也给出理由，避免大家只机械地打勾。
7 案例：依赖未迁导致切换失败
某零售团队已把订单 API 和数据库部署到云上，健康检查全部通过。演练时使用了库存模拟服务，正式切换时却继续调用机房的真实库存接口。团队看到应用实例正常、数据库可连接，便把入口切到新环境。随后门店能打开结账页，但提交订单频繁超时。
这里“页面可用”与“订单可用”分属不同链路。静态页面不需要访问库存，健康检查也只确认进程存活；真正提交订单才触发库存调用。目标网络没有完整准备访问库存所需的通路和规则，所以应用没有崩溃，业务却已经中断。扩容应用实例不会修好这条缺失的连接。
值班人员首先检查切换后的成功订单数和错误率，确认问题从新入口开放后出现；随后沿请求记录定位到库存调用超时。此时应区分域名无法解析、连接无法建立、身份验证失败和远端处理过慢。它们都可能表现为“下单失败”，需要不同修复动作，不能把全部故障归因于云上性能差。
团队从目标应用所在网络进行测试，发现库存地址能够解析，但预期端口无法连接；进一步核对发现跨环境访问规则缺失。证据把修复范围收敛到了网络通路。处理期间应保护日志中的用户信息和凭据，也不要为了快速联通而放开所有来源；需要的是让明确的调用方访问明确的服务。
是否立刻回退取决于写入状态。假设新端已经写入了部分成功订单，就不能直接让旧应用使用旧数据库继续接单。负责人先暂停受影响的入口，确认成功请求的记录位置，并按预案决定保持云端作为唯一写入端、修复库存连接后恢复。若要回旧端，则必须先解决这部分新数据的接续问题。
网络规则修复后，也不能只测端口。业务人员用测试订单完成创建、查询和取消，检查库存变化与订单状态是否对应；再观察真实流量下的超时、延迟和成功订单数。对已返回失败或状态不明的请求，按订单编号核对是否实际创建，避免门店重复提交造成重复订单。
复盘发现，真正缺口是依赖验收没有进入切换门槛。修正措施包括：依赖图标记真实服务与模拟服务；从目标环境验证关键接口；把真实库存调用纳入演练；让业务负责人签收完整下单流程。模拟服务仍然有开发价值，但不能承担真实跨环境连接的验收责任。
这个案例也说明，依赖暂留机房不一定是错误。错误在于把“暂留”当成“不需要处理”。只要连接、身份、延迟、维护窗口和故障负责人都得到验证，分阶段迁移可以成立；如果这些条件无法满足，就应将强依赖一起调整到相同波浪，或改变切换安排。
8 把迁移波浪写进项目方案
项目方案中的波浪应是一份能执行的约定。每批说明业务范围、应用与数据、迁移策略、前置依赖、参与角色、时间窗口、验收条件和回退办法。服务器数量可以作为工作量信息，但无法替代业务范围。例如“订单提交与查询迁移”比“迁移 6 台机器”更能说明业务需要接受什么。
先安排基础准备：目标账号与权限、网络连接、日志与告警、资源命名和费用归属。它们不一定属于某个业务应用，却决定后续波浪能否反复使用同一套方法。基础准备也需要验收，例如值班人员能否查看目标日志，发布身份是否只有必要权限，费用是否能按业务识别。
再安排试点波浪，验证迁移流程是否完整。订单 API 可以先在隔离环境完成演练，再在明确的低峰窗口切换。试点不是要求风险为零，而是让风险在可管理范围内暴露。试点结束应总结哪些步骤可复用、哪些假设不成立，以及下一批估算需要怎样调整。
后续波浪按依赖和团队容量展开。对仍依赖机房的服务，注明连接需要保留多久、费用归谁、机房维护是否会影响云端业务。若某批必须等待共享身份系统改造，计划中应画出这个依赖，而不是只放 2 个没有关联的日期。关键前置项延误时，受影响范围才容易识别。
验收条件要能判断通过或不通过。例如在约定流量下，订单成功率和延迟达到业务确认的阈值；已确认订单核对无缺失；备份恢复演练成功；值班团队收到并处理了测试告警。具体阈值根据现有基线和业务目标确定，不宜直接套用别的项目数字。
回退办法必须指定触发条件、决策人和数据处理方式。入口回切时间、业务恢复时间、数据核对时间不是同一个数。方案中可分别记录，避免把“改域名只需几分钟”写成完整恢复承诺。超过预定的可回退分界后，应启用经过演练的替代处置，而不是临场猜测。
最后安排退役与交接。业务通过验收、观察期结束且保留要求满足后，再按批准流程关闭旧资源。交接材料应包含部署、权限申请、常见告警、恢复与费用查看方法。迁移团队离场后，运行团队能够独立完成这些动作，才说明迁移成果真正进入日常运维。
9 从云迁移走向混合云与多云（C61）
迁移完成后，系统不一定只存在于 1 个云环境。订单 API 在云上，库存系统仍在机房，这种安排已经带来跨环境运行问题。若机房与云按共同的业务、连接和管理方式协同工作，可以进入混合云的讨论。仅仅还有几台旧服务器，不等于已经具备完善的混合云能力。
多云通常指使用多个云提供者的服务。选择它可能出于业务布局、已有采购或特定能力需求，但“多放一个环境”不会自动提高可靠性。身份、网络、数据、观察和团队操作都要协调；如果所有环境仍依赖同一条连接或同一套关键数据，它们可能共享故障来源。
迁移时留下的依赖图，是进入下一课的起点。给每个组件标明所在环境、负责团队、访问身份与数据流向，就能看见跨环境调用实际发生在哪里。接着再问：链路中断后哪些业务还能继续，权限撤销是否及时，故障记录能否关联，数据保留和费用如何统一解释。
不要为了保留选择权而要求所有组件随时搬走。可迁移性也有成本：采用某种通用接口可能降低替换难度，放弃适合业务的托管能力也可能增加维护负担。合理做法是识别真正需要退出能力的部分，验证数据导出、配置保存和恢复路径，再接受有依据的绑定程度。
同样，迁移期间的新旧环境并行通常是临时安排，需要结束条件；长期混合运行则需要持续投入。前者关注如何安全完成交接，后者关注连接失效、独立维护和日常权限变更时业务如何继续。把这 2 种状态混淆，容易让“临时连接”在没人负责的情况下长期存在。
因此，本课的终点是一套有边界的迁移结果：目标已验证，依赖已记录，数据归属明确，责任已经交接，暂留项目有后续安排。C61 将在这些事实之上讨论混合云与多云，重点从“怎样搬过去”转向“多个环境怎样长期共同运行”。
放进方案里
本项目以退出到期应用服务器、维持订单业务连续性为迁移目标。范围包括订单 API、关系数据库、图片访问与相关运行配置；库存服务本期保留在机房。订单接口保持兼容，已返回成功的订单不得丢失，允许在公告窗口内暂停写入 20 分钟。各项验收阈值由业务负责人与运行团队依据现网基线共同确认。
迁移按基础准备、试点、后续业务波浪推进。基础准备完成目标身份、网络、日志告警和费用归属；试点验证部署、数据迁移、库存访问与回退；后续批次依据试点证据调整范围和时间。每批列明业务负责人、技术执行人、运行接收人及共享专家需求，关键依赖未通过时不得进入正式切换。
订单 API 采用少量改动的搬迁方式，数据库是否调整到托管平台以兼容性、复制和恢复演练结果为准。采购与授权负责人在资源投入前确认数据库、运行时和配套组件的许可条件。仍跨环境运行的依赖单独记录连接、授权、延迟要求、持续费用和维护责任，不以应用健康检查代替完整业务验收。
切换前冻结相关变更，核验备份可恢复，明确唯一写入端和决策人。窗口内暂停旧端写入、完成增量同步与数据核对，再开放新端。新端未产生业务写入时，可按预案恢复旧端；新端已写入后，必须先处理数据接续，禁止直接回指落后数据库。触发回退或向前修复的条件均在演练中确认。
验收同时检查成功订单、错误率、延迟、库存一致性及告警响应，并核对运行费用。观察期覆盖相关对账任务，结束后由业务与运行团队签收。旧环境在满足验收、数据保留和授权要求后退役；暂留系统注明复审日期。交接附部署、权限、恢复和费用查看方法，后续优化另列负责人及预算。
10 小结：下一步混合云与多云（C61）
云迁移需要把业务目标、运行依赖、迁移策略和验收证据连起来。先盘点并验证依赖，再按价值、风险和准备程度组织波浪；切换时明确写入归属，完成数据核对；验收后把运行责任和退役工作交接清楚。
可以用 3 个问题检查方案：应用健康但订单失败时，能否沿依赖找到证据？新端已经写入后，回退怎样保证数据接续？旧环境仍有组件保留时，谁负责连接和故障？如果回答还不清楚，方案仍有需要补齐的运行条件。
下一课 C61 将讨论混合云与多云：当多个环境需要长期共存，如何安排身份、网络、数据和观察能力，以及如何判断这种复杂度是否值得承担。