十余年来，数据库行业波涛迭起：从轰轰烈烈的去IOE 运动，到如火如荼的数据库国产化落地，再到如今 AI 给数据库领域带来全新变革。
身处浪潮之中，DBA 群体不断面临角色的重构：从传统数据库运维，走向运维开发、平台建设、开源贡献，再走向技术管理。
本期ITPUB 邀请 vivo 数据库团队负责人王乐老师，探讨数据库迁移落地、运维平台化建设、ghost 开源社区实战贡献，分享 DBA 如何完成从运维到开发的能力蜕变，解读“埋头种因，坚持做正确的事”这一技术长期主义信念。
01
风采展示
问题1：王总，您好，非常荣幸邀请您接受本次专访，请简单介绍您的从业经历，在数据库迁移、自动化平台建设、金融分布式集群运维、开源贡献与技术管理方面，有哪些关键的成长节点？
王乐：主持人好，我是王乐，很高兴跟大家一起交流。我2013年从武汉大学毕业以后，先在银行做了几年DBA，负责传统支付业务的Oracle数据库运维，对高可用和数据一致性有了深刻的认识。接着加入vivo开始学习MySQL，并主导了公司内部第一套去O的数据库迁移。早期手工运维效率比较低，我就自学了Python，开发上线了数据库自动化部署平台和自适应基线性能监控，并提出了数据库管理从“规范化->自动化->平台化”的演进路线。后来我加入了腾讯金融(财付通)，先后管理了腾讯所有金融业务的数据库，负责了微信支付数据库的国产化改造、条带化容灾、红包“春保”等项目。期间，我又学习了Java和Go开发，也几次修复了gh-ost数据一致性的高危bug并回馈社区，实现了运维到SRE的转变。现在又回到vivo，主要负责技术管理工作。十几年来，我始终扎根数据库领域，从传统DBA到运维开发，再到技术管理，每一步都是在“种因”， vivo讲“埋头种因”，这也是我一直坚持的信念。
02
数据库迁移落地
问题2：您完整走过去 IOE、国产化、AI 智能化三代浪潮，回看这十几年，数据库领域最大的认知迭代是什么？
王乐：我觉得最大的认知迭代，是从“依赖数据库的能力”走向“用好数据库的能力”。 早期去IOE，大家关注的是用开源和分布式架构替代集中式商业数据库，解决成本和扩展性问题。那时候我们容易把数据库本身的能力当成“万能药”，甚至依赖一些隐含参数来调优，有了开发经验以后就会明白，很多隐含参数实际也是无奈之举，一个设计良好的系统是不需要“黑魔法”来救火的。到了国产化阶段，焦点变成了自主可控与生态适配，我们意识到没有完美的数据库，只有最适合业务场景的技术架构，技术选型必须回归业务本质。AI浪潮可能会改变数据库的使用和管理方式，DBA的能力模型也必须从单一的数据库运维，扩展到平台开发、架构设计、甚至技术管理。只有持续拓展能力边界，适应时代发展，才能真正“用好”数据库，为业务创造价值。
问题3：经历过去 IOE，现在又迎来数据库国产化替换浪潮，两次大的迁移浪潮，底层技术环境、工具生态、人才储备差异很大。对比当年 Oracle 到 MySQL 迁移，当下做国产数据库替换，会遇到哪些新的现实挑战？有哪些历史经验可以直接复用，哪些经验需要抛弃？
王乐：挑战非常明显，这个阶段的组织成本已经超过了技术成本，最大的瓶颈就是人才断层。以前去IOE使用的是开源数据库，生态成熟，人才众多；现在大多国产数据库的生态相对封闭，真正了解底层原理的人非常稀缺，这是最被低估的挑战。之前我在腾讯做国产化替代的时候，遇到了ARM架构适配的问题，当时调动了腾讯和华为的十来个专家花了很长时间才定位到根因，人力投入成本是很高的。
国产化替换时，有些历史经验是可以复用的，譬如，迁移过程必须做好灰度，要有回退能力
如果说需要抛弃的经验，我觉得应该是不要绑定单一厂商。绑定单一厂商，风险很高，做数据库选型一定要遵循“上得来、下得去”的原则。
问题4：很多企业如今还在做各类数据库异构迁移，不只是 Oracle 转 MySQL，也包含国产数据库替换。从您实战经验看，一场大规模数据库迁移，最容易失败的环节是哪里？如何建立一套可复用的迁移评估演练割接回滚完整流程？
王乐：最容易失败的环节，往往不是数据同步，而是迁移之后的性能问题。很多性能问题是在特定业务场景下才会触发的，这些在基准测试时很难发现，却最容易导致迁移后效果不理想。
建立可复用的迁移流程，核心就是要做到“可灰度、可观测、可回退”。评估阶段要全面梳理兼容性和数据量级；演练阶段必须进行全量演练，要有完善的监控手段来监测性能以及数据一致性；割接阶段采用灰度引流，先切少量流量验证，验证没问题再切换；最后，必须要有完善的回滚预案，且预案要提前演练。
03
运维平台化建设
问题5：现在 AI、AIOps、数据库 Agent 热度很高，不少团队希望直接把 AI 能力嵌入现有运维平台。如果在您这套 “规范化自动化平台化” 体系之上叠加 AI 能力，前提条件是什么？对于还没有完成自动化建设的团队，是否适合直接上马 AI 运维能力，会带来哪些风险？
王乐：我的理解是：平台能力是底座，专家的经验是灵魂，AI是让体系活起来的点睛之笔。AI要真正在运维平台中落地，不是简单地接一个大模型就够的。AI需要通过MCP或者tools拿到现网环境的真实数据，没有自动化的工具接口和规范化的数据，AI的手就伸不出去只能空谈，所以平台的能力是基础。另外，智能化运维的灵魂其实是各个专家在垂直领域的专业经验，这些经验必须被结构化地沉淀到知识库或知识图谱中提供给AI，这样AI才能具备垂直领域的能力， 这是 AI 区别于通用模型的关键。对于还没完成自动化建设的团队，我是不建议直接上AI。数据质量差或者自动化不完善，AI的推理会有大量误判，反而增加运维负担。第一步是先完善平台化建设。
问题6：现实中经常出现一种现象：运维平台功能齐全、界面完善，但一线 DBA 依旧绕开平台手工操作，平台沦为演示工具。结合您的实践，造成 “平台和生产两张皮” 的根源主要有哪些？在需求调研、功能设计、落地推广层面，可以做哪些动作来规避该问题？
王乐：我认为根源在于平台没有真正解决运维的痛点。运维平台如果能够为业务提供价值，提升运维效率，降低运维风险，DBA是会喜欢用的。解决运维的痛点，我觉得，首先在需求调研阶段要挖掘运维的真实需求。有时业务的诉求并不是他的真实需求，比如开发找DBA帮忙解析Binlog，实际上可能是由于发版时自行变更数据库改错数据了，真实需求其实是需要一个数据库变更系统来帮助他降低变更风险；其次，在功能设计阶段要考虑用户体验，提升易用性；最后，落地推广阶段注意灰度，先灰度有迫切需求的用户，灰度过程中及时发现问题并优化，再逐步推广，让用户感受到平台是他的帮手而不是负担。
04
开源共建与技术管理
问题7：财付通环境下 ghost 一年执行数千万次在线改表，期间发生过严重的数据丢失事故。大规模生产环境使用开源 DDL 工具，大家大多只关注功能是否够用，忽略底层源码风险。当时事故给您带来哪些冲击，是什么促使您直接深入源码定位并且修复问题？
王乐：冲击非常大。财付通是微信支付的底层，对数据一致性要求非常高，数据一致性是支付业务的生命线。当时所有线上业务表变更都是通过gh-ost执行的，执行次数非常多，即使是一个极低概率出现的bug也有可能被放大成严重事故。实际上，我们遇到的几次数据一致性的bug，都是在非常极端的场景下才会触发的。正因为gh-ost执行频率非常高，并且业务对数据一致性要求也非常高，才促使我去研究gh-ost的代码。如果我们对gh-ost的底层原理不清晰，那这个工具就是一个定时炸弹，随时都有可能在线上爆炸，影响面可能会很大。研究gh-ost代码主要是为了消除线上变更的风险。我之前也看过一些MySQL的源码，每年在制定年度计划的时候都会给自己列一项”研究MySQL源码”的计划，但在日常工作中，大多数时候都不需要我们对源码有那么深入的了解，所以我也就一直没有动力深入地去研究。归根结底还是业务需求驱动的，不是为了研究代码而研究，研究代码主要还是为了解决业务问题。
问题8：您修复 ghost 源码中多项数据一致性高危 bug，并且回馈社区，一度成为 ghost 国内最主要贡献者。对于绝大多数运维工程师而言，阅读开源工具源码、提交 bug 修复是很高门槛。运维人员想要参与开源工具贡献，有哪些可行切入路径？最大的障碍是在技术本身还是什么？
王乐：前面提到了研究源码还是为了解决业务的问题，那切入路径我觉得就可以从测试和复制bug开始。我们日常使用的数据库或者周边工具，如果在使用过程中发现有不符合预期的情况或者有些需求没法满足，就可以做一些针对性的测试，把问题清晰描述出来，并配上复现步骤、环境配置、日志截图等，提交issue给社区，这比直接修Bug更有价值。当遇到一个反复出现的问题，先查issue看是否已有解决方案；如果没有，再自己尝试阅读源码和修复bug，并提交PR给社区。给社区提交代码最大的障碍不在技术本身，而是缺乏即时的正向反馈。运维工作本身压力比较大，下班后再去啃陌生代码库、等待review、被要求修改，很容易产生挫败感。如果连续两次PR被打回，很多人就放弃了。其实PR被拒绝、issue被关闭都很正常。当然，现在AI时代来了，难点可能不再是提PR，而是PR太多了，如何让自己贡献的代码更有价值，又成了新的挑战。
问题9：您提到腾讯 “做难而正确的事” 与 vivo 本分文化 “埋头种因” 内核相通，形成您 “埋头种因，坚持做正确的事” 的信念。能不能结合您过往真实项目，举例讲讲这套理念如何指导您做技术选型、项目取舍？很多难而正确的项目短期看不到收益，还会消耗团队资源，如何对内争取支持？
王乐：vivo的本分文化一直要求“做正确的事，把事情做正确”；在腾讯的时候，Pony也多次提到“做难而正确的事”，强调以用户价值为依归，我认为这两者的底层理念是相通的。首先是要坚持做正确的事，对业务对用户长期有价值的事情；其次是把事情做正确，即使有困难也要迎难而上。我一直以来受到这种文化的熏陶，坚持”埋头种因，坚持做正确的事”的信念。我回到vivo后做的第一件事情，就是大力建设我们的数据库高可用能力，同时推动云上数据库转自建，实现多云统一和自主可控。我认为这就是在做难而正确的事，短期看这给我们团队带来了很大的挑战，也增加了团队工作量，但长远来看，自主的数据库高可用能力能够让我们的数据库运行更加稳定，对业务有着长期的价值。有时候，做正确的事是很难的，最大的难点在于争取组织的支持。例如，我们做数据库运营平台需要获取团队内外部的支持，争取支持的关键就是寻找运营平台跟业务价值的契合点，不是为了运维的平台化而做平台化，还是要解决业务的真实需求。当前有些需求只是关联性的，不是直接的运维平台化需求，需要挖掘出业务需求和平台化需求中间的契合点。譬如，每次业务故障复盘，业务人员都要求我们提高系统的稳定性，这个需求其实就是对数据库的可用性提出了更高的要求，譬如4个9或者5个9的可用性，那我们就需要通过平台来实现数据库的故障自动切换或者集群的自动管理，这就转换为平台化的需求了。对于难而正确的项目，找到他跟业务价值的契合点，通过技术手段实现业务价值，更容易获得支持。
问题10：回望您完整职业路径，从一线 DBA，到做迁移、建平台、扛金融级集群、做运维开发，再走向技术管理，如果给想要拓展能力边界的 DBA 三条务实建议，您会给出什么？
王乐：结合我自己的情况，我觉得首先一点就是持续学习。技术的更新迭代是很快的，单就数据库来说，过去十几年我们就经历了传统数据库、开源数据库、NoSQL、分布式数据库、各种国产数据库、向量数据库等各种数据库的变迁，现在尤其是AI时代来临，技术的迭代速度会更快，我们需要一直保持学习的心态，持续学习。其次是要主动走出舒适区。尤其对于有一定经验的DBA，不要沉溺于过往的经验积累，也不要满足于只掌握某一种数据库。要有意识地去承接能力圈之外的事情，主动迎接挑战——多拓展几种数据库的知识，多去了解不同的技术栈，同时学一学代码开发，尤其是AI Coding。当你迈出去了，舒适区自然就变大了。最后就是埋头种因，果水到渠成。拓展能力边界不是一蹴而就的事情，短时间内可能看不到明显效果，这时候最容易动摇。但是相信长期主义的力量，今天多学一门语言、多接触一种数据库、多解决一个难题，都是在种因。不要因为短期没有正反馈就放弃，改变一定会在某个时刻发生。坚持做正确的事。这就是我的一些想法，希望能给大家一些启发。
热门跟贴