4. 迁移规划：制定迁移计划、时间表、资源分配

规划是迁移的灵魂。说实话，我见过太多团队上来就动手迁移，结果做到一半发现人力不够、窗口时间冲突、关键业务没人兜底，最后只能回滚重来。我自己也踩过这个坑——有一次评估不充分，漏了三个老系统之间的隐藏依赖，差点导致全量数据丢失。从那以后，我养成了一个习惯：无论迁移规模多小，都必须先做一份成文的迁移规划。

这一章我们就聊聊——怎么把「迁移规划」从口头讨论变成可执行、可检查、可回溯的文档。说白了，就是三件事：计划（做什么）、时间表（何时做）、资源（谁来做、用什么做）。

4.1 制定迁移计划：从资产清单到动作列表

很多人把迁移计划等同于一张 Excel 时间表。其实不对。一份靠谱的迁移计划，至少包含三个层次：资产摸底、迁移策略、动作清单。

先做资产摸底。我记得有一次接手一个用了六年的旧 DLP 系统，IT 部门说有 200 条策略，结果我导出配置一看——300 条，还有 40 条已经废弃但没删除。浪费大量精力。所以我的习惯是：先把所有策略、规则、黑白名单、异常事件全部导出，做一次清洗。然后分三类：必须保留、可以合并、可以废弃。

接着定迁移策略。这块我倾向分批迁移——先迁非核心策略，再迁核心策略，最后迁那些影响面大的规则。为什么？你想想看，万一核心策略迁移后出了问题，你能快速回滚，影响面小。我曾经一次性迁了 50 条核心数据防泄漏规则，结果新 DLP 的语法兼容有瑕疵，导致员工发送加密附件全部被拦截。那一次我被叫去开会开到半夜……后来再也不敢蛮干了。

4.2 时间表规划：分阶段、设缓冲

时间表最容易出问题的地方，是低估测试和回滚的时间。我见过一个团队排了 3 天迁移、2 天验证，结果迁移用了 1 天，验证因为数据比对不一致，花了 4 天。时间表完全被打乱。

我自己的做法是 4:4:2 原则：
40% 时间做方案设计与准备
40% 时间做迁移与测试
20% 时间做缓冲和复盘

具体到周粒度，我会这样排：

1. 第 1 周：资产清单、依赖梳理、风险识别。（准备阶段）
2. 第 2 周：环境搭建、策略转换、初步验证。（试跑阶段）
3. 第 3 周：分批迁移、A/B 对比、问题修复。（迁移阶段）
4. 第 4 周：全面上线、性能回执、监控稳定。（收尾阶段）

注意，我这里每阶段都预留了“缓冲日”——通常 1-2 天。比如第 3 周如果遇到依赖冲突，多出来的时间不用挤占后面的窗口。嗯，这个缓冲我曾经在客户现场救过急——当时第五批策略迁移时老 DLP 突然挂了，我们花了半天恢复，但因为有缓冲，最终没影响上线。

4.3 资源分配：人、钱、环境

资源分配不只是说“配备几个人”。我把它拆成三个独立维度：人力角色、预算额度、环境保障。

4.3.1 人力角色

一个小型迁移（比如 5 台旧 DLP 服务器、100 条规则）至少需要：

• 项目经理（1 人）：统筹进度、协调资源、控制风险。我个人经验 PM 最好是懂安全的人，不然会被细节拖垮。
• 安全工程师（2 人）：负责策略转换、规则测试、日志比对。
• 运维工程师（1 人）：负责基础环境、网络策略、备份恢复。
• 业务代表（1 人）：来自被保护业务的 team，帮助确认规则不能影响正常业务。这个角色常被忽略，但缺了他容易出大篓子。

中型迁移（200+ 策略，跨部门）建议再加一个自动化脚本开发的岗位，专门写迁移工具和批处理。我自己参与过的最大一次迁移，写了 2000 行 Python 脚本来自动转换 1500 条规则——节省了 3 个人周的工作量。

4.3.2 预算与工具

除了人的工时，还要考虑：

• 新 DLP 的 License 与续费（如果老系统还在过渡期，可能需要双 License 并行 1-2 个月）。
• 迁移工具的采购或开发成本。有时候用开源方案（如 Elasticsearch 旧库转新库）需要自己适配。
• 测试环境的服务器或容器资源（很多公司只给生产环境，测试环境靠虚拟机凑，我建议至少准备一台与生产同配置的沙盒）。

资源项	最小配置（小规模）	推荐配置（中大规模）
人力总工时（周）	8-12 人·周	20-40 人·周
预算（不含 License）	5-10 万元（工具+环境）	15-30 万元
测试环境机器	2 台虚拟机（4C8G）	4 台物理机（8C16G）
网络带宽预提	100Mbps 链路测试	1Gbps 链路，带 QoS

不过这些都是典型值。如果你现有环境是那种 10 年老系统，有大量定制化插件，预算就得翻倍。我亲身经历：一个制造业客户的旧 DLP 使用了第三方加密插件，迁移时插件不兼容，只好用 3 个月时间重写适配层，预算超了 60%。

4.3.3 环境保障

这里我有一个死规矩：迁移前必须做全量备份和可恢复演练。别觉得备份了就万事大吉——要确保备份能在一小时内恢复到线上。我曾经见过备份文件损坏、恢复失败的情况，好在那次迁移还没正式开始，否则后果不可想象。

4.4 风险与应急预案

风险不是“万一发生”，而是“一定会发生”，只是程度不同。常见风险包括：

• 策略语法不兼容：老 DLP 的某些正则表达式或动作在新系统里不被支持
• 业务影响：误拦截导致正常邮件/文件无法发送
• 网络延迟：新 DLP 的扫描延迟高于旧系统，影响用户体验
• 数据不一致：迁移过程中部分日志丢失或重复

对每个风险，我习惯做一个三列的表格：风险描述 → 触发条件 → 应急动作。比如说：

风险	触发条件	应急动作
策略语法不兼容	预览测试时发现错误日志	回退旧策略，手工修改后再试
误拦截影响业务	业务方反馈附件不能发送	立即停止迁移批次，临时加白名单
网络延迟超阈值	监控显示请求平均延迟>500ms	切回旧 DLP，分析瓶颈后再迁移
数据丢失	日志量级对不上	重新执行增量迁移工具，并比对唯一键

我每次做迁移前都会把这些风险点走一遍，并指定“应急决策人”——通常是项目经理，他有权在 10 分钟内决定是否回滚。千万别等人齐了再开会，等你开完会生产线已经崩了。