网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

第三是平滑迁移的能力。迁移的过程中保证业务不停，同时要高度兼容，节省调试时间。马波勇谈到：“太保集团作为32年的国企，数据量及业务量都很大，如何在有限的时间窗口，完成数据迁移，成为摆在太保集团面前的一大难题。”

那么，这三座“大山”，太保和OceanBase是如何携手跨过的？

最难的P17系统，

OceanBase如何搞定？

OceanBase所升级的太保P17核心系统，同时面临着上述的三座大山。

在太保的业务系统中，有P20的级别之分，P17是集团排名中的高级别，因此，该系统的成功升级具有标杆作用和里程碑意义。“P17客户服务系统”是太平洋(601099)保险产、寿、健康、长江等所有子公司客户服务系统的整合，为公司6地8个电话中心超过2000坐席提供系统服务。”太保集团数智研究院首席数据库专家林春介绍道。

“与一般热线系统相比，‘P17客户服务系统’涵盖了太平洋保险几乎所有子公司业务的服务入口功能，包括车险报案、车险增值服务、非车人意报案、道路救援、寿险保单查询、寿险保全受理、投保预约等等，对接周边系统超过200个，是太平洋保险关联关系最为复杂的系统之一。”

同时，作为太平洋保险的服务品牌，“P17客户服务系统”需要提供7*24?时的全天服务，系统可?性要求全年99.9%以上，对停机时间有着严苛的控制。因此，也是太平洋保险运维保障最?的核?系统之?。

毫无疑问，对于P17的升级，是最为慎重的决定。2021年初，太保对国产分布式数据库，从功能、性能、易用性、完整性、可移植性、可靠性、扩展性、安全性等指标进行了全方位评估，最终选择了OceanBase升级传统数据库。

2022年上半年，在不少项目暂停、放缓之时，太保和OceanBase正在紧锣密鼓的远程协作，加班加点，只为搞定P17。

据林春回忆，2022年初启动项目到8月31号，核心业务场景就完成了数据功能的开发；12月18日，P17第一个子系统成功上线，并完成了全量数据库迁移；2023年5月6日，核心交易、相关的报表库迁移上线；5月13日核心系统中最难的核心交易库上线。至今，P17核心系统已经成功运行了200多天，确保交易成功率达到99.99%。

“项目刚开始时，正是上海管控最紧张的时刻。大家没办法到场地，造成了很多困难，但是OB在产业侧和技术侧联合攻坚，把这块硬骨头啃了下来。”林春谈起到项目的全过程，仍然不禁感慨。

OceanBase的系统整体架构图

整个升级的流程，可以分为四个阶段：

第一阶段的重点，是通过OceanBase的分布式架构彻底升级传统商用的主备架构，破除传统数据库与操作系统、中间件的耦合。据了解，与Oracle配套的DS、Cognos等产品对于Oracle深度依赖，适配改造复杂度很?，将数据库分库分表，从集中式拆分成分布式，每个分片都能够独立执行读写，这个过程中需不断拆解中间件和操作系统之间的关系。

第二阶段，OceanBase和太保并没有急着对业务进行升级，而是建立了迁移“标准”，一次次探索形成行业经验，破除替换升级的壁垒。

OceanBase华东区金融技术服务总监郭文讲道：“厂商和用户侧的目标是希望效果稳定的与传统数据库兼容，标准化、流程化、制式化能够降低双方的人力投入，少走弯路，同时能够复制工具和经验。”

郭文介绍道：“OceanBase通过制定33类标准规范和28类最佳实践，以及打磨了16款数据库转向工具，实现了标准化的Oracle兼容，这会极大程度破除迁移的不透明性，让企业更有信心，意识到升级不再是一件特别困难的事情。”

比如创新研发的“指南针”工具，能够对传统数据库进?改造评估预扫描，包括近20个检查?类，近200多个检查项，评估项全??效，极?提升项?组问题排查的效率，缩短项?周期从?降低应?改造成本。以“P17客户服务系统”为例，扫描出改造项约6000个，假设???式排查2个问题/?时，单个项?即节约??成本12.6?/?。

第三阶段，对P17中的业务场景进行逐个点测。对寿险保监会稽核接口系统、寿险营销员系统的佣金计算、智能决策服务平台和寿险统一承保平台等“一事一议”的替换。

第四阶段，从点测到全面替换。这里的全面替换，并不只是P17系统的全面替换，而是太保秉持着“先难后易、应替尽替”的原则，以P17这套最复杂的系统为模版，对太保几百套系统进行分布式替换。