阿里巴巴集团数据库运维经验分享

2021年12月18日，阿里云用户组（AUG）第四期活动在北京顺利举行。阿里巴巴集团数据库运维团队同学受邀参会，向现场20多位客户深入浅出地分享了阿里巴巴集团数据库运维多年来的发展和实践经验，特别是通过介绍对DAS和DMS的使用，向客户提供了建立自动运维的思路和方案。本文根据现场分享整理而成。

运维的工作

大家可能遇到过类似情况：公司刚成立或还是小规模的业务时，肯定是DBA来建库。建好数据库后，接下来业务写完了，我们要评估一下，看看有没有查询。最严重的问题，就是出故障了，数据库挂了，然后DBA就要背锅了。当然，我本人也没少背这样的锅。

实际上，运维的工作就是从开始的部署，到管理，到优化，最终走到业务这一步。

下面这些故事我相信大家都经历过，这也是我本人的经历：
第一个例子，是在之前的公司，业务马上要上线时却突然发现数据库不够，要立即申请，当天晚上就要部署三个数据库，业务要上线。

接下来是误删数据，估计大家都碰见过，就是再成熟的公司，也可能遇到这样的情况。包括前两天我们自己的元数据也搞了这么一下，然后把数据全给清掉了，该怎么办呢？

最后还有是在大促的时候。其实我也特别奇怪，好多业务都今天晚上搞大促了，要今天晚上切流，这个时候你突然发现他从来没有压测过，也根本就不知道自己的业务上线能力在哪儿，结果直接就打崩了，这也很常见，对吧？

以上所有的故事，肯定都是大家遇到过的问题，其中受虐待的就是咱们运维的同学。

阿里巴巴集团数据库运维的发展

实际上，咱们从头往后看，这些故事那都是缺乏一些基础的监控，还有一些基础的运维手段，造成我这个人一天到晚在忙，但是我到底忙啥，有没有价值等其实是看不到的。

从咱们整体运维的发展来看，最早的时候就是刀耕火种，包括咱们现在刚才说的初创公司，可能也没有这种完善的工具管理。我不知道大家有没有这种体感，20年前你如果能够把一个Oracle在Linux上部署起来，那你就有一点点感觉了，就得瑟得不得了。

在这个基础上，要慢慢把一些东西给放出来，比如我的查询的review，或者说我的业务流程上面查一些数据。之前都是要给DBA提这个需求，然后我给你导出数据，我给你做查询，我给你做优化。因此，在这个基础上做出了IDB。咱们最早像MySQL，因为MySQL比较多。而在MySQL这个时代，实际上官方只提供了一个workbench，慢慢地用起来，你会发现这个东西非常不友好。就是我只能连到我的仿真环境，很少有权限能直接连到我的生产平台去做一些基础的数据处理。

那么在这个基础上，线上的数据安全怎么办呢？只能通过DBA。所以在这个基础上，阿里云或者阿里集团，最早内部研究了一下APP，把一些基础的查询能力开放给了他们的开发去自己上传。同时会有一些限制，比如，一些DML的操作你是做不了的，DDL的操作也做不了。

在这些基础的问题解决以后，我们能不能再深一步？在我做简单查询的基础上，可以让业务自己去做一些DBA。就是这种日常觉得非常繁琐的工作，让业务自己去做Cloud DBA。Cloud DBA实际上最早的时候，我相信在三年前有用过的同学会比较清楚，只有一个能力，就是我去发一个查询上去看一下。

接着到17年前后的时候，实际上Cloud DBA和iDB这两个产品本身是合的，后来拆出来变成了两个，一个是DMS-Database Management；还有一个是DAS-自治。这里的自治实际上是针对所有和数据库相关的人，这不是单单针对咱们运维，或者说咱们某个运营。

智能运维的发展

参考阿里集团的数据库运维发展来看，我们可以模拟出智能运维的发展路线，大概是这样的：

09年开始有了智能运维的概念。咱们感觉现在这种自治服务或者说这种自动优化的开源东西有很多，就觉得智能运维好像很早就有了。但实际上，咱们看真正大量应用到生产，是从09年到11年，到现在也不过十年，并没有那么久。

接着，到12年的时候，把这些变更的能力直接下放给咱们的开发同学。那DBA在干什么呢？就做一些简单的review或者是审批。再往下走，我们发现这个审批也太频繁了，那么就把一些简单变更的能力、审批权一并交给他们业务自己，同时对业务做一些行为上的控制，例如一些关键的监控不允许做，一些评估完以后可能会导致大量性能损耗的变更直接禁掉。然后，还是要进一步审批，到16年的时候可以全自助变更，即可以直接由业务自己去变更，变更风险和变更内容都是业务自己把握。

同时，在14年时，引擎已经跑在云上。到16年，最简单的是一个基于Cost的消费诊断。因为大家都知道，咱们有一个审计的能力。我们有个思路，包括做一个慢查询，或者说做一个DBA也好，上去第一眼就看有没有这种所谓的大IO的查询。一般说，对于数据库本身的资源，实际上就是CPU、内存、网络这三种情况。基于Cost的自由诊断，实际上咱们可以讲，就是如果我有了全量的一个缺口，在这个基础上，我实际上是可以去完全复现到当时流量的一个情况。这时候我就可以完全判断出来哪些语句对我的实例影响最大，所以在16年的时候是有一个基于cost的一个诊断。

接下来到17年，自动驾驶的概念提出来了。那包括什么呢？下面一起来看看。

DMS 生命周期管理

资产管理
把资产管理放在第一项，实际上是一个真实的需求。工作中，经常碰到有业务问我，这个库是干嘛的？甚至还有一些更古老的系统，业务还会问这个库在哪儿？这个库我找不着了…类似地，还包括机房裁撤，或者需要迁移。这时候你要梳理所有的数据库，那你从哪知道这些信息呢？DMS的资产管理，可以帮你解决这个最基础的管理需求。

SQL诊断
DMS里边的SQL诊断，实际上就是DBA做的review。类似一个查询给到DBA，请DBA检查一下语句是否合理。DMS实际上就是利用人工智能和过往DBA的运维经验后，把它整合到消费者端里的一个能力。通过它自动来帮你判断你的语句是不是合理，可不可能对线上的生产产生一定的冲击。同时也会给出一个优化的建议，这些都是在事前做的SQL诊断。

数据库开发
对于一个项目来说，数据库是相对底层的一层，数据库的开发，决定了整个系统的流畅性。所以这块要有一个整体上的项目管理的跟进。不是随意下一个变更，或者随意添加一个新功能，需要有一个整体的针对项目的生命周期的管理。

安全
数据安全一般有两种，一种是对外的，像针对网络攻击的数据安全，另外一种，是内部的风险，比如数据误删，或者误变更，包括一些敏感信息的数据安全。

DMS可以通过权限管理，限制敏感数据的泄露，同时不影响开发。审计帮我们记录历史操作，当出现问题时，可以查询之前的操作历史。

集成
数据迁移，比如数据要去归档，或者入湖，或者到其他大数据平台，一般是用DTS实现。任务编排，DMS的本身也支持任务编排的方式。所以DMS整个看下来，是一个从实例管理到数据管理的一个全链路的一个大的系统也好。一般来说，整个数据管理周期就是这些项。

DMS-三权分立
权限管理是授予不同用户不同的权限，免除安全隐患。上层要有一个技术负责人，整体负责更高层的权限，做一个层级比较分明的一个权限的一个分类。

申请数据库时，DMS会根据业务量需求、存储需求和你提供的QPS及业务模型，通过大数据压测，然后整体智能推断出来你的业务大概需要一个什么规格的数据库。

DAS

审计
审计是日常DAS里应用最多的一个功能，出问题时，就直接看审计去追当时做了哪些操作，实际上这是一个最早的决议的能力。

自优化
目前来说，其实DBA比较关注的应该是优化。日常的时候，DBA主要在做的也是优化。

DAS在目前来说，它是可以提供一个基础的语句是否合理、性能是否正常的判断。还有比如说可以自动加索引，或者自动限流的功能。实际上通过自动化工具把这些基础的工作做完以后，你会发现DBA会解放出来，不会每天在看你的海量SQL，对DBA是非常友好的。

自安全
这里实际上涉及到业务流量的一个保护。比如在八月份的时候，我们自己的元数据库被一个热点更新打爆了。当时我就先把这个热点限流掉，那个东西如果要是限不住的话，云上再创建实例的时候就建不出来。所以限流这块也有一个咱们日常的安全意识。数据库是限流制度的最后一道坎，真的需要我数据库来限流了，那就是很危险的一个状态。

自运维
智能压测，就是可以去采集一些基础的产品，然后到目标附近去做一个完全的复现。这个东西干嘛用呢？第一是直接可以做压测的。因为咱们业务模型一般不会变，变化的只是流量。第二是评估兼容性。比如说咱们5.6升8.0，好多业务组有这种需求，所以这块儿是把整个预期内的兼容性和预期外的兼容性都可以直接跑过来，这是智能压测的一个能力。

还有后边的版本自升级和高可用，实际上这就是咱们经常看的一个基础能力。所以一般来说，包括DMS，还有DAS，这两个已经完全涵盖了咱们运维同学日常要做的80%的工作。

自动驾驶
自动驾驶的能力包括咱们说7*24小时这种异常检测、自动扩容等。这个自动扩容，实际上是要和产品去做结合的。如果说有一个产品本身，它就是一个秒级的升降配，这时候DAS的自动驾驶是可以通过压力诊断，去把它马上做出来的。

智能运维的效果

回头咱们再来看智能运维的效果吧。

首先，在实例申请上，无论DBA在哪里，在做什么，都能够在线审批，批完就可以建立实例；接下来，咱们再说误删数据的事情。误删发生后，我可以最快在分钟级帮你把数据找回来，同时还能去诊断一下到底是什么原因造成的数据误删。包括数据库被打爆的情况，以前经常是业务端先报错，然后一路查，最后查到发现是数据库被打爆，但现在有了智能运维和监控，我们应该会第一时间比业务还早发现问题，找对应的业务去梳理问题。

所以基本上以上这些内容，我觉得应该是给大家一个日常智能运维的思路。通过智能运维的系统，把咱们的运维同学解放出来，可以有时间多深入一些业务，给业务开发同学一些建议。运维同学自身也可以再往上走一步。（正文完）
阿里巴巴集团数据库运维经验分享