本文作者：林晓斌，网名丁奇，腾讯云数据库负责人。
今天给大家分享上周在 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和研发做优化，起到治未病的作用。
当然一旦操作简单以后，将监控、建议和操作集中在移动端，就更容易了。运维同学不用在婚礼的时候还掏出笔记本，登录vpn解决了，一些简单的操作，可以在手机端直接完成。这也是DBbrain结合微信的优势，会提供给运维的便利。
那么，到了智能时代，云数据库+智能诊断系统，会抢了DBA的饭碗吗？
今天我们分析了数据库运维发展过程，大家可以看到，在前面的几个阶段，随着工具越来越成熟，解放了一部分低价值的工作量，DBA的价值一直在提升。那从专家时代的白屏化，到智能时代，其实本质上，也是工具成熟，减少低价值工作，跟之前是没有区别的。
从拼体力到做工具，通过更快的满足业务需求，去掉的是搬机器的工作，去掉的是一行行敲命令的工作，聚焦于更高的效率；从工具化到成为专家，通过更快地定位问题，去掉的是登录机器，执行和工具的动作，聚焦于专家经验积累；到了智能时代，去掉了基本的性能优化、问题发现工作，聚焦于复杂的数据库问题，聚焦于业务架构，优化架构设计，这个是更高的业务价值。因此我认为数据库运维智能时代的关键词是业务价值。
其实业务价值是贯穿于各个时代的，所有的工作都最终是服务于业务的。只是在智能时代，DBA对业务价值的贡献，因为云数据库和智能诊断工具，会凸显得更加纯粹。
