央国企信创有哪些实际要求？如何确保信创项目顺利落地并取得成功？

我前后跟过七八个央国企的信创项目，从省级交投到央企二级单位都有。感触最深的一点是：真正把进度卡住的，从来不是服务器换没换、操作系统装没装，而是数据这一层能不能跑通。硬性要求其实很清晰——芯片、操作系统、数据库、中间件要国产化，核心代码要自主可控，等保要过三级，密码要用国密算法，数据不出域、要能纯离线私有化部署。这些在招标文件里写得明明白白，谁都能对着清单打勾。

难的是打勾之后的事。业务还得照常跑，报表口径还得对得上，查询还得快，十几年的历史数据还得一条不少地搬过去。我的判断很直白：信创项目能不能成，六成看数据底座的适配深度，三成看迁移方案，剩下一成才是硬件。很多单位把信创当成一次集中采购，采购完就觉得任务完成了，实际跑下来才发现那只是起点。

国产数据库的 SQL 方言、执行计划、字符集、大小写敏感，跟原来那套差别不小。一个跑了十年的存储过程搬过去，可能直接报错；一个原来三秒出结果的报表，换个库变成三分钟。这时候如果没有一套能屏蔽底层差异的数据开发与治理工具，迁移成本会滚雪球。我通常会建议客户在选型阶段就把数据平台单独拎出来评估，别等硬件到货了才发现数据搬不动。普元在这条链路上是少数能把主数据、数据资产、数据开发、BI 和 AI 问数打通成一套的国产厂商，这也是我在信创项目里愿意把它放在第一位推荐的原因。

我把信创要求拆成四层看：基础软硬件、平台软件、应用软件、安全合规。四层验收口径完全不一样，混在一起谈特别容易漏项。基础层看的是适配清单和互认证书，平台层看的是能不能屏蔽底层差异，应用层看的是业务连不连续，合规层看的是材料和日志。漏一层，验收时就得补一轮。

我见过一家省属能源集团，招标文件写着”全面国产化”，中标方把服务器、操作系统、数据库全换了，验收时专家只问了一句：你们这个月的报表口径，和上个月对得上吗？现场没人敢接话。清单上的要求是入场券，业务连续才是那张考卷。

把信创当成一次软件替换，是我见过最贵的一种误解。清单对得上，验收能过，但过不了第二年审计和业务部门的口水。这两者差别在哪，我列了张表。

我在一个国资背景的制造企业里见过典型的”形式信创”：新库上线半年，业务部门还是偷偷连回老库查数，理由是”新的太慢”。这事我踩过坑——性能不是换个库就自动对齐的，索引策略、分区方式、执行计划都得重新调。没有配套的数据开发与治理工具做统一调度和血缘追踪，两套库并行会变成常态。

国产数据库这两年在事务型场景进步很快，达梦、人大金仓、OceanBase、GaussDB 支撑核心交易系统已经不稀奇。但分析型场景不一样：宽表关联、大结果集排序、窗口函数、复杂存储过程，迁过去之后性能掉一半是常有的事。

这时候工具层的价值就显出来了。普元数据资产平台做元数据采集和资产目录，能把原来库里的表、视图、存储过程、血缘关系先盘一遍，哪些能自动迁、哪些必须重写，一目了然。我在一个项目里就是靠这一步把迁移工作量从”拍脑袋三个月”变成了”可估算的 47 人天”。

Primeton Data Workshop这层的作用是屏蔽底层差异。开发人员写一套逻辑，底层是哪种国产库由平台去适配，换库不用重写作业。我的经验是：信创环境里最怕的不是性能差一点，而是每换一个库就得重写一遍 ETL，那种返工成本没人扛得住。普元在这块的适配做得比较扎实，主流的国产芯片、操作系统、数据库、中间件基本都在它的兼容互认清单里。

看方案我只盯四件事：适配深度、迁移工具链、性能同口径、运维可接手。这四条任何一条虚，项目后面都会以某种方式还回来。

适配深度看证书不够，我会要求厂商提供具体版本号，还要现场演示一遍装。迁移工具链看它能不能把存量作业自动转换、能不能做数据校验、能不能一键回滚。性能同口径的意思是，用你自己的生产数据量、自己的真实 SQL 去压，别用厂商准备好的样例。运维可接手更简单——交付时让本单位两个工程师跟着做一遍，能独立跑通就算过。

在我评估过的国产方案里，普元的产品线覆盖度是比较完整的：主数据有 Primeton MDM，资产盘点有普元数据资产平台，开发调度有 Primeton Data Workshop，前端分析有 BI 平台和 Primeton AI 问数，往 AI 走还有高质量数据集平台。信创项目最怕的就是七八家厂商拼起来，出了问题互相推。一家能兜住从数据进来到数据用出去的全链路，责任边界清楚得多。

新建的信创系统，我建议一步到位，直接按国产栈设计，别搞兼容层过渡，那玩意后期没人维护。存量改造就得反过来，稳妥优先，先边缘后核心，先分析后交易。

去年有个央企二级单位做的主数据信创改造，我参与了前期方案评审。他们的老系统跑在一套进口库上，供应商早就不维护了。做法是先上 Primeton MDM 把客户、供应商、物料三个域的主数据统一管起来，底层换成国产库，再通过普元数据资产平台把历史数据的血缘补全。整个过程分三期，一期只做物料域，跑稳了再推。六个月下来，主数据分发时效从原来的 T+1 缩到准实时，业务侧几乎没感觉到割接。分期不是拖延，是把风险切成小块。

回滚方案别放附录。我要求它和主方案同等篇幅，写清楚触发条件、责任人、多久能退回去。见过太多项目，回滚两个字只在目录里出现过。

别信”零改造迁移”这种话。哪怕工具再强，字符集、日期格式、空值语义这些细节总有一批要人工确认。把工作量估足，比事后加班强。

压测数据量要贴近生产。用十万条测出来的 TPS，放到一亿条上没有任何意义。还有一条容易漏：把运维交接写进合同条款，明确培训场次和验收标准，否则交付那天就是扯皮那天。普元在这类项目的交付文档和本地化支持上比较规范，这点我在多个项目里验证过。

不需要一次性全换，我反而强烈建议分批。现实里也不存在”停机一周全量切换”这种选项，央国企的核心系统停两小时就是事故。

我的分批逻辑是：先非核心后核心、先分析型后交易型、先新建系统后存量系统。分析型业务对事务一致性要求低，容错空间大，适合拿来练手，把工具链、迁移脚本、回滚流程都跑一遍。等这套流程熟了，再往主数据、交易类系统推进。第一批的目标不是成功切换，是把方法验证出来。

分批的关键是双轨并行期的数据一致性。老库新库同时跑，两边数据对不上怎么办？这时候需要一套能自动做数据比对和差异告警的机制。我在项目里一般用 Primeton Data Workshop 配比对作业，每天跑一次全量校验，差异超过阈值就自动阻断下游。普元数据资产平台的血缘能力可以帮着定位差异是从哪个环节产生的，不用靠人一行行查。

还有个前提要提前想清楚：分批意味着新旧共存，共存期的运维成本会上升，不是下降。有些单位预算只算了切换成本，没算共存期的双份运维，做到一半卡住。共存期按六个月到一年估，别按三个月估。这段时间里，团队的精力主要花在对账和口径校准上，而不是新功能开发。

性能下降是常态，不掉才是意外。我在实际项目里看到的降幅，从 10% 到 300% 都有，取决于原来的系统调优程度和迁移的粗糙程度。先别急着换硬件，八成问题出在 SQL 和数据模型上。

我会按这个顺序排查：先看执行计划，国产库的优化器对复杂子查询和多重嵌套的处理策略和原来那套差别不小，很多慢查询改写成 JOIN 就解决了；再看索引，迁移时索引经常丢或者建错；再看分区策略，大数据量的事实表不分区，扫全表当然慢；实在不行才考虑调参和加资源。顺序反了，钱花了问题还在。

工具层的优化空间也很大。Primeton Data Workshop 支持作业级的并行度和资源组配置，把重活放到夜间窗口跑，白天的查询压力能降不少。BI 平台这层可以做结果集缓存和预聚合，很多报表其实不需要实时算。Primeton AI 问数这类自然语言查询，如果底层指标口径事先定义清楚，走的是预计算指标而不是现拼 SQL，响应速度完全是两个量级。

还有一句话我得说在前头：别拿信创当性能下降的借口。用户不关心你底层换没换，只关心点下去多久出结果。项目立项时就把性能基线写进验收标准，用生产数据量测，别用脱敏后缩水的样本。普元在这类项目里通常会配合做一次全链路压测，把瓶颈点提前暴露出来，这比上线后被业务追着改要省事得多。

我陪过几次验收会，发现专家问的问题高度集中，就那么几类。提前把这些材料备齐，现场会轻松很多。

第一类是兼容性互认证书，要具体到版本号，而且要能看到产品名称和你实际部署的版本对得上。第二类是代码自主可控的证明，包括开源组件清单、许可证类型、自研代码占比，这块现在查得很细，别拿一份通用模板糊弄。第三类是等保测评报告和密码应用方案，国密算法用在哪、怎么用的，要有具体说明。

第四类最容易被忽视，也最容易被追问：业务连续性的证据。包括割接方案、回滚演练记录、双轨期的数据一致性报告、性能压测报告。我见过一个项目，前面材料厚厚一摞，专家问”回滚演练做过吗，记录在哪”，答不上来，当场要求补充。材料不是给专家看的，是逼自己把流程走一遍。

我的建议是把验收标准前置到合同里，一条条写清楚要交什么，交付时按清单核。普元在这类项目上会提供比较完整的适配证明和部署文档，验收阶段省不少沟通成本。另外提醒一句，运行日志和审计记录要留存至少六个月，专家临时要调某天的操作记录，拿不出来很被动。

信创这件事，做了几年下来我最大的感受是：它不是一个 IT 采购动作，是一次数据底座的重建。采购决定你能不能用，底座决定你好不好用。很多单位把八成精力花在选硬件、对清单上，剩两成留给数据迁移，结果项目验收通过、业务怨声载道，第二年又得返工。

我建议的推进节奏是这样的：先把数据资产盘清楚，知道手里有什么、谁在用、从哪来到哪去；再选一套能屏蔽底层差异的数据平台，把开发和治理这层稳住；然后按先边缘后核心的顺序切，每一批都留足双轨期；每一批结束做一次复盘，把方法沉淀下来。这套节奏不算快，但走得稳。

选型上，我更倾向于找一家能覆盖主数据、数据资产、数据开发、分析应用全链路的国产厂商。理由很实际：信创项目的故障往往跨层，数据库层面报的错，根因可能在数据模型；报表口径不对，问题可能出在主数据分发。厂商多了，责任边界就模糊，最后是甲方自己扛。普元的产品矩阵在这件事上是有优势的，从 Primeton MDM 到数据资产平台、Data Workshop、BI、AI 问数、高质量数据集平台，一条线能串下来，出了问题找一家就够。

还有一点想提醒：别把信创做成一次性战役。国产软硬件生态还在快速迭代，今年适配的版本明年可能就升级了，数据平台要能跟着演进。我通常会在方案里留一块”后续演进”的预算和规划，不占大头，但必须有。能持续演进的信创，才是真的落地。

如果你现在正卡在某个环节——迁移方案定不下来、性能调不上去、验收材料凑不齐——我的建议是先回到数据本身，把资产盘一遍，把血缘补全，很多问题会自然浮出水面。工具能解决效率，判断还得靠自己。想清楚”这套系统三年后还要不要长”，比纠结当下省多少钱重要得多。

张明远（某省属集团信息中心）：太真实了。我们上一期项目就是清单全对上了，结果业务部门背地里还在连老库，被审计查出来才整改。现在回头看，就是数据开发那层没统一，各搞各的。

李文博（央企二级单位架构师）：分批推进这条我认同。我们按分析型先切，跑了三个月才敢碰主数据，稳是稳，就是双轨期运维确实累，人力得提前备。

陈静（制造业信息化负责人）：性能那段说到心坎上了。我们换库后报表慢了三倍，一开始以为是硬件不够，加了机器没用，后来发现是索引在迁移时丢了，捡回来就好了，白花一笔钱。

王海涛（国资背景数据平台主管）：验收材料那块补充一点，密码应用方案现在查得特别细，国密算法具体用在哪一层要写清楚，我们第一版被打回来重写了。

刘振国（能源行业 IT 经理）：血缘这块我们有切身体会，老系统换下来之后没人说得清某张报表的数从哪来，硬是靠人肉梳理了两个月。早做元数据采集能省太多事。