作者：沙丘社区分析师团队
01
项目背景
为了落实集团科技创新的总体工作部署要求，湖北移动有序推动自主可控能力的规模化落地，其中，数据库作为数字经济时代的关键基础设施，是推进IT系统自主可控的关键路径，升级改造工作任重道远。
湖北移动以核心数据库升级为契机，落实IT系统全栈升级。总体实施原则是以稳定生产为前提、以应用改造为牵引，分阶段完成数据库自主可控升级工作，升级过程中尽可能减少业务适配改造开发工作量。
湖北移动自下而上从底层服务器芯片、操作系统开始推进全栈自主可控工作，重点聚焦数据库升级工作的推进，梳理涉及的系统范围，制定短期、中期、长期实施计划，统筹主要开发商及周边生态厂商，数据库厂商、服务器厂商、操作系统的兼容性测试、性能测试、能力沉淀、割接落地等方面的工作。在业务层面，湖北移动参照中国移动新一代业务支撑系统建设要求，充分发挥分布式数据库多租户的能力，设计了可以支撑未来5~10年的可在线弹性扩缩容的核心数据库系统。在运维智能化方面，湖北移动通过升级项目进行部分尝试，例如引入基于AI模型的智能专家提升对新架构、新知识的快速上手能力，并计划逐步实现运维智能化。
02
解决方案
湖北移动围绕集团自主可控战略，基于新一代云原生规范，从支撑厂商的契合度、支撑能力、产品生态等方面进行数据库选型，制定升级改造方案和实施计划。
数据库升级涉及内部业务、安全、开发等多个部门，外部涉及多个外部厂商的协调工作，在业务支撑中心各级领导的带领下，湖北移动成立自主可控专项工作组，明确各方职责，召开项目双周推进协调会，处理项目推进过程中存在的问题和困难，确保自主可控顺利推进。经过与各合作伙伴的联合攻关，打通了开发、测试、迁移、割接上线、后续运维的各环节。
湖北移动充分利用分布式数据库架构的优势，首例实现跨一级云、省公司云资源池部署，完成**业务全量数据库的升级改造工作。以一级云**资源池POD作为数据库集群主中心，主集群三副本，业务接入采用软负载转发至OBProxy方式，自动转发业务请求给主集群，当主集群级别故障的时切换到备集群，应用无需修改连接串就可以访问备集群，降低容灾切换的操作难度。
湖北移动建立了全流程自主可控工作机制，在确保IT系统稳定运行和前端感知不降级的基础上，保证改造工作按时、保质完成。在批量改造迁移前，湖北移动完成了必要的业务功能验证工作，合计测试用例4000+。
由于OB分布式架构与原O集中式数据库的架构不同，湖北移动从多个维度进行比较和测试，特别针对分布式场景下的高可用测试进行验证，最终自动恢复的场景可以达到78.8%。
湖北移动采用OB提供的OMS进行数据的全量和增量的迁移，在原O库侧监听停止和业务进程停止的情况下进行两边数据的比对，最终目标是实现两边数据的100%一致。在数据一致性比对过程中，遇到由于业务操作先后顺序、OMS参数设置不当导致了部分一致性问题，通过优化操作流程和参数设置，最终实现数据100%一致。除了OMS自动化工具外，湖北移动还准备了自动化脚本，可以快速对数据不一致的表重新同步，通过这种方式保障数据一致性。
湖北移动采用OB的ODC将新的数据库资源纳入到4A系统进行管控，实现所有SQL操作的可查、可溯源。ODC类似于PLSQL客户端，可以连接OB进行SQL执行分析、断点调试、数据导入导出、对象管理等基础功能，并且提供SQL审计、敏感数据访问的金库接口，可与内部4A系统进行对接，满足集团安全管控要求。
湖北移动采用OCP 对OB集群、租户、用户等逻辑组件进行全生命周期管理，包括对主机、网络等相关基础资源的监控管理。通过访问OCP管理页面，可以实时查询集群节点、CPU、内存、存储等指标的实时数据。通过SQL监控模块可对于高消耗CPU的问题SQL可以进行限流操作；此外，OCP内置超过2000条的告警策略，实时对OB资源进行监控，通过将告警信息转发给综合管理系统，可以及时触发告警。OCP是DBA运维人员日常监控和管理OB集群的重要手段。
针对11类系统级别的故障场景，湖北移动制定了14项主动应急预案，涉及场景、影响、应急操作步骤等内容。应急事件的来源主要是两大类，一类是应用发现的异常，另一类是来自数据库自身的告警。数据库自身的告警一般是指具体的数据库异常等待事件，湖北移动以故障影响最小、处理时间最短为原则处理紧急故障，根据实际处理结果，决策是否需要启动相应的应急操作。
为了保证原O库到OB迁移的在线数据同步能力、数据一致性校验能力，采用OB的OMS迁移工具进行全量同步、增量同步、反向同步、全量校验等功能。结合全量表count和逐字段效验保证，通过模拟数据割接的操作流程磨合，确保2~3轮校验数据一致性，才能进入最终割接阶段。
湖北移动核心数据库升级项目在如下方面进行了创新：
（1）基于大模型的数据库智能专家创新
由于分布式数据库体系架构复杂、知识点比较多，开发运维人员碰到的问题通过传统搜索方式存在大量信息干扰，无法快速准确的找到答案，导致工作上响应的不及时。
湖北移动与OB公司合作，基于大模型技术在数据库领域进行探索和尝试。采用ChatGPT，依托海量数据库文档、数据库常见问题、故障排查手册、数据库最佳实践等基础数据输入，可以实现数据库知识获取能力的提升和优化，可快速从大量后台文档中检索信息，提升检索准确率，降低无关信息的干扰、节省搜索时间。
基于大模型的数据库智能专家目前后台调用通义千问大模型能力，对数据库官方文档、知识库文档进行切片和训练，生成模型，通过向量搜索和AI理解能力实现前后台交互。
未来，湖北移动规划了将数据库智能专家演进到智能运维专家的路径：
第一阶段基于大模型移动端的场景应用需求，对细分领域知识文档搜索和整理，然后进行切片和模型训练，通过向量搜索和AI理解能力，通过移动端交互快速响应专业场景的答案，实现智能运维移动端AI专家1.0版本。
第二阶段拓展场景应用，延伸到IT全栈跨领域的运维技术支撑，形成湖北移动对大模型、素材库、场景库、支撑业务运维应用的体系框架，进行故障根因分析、优化建议，实现全栈技术的AI支撑专家。
第三阶段部分对接现网生产系统进行交互，可以获取在线系统状态，通过API对接外部运维工具，实现运维操作的AI编排，实现生成、审核、执行、操作、复核等流程串联，最终生成执行报告。
（2）SQL安全管控能力提升创新
以往，SQL审核和SQL执行是相互隔离的两套系统，需要先审核再执行。目前通过ODC4.2版本新功能，可以将SQL管控规则嵌入ODC执行窗口，可以做到执行前规则预置、执行后审计，经过ODC系统管理员授权，可以在安全规范的环境中配置SQL规范，在窗口中执行SQL语句时，ODC会根据配置的规范对输入的SQL进行检查。
（3）数据库全链路追踪能力创新
OB数据库是分布式数据库，涉及的组件、数据库节点较多，调用链路相对复杂。如出现SQL超时问题的时，往往无法快速定位是OB数据库内核或是网络的问题，运维人员需要对大量节点的内核日志、proxy日志、驱动日志、业务系统日志进行分析。
湖北移动利用全链路诊断机制，可快速定位组件内部的问题。全链路诊断是对全链路所有组件进行问题定位的诊断，可以通过客户端访问OB数据库，客户端请求经过OBProxy分发到OBServer，或者直接访问OBServer。在这个过程中，运维人员可以根据运维需要，通过使用PLSQL程序包里的DBMS monitor中的相关方法，控制相关应用程序根据不同标识信息、维度判断是否需要开启全链路诊断trace。运维人员通过对所有trace日志进行搜集、分析后可以追踪每个事物或者每个SQL在整条链路中的执行耗时等信息，辅助定位问题。
价值与效果
04
实践总结
在湖北移动核心系统数据库升级过程中，总结如下经验：
第一，数据库升级改造涉及多部门、多厂商的协调配合，特别是业务兼容性适配、性能测试阶段，需要充分调动各方的积极性，整合各方的需求和分工边界，做到项目关键信息的及时沟通确认，守住项目关键里程碑点。
第二，需要充分理解和挖掘分布式数据库的特点和优势，借助分布式原生能力对原有IT架构进行升级，包括数据库的高可用架构、应用程序多活部署方案、建立完善的分布式数据库开发、运维体系架构。
第三，引入新技术增强运维能力，打造基于分布式数据库 + AI 的核心系统基础能力。
