首先，vivo开发了自己的数据库运维平台DaaS，支持数据库运维工作。在规模覆盖、效率提升、故障告警处理等方面均衡发力，确保数据稳定。以工单自助服务和故障自愈为核心，实现数据库的高效运维。其次，在数据库资源的灵活管理层面，vivo非常重视资源成本的优化。围绕资源分配、资源弹性伸缩、资源隔离给出智能化解决方案，包的自动优化进一步降低管理成本。最后，基于个人隐私数据，平台还为MySQL提供了对业务几乎没有影响的透明加密方案，减少隐私数据加密带来的研发和运维工作量。1.云原生时代的数据库运维挑战1.1数据库运维体系的演进从数据库运维体系的演进来看，1.2000年前后，PC互联网时代兴起，商业数据库成为市场主流，开源数据库方兴未艾。数据库运维常用的方式是手动添加脚本。当时大部分公司的数据库规模都比较小，这完全够用了。人们面临的主要运维挑战是商业数据库软硬件成本高，而开源数据库软件和配套工具不成熟，通常需要自行开发才能满足开源数据库本身的稳定性和可扩展性要求，门槛高。2、2010年前后，随着移动互联网时代的兴起，社会数字化进程骤然加速，数据量急剧增加。这时，一个IT基础设施的革命性概念被提出，即云计算，简单来说就是通过网络提供服务器、数据库或者某种软件服务资源。在数据库运维领域，自然衍生出云计算的一个分支概念，DaaS，数据即服务，数据库的运维方式从手工脚本方式转变为数据库平台方式。同时，随着开源数据库技术和各种周边生态软件的成熟，开源数据库得到了广泛的应用。这时候，数据库运维的挑战就变成了如何高效交付资源、保证数据库稳定性、优化数据库成本。3、2020年前后，后移动互联网时代，社会数字化进一步深化。云原生的概念被提出来了。微服务架构、资源弹性、容器等云原生技术得到广泛应用。在数据库稳定性方面，大大缓解了，因为开源数据库的高可用系统普遍比较成熟。在数据库规模方面，实例数和类别数进一步大幅增加。在数据库安全方面，我国于2021年8月正式颁布个人信息保护法，保护个人隐私数据成为数据库运维时代的重点。1.2云原生时代的挑战在这样的时代背景下，我认为数据库运维主要面临三个挑战：云原生时代的应用架构普遍是微服务化的，一个系统拆分成多个微服务化的。services，这个系统的数据库也拆分成Multiple。这导致数据库实例成倍增加，数据库运维工作量成倍增加。那么如何有效地运维大型数据库实例呢？这是第一个挑战。云原生概念的应用架构层面的弹性伸缩，自然需要数据库层面的弹性伸缩。具体来说，就是在效率上实现快速伸缩，不损失业务，在成本上实现快速伸缩，按需量用。但是，主流的开源数据库本身就是一个存储计算一体化的架构，要支持这两点并不容易。数据库是如何做资源弹性伸缩的？这是第二个挑战。在数据库安全方面，需要保护个人隐私数据。这个需求不言而喻，但是如何实现技术呢？如何识别个人隐私数据，识别后数据如何加密。对此，开源数据库没有具体的实现方案，也没有提供专门的工具。这些都需要我们自己去探索。这是第三个挑战。既然挑战都结束了，那么我们就来看看vivo对于这三个挑战的回应吧。2.vivo大规模数据库实例高效运维2.1高效运维实践现状vivo开发了数据库运维平台DaaS来支撑数据库运维工作。在规模上，支持数万数据库实例的运维服务，包括MySQL、Redis、MongoDB、Elasticsearch、TiDB6个数据库，5个开源数据库，1个自研磁盘KV。在效率上，节省了92%的数据库运维工作量。每月总工单数以千计，其中92%不需要运维参与，由平台用户自行执行。在故障告警处理方面，70%的数据库告警自动分析或处理，进一步解放了数据库运维的人力，保证了数据的稳定性。综上所述，数据库高效运维的核心是工单自服务和故障自愈。接下来将详细描述这两点。2.2工单自助首先看工单自助。实现工单自助服务，主要有三点：95%的运维操作平台化，用平台操作代替人工或脚本操作。所谓平台化，其实质就是用代码把最好的运维体验固化在平台里。这是一切运维效率的基础。99%的工单成功率，一方面，所有运维操作都有工单流水记录，是运维工作量化和进度的依据；只有当工作表的单击执行成功率达到99%以上时，才能开启自助服务，效率可以说是得到了提升。一些开源数据库生态工具是空白的。比如普通数据库Redis，需要自助数据变更。一方面，需要保证变更流程不影响业务。这需要良好的变更速度和负载控制，并在变更前消除大密钥等风险因素。另一方面，也需要保证变更过程中的数据安全，这就需要在变更前进行备份，变更后可以随时回滚。这些都没有集成现成的开源工具，vivo已经通过自研的方式一一填补了这些工具的空白。2.3故障自愈随着数据库规模的倍增，故障告警的数量也急剧增加。vivo平均每天有数百个数据库故障告警。告警问题的人工排查和处理无法满足数据库稳定性的要求。自然而然提出了数据库故障自愈的需求。故障处理简单的分为三个步骤：发现、定位、恢复。出现的故障我们反复分析确认，定位环节是最耗时的。因此，目前的故障自愈系统主要是做故障分析和定位。从整体上看，故障自愈主要是两个难点，一是故障自愈方案的确定，二是相关基础工具的开发。一般认为，故障自愈方案应该是综合信息采集+机器学习自动确认。这样的解决方案是通用的，更高效和准确。但基于团队目前的情况和问题，我们认为目前的故障自愈方案可以根据运维专家的经验来确定。这是因为在数据库运维方向，目前常见的与数据库相关的故障场景不到50个，且可变因素单一。因此，即使最好的专家经验列举处理方法，也能自动解决大部分故障，简单实用。另外，在故障自愈的基础工具方面，我们主要自主研发了：Redis流量分析、热键分析、MySQL根因SQL分析等工具。接下来介绍故障自愈的逻辑架构：整个系统由故障告警驱动。系统获取告警信息后，搜索匹配的计划，然后执行计划中设置的基本操作，包括分析操作和恢复操作，如Redis流量分析或MySQLbinlog清理等，最后生成执行报告，包括中间状态的现场监控快照、智能分析结果等，同时还提供标记案例的能力。最终的执行结果会自动赋值并通知相应的负责数据库运维人员或消息组。通过该框架，70%以上的故障得到了自动分析或处理，包括至少30个基础能力建设，26个故障预案，10个故障场景全自动处理。3.vivo数据库弹性资源管理3.1资源弹性管理问题&现状先来看看vivo数据库资源管理的现状和面临的问题：传统数据库是主流。从数量上看，在线数据库有几万个实例，85%是REDIS，10%是MySQL，剩下的5%是其他数据库。两者都是传统的存储和计算一体化的数据库，弹性伸缩能力并不完善。比如开源的RedisCluster的弹性伸缩就是单线程的。数据规模达到一定规模后，其扩容速度和稳定性还需要进一步提高。目前，数据库资源管理还没有容器化，数据库资源只能通过其他方式进行隔离。同时，对于Redis等传统数据库，容器化无法解决弹性伸缩的速度和稳定性问题，只能从数据库软件本身解决。目前数据库资源直接部署在物理机上，PB级的数据直接部署在几千台物理机上，所以数据库的成本比较敏感。3.2资源弹性管理的主要实现要点针对以上问题，vivo数据库平台主要做了以下工作：打包，统一同类数据库的资源池，提高资源利用率。在资源弹性伸缩方面，自主研发的多线程RedisCluster伸缩工具显着加快了RedisCluster的伸缩过程，同时增加了限速、大键检查、历史负载检测、裂脑检测和其他功能最大限度地稳定扩容和缩容。对于资源隔离，使用了两种措施。(1)程序配置实现隔离，如Redis。线程模型决定了几乎只消耗一个CPU核，内存占用主要由配置决定。对其他网盘的争用很少，所以混合部门不存在隔离问题。(2)通过巡检和容量预测实现软隔离，尽量解决非突发资源争用问题。3.3包自动优化在资源成本优化方面，除了刚才提到的混合部署，还可以做包自动优化，进一步降低成本。下面介绍具体的包自动优化流程：第一步：平台自动全网扫描数据库实例，挑选出认为符合缩容条件的实例。步骤2平台自动下发收缩工单给实例对应的业务项目经理审批。第三步，根据审批结果实施收缩，否则放弃本次收缩。该功能上线约4个月后，平台自动发起千余次缩容，节省空间100余T。4.vivo个人隐私数据全链路保护4.1数据库层面的隐私保护现状在线数据库拥有数十万张“表”，总计上千万字段，其中隐私数据识别覆盖率100%，涉及MySQL、MongoDB、Elasticsearch、TiDB四种数据库，人工抽查识别准确率79%。当识别出个人隐私数据时，加密是主要的处理方式，因此平台还为MySQL提供了对业务几乎没有影响的透明加密方案，以减少隐私数据加密带来的研发和运维工作量。4.2全链路功能隐私数据库保护应是贯穿业务研发阶段和运营阶段的全链路保护。研发阶段：统一数据库建表入口，提供平台工具方便用户在新建表中标记私有数据字段，主要解决日常新增数据结构的识别问题。运行阶段：定时扫描全网表的结构数据，自动识别未标记的隐私数据，人工校验校准，主要解决存量数据结构的识别问题，也是对研究和识别中识别的补充发展阶段。运行阶段的操作：数据查询结果包括隐私数据的自动加密和展示。当数据导出为私有数据时，会自动加密并添加水印。4.3最后一道防线：数据库加密为了数据安全，数据库加密是最后一道防线。如上所述，如果隐私数据被识别出来，那么加密的目标就在那里。基础加密算法行业也比较成熟，不乏加密方式。唯一的问题是加密过程。对于新的业务接入，加密过程比较简单，无需业务接入即可为所欲为。但是对于现有的成熟业务来说，几十张表，几千万条记录是家常便饭。如何在不影响用户访问的情况下进行加密是一个比较头疼的问题。为了解决这个痛点，目前的数据库平台为已有的业务数据提供了无损加密方案。因为主要的私有数据在MySQL里面，所以是基于MySQL的。首先介绍一下加密涉及的三个组件：数据库平台是用户操作入口，表结构更改工具gh-ost负责历史数据的加密转换，MySQL代理负责制作加解密过程对业务程序透明。下面介绍一下无损加密的主要流程：第一步，用户必须在数据库平台配置需要加密的字段。如果不需要对历史数据进行加密，则整个加密配置过程就结束了。第二步，如果要对历史数据进行加密，会生成数据清洗工单，交给表结构变更工具gh-ost执行。具体过程是增加一个密文列，将明文列数据复制出来，加密。然后MySQL代理会自动将明文列请求转为密文列，数据清洗完成。第三步和步骤2执行完后，如果业务出现问题，可以随时回滚。当业务方确定数据加密后服务稳定后，可以选择回收明文列，最后更新MySQL代理配置，去除明文数据同步更新。即使整个加密过程完成，也几乎不需要为业务更改代码，对业务没有任何损害。五、未来展望5.1故障排除在我看来，故障自愈的演进可以分为三个阶段：第一阶段：基于专家经验的故障自愈枚举（目前是这个阶段）。第二阶段：在第一阶段的基础上引入人工智能判断，形成以人工智能判断为辅、专家经验为主导的故障处理体系。第三阶段：构建以AI判断为主，专家经验为辅的自愈系统，进一步提高自动化程度。3.2资源管理接下来，在弹性资源管理的方向上，我个人认为它的发展可以分为三个阶段：第一阶段：数据库混合资源管理（这是目前的阶段，包和版本可以混用）。第二阶段：数据库容器混合资源管理。该阶段主要使用容器来消除模型隔离和品类隔离，有助于更高密度的资源部署，实现统一标准化的封装。第三阶段：存储计算分离架构数据库的资源管理。在底层资源调度层面发挥作用后，只能通过数据库架构本身的升级来提升资源弹性。5.3隐私数据治理在个人隐私数据方向，还有两个问题需要解决：首先是非结构化数据隐私的自动识别和加密。结构化和半结构化数据，如MySQL、MongoDB，可以通过字段对表或集合的私有数据进行批量识别和处理。但是对于Redis的结构，目前一次只能识别并处理一个key-value键值对。解决方案是将非结构化数据转换为半结构化数据，例如特定的前缀键或常规键，并将其绑定到固定值结构。第二个问题是隐私数据的识别准确率目前只有79%。目前的思路是人工标注+AI识别。5.4数据库平台的未来展望最后??说说数据库平台的建设。一言以蔽之，8个字，统一标准，开源共建。拓展一下，如今的数据库技术市场百花齐放。DBengines网站上列出了395种数据库。满足企业的刚性需求。但是我们缺乏一个公认的跨品类数据库运维标准，我们也缺乏一个主流的跨品类的开源数据库平台。个人期待通过这样一个开源平台，支持数据库厂商、数据库生态工具开发者、企业用户对数据库服务共建的诉求，加快数据库服务建设速度，让上云成为可能-原生时代没有难以操作的数据库。
