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

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

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

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

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

   
   

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

   
   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

隐私数据库保护应该是贯穿业务研发阶段，运营阶段的全链路保护。

• 研发阶段：统一数据库建表入口，同时提供平台工具便于用户对新建表中的隐私数据字段进行标记，这主要解决日常新增数据结构的识别问题。

• 运营阶段：定期扫描全网表结构数据，自动识别未标记的隐私数据，并人工抽查校准，这主要解决存量数据结构的识别问题，同时也是研发阶段识别的补充。

• 运营阶段操作：数据查询结果中包含隐私数据自动加密显示.数据导出隐私数据时自动加密，并添加水印。

4.3 最后的防线：数据库加密

对于数据安全来说，数据库加密是最后一道防线。前面提到隐私数据识别出来了，那么加密的目标有了。基础加密算法业界也比较成熟，加密方式也不缺。唯一的问题是，加密的过程。

对于新增业务来所，加密过程比较简单，没有业务访问怎么做都行。但是对于存量的成熟业务来说，几十张表，数据规模千万记录都是常事，怎么加密还能不影响用户访问，就是个麻烦的问题。为了解决这个痛点，目前数据库平台提供了一个存量业务数据无损加密方案，因为主要隐私数据都在MySQL中，所以这是基于MySQL的。

首先介绍加密涉及的三个组件：数据库平台是用户操作入口，表结构变更工具gh-ost负责历史数据加密转化，MySQL代理负责让加解密过程对业务程序透明。

接下来介绍无损加密的主要流程：

• 第一步、用户要在数据库平台上配置需要加密的字段。如果不需要对历史数据加密那么整个加密配置流程就结束了。

• 第二步、如果要加密历史数据，就会产生一个数据清洗工单，交给表结构变更工具gh-ost执行，具体过程就是新增一个密文列复制明文列数据并加密。然后MySQL代理会自动将明文列请求转向密文列，至此数据清洗完成。

• 第三步、步骤2执行后，业务如果发现有问题，可以随时回滚。业务方认定数据加密后服务稳定时，就可以选择回收明文列，最后更新MySQL代理配置，去掉明文数据同步更新，整个加密过程就算完结，全程几乎无需业务改动代码，且对业务无损。

个人认为故障自愈的演进可以分为三个阶段：

• 阶段一：专家经验式枚举故障自愈（这是当前所在的阶段）。

• 阶段二：在阶段一基础上引入AI判断，形成AI判断为辅，专家经验为主的故障处理体系。

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

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

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

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

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

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

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

   
   

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

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

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

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