【保姆级方案】 担心平台切换影响业务使用？来看阅文数据平台切换秘籍

丨导语丨

任何企业系统都会面临切换，每次切换都会在所难免遇到各种问题，如何在切换过程中保证业务的无感和稳定使用？并且系统切换后，在系统使用习惯改变而带来的“阵痛”下如何用新的系统为业务带来价值，都是本篇文章要重点传递的信息。

系统改造背景

阅文大数据平台报表系统最初使用的是SHOW系统，由2015年投入使用，历时7年，承载了阅文司内十余条业务线，各个职能部门的所有报表。但由于SHOW系统后续迭代慢且没有团队持续维护，面临着下线的终点。面对这一情况，阅文亟需寻找一款产品替代SHOW成为新的公司级报表平台，这款产品不仅要符合当前业务形态、使用场景，并且需要足够先进，且支持可持续性的迭代发展，顺应业务不断生长的分析和洞察诉求。在已有上述需求框架的基础上，阅文本着在公司侧“降本”，在用户侧“增效”，历经多种平台调研之后，选择了用新一代BI产品DataTalk来承接内部报表平台的角色。

面临的挑战

完成了平台产品的选择之后，旧系统下线之前，如何在不影响全公司业务正常使用的情况下，平滑迁移并保证迁移过程中所涉及的报表质量、安全、数据一致性等多个方面不出问题？且在迁移完成之后，如何确保报表信息准确和完整，同时严控权限，防止迁移过程中造成报表权限的放大或缩小给业务带来风险？与此同时，面临着旧系统下线时间点的限制，加上存量报表数量庞大（4000+），报表迁移可谓是难上加难。 

面临困难最好的办法就是，直面和突破，虽然问题看起来都很庞杂，但是总需要整理出对应的关键路径和解决方案。于是在有限的迁移时间下，开发出一款便捷高效的迁移工具解决上述所有问题，显得尤为重要。因为平台级的切换涉及的细节项很多，需要代入项目管理的思维。

►►►

一期（1个月）：平台对接信息梳理

1、历史报表目录梳理，包含废弃报表以及业务组的梳理；

2、对应角色组权限的梳理；

3、系统对接接口及功能需求梳理；

►►►

二期（2个月）：细化功能需求，产品需求排期

1、精细化权限控制设计与开发；

2、一键迁移脚本的开发；

3、功能需求排期及对应的应用解决方案；

►►►

三期（2个月）：平台平滑切换，深化应用场景

1、批量迁移存量历史报表；

2、历史平台定时下线；

3、阅文灵活频繁的应用DataTalk；

4、插件式的共建开发功能组件；

脚本设计与开发

一

问题与现状分析

产品定位不同：

SHOW：是一款使用便捷的报表平台，支持多种数据源类型，并且可以进行视图配置，视图可视化，可挂载在其他平台，同时可以进行定制化推送。

DataTalk：含义是用数据(Data)去对话(Talk)，是数据分析与可视化展示的纽带，支持不同用户角色，支持多种数据源，由近百种可视化组件构成，可以多端消费（PC、大屏和移动），且支持告警、订阅和推送的一款BI可视化产品。

系统切换所面临的挑战：

1）兼容问题

SHOW平台与DataTalk平台从架构与功能实现上来看是两个完全不一样的系统，在报表配置上也存在很大差异；DataTalk能否覆盖SHOW上所有功能点，关系到SHOW报表能否完整地迁移过去。

2）效率问题

如果靠盲目地堆人力去手动迁移报表，工作量是巨大的，必须要通过迁移工具来最大限度地减少人力介入，提高系统迁移效率。

3）安全问题

已有系统权限如何对齐，如何保障迁移后用户报表权限无变化也变得尤为重要。DataTalk系统功能权限与业务权限和业务内容权限区隔的设计，可以很好地满足新系统权限承接。

4）标准问题

• 报表迁移不是短时间能够完成的，如何保障在迁移过程中，用户能够正常使用报表；
• 如何做好备份：如何保障在迁移过程中报表不会丢失；
• SHOW配置里面有很多研发自定义配置，数据打通和整合过程中会出现很多兼容性问题，如何定义统一配置规则兼容这些自定义配置？

5）质量问题

• 迁移完的报表在功能上是否有丢失；
• 报表数据准确性有没有保障；
• 业务使用和操作习惯上是否有较大出入。

二

迁移思路

报表迁移涉及两个平台的产品、研发和业务等各方协调。我们迁移方案划分以下几大部分：标准化、组织保障、工具建设和运营效率。通过这一系列实现的关键路径，来保障平台切换以及报表迁移的最终完整落地。

1）标准化

标准化包括两个方面：流程制定和标准执行

• 在流程制定上，我们分几个阶段性里程碑，每个阶段都会划分任务明细，每个任务都明确负责人，完成时间和风险点。
• 标准执行，需要保证替换一个正常的SHOW报表，需要确认报表菜单、权限、功能完整和展示正常。

2）组织保障

报表迁移涉及跨公司合作，部门与部门间的沟通，在推动和执行上，阻力也会比较大。成立公关小组，负责技术攻关、业务沟通、系统功能推进、问题答疑等。

3）工具建设

迁移工具建设涉及的报表应用场景比较多，需要沟通协作的地方也很多，除了需要通过组织和流程来保障项目正常开展，我们也考虑通过技术系统化和自动化的方式进一步提效，让系统代替人工，尽量避免开发人力介入。

我们通过拆分整个迁移流程，先小批量迁移，提前暴露存在的问题，通过DataTalk功能持续迭代和迁移工具对各种场景兼容，来适配绝大部分报表配置。

4）运营效率

小组成员日常工作主要包括两大部分：平台功能推进和平台运营。平台功能推进就是上面介绍的迁移工具建设和DataTalk功能迭代，平台运营是另外一大类工作，主要时间投入到DataTalk报表使用咨询和报表问题答疑。

投入很多时间在平台运营主要是新报表平台对于研发和业务同学来说，都有使用和学习成本；以及两平台存在功能差异，使用习惯，导致的系列问题。主要体现在下面三个方面:

• 配置难：一个复杂的新报表,研发如何快速配置?
• 细节功能差异：两平台在细节功能上的差异，比如数量限制，排序等等，引发使用习惯的冲突。
• 不会用：新用户如何进DataTalk平台？如何申请权限？如何能够快速查询到自己想看的数据？有问题找谁解决？

为了帮助用户能快速适应DataTalk平台，通过文档、客服、产品、技术等组合方式快速解决用户遇到问题。

三

整体技术架构

整体的技术设计根据两平台实际现状、业务要求，先易后难的原则，大致分为五大部分：

1）SHOW平台数据层

• SHOW报表配置数据：所有报表的配置信息，包括筛选信息、业务逻辑、数据源、输出信息等；
• SHOW报表权限数据：包括用户信息、菜单信息、角色信息。

2）迁移数据层

• SHOW报表数据：对原始SHOW配置信息进行清洗和整理；
• 权限数据模块：两平台对于用户认证模式不一致，鉴权方式不同，需要对用户、菜单、角色进行重新整理和映射；
• 空间拆分数据模块：历史SHOW报表存放同一个业务平台，迁移到DataTalk后，根据业务需求，拆分成不同的业务空间，对应的用户权限和菜单目录都需要重新进行构建；
• 平台报表问题映射模块：迁移过程中会对转换后的DataTalk报表进行功能检查，并记录问题类型，统计公共问题并进行转换工具兼容。

3）迁移逻辑层

• 解析SHOW报表配置：SHOW配置是XML格式，DataTalk配置是JSON格式，需要进行一步配置解析，并转换成JSON格式；
• 构建DataTalk报表配置：不同业务场景下组件自定义组合，构建不同的配置格式；即根据解析后的SHOW配置构建对应业务场景下的DataTalk配置；如遇到不兼容的场景，通过DataTalk功能迭代或者工具兼容来实现；
• 模拟DataTalk报表增删改查流程：在DataTalk平台新建一张报表，需要经过新建、编辑、删除、移动等操作；迁移工具模拟这些人工操作，减少开发介入这些重复操作；
• 模拟DataTalk权限增删流程：一个SHOW报表替换成DataTalk报表以后，对应新报表权限要与SHOW报表保持一致。

4）接口层

该模块是对各子功能进行再次封装，适应不同场景下转换需求。

5）迭代与问题反馈

四

报表迁移

我们从技术角度验证了迁移方案的可行性和时效性，但是几千张报表的迁移，我们会遇到很多实际问题。为防止出现大量因迁移导致的报表问题，我们制定了比较稳妥的迁移方案。

1）数据准备

在跟各业务进行充分沟通后，对历史报表菜单结构和用户权限进行拆分；并对用户与报表关系进行重新构建，方便在DataTalk上统一初始化权限；

2）初步体验

为了用户能快速适应新平台，解决两个平台并用造成报表配置不一致的问题，在DataTalk上进行SHOW报表挂载，可以解决如下几个问题：

• 方便权限迁移，可以全量初始化一次；
• 可以使用户快速熟悉DataTalk平台功能；
• 在没有正式迁移报表前，对业务使用影响最小；
• 方便后续批量替换。

3）分批次替换

• 下线老平台用户权限，只保留一个DataTalk入口；
• 对SHOW报表进行分类，按类型小批量进行替换挂载SHOW报表，在用户使用过程中发现隐藏问题或者优化点；

4）全量替换

• 对所有的SHOW报表进行全量转换，存放临时目录，并对所有报表进行检查并打标签，转换成功或者异常；
• 替换能够转换成功的SHOW报表；
• 人工修复少部分异常报表并替换。

5）收尾

• 集中处理替换异常报表；
• 报表推送功能迁移；
• 持续迭代DataTalk功能。

五

切换后的深度应用

在系统完成切换之后的一定周期内，肯定会有源自于不同系统使用习惯带来的声音和反馈。如何让新系统在业务使用场景中发挥最大价值，也需要逐步去突破：

1）系统性培训

• 基础使用功能培训
• 产品使用手册及数据消费场景整理
• 业务可一键克隆应用的模板
• 多端消费、协同办公应用场景

2）系统性整理说明文档

• 注册流程
• 权限管理及配置说明
• 业务空间及报表消费路径
• 数据指标说明

3）结合业务应用场景开放式共建

利用平台的开放式架构进行插件式的共建开发功能组件，满足业务不断生长的业务诉求。

写在最后

在通过这样一个迁移脚本引发的思考与技术分享之余，大家也可以看到在 TO B 的数据平台应用过程中，切换是一个成本比较大的事情，但是每个企业随着自身的发展，以及平台技术的迭代和更新，系统更迭更换也是必不可少的。不同系统的技术方案不同，但是对于业务可用性的保证，以及结合企业和业务情况进行的平台产品选型的底层逻辑都是一致的。数据平台产品要通过数据为业务产生价值，用数据赋能工作，进一步帮助业务实现增长。

阅文平台切换后的一些数据：

• 报表/仪表盘总量：4000+
• 平台月均访问量：工作日10000+/日
• 平台周活跃用户数：400+/周

DataTalk便捷了阅文集团内员工的信息展示和沟通，同时为管理决策层提供了有力的数据支持和决策保证。