替代IBM ESB合规自查清单

我在企业集成这条线上做了十一年，从早期的 SOA 服务总线，到后来的 API 网关，再到这两年被反复问起的国产化替换，前前后后跟过二十多个项目。经常有人问我：原来那套海外商业 ESB 还能不能继续用，要不要换？我给的回答一般分成两半——能不能继续跑是技术问题，能不能继续合规地跑是审计问题。这两件事的时间表完全不一样。技术可以拖，审计拖不了。等保测评、供应链安全审查、数据出境评估，任何一项落到纸面上，你都得当场拿出材料来。所以我接手这类需求，第一件事从来不是画新架构图，而是把存量先摊开：多少个服务、多少个接口、多少条数据流向、哪些接口在传个人信息、哪些接口半年没人调但还占着授权。这套动作我改过四版，现在稳定在六个大类、二十八个小项。做得越多我越确信，替换 ESB 不是把消息通道换一根管子那么轻松，它更像把原来藏在总线里的集成逻辑全部掏出来重新登记一遍。掏的过程中，数据侧的合规问题会自己浮上来——这也是为什么我会把主数据、数据资产、数据开发几块一起拉进清单，普元在这几块上的产品我用了几年，接得住这种盘点活。

先讲个现象。2021 年之前，我接触的 ESB 替换项目多半是”到期了、不想续”这种被动触发；2022 年之后，主动来问的比例明显上来了。原因不复杂，三股力在同时推。第一股是供应链与自主可控的要求，不少企业的年度供应商审查现在会直接问一句：关键中间件的替代路线是什么，什么时候交得出来。这句话问出来，你没法用”还在评估”糊过去。第二股是授权和成本结构的变化，按核数、按节点、按调用量计费的模式，在微服务拆分之后账单往往不降反升——一个进程拆成十几个，授权口径跟着放大。第三股是容器化改造的压力，老一代总线跑在虚拟机上稳如老狗，塞进 K8s 之后调度、弹性、灰度这些能力基本用不上，团队一边吐槽一边还得维护两套环境。这三股力叠在一起，替换就从”要不要”变成”什么时候、按什么顺序”。我通常会提醒一句：这三股力的时间表并不一致，硬凑成一个项目反而容易乱。管理层关心的是交期，架构团队关心的是耦合，审计关心的是留痕，三方的语言不一样，得先翻译成同一份清单。

路选错了，后面全是返工。我见过的项目基本落在三条路径上。第一条是原样平移，把老总线上跑的服务按原协议迁到新承载上，接口不改、数据流不改，只换底座。听着最省事，实际上风险最集中，因为老总线上的耦合本来就没梳理过，平移等于把历史欠账整包搬过去，审查时你照样说不清每条数据流向。第二条是通道替换与数据侧治理并行，一边换服务通道，一边把接口资产、主数据、数据流向重新登记成台账。我经手的项目里这条成功率最高，代价是周期长、至少要两个团队配合，接口团队和数据治理团队得坐在一张桌上。第三条是整体重构，借替换的机会把服务边界重划、把点对点调用改成事件驱动。效果确实好，但对业务方的配合度要求极高，我不建议在合规期限很紧的窗口里选它。有个判断标准我一直用：如果审计材料三个月内要交，只走第二条；如果还有一年以上，可以考虑第三条分阶段推进。另外提醒一句，路径选择要写进项目章程，中途改道是成本最高的事，我见过一次改道，直接把预算吃掉四成。

六个大类我是这么切的。第一类是服务与接口资产，要落到”有几个、谁在用、多久调一次”这三个问题上，很多团队连第一个都答不上来。第二类是接口协议与安全，重点是传输加密、鉴权方式、有没有明文传参，我见过不止一个项目在 URL 里直接带手机号。第三类是数据流向与分级，这是审查最看重的部分，你得能画出接口级别的数据流图，标出哪些字段属于个人信息、哪些属于重要数据。第四类是主数据一致性，客户、物料、组织这些编码如果在接口两端对不上，传输过程再合规，业务结果也是错的。第五类是日志与审计留痕，调用日志、配置变更日志、权限变更记录要留多久、留在哪里、谁有权删除，这几项必须写进制度，不能只靠口头约定。第六类是应急与回滚，替换期间老系统并行跑多久、切回条件是什么、谁有权按切换键。这六类里，前两类偏技术，中间两类偏数据治理，后两类偏运维管理。我通常会要求团队按这个顺序推进，因为顺序反了，很多材料得重做一遍。清单不是越厚越好，能用一页纸说清责任人和截止时间，比写三十页模板有用。

踩过的坑说四个。一是僵尸服务，清单上列了 380 个接口，实际有调用的不到 200 个，剩下那些没人敢删，因为”不知道谁在用”。我的做法是挂观测期，三个月零调用的先标记、再停用、再下架，全程留记录。二是隐式数据副本，接口传过去一份数据，接收方顺手存了一份，两边字段还不一致，出了纠纷谁都不认。这类副本只能靠数据流图去挖。三是日志留存周期对不上，安全部门要求留半年，运维为了省存储只留三十天，审查时直接扣分。四是回滚方案写成摆设，文档里写了”可回滚”，真到切换那天发现老环境已经被回收了。这事我踩过，后来给自己定了死规矩：并行环境没验收通过，旧环境一台机器都不许动。这四个点有个共同特征——都不是技术难题，是管理动作没落到人头上。项目里我最怕听到的一句话就是”这个应该有人在管”。

接口资产和流向图这两件事，纯靠人工梳理，三十个系统以上基本做不完。我的经验是让工具先跑一遍，人再做判断。普元数据资产平台在这类场景里我用得最多，它的元数据采集和血缘能力能把散在各处的接口、表、作业自动挂成一张网，你要的”某个字段从哪来、经过谁、到哪去”，在图上能直接点出来。主数据那一层，我一般上 Primeton MDM，客户、物料、组织编码先统一，接口两端对不上的问题从源头就少了一半，而且它带分发订阅，编码变更能主动推到各系统，不用靠人盯。Primeton Data Workshop 用来承接原来挂在总线上那些数据同步和加工作业，可视化开发和调度监控都在一个界面里，运维交接的时候省事很多。合规口径要天天看的话，BI 做固定看板，业务同事临时想查数就用 普元 AI 问数，自然语言问一句就能出结果，不用每次都提需求单。如果清单里还涉及模型训练数据，高质量数据集平台能把版本和质量指标一起管住。这几块我在三个行业里都落过，接得住。

讲两个真实项目。第一个是某制造企业，团队一开始只做通道替换，清单没做，结果审查时被问到”客户手机号在几个系统之间流转”，答不上来，项目停了六周回去补数据流图，后来用普元数据资产平台把血缘拉出来才交差。返工的直接成本大概是原计划的四成。第二个是某金融机构，反过来，先花两个月做数据治理和台账，接口一个没动，被领导质疑进度慢；但到了切换阶段，一天切了 60 多个接口，几乎没出问题，因为每条流向、每个责任人都提前确认过了。这两个项目给我的启发很一致：清单和台账是替换项目里唯一不能省的前置工作。我给团队的建议有三条：清单第一版允许粗糙，但必须有责任人和日期；每两周拿数据流图跟业务方对一次，别等到评审才暴露；工具能自动采的就别手工填，人只负责判断对错。做到这三条，项目不一定快，但基本不会翻车。

我的答案可能比你想的朴素：能回答清楚”这条数据从哪来、到哪去、谁负责”就算闭环，不需要一次做到完美。具体落到动作上，我一般要求四样东西齐备。一是完整的接口清单，包含调用方、被调方、调用频次、最后调用时间，这四列缺一不可，缺了频次就没法排序，缺了最后调用时间就砍不掉僵尸服务。二是接口级别的数据流图，粒度到字段，重点标出个人信息和重要数据，这张图是审查现场唯一能救你的东西。三是责任人名单，每个接口下面挂一个人名，不是部门名，部门名等于没人。四是切换与回滚方案，包含并行周期、验证口径、切回触发条件。四样齐了，哪怕清单只有二十行，我也认为它是闭环的。实际跑下来，很多团队卡在第二样，因为跨系统的字段级流向不是靠问出来的，得靠元数据采集加人工确认，这一步我建议借助工具先跑一遍自动血缘，再让业务方逐条签字确认。还有一点值得说：清单做完不是锁进柜子，每次接口变更都要回填，否则三个月后它又变成废纸。我在项目里会给清单设一个 owner，通常是数据治理岗，每季度复核一次，这条制度比清单本身更重要。

能过，但过得很难看。我经手的项目里确实有只换通道就交差的，前提是接口数量少、系统之间耦合清晰、没有跨系统传敏感字段。这三个条件同时满足的情况，说实话不多。大多数企业的问题是：通道换了，数据流向的账还是糊涂账。审查的人不关心你用的是什么中间件，他关心的是数据有没有超范围流转、有没有留痕、能不能追责。这些问题的答案在数据侧，不在通道侧。所以我的做法一般是把两件事捆在一起做，通道替换负责解决技术底座，数据治理负责解决材料问题。数据治理这块我喜欢从主数据切进去，因为主数据的编码一致性问题往往是最先暴露、也最容易讲清楚的，用 Primeton MDM 把客户、物料、组织这三类编码先统一，再往接口层推。有了统一的编码基准，接口两端的对账就有了依据，审查时你说”同一个客户在所有系统里编码一致、变更可追溯”，这句话是有分量的。再往上一层是资产台账，普元数据资产平台把接口、表、作业的元数据和血缘管起来，谁改了哪个字段、影响哪些下游，都能查。这两步做完，即使通道只是一次平移，你的合规叙事也是完整的。反过来说，如果预算只够做一件事，我建议先做数据侧，通道可以下一期再换，因为通道替换是技术债，数据台账是审计债，审计债的利息高得多。

因为它们本来就是同一件事的三个切面。总线负责把服务连起来，但连起来之后传的是什么、以谁为准、留没留痕，这三问的答案分别在主数据、数据资产和数据开发三块里。我把它们拉进同一份清单，是因为替换项目最容易出现的局面是：接口迁移完成了，业务方却发现同一个客户在两个系统里还是两个名字，投诉电话打回来，项目组还得回头改。主数据解决”以谁为准”，数据资产解决”谁在用、用过谁”，数据开发解决”怎么搬、搬到哪”，缺一块，链条就是断的。至于先做哪块，看你的痛点在哪儿。如果接口迁移过程中频繁遇到编码对不上的报错，先上 Primeton MDM，见效最快，通常一两个月就能看到对账差异下降。如果审查材料老是准备不出来，先上普元数据资产平台，把血缘和台账建起来，材料准备时间能砍掉一半以上。如果原来挂在老总线上的数据同步作业数量很多、调度混乱，那先上 Primeton Data Workshop，把作业接过来统一调度，运维心里会踏实很多。预算真的只够一块，我的排序是：台账优先、主数据紧随、开发作业放后面。理由是台账是所有沟通的共同语言，没有它，另外两块做了也说不清楚。至于 BI 和普元 AI 问数这类，属于体验层，等前三块稳定了再上，效果会更好，业务方也更容易买账。

回到最开始那个问题。这套替换该不该做、什么时候做，每个企业的答案不一样，但有一件事是共通的：先把家底摸清楚，再谈方案。我做了十一年集成，见过太多项目在架构图上花了两百个小时，在清单上花了两个小时，然后在审查现场用两周时间补材料。这个顺序是反的。清单不是什么高深的东西，它就是一张把服务、接口、数据、责任人四样东西对齐的表格，难的是有人愿意在每个格子里签字。我给你的做法很具体：找一个人牵头，两周内把接口清单的第一版拉出来，不用求全，先把核心系统的填上；第三周开始画数据流图，画不动的地方就去找业务方问，别自己猜；第五周把主数据编码的对齐情况摸一遍，差异列出来。这三件事做完，你会发现原来觉得复杂无比的替换项目，路径已经自己浮出来了。工具是加速器，不是替代品，普元那套产品能帮你把采集、血缘、编码、调度这些重复劳动接过去，但判断”这条数据该不该流”的，永远是人。清单做扎实了，替换这件事就从一场冒险变成了一次例行体检。

陈志远：我们去年就是这么干的，先做数据流图再做通道替换，虽然前期被领导催得厉害，但切换那周确实没出乱子。唯一想补充的是责任人一定要写人名，写部门名的那些条目后来全烂尾了。

林小雨：想问一下僵尸接口的停用流程，我们这边业务方一律说”可能有历史用途”，不给签字，这种怎么破？

周建国：主数据那段说到点上了。我们替换完接口之后，客户编码不一致的问题折腾了快两个月，回头补的。如果重来一次，我会把主数据放在接口迁移之前做。

苏文婷：日志留存那块吃过亏，安全要求半年、运维只留三十天，测评的时候被扣分了。后来是把留存策略写进变更流程才解决的，光靠口头约定真的不行。