迁移 · 阅读约 10 分钟
迁移关键数据平台前需要回答的八个问题
涵盖资产清单、依赖、验证、安全、性能、切换、回退及运营责任的就绪评估框架。
关键迁移是一项受控业务变更
当证据满足约定验收标准时，数据平台迁移才算就绪，而不是复制任务能启动就算。 团队需要已验证的清单、依赖图、获批目标架构、已核对数据、性能与安全证据、经过演练的切换和回退手册，以及明确的决策负责人。
以下问题适用于数据库、仓库、湖仓、ETL 与 CDC 管道、语义模型、报表及依赖它们的应用。
如果任何一项准备情况只能靠乐观估计，拿不出可审核的证据，就应在切换前缩小范围或补齐缺口。
1. 为什么要迁移？
选择目标前先说明预期业务或运营成果，例如降低报表延迟、达到明确恢复目标、淘汰已停止支持的技术、加强数据驻留或安全控制、降低服务成本，或更快交付经过治理的数据产品。
应做
- 记录当前基线与目标指标。
- 指定管理层支持方，以及有权验收结果的数据或业务负责人。
- 将就绪、演练与切换任务分配给具体人员。
避免
- 仅将“数据已搬移”或“新平台已上线”定义为成功。
- 先选偏好的产品，再补造理由。
- 让截止日期或沉没成本凌驾于约定退出标准之上。
2. 我们了解整个环境吗？
建立受控资产清单，支持范围、架构、测试及责任决策。记录数据资产与规模、引擎与版本、键与数据结构、管道与调度、关键程度、保留期、服务水平、备份恢复、身份、分类、高峰负载、成本及负责人。
单靠配置文件通常无法揭示完整生产要求。应纳入电子表格、文件投递、平时不运行的月末作业、合作伙伴供数、手动提取，以及自动发现可能遗漏的工作。
3. 我们理解依赖关系吗？
梳理上下游读写、API、消息、文件、批处理与流处理、共享数据库、BI 报表、语义模型、认证、网络路径及外部相关方。对每项依赖记录数据延迟、缺失、重复或不可用时的业务影响。
与工作负载负责人验证工具生成的依赖图。识别必须共同迁移的组件，以及分开迁移时所需的临时混合连接。
4. 目标架构获批了吗？
目标不只是一个接收数据的服务。应记录数据模型与键、转换与历史、批流模式、重试与幂等性、容量与负载隔离、区域与驻留、网络、身份与密钥、可观测性、成本控制、备份恢复及长期责任的决策。
警示信号
- 尚未了解性能、安全、可用性或数据驻留要求，就已选择目标。
- 按平均负载配置容量，却未测试高峰并发与增长。
- 未经审查就复制旧权限与临时变通方案。
- 将引擎转换、规则重构、语义模型替换及所有报表打包为一次切换，却未接受叠加风险。
保护比较基线：冻结可避免的变更
交付经验： 需求与源基线获批后，应冻结可避免的源数据结构、ETL 逻辑、业务规则及报表定义变更，直到迁移平台投产并稳定。
迁移或 ETL 转换的目的是在另一平台上复现约定的处理逻辑和结果，并不意味着要重构整个系统。若源系统在实施期间持续变更，开发人员就必须反复更新映射、转换逻辑、测试和文档。目标不断变化，会增加返工，并影响项目进度和计划中的生产切换。
业务需求变化还会带来第二个问题：团队失去证明目标与旧系统等价所需的稳定参照。如果转换期间计算、规则、数据定义或预期报表改变，差异可能来自迁移，也可能来自新需求，导致结果难以核对，验收变得主观。
应做
- 批准并版本化作为迁移基线的源端数据结构、ETL 逻辑、业务规则、语义定义及预期输出。
- 从需求签核至生产稳定，明确变更冻结窗口。
- 将功能增强与业务规则重构留至单独界定范围的迁移后阶段。
- 对紧急安全、监管、生产缺陷或运营变更，采用正式例外流程。
- 每项获批例外都记录负责人、原因、源端影响、目标变更、进度影响、新测试证据及更新后的核对基线。
避免
- 允许日常源系统发布在未经迁移影响评估时修改表或 ETL 作业。
- 混合转换与重构，却保持原进度及验收标准不变。
- 改变 KPI、计算或业务定义后，仍直接与旧结果比较。
- 接受无文档的紧急变更，或期望开发人员在不重新规划的情况下承担反复返工。
冻结并不意味着忽略关键生产需求，而是确保不可避免的变更受控，在需要时一致应用于源端与目标端，反映在测试基线中，并纳入切换决策。若例外数量显著，应重新设定范围与进度基线，而非假装原迁移计划未变。
5. 能证明数据与业务输出正确吗？
转换前先确定数据核对方法。技术检查应覆盖预期对象与数据结构、类型兼容性、键与约束、完整性、重复记录、顺序、转换逻辑、插入、更新、删除、序列值、检查点，以及重启后的处理方式。
行数有用但不足够。还应增加余额、按法律实体或状态汇总、时序与引用完整性、报表及 KPI 一致性，以及高价值、边界、空值、重复和历史记录抽样。每项重大差异都需分配负责人及处理方式。
6. 完整工作负载通过测试了吗？
测试人员实际运营的平台，而不只是数据传输工具。
| 测试层 | 必须证明什么 |
|---|---|
| 迁移机制 | 初始加载、CDC、重启、转换、删除处理、恢复及验证 |
| 功能与集成 | 管道、应用、API、BI、语义模型、调度、外部相关方及端到端数据流 |
| 用户与回归 | 关键用户路径，以及与已接受源输出的历史比较 |
| 性能与容量 | 日常及高峰流量、批处理重叠、并发、吞吐量、源负载及目标利用率 |
| 安全 | 身份、最小权限、网络限制、加密、密钥、审计、脱敏及拒绝访问路径 |
| 可靠性与运营 | 备份、还原、灾难恢复、监控、告警、重放、操作手册及支持交接 |
| 切换与回退 | 计时的生产步骤、检查点、决策阈值、恢复验证及沟通 |
使用接近生产的数据变化及代表性资源争用。功能正确但错过运营窗口的工作负载仍未就绪。
7. 能安全切换并恢复吗？
根据获批的业务容忍度选择切换方法：
- 离线： 一致性模型最简单，但写入停机时间最长。
- CDC 或快速切换： 减少停机，但增加复制延迟、最终积压清空及源负载控制。
- 双活： 只有每种写入冲突都能按明确规则得到一致处理时，才支持逐步迁移流量。
- 分批迁移： 组件责任与依赖边界清晰时，可降低一次大切换的风险。
不要承诺零停机。使用经过测量的中断窗口及计时手册，列明前提、负责人、成功标准、证据链接、继续／停止检查点、沟通安排，以及最晚安全回退决策时间。
回退计划必须说明数据如何处理。如果目标接受写入，应提前决定流量返回源端时，如何保留、核对、重放或放弃这些变更。演练恢复与验证，而不仅是路由切换。
8. 团队能运营目标环境吗？
移交生产前，确认监控与告警、操作手册、访问、备份还原、事件处理路径、值班责任、培训、容量成本评估、增强责任及重点支持期退出标准。
不要在流量转移后立即停用源端。应等到回归、核对、健康、性能、安全、备份及业务验收证据均稳定。
上线准备检查
| 检查项 | 证据 | 停止信号 |
|---|---|---|
| 目的 | 成果、基线、目标、业务支持方及数据负责人 | 没有可衡量理由或明确负责人 |
| 数据环境 | 资产、规模、分类、服务水平及负责人 | 未知数据或无人负责的工作负载 |
| 依赖关系 | 由负责人验证的上下游依赖图 | 仅依赖工具发现 |
| 架构 | 获批的数据、容量、安全、恢复及成本设计 | 兼容性或数据驻留假设尚未确认 |
| 正确性 | 技术验证与业务核对 | 只有行数，或仍有无法解释的差异 |
| 测试 | 功能、性能、安全、恢复及回退证据 | 只测试正常路径与平均负载 |
| 切换 | 经过演练的手册、决策阈值及考虑数据的回退方案 | 两个系统均可写入，但没有冲突规则 |
| 运营 | 监控、操作手册、支持责任及培训 | 项目团队上线后立即离开 |
如何衡量迁移效益
将目标与源基线比较。可用指标包括数据时效、管道与报表周期、可用性、经测试的恢复点目标（RPO）与恢复时间目标（RTO）、查询响应与吞吐量、核对差异及事件率、人工干预、操作人员投入、每项工作负载成本，以及接入新源或交付经过治理的变更的时间。
已复制行数、已转换作业及已配置服务反映交付进度，但不能证明业务成果。