阿里云高级专家王林平：云数据库的运维体系构建

2021年12月18日，阿里云用户组（AUG）第四期活动在京举行。活动现场，有着十几年数据库经验的阿里云高级专家王林平，向数十家北京企业分享了智能、安全的云数据库运维体系构建思路，深入浅出的分享让大家受益匪浅。本文根据作者的现场演讲整理而成。

数据库运维要解决的问题

DBA/运维工作之痛
首先，做运维的同学，可能比较有体感，凌晨两三点被薅起来执行变更SQL。其次，包括我们的一些产品、运营、研发可能有查询需求需要授权，包括烂SQL把咱们的库打挂了。我第二份DBA工作的时候做了一件事情，就是把权限收回来，前任的这个负责运维的同学把权限发出去了，我得把权限收回来。第三个就是我们的性能问题，比如说因为性能问题导致的故障啊，半夜被薅起来。我希望我的分享能让大家有一些思维上的开阔，希望让我们做运维和做DBA的以后能幸福一点！

从互联网这十多年的整个业务发展来看，面临着一系列的业务变化。比如说业务从小变大，业务变复杂了，有一些场景下，比如说我们为了让业务的健壮性、稳定性、性能更好，可能要做微服务。随着我的业务变大，数据量也激增。

我举个例子，天猫淘宝，可能跟我一个年代的同学或比我早的会更有体感。2001-2002年的时候，我在淘宝上买过一个光盘，是在中关村线下交付的，当时还没有邮寄。那个时候淘宝还比较小，现在的淘宝大家可以想一下，那会儿可能一天几百单上千单了不得了，但现在天猫淘宝整个电商的体量大概是一天千万级。如果是双11双12的话，可能会翻得更大。这个过程中，整个天猫淘宝的体量变得非常大，数据量很大，业务模块也更复杂。另外，我们不同的团队研发、产品、运营等人员的水平参差不齐，他们在整个使用过程中，我们去做了一些产品数据库的使用迭代。在这个过程中，我们的部署、运维管理、安全等场景都会面临难题。

DBA/运维的数据库需求
PPT上其实是我们要解决的一些问题，整个包含了这几部分：

一部分是生命周期的管理。也就是传统情况下，我们怎么去对这个数据库的比如说部署、交付、拉起，包括它最终的生命周期的结束、做备份、做整个的归档。
第二部分是管理和使用。管理和使用其实可能主要是面向咱们的研发测试、产品和非运维的同学。
第三部分是稳定性和安全，这是咱们运维，包括后端研发的同学非常关注的。我的数据库挂了，怎么去快速的恢复？或者我有没有一个快速恢复的手段，比如说高可用的能力。
第四部分其实是性能优化和诊断。这一块儿，后面的嘉宾会深入讲一下，但我这个地方会涉及到一些方向。
第五部分是批量智能运维。这个是我在原公司做的，包括现在阿里也在花很大的精力做批量智能运维的这个事情。为什么呢？比如说我举个例子，现在天猫淘宝的DBA可能还有二十多个。但是实际上我了解天猫淘宝的节点应该是以万计。每次大家可以做个算术题，二十多个人几万个节点，怎么去运维，就面临着批量智能运维的问题。

云数据库如何智能安全运维

数据库实例生命周期管理
我们先看一下，这是一个典型的云上RDS或者PolarDB的整个生命周期管理。

第一个包括了实例生产和基本管理，里面包括实例生产的申请资源。
第二个是数据的迁移同步。我们其实是提供了非常多的能够把数据迁出去迁回来的一些能力。
第三个是实例的变更。如果已经用过阿里云的客户，其实会发现实例变更是一个非常高频的场景，比如它的这个资源不够了，要升配我们的实例；可能机房有问题或者硬件有问题，我要换个区……这个变更是非常高频。再就是升级版本，实际上在我们线下自建的这个场景下升级版本有点困难。比如说传统的方式像Oracle、MysSQL其实要做滚动升级。但我们是帮客户做到了一个相对平滑的升级。
第四就是我们的这个性能链路。这是我来阿里云之后，打开的一个思路，就是我原来自己去做运维的时候，其实是非常散的去收集性能包括审计这些信息。我们云上其实建立了一个叫性能链路的旁路信息，包括SQL洞察，整个数据库的一些日常的行为都会被采集出来，提供给咱们去做一些性能的诊断。DBaaS智能自治服务其实就用的是链路的数据。
最后读写分离的设置、参数调整、备份恢复这些其实都是我们的生命周期管理里要去解决的一些问题。

数据管理和使用
管理和使用其实是从阿里集团内部孵化的一个产品。集团最初可能只有几十个DBA，但要给几万甚至更多的研发测试，甚至其他的相关团队提供服务。这里面临的几个问题，数据安全；数据去做开发，开发包括流程规范的设计，SQL审核优化；去做发布；去做数据的加工（比如同构）；要迁移一个数据；还有就是资产管理，要对我们数据库里面的数据做一些源数据的管理、质量管理、管理血缘分析等。我们现在在云上提供了一个能力叫DMS，它是从我们集团的IDB孵化出来的。IDB最初是为了解决像授权、SQL审计这些问题的，后来它的这个能力拓得更宽了一些。

前一段时间我们去跟客户交流时，客户对这个能力很认可，他们就是通过我们的这个DMS就把整个数据管理的能力赋能给研发和测试了，从很大程度上降低了DBA的压力。

稳定性和安全
下面这个是DBaaS。DBaaS是我们阿里云关于稳定性和安全的一个能力，它提供了高可用性、同城容灾、监控报警、实例的数据安全、异常事件的主动运维、异常自愈等能力。尤其是异常自愈的这个能力，其实是我们一直在去探索的，像我们去做一些自动修复，包括这个异常的自动化保障，自动化系统和人工形成正反馈，参数、主机巡检等。在这里，我展开一个点来讲讲。

DBaaS高可用
大家看下面这个图，大家如果做研发或是DBA运维，应该了解一个叫高可用的能力。高可用里有两个概念，一个叫Switch Over，就是我的主动的正常的切换；一个叫Fail Over，就是我的某个节点挂了，被动的要切换。我们在云上做了一件事情，是希望让它更倾向于去做Switch Over，即正常切换，我们提前发现或者是预测问题来主动发起这个Switch Over，让咱们业务受损是可控的，而不是不可控。因为Fail Over的时候，我们的业务已经受损了。

在这个地方有几个事情，一个是我们会去做一些基础资源的采集。如果发现这些基础资源有问题，之前是依靠于我们去做一些监控报警，现在就是把这些信息采集起来。这个过程中，我们发现了问题后，可能会在云上主动直接切掉，然后给咱们的客户补一个通知。

第二部分就是我们发现了问题之后，基于我们的数据库服务，可以做一些像限流、索引的优化，自动的这种优化可以让我们的受损情况转化成非受损，这是一个干预行为。然后就是说我们去做一些主备链路的可用性，检查复制状态，这都是一个旁路，包括kill现有链接的这种行为让我们的业务HA能够提前发生。我们可以理解为，我们希望的是能预测发现你这个实例有问题了，就干脆直接提前切了，而不等他这个节点彻底挂了再切。

在这条线之后，比如说我前面这些事情都没有发现问题，最终会产生一个Fail Over。我们还有一个DAS可以做更早的事情，就是对流量资源和占用率去做一些升配。最近有两个能力，一个能力是说CPU打得比较高了，另一个能力是有一个比如说电商这种场景，我们可能会提前地去做一些基于时间的升配，比如凌晨2点到3点可能有一些高峰，我就提前基于这个DAS去做这个升配。相对来说，云上比自建好的一个能力是我们在可用区容灾这块儿可以解决脑裂问题。

包括无限HA，也是我们未来要解决的一些问题。无限HA是什么？有一个非常高的流量进来把主节点打挂了，然后我们切了备节点，接着备节点又打挂了，又要切。但这时我的主节点还没有修复，那就可能我的两个节点都挂。这个其实是我们未来要解决的一些问题。如果大家有一些想法也可以跟我们探讨。

性能优化与问题诊断
我们主要还是基于DAS来做的，就是数据库自治服务。这里面包含问题的发现、诊断，缺陷的性能优化、扩缩容，以及缺陷的修复。我跟同事做过一些讨论，其实我们在云上和云下的一个最大区别就是我们有大概几百人的内核团队，比如说像我们比较大的产品，Polar、RDS和ADB这种产品线，可能发现一些问题之后就直接修复了。但如果传统咱们自建的话，我可能要反馈给社区，社区的修复周期特别长。这是云数据库一个非常好的优势。下一个我们是希望通过这个自治服务，做到自发现、自优化和自修复。咱们的运维和DBA在这个过程中，他可能会更聚焦于业务架构的支撑，更好地去为业务服务。

批量智能运维
批量智能运维这一块，目前做了这么一些事情，实例的自动接入，监控，然后有盯屏能力，我们有一个实时的大屏可以盯屏，还有就是异常的发现，再就是自动优化。自动优化和自动修复其实有一个区别，优化是止血，修复是让这个彻底地或者说短时间内恢复。然后还有一个智能压测做容量评估，然后有审计，然后未来的话我们会做异常根因分析，做自动修复的增强。还有SQL Review的辅助，这些都会做进一步的探索。

云数据库智能运维展望

这是我对下一步可能的智能运维的一些想法：

第一个就是我们的数据管理的全自助。比如说我们研发和测试，包括相关的技术岗位，就自己自助使用数据库好了，我们这边在这个过程中就只需要去做一些审批流程，安全边界的设计。

第二个就是稳定性和健壮性，需要更安全、更稳定、更可控、更透明的能力。DBA可能要去设计一些逻辑曲线，发现问题和规避问题。

在性能优化这一块，应该要充分利用工具来解放DBA和运维的头脑，要去做一些处理决策。

批量运维这一块我认为是异常发现、修复、优化、容量评估，这个是未来要解决的。

还有就是生命周期的管理。生命周期管理未来其实在云上的能力，会做一些像自助开通、释放、弹性、Serverless，让DBA这边能更注重于资源模型设计更高性价比。

我今天分享的内容就是这些。然后其实我讲的稍微有点宏观，但是把整个数据库相关的一些主要的模块其实涉及到了，谢谢大家。（完）
阿里云高级专家王林平：云数据库的运维体系构建