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