作者：vivo 互联网服务器团队- Deng Song

本文根据邓松老师在“2022 vivo 开发者大会"现场演讲内容整理而成。

数据库运维面临着大规模数据库实例难以有效运维、数据库难以做好资源弹性伸缩以及个人隐私数据安全难以保障这三个方面的挑战。对此，vivo 给出了自身的应对方案。 

首先，vivo 自研了数据库运维平台 DaaS 来支撑数据库运维工作。在规模覆盖、效率提升、故障告警处理等层面均衡发力，保障了数据的稳定性，以工单自助，故障自愈为核心，实现了数据库的高效运维。 

其次，在数据库资源弹性管理层面，vivo 重视资源成本优化。围绕资源分配、资源弹性伸缩、资源隔离分别给出了智能化解决方案，并通过套餐自动优化，进一步降低了管理成本。

最后，基于个人隐私数据，平台也提供了对业务几乎无影响的 MySQL 的透明加密方案，来减轻因为隐私数据加密带来的研发和运维工作量。

一、云原生时代数据库运维挑战

1.1 数据库运维体系演进

从数据库运维体系的演进历程来看，

1、2000 年左右，PC 互联网时代兴起，商业数据库是市场主流，而开源数据库方兴未艾。普遍的数据库运维方式，还是人工加脚本，当时大部分公司数据库规模量相对不大，这样做完全够用。人们面临的主要运维挑战是商业数据库软硬件成本高，而开源数据库软件和配套工具不成熟，通常要自研来满足开源数据库自身的稳定性和扩展性要求，门槛高。

2、到了 2010 年左右，移动互联网时代兴起，社会数字化进程陡然加速，数据量规模大增。此时，一个针对 IT 基础设施的革命性的概念提出来了，那就是云计算，简单来说，就是通过网络的方式提供服务器，数据库，或者某种软件服务资源。在数据库运维领域，则自然衍生出了云计算的一个分支概念，DaaS，data as a service，数据库的运维方式因此由人工脚本方式转变为了数据库平台的方式。同时，随着开源数据库技术以及各种周边生态软件走向成熟，开源数据库得到了广泛应用。这时，数据库运维的挑战变成了如何高效率交付资源，保障数据库稳定性，做好数据库成本优化。

3、到了 2020 年左右，后移动互联网时代，社会数字化程度进一步加深。云原生的概念被提了出来。微服务架构，资源弹性，容器等云原生技术广为传播。数据库的稳定性方面，因为开源数据库的高可用体系普遍成熟而大大缓解。数据库规模方面，实例数量和品类都进一步大增。数据库安全方面，2021 年 8 月我国正式出台了个人信息保护法，个人隐私数据保护成为了数据库运维的时代重点。

1.2 云原生时代挑战

这样的时代背景下，我以为数据库运维主要有三个方面的挑战：

1. 云原生时代应用架构普遍微服务化，一个系统拆成多个微服务，这个系统的数据库也分拆成多个。这导致数据库实例成倍增加，数据库的运维工作量也成倍增加。因此大规模数据库实例如何有效运维?这就是第一个挑战。

2. 云原生理念应用架构层面的弹性伸缩，自然也要求数据库层面做到弹性伸缩。具体来说，是效率上做到快速扩缩，业务无损，成本上也要做到，按需按量使用。但是主流开源数据库本身是存算一体架构，这两点支持不容易。数据库如何做好资源弹性伸缩？这是第二个挑战。

3. 数据库安全方面，个人隐私数据需要保护，这个必要性无需多说，但是怎么技术落地？怎么识别个人隐私数据，识别之后又如何进行数据加密。而开源数据库在这方面，即也没有具体的落地方案，没有提供专门的工具，这些都有待自己探索。这是第三个挑战。

挑战讲完了，接下来我们看下 vivo 在这三个挑战方向的应对。

二、vivo 大规模数据库实例高效运维

2.1 高效运维实践现状

vivo 是自研了数据库运维平台 DaaS 来支撑数据库运维工作。

• 规模上，支撑了数万数据库实例的运维服务，包含了 6 种数据库：MySQL，Redis，MongoDB，Elasticsearch，TiDB5 个开源数据库，1 个公司内部自研的磁盘 KV。

• 效率上，节省了 92%的数据库运维工作量。月均数千的总工单量，其中 92%都是无需运维参与，由平台用户自助执行。

• 故障告警处理上，70%的数据库告警实现自动分析或者处理，进一步解放了数据库运维人力，保障了数据稳定性。

综上所述，数据库高效运维的核心就是，工单自助，故障自愈。接下来将详细介绍这两点。

2.2 工单自助

首先看工单自助，要实现工单自助，主要有三点：

1. 95%运维操作平台化，用平台操作替代手工或者脚本操作。所谓平台化的本质，就是用代码的方式，将最佳的运维经验固化在平台中。这才是一切运维效率的基础。

2. 99%工单成功率，一方面是要做到，所有运维操作都有工单流记录，这是运维工作量化和进步的基础；另一方面，因为异常的工单还是要数据库专业运维介入处理的,所以只有工单一键执行成功率达到 99%以上才可以开放自助，才谈得上提升了效率。

3. 部分开源数据库生态工具是空白的，例如常见数据库 Redis 要数据变更自助，一方面需要做到变更过程业务无影响，这要求做好变革速度 &负载控制，变更前排除大 key 等风险因素。另一方面还需要做到变更过程数据安全，这要求变更前做好备份，变更后可随时回滚。这些都没有现成开源工具集成，vivo 是通过自研逐个填补了这些工具空白。

2.3 故障自愈

随着数据库规模的成倍增加，故障告警的数目也急剧增多，vivo 日均数百数据库故障告警，存粹靠手工进行告警问题排查处理越来越不能满足数据库稳定性的要求。

数据库故障自愈的需求就被自然提了出来。故障处理简单分为：发现，定位，恢复 三个步骤，针对已经发生的故障我们反复分析确认，其中定位环节是最耗时，所以当前故障自愈系统主要做的就是故障分析定位的工作。整体上故障自愈主要是两个难点，一个故障自愈方案的确认，另一个是相关基础工具的开发。

通常认为故障自愈方案最好是全面信息采集+机器学习自动确认的，这样的方案具备普适性，也更有效率且准确。但是立足于团队和问题现状，我们认为当前的故障自愈方案可以是全基于运维专家经验确认的。这是因为在数据库运维方向，目前常见数据库相关故障场景不到 50 个，且变量因素单一，所以即便凭借优秀专家经验枚举处理办法，也能自动解决大部分故障，简单实用。另外在故障自愈的基础工具上，我们主要自研了：Redis 流量分析，热 key 分析，MySQL 根因 SQL 分析等工具。

接下来介绍故障自愈的逻辑架构：

整个系统是由故障告警驱动，系统获取到告警消息后去查找相匹配的预案，然后执行预案中设定的基础操作，包括分析操作和恢复操作，例如 Redis 流量分析或者 MySQL binlog 清理等，最终生成执行报告，其中包括中间状态的现场监控快照，智能的分析结果等，同时也提供案例标注的能力。最后执行结果会自动分配并通知到对应负责的数据库运维人员或者消息群组当中。

通过这套架构，最后实现了超 70%的故障自动分析或者处理，包括至少 30 个基础能力建设，26 个故障预案，10 个故障场景全自动处理。

三、vivo 数据库弹性资源管理

3.1 资源弹性管理问题 &现状

我们先来看 vivo 数据库资源管理上要面临的现状和问题：

1. 传统数据库占主流，从数量上看，线上数据库数万个实例，85%是 REDIS，10%是 MySQL，剩下 5%是其它数据库。都是存算一体的传统数据库，弹性伸缩能力并不完美，例如开源 Redis Cluster 的弹性伸缩是单线程的，上了一定数据规模后其扩缩速度和稳定性都有待进一步提升。

2. 当前数据库资源管理还没有容器化，数据库资源隔离得另想办法。同时对于 Redis 等传统数据库来说，容器化也不能解决其弹性伸缩的速度和稳定性问题，这些都只能从数据库软件本身上去解决。

3. 目前数据库资源都是直接部署在物理机上，PB 级数据直接部署在数千台物理机上，数据库成本问题比较敏感。

3.2 资源弹性管理主要实现点

针对上述问题，vivo 数据库平台主要做了如下工作：

1. 资源分配上，实行单机器多实例多版本多套餐混合部署，同类数据库资源池统一，提升资源利用率。

2. 资源弹性伸缩上，自研多线程 Redis Cluster 扩缩工具，显著加速 Redis Cluster 扩缩容过程，同时增加限速，大 key 巡检，历史负载检测，脑裂检测等功能尽量增扩缩容稳定性。

3. 资源隔离上，则采用两个措施。

   （1）程序配置实现隔离，如 Redis，线程模型决定了几乎只消耗一个 CPU 核心，而内存占用也主要由配置决定，其它网络磁盘很少存在争用，所以混部就没隔离问题了。

   （2）通过巡检和容量预测的方式实现软隔离，尽量解决非突增的资源争用问题。

3.3 套餐自动优化

在资源成本优化上，除了刚才提过的混合部署，还可以做套餐自动优化，进一步降低成本。

下面介绍下具体的套餐自动优化流程：

• 第一步 平台自动扫描全网数据库实例，挑出其中被认定是满足缩容条件的。

• 第二步 平台自动发送缩容工单交由实例对应的业务项目经理审批。

• 第三步 根据审批结果执行缩容，或者放弃本次缩容。

大概在这个功能上线后的 4 个月内，平台自动发起超千次缩容，节省了超百 T 空间。

四、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 判断，形成 AI 判断为辅，专家经验为主的故障处理体系。

• 阶段三：构建 AI 判断为主，专家经验为辅的自愈系统，进一步提升自动化程度。

5.2 资源管理

接下来在弹性资源管理这个方向，个人认为其发展可以分为三个阶段：

• 阶段一：数据库混合资源管理（这是当前所在的阶段，套餐，版本可以混合）。

• 阶段二：数据库容器混合资源管理，这一阶段主要是利用容器消除机型隔离，品类隔离，有助于更高密度资源部署以及套餐统一标准化的实现。

• 阶段三：存算分离架构数据库的资源管理。在底层资源调度层面发挥到极致后，只能通过数据库架构本身的升级提升资源弹性。

5.3 隐私数据治理

在个人隐私数据这个方向，还有两个待解决的问题：

1. 第一个是，非结构化数据隐私自动识别和加密问题。结构化和半结构化数据，就是 MySQL，MongoDB 这种，通过字段的可以批量识别和处理一个表或者集合的隐私数据。但是对于 Redis 这种结构，当前一次只能识别和处理一个 key-value 键值对。解决思路是，非结构化转为半结构化数据，例如特定前缀 key 或者正则 key，绑定固定的 value 结构。

2. 第二个问题是，隐私数据的识别准确率问题，当前只有 79%，这个目前思路是人工标注+AI 识别。

5.4 数据库平台的未来展望

最后谈下数据库平台建设，概括来说 8 个字，统一标准，开源共建。

展开来说，如今的数据库技术市场百花齐放，DBengines 网站榜上有名的数据库就有 395 种，单个系统构建依赖多个品类数据库的情况逐渐普及，通过统一的数据库平台来支撑数据库运维工作，几乎成了企业的刚性需求。但我们缺乏一个公认的跨品类的数据库运维标准，也缺乏一个主流的跨越多品类的开源数据库平台。

个人期望用这样的开源平台来承载数据库厂商，数据库生态工具开发者以及企业用户对数据库服务共建的诉求，加速数据库服务建设速度，让云原生时代没有难运维的数据库。