AI会抢了DBA的饭碗吗？

腾讯云数据库 TencentDB

发布于 2019-11-18 11:10:37

2.4K0

发布于 2019-11-18 11:10:37

文章被收录于专栏：腾讯云数据库(TencentDB)腾讯云数据库(TencentDB)

本文是腾讯云数据库负责人林晓斌（丁奇）在腾讯云Techo开发者大会现场的演讲实录，演讲主题是《数据库智能时代和DBA的职责演进》。

林晓斌演讲现场

以下是上方演讲视频的内容纪要。

在我看来，数据库运维经历了四个大的阶段，前面三个我分别称为石器时代、工具时代、专家时代。

在2008年及之前，少有公司有专门的DBA团队，那时候都统一在OP范畴。

我记得那时候写应用，如果涉及到需要数据库，我的发布步骤里面，还要包含数据库的安装步骤。然后op同学就按照安装命令一行行执行。数据库很多时候被当做应用程序的本地存储，用来替换更早之前，程序员需要自己维护的本地文件存储。研发要自己确定整个机器的内存分配，当然也是因为那时候单机的内存很小。我记得我要在3G的可用内存里，分配好应用进程和MySQL分别占多少内存。

数据库也被当做一个本地进程一个监控，跟应用服务器上的应用进程、agent等统一对待。所以什么线程监控、死锁监控，还都没有。慢慢地数据库的服务开始转给OP，那时候的工作甚至还包括搬机器。

所以我们说，这是石器时代，当DBA特别需要体力。不止是上服务器，查问题也是，一个个进程看过去，那时候故障排查的资料也不多，很多现象最后陷入到数据库内核原理那一步，就变成无头公案。

后来，数据库越用越多，维护数据库的工作就给了专门的团队，DBA团队才开始慢慢成为中型公司的标配。

懒惰促使技术进步。每次安装数据库、迁移、升级都要一点点执行，可受不了，于是自动化脚本、工具、crontab就开始。当然由于DBA团队多是从op出身，操作还是很规范的，虽然脚本、工具多，却也不会乱。但是每次操作都要登到服务器上，很多窗口都是黑色背景。

在我印象里，这个工具时代的主要特征，就是黑屏。

要看个线程状态，上主机执行show processlist；要重启实例，上主机mysql_admin ;MySQL进程crash了，上主机，gdb挂core文件。

那个时候其实已经开始凸显专家的专业性，但是为了看不同的信息，要到主机上执行大量的命令，每个专家的查问题的习惯思路也都还不一样；现在大家流行说devops，其实反过来，在很早之前，op和DBA就先实现了opsdev，也就是运维研发。

他们是第三个时代的缔造者。

从基本的实例生命周期管理开始，再到实例监控，再到实例集群监控、大盘监控……专家时代的特征之一是：agent林立，要采集各种信息，从主机信息、到进程信息，cpu、io、load这些算是通用监控了。

对于每个不同的数据库，又有数据库内的监控，比如MySQL总是要监控增删改查命令数，读写io次数等，而redis更关心mget这类吃cpu的大操作的次数。同时数据可视化技术直接造福DBA。监控数据几乎直接跳过原始数据阶段，进入可视化状态。

为了收集数据并快速展示，消息队列也成了运维系统的标准组件之一。

这些数据被从agent采样，通过消息队列发到存储服务器，然后再可视化展现出来，到web页面上，背景往往是白色的，因此这个时代的特征之一，就是白屏化。当一个公司的DBA团队有了一个统一的白屏系统后，问题诊断的模式开始固定。

举个例子，当然，这些都是示意图。

如果你看主从延迟的监控曲线，看到这种图形，就是在某个时间点后，延迟曲线变成一个45度的线段，然后过一段时间又几乎垂直地恢复，那就是从库应用线程被堵住了。这往往是因为从库上有查询堵住了主从同步线程的更新。

再举个例子，如果你看到一个主库的多个从库的主从延迟，都以类似的曲线上升，这往往表示的是主库的更新特别多了。

这时候有经验的DBA会去看主库的各种更新类监控项。比如这个例子，主库的InnoDB_rows_updated出现类似的突增，那基本就确认结论了。

再看下一个，slave1的延迟增大，同主库的其他slave的没有明显异常。这就说明不是主库的原因了。而且这个曲线也不是45度直线，表示不是事务堵住。这种情况一般就是slave1上的资源消耗过大。

这样下一步我们就是去看cpu占用，果然有增大，然后再看cpu消耗相关的指标，比如这个例子里，读数据行数增加很多，那就是查询变多，或者慢查询多，也能很快得到结论。

这些是在黑屏的时候很难直观的看出来的，也就很难很快得到答案。

也就是说，白屏化带来了三个方向的改变，催熟了专家时代。

首先，解放后端。

很多操作只需要按一下按钮就完成，这完全可以由业务使用方自己来做。比如申请实例、升级实例、SQL审核等等。这样就把DBA从日常的操作中解放出来。工具时代工具即使再方便，也不会允许研发直接上数据库服务器上去执行工具。

其次，形成定式。

在固定的图形界面下，这些查找问题的经验，开始被定式化。那些“一目了然”的分析和解决问题的方法，开始被当做套路使用，而且成功率还挺高。定式化的方法，特别适合积累和传承。

第三，反馈迭代。

白屏能提供给专家数据的，能够快速定位问题；白屏不能提供的，就会颇费周章。于是作为跟DBA同一个团队，甚至于是同一拨人的运维开发，开始对监控系统快速升级迭代，这个过程是正向循环，在一个团队里飞快地积累解决问题的经验。

因此这个时代的特点是：

DBA的数据库经验和运维经验，得到快速积累。
数据库专家经验跟业务研发经验分离，DBA的经验在解决数据库问题时成为稀有资源，个人价值被具象化到跟业务挂钩。
经验易于积累和传承，DBA团队成长很快。
一个快速积累处理问题能力的团队，很容易形成口碑。这对团队也是一个正向的反馈。

虽然这个过程也经常会碰到一些无奈的情况。比如偶尔会被问到一些很简单的问题，比如在白屏化掩盖了一些细节情况下，还是需要直接登录到服务器上去看更详细的数据，再做分析。

因此这个过程偶尔挺累，但是总体都在把控之中，又有技术的稀缺性，而白屏化加分析讨论又能快速定位和解决一些简单的问题。

总体来说，过得还是比较舒适的。

专家经验持续输出，当然问题也越来越复杂。尤其是公有云数据库场景下，用户的使用场景更加不可控。

在公司内部服务的时候，DBA专家，是可以限定业务研发使用数据库的方式的。比如存储过程不能用、触发器不能用、join不能太复杂、DDL等操作必须后端统一处理等等，而在这种限定使用模式下，首先就不太容易出问题，其次就算出了问题，查明和解决问题的方法，也在专家团队的固定模式，也就是套路中。

但是在云服务就不是这样了。数据库的用户是客户的研发团队。一个云MySQL或者云redis的用户，总会按照他们自己的习惯，来使用数据库服务。

而用户反馈问题的时候，往往现场很快就结束了。这时候传统的方法是开始碰到问题。由于没有现场，查问题非常麻烦。

另一方面，客户的应用端到云数据库服务端，网络很多跳，链路复杂，追查问题很难定位。

在这种情况下，全日志和全链路监控，就应运而生。

全日志也成为审计日志，是把数据库上所有的操作都记录起来，包括增删改查，登录行为等等。

这样理论上可以复现任何时刻的现场。当然由于这种粒度的数据量很大，所以往往只能保存一段时间的日志。审计日志可以用来快速定位数据库内的问题。

那么数据库外的呢？

由于链路更复杂，链路上每一个环节出点问题，导致连接失败、查询变慢等等，客户都会认为是数据库出问题了。

这类问题首先是特别难查。作为DBA，客户反馈查询语句慢了，第一时间就会去看sql写法对不对、表索引是否合理等等。需要排除掉很多可能，才会最终怀疑到网络上。这就影响了排查问题的时间。而网络由于有多跳，容易最终查不到确切结论。

全链路监控就在这样的场景下出现。

不论是保存日志里所有日志，还是链路上所有状态，都需要一个大规模、压缩率要很高、写入速度足够快的存储系统。数据量大以后，就可以在数据上做各种预分析操作。

自然的，这个系统就会进化为下面的状态。简单的问题能够自动处理；复杂的问题提供建议；疑难问题定位线索，提供给专家准确的信息——腾讯云数据库团队研发的DBbrain，就是面向这样的能力构建的系统。

这些能力具备以后，就有了更进一步的能力，提前发现潜在问题：我们知道很多业务，尤其是电商类的业务，在节假日、运营活动前都会封网一周或更久，也就是说，其实真的会导致高峰期出问题的哪些慢查询、哪些不合理的表结构，是在高峰之前一周，就已经在线上的了。只不过处于潜伏状态。因为压力不大，这些潜在的危险查询，并没有造成影响，甚至连慢查询都不算。

这个潜伏期，其实也是发现问题的缓冲区。DBbrain可以在这个缓冲时间内，发现潜在的性能和使用问题，通过给出建议的方式，提示客户的DBA和研发做优化，起到治未病的作用。

当然一旦操作简单以后，将监控、建议和操作集中在移动端，就更容易了。