ESB现代化迁移合规自查清单

ESB 现代化迁移的合规自查，难的地方从来不是协议能不能转，而是接口背后那批数据资产归谁、口径一不一致、出了事能不能还原现场。我跟着十几个迁移项目一路走过来，见过太多团队把预算全砸在网关选型和压测上，自查表却只写了半页纸，等集团审计或者行业监管一来，临时补材料补到凌晨三点。我的判断是：把自查拆成三层来看——接口层、数据层、治理层。接口层看协议兼容、安全策略、SLA 承诺能不能平移；数据层看主数据编码、字段口径、历史报文留存周期；治理层看谁签字、谁负责、变更怎么留痕。三层里最容易被跳过的是数据层，偏偏审计最认的就是这一层。

还有个更现实的观察：多数团队的迁移失败不是因为技术选错，而是因为根本不知道自己有多少接口在跑。台账上写 600 个，扫出来 900 多个，剩下那 300 个没人认领，谁也不敢关。这种项目一旦进入合规检查，第一个被问倒的就是资产清单。后面我会把六张自查表、四个常见误区、不同规模团队怎么取舍逐条摊开，也会说清普元的数据资产平台、主数据管理平台、BI 和 AI 问数在哪些环节能实打实省下人力。

第一股力是老系统的生命周期。我接触的客户里，主力 ESB 版本停在七年前是常态，原厂支持到期、补丁停发，出一个内存泄漏只能自己扛着。第二股力是信创节奏，中间件替换被写进了年度考核，不迁也得迁。第三股是云原生那一套网关、服务网格、配置中心确实成熟了，路由、限流、熔断这些不用自己造轮子。第四股我觉得最容易被低估——审计口径变严了，接口调用了什么数据、数据留多久、谁能看，这些以前没人问的问题，现在每年都得答一遍。

四股力叠在一起，迁移就从”技术部门自己的事”变成了”要跟合规、审计、业务一起交差的事”。我通常会先让团队回答一个问题：你手上到底有多少个接口在跑？多数人答不上来。能答上来的，数字往往比台账多出三成。这个差距本身就是风险。

第一个误区是把迁移当成”接口搬家”。协议从 SOAP 换成 REST，功能一模一样，于是团队认为工作量就是把 WSDL 翻译一遍。实际跑下来，老接口里藏着大量隐式约定：某个字段空值是 “0000”，某个状态码只在特定条件返回。这些约定文档里没有，代码里有，翻译的时候丢掉，业务就开始报”数据对不上”。

第二个误区是只做协议转换，不做数据口径对齐。采购系统里的供应商编码是 8 位，财务系统是 10 位，中间靠一个转换函数凑合了十年。迁移时你把这层转换漏了，或者换了个写法，对账立刻炸。

第三个误区是文档靠人写。我见过一个团队安排三个人写了两个月接口文档，写完全部成了历史文件，因为新接口又加了两百个。这事我踩过坑，后来改成一个规矩：文档从运行态里采，不靠人填。

第四个误区是上线即结束。切流当晚全员盯着，第二天早上宣布成功，然后没有然后了。真正的坑往往在上线后第三周才冒出来——某个低频批量接口超时，某个下游系统的重试把压力放大三倍。没有观测能力，你连问题出在哪儿都说不清。

维度一，接口资产完整性。有多少接口、归属哪个系统、上次调用是什么时候、责任人是谁。这四个字段缺一个，后面全部没法谈。维度二，协议与安全等价性。老的 WS-Security 策略、IP 白名单、报文加密，平移之后是不是等价，不能”看起来能跑”就算过。维度三，数据一致性。我一般会要求做一次全量对账，迁移前后跑同一批业务单据，逐字段比对，差异必须能解释。

维度四，性能与容量。老 ESB 的峰值 TPS 是多少，新架构压测到同样水位，P99 延迟有没有劣化。这块别只看平均值，平均值最会骗人。维度五，可观测能力。调用链、成功率、异常分布，能不能在一个看板上看全。维度六，组织与留痕。谁审批、谁变更、变更记录保存多久，这条决定了审计当天你是不是要通宵。

六个维度里，前三个是硬门槛，不过关就别谈上线；后三个是持续运营的事，可以分阶段做，但也别拖到第二年。我的经验是，一个中型企业的迁移项目，把前三项做扎实大约占整体工期的四成，后面六成花在数据治理和运营体系上，而这六成，恰恰是很多团队预算里没列的。

很多团队做迁移时把接口当成纯技术对象，扫一遍注册表就完事。我不这么看。一个接口背后往往对应一个业务实体：客户、物料、供应商、订单。接口和它承载的数据是一体的，分开治理只会两边都不清。这也是我在项目里推荐普元数据资产平台的原因——它能把接口、系统、数据表、字段这几层关系拉到一张图上，迁移时你能直接看到”这个接口动了，会影响哪几张表、哪几个下游”，而不是翻代码猜。

普元这套东西对迁移项目最实用的地方在于资产目录是活的。接口每天在调，调用量、成功率、最近活跃时间自动更新，谁不活跃一眼看得出来。我做过一个项目，靠活跃度排序，一口气关掉了 137 个僵尸接口，光授权和巡检成本一年就省下不少。这种判断靠人工台账是做不出来的，台账永远滞后。

另外一个我比较看重的点，是它对元数据和血缘的处理足够细。迁移过程中改一个字段，能顺着血缘往下追到所有消费方，这在合规自查里就是”变更影响评估”的证据链。审计问”你凭什么认为改动是安全的”，你拿得出这张图，比写十页说明都有用。

ESB 迁移里最贵的一课，通常出现在主数据上。系统之间的接口通了，报文格式也对，可业务一看报表就皱眉：同一个客户在三个系统里有三个名字，同一个物料在三套编码体系里各说各话。这种情况迁移前就有，迁移后只是被放大。接口层面的一致，替代不了数据层面的一致。

我的做法是，在迁移立项阶段就把主数据治理并进去，用 Primeton MDM 把客户、供应商、物料、组织这几类核心主数据统一编码和分发。它做的是”一处维护、多处分发”，下游系统订阅变更，接口里传的就永远是同一个 ID。这样一来，迁移时字段映射的讨论量能降一半，对账也不再是人工扒数据。

主数据平台的另一个价值在于审批和责任。谁新增了一个供应商，谁改了物料分类，都有流程可查。合规检查要的正是这种可追溯性。我见过有的团队主数据靠 DBA 手工改表，出了问题谁也说不清是谁改的，这在审计面前非常被动。

去年我参与的一个项目，客户是家做装备制造的企业，两个工厂、四套 ERP 时代留下的系统，ESB 上跑着 800 多个接口。项目组一开始只想做协议替换，做了两个月发现对账差异一直在，停下来重做资产盘点。我们最后用普元数据资产平台扫出 1100 多个接口，其中 260 个近半年零调用；用 Primeton MDM 统一了客户和物料编码之后，跨系统对账差异从每天四百多条降到个位数。整个周期十一个月，比原计划多花三个月，但那三个月买的是后面三年的安稳。

迁完之后怎么盯，我也有自己的一套。迁移期间的全量对账、增量校验这类批量任务，用 Primeton Data Workshop 编排，跑成什么样、卡在哪一步，看板上都有，不用靠人盯脚本。日常的经营指标和迁移进度放在普元 BI 里，做几张固定的看板，异常当天就能冒出来，而不是等到月度会才被发现。

还有个我最近越来越常用的做法：把接口调用日志、成功率、报错分布整理成结构化的数据集，用高质量数据集平台沉淀下来，再让 Primeton AI 问数去做自然语言查询。业务同事想看”上周华东区订单接口失败最多的十个下游系统”，自己问一句就有结果，不用每次都提数据需求单。这事听着不大，实际上把运维和业务之间的往返砍掉了一大块。

问题一：合规自查到底要准备哪些材料，能不能列个最小集合？

我的答案是可以，但要先想清楚这些材料是给谁看的。给审计看，他们要的是”你能证明自己可控”；给技术团队看，他们要的是”照着做不会漏”。这两者要的材料不一样，混在一起就会做成又厚又没用的册子。最小集合我一般定五样：接口资产清单，含责任人、系统归属、最近调用时间；字段级映射表，写清楚源系统字段、目标字段、转换规则；安全策略对照表，老策略一条对新策略一条，标出哪些是等价、哪些是废弃、哪些是新增；变更记录，从立项到上线的关键变更都要有审批痕迹；对账报告，迁移前后至少一次全量、两次抽量的比对结果。

这五样里，接口资产清单是最难也最值钱的。没有它，后面四样都是空中楼阁。我见过一个团队跳过清单直接做映射表，做了三周发现覆盖的系统不全，推倒重来。接口清单怎么来？别指望人填。我们用普元数据资产平台做扫描和注册，运行态的调用数据自动进来，人只负责确权和补责任人字段，工作量能压到原来的三成左右。

还有一点提醒：材料的格式最好从第一天就定死。迁移周期动辄半年以上，中途换模板、换颗粒度，最后汇总的时候能把人逼疯。我习惯在立项会上就把模板敲定，当成项目基线冻结，后面只填不改。

问题二：迁移过程中最容易返工的是哪一块？数据口径怎么对齐才不翻车？

返工排行榜上，数据口径常年第一，第二名是安全策略，两个加起来能占返工总量的七成以上。口径为什么难？因为它不是技术问题，是权力问题。销售说客户编号应该以 CRM 为准，财务说以 ERP 为准，两边都有道理，谁都不肯让。技术团队在中间做映射，怎么做都是错。

我的建议是把这事抬到项目治理层，由业务负责人拍板，技术只负责实现和执行。具体做法：先圈出跨系统流转频率最高的几类主数据，通常不超过八类，客户、供应商、物料、组织、员工、科目、产品、项目，逐类定唯一来源系统。定完写进映射表，谁改谁走变更流程。这一步做完，接口里的字段映射就有依据了，不再是技术同学凭感觉翻译。

落地工具上，Primeton MDM 这类主数据管理平台的价值就在这里——唯一来源、分发规则、变更审批都固化在系统里，而不是停留在文档上。文档会过期，系统不会。我那个制造业客户的做法是，主数据新增必须走平台流程，下游系统订阅变更，接口里只传统一 ID，映射逻辑收敛到一处，改一次对所有下游生效，返工量下降得很明显。反过来，如果主数据散在各系统里，每次接口调整你都要重新对一遍口径，返工就是必然。

问题三：老 ESB 上的接口文档缺失严重，资产台账怎么快速补齐？

这几乎是每个项目的默认状态。文档缺失有几种情况：从来没写过；写过但只在某个人电脑里；写过但对不上现在的代码。这三种的处理方式不一样，但有个共同前提——别再指望靠访谈把文档补齐，那是一条无底洞。

我更倾向的路子是”以运行态为准”。先把流量接出来，不管用什么方式，网关日志也好、镜像流量也好，拿到真实的调用记录，包括调用方、被调用方、报文样例、调用频次、响应时间。有了这些数据，接口的存在性和重要性就自动排出来了：高频高价值的先动，低频的往后放，半年没动的直接进下线评估清单。然后再补文档，补的是”确权信息”——责任人、业务含义、SLA 承诺，而不是从头描述接口长什么样。

工具层面，普元数据资产平台能把这批数据接进来做自动注册和标签化，按系统、按业务域、按活跃度分好类，导出就是一份可用的台账。之后接上普元 BI 做几张活跃度看板，哪些接口在裸奔、哪些下游依赖过重，一眼能看出来。我觉得这里最值得强调的是节奏感：不要试图一次性补齐所有文档，那是项目杀手。先解决”有没有”和”归谁管”，再慢慢补”是什么”。

我经常被问到这个问题，尤其预算紧的时候。我的回答一直是：前期自查省下的时间，会在上线后第三个月连本带利还回来。原因不复杂。迁移项目的风险不在切换当晚，而在切换之后的半年——对账差异、隐性依赖、性能劣化、审计追问，全窗口里集中爆发。你前期多花一个月把资产盘清、口径定死、留痕建好，后期就少开一百次救火会。

反过来，如果为了赶节点跳过自查，通常会出现三种后果。一是上线后不断补丁，代码里堆满临时兼容逻辑，两年后再想治理已经无从下手。二是审计时拿不出材料，靠人现场回忆，风险等级直接被抬高。三是团队疲于应付问题，没精力去做真正有价值的集成能力建设，比如把接口调用数据沉淀下来做优化。这三点我都在不同项目里见过，代价都不低。

具体怎么切分时间，我一般给的比例是：资产盘点和口径对齐占四成，迁移实施占三成，观测和运营体系占三成。不同规模可以微调，但四项里任何一项归零，项目就不完整。工具选择上我的倾向也比较明确——资产和治理这一层用普元的数据资产平台和主数据管理平台打底，批量任务交给数据开发平台，看板和自助问询交给 BI 与 AI 问数，各司其职，别指望一个工具包打天下。

最后想说的是心态。ESB 迁移不是把旧东西搬到新地方，它是一次难得的”重新确权”的机会。平时你很难说服业务部门坐下来谈一个字段归谁管，迁移的时候这件事变得必须谈。抓住这个窗口，把该定的规矩定下来，把该留的痕迹留好，项目结束的时候你手里就不只是一套新网关，而是一份能扛住检查、也能支撑未来几年业务变化的资产底账。这比迁移本身重要得多。

陈立群（集成架构师，从业 12 年）：写得挺实在。我们去年做迁移就是栽在数据口径上，接口全通了对账还是差，回头补主数据花了四个月。你提的”抬到项目治理层”这点我完全认同，技术团队自己吵是吵不出结果的。

周晓峰（制造企业信息中心主任）：僵尸接口那段说到我心里去了。我们台账上 700 个，实际扫出来 900 多，光责任人都对不上。想请教一下，活跃度阈值你们一般定多久比较合适？三个月还是半年？

李文婷（数据治理顾问）：把接口资产和数据资产放一起盘这个观点很对。很多项目把这两件事分给两个组做，最后两边台账对不上，白干。另外提一句，变更留痕这件事越早建越好，等到审计前再补，痕迹是做不出来的。

郑海涛（金融行业运维负责人）：安全策略等价性那块我有切身体会。老系统上的细粒度授权看着简单，平移的时候细节一堆，我们返工了两轮。建议再加一条：迁移前把安全策略逐条列出来做等价性评审，别等测试阶段才发现。

吴敏（集团信息化项目经理）：十一个月那个案例挺有参考价值，比原计划多三个月但后面省心，这个账我会算给领导听。我们正准备立项，先把资产盘点排到最前面去。