转载

dba将死，云架构师即将到来

最近在招人，在招人的时候，有不少反思。作为一个dba，我们这个行业的趋势如何，我们的出路如何。

（一）首先看到的一点是，目前越来越多的公司使用了云服务，自建机房的企业越来越少了。上云之后，很多企业对数据库的使用方式，是直接使用了云厂商提供的RDS，数据库服务，而不是在云上自建虚拟机再安装数据库。

除非是一些很特殊的场景，需要通过自建来实现，比如跨云的postgresql实时同步、多master的MGR（不过这个aws也实现了）。

上云、使用rds之后，基本解决了几个问题：

1. 多可用区的架构，实现了数据库的高可用。

2. 数据库备份，rds服务本身就自带这个服务。而且可以很方便的实现任意时间点的还原。

3. 简单的数据库监控。基本的cpu、连接数、内存使用率、主从lag这些监控指标都有了（当然，在深入一些的比如等待事件、长事务、没结束的慢查询、最大的表缓存数量、10分钟内产生的wal大小等等，这些是没有的）。

4. 数据库迁移，云厂商也提供了很多迁移工具，比如阿里云的dts，aws的dms，可以实现迁移、同步、发布/订阅的功能。

另外，由于rds提供的只是数据库服务，dba无法登录到数据库主机上，因此主机硬件的一些内核参数调整，也基本无缘了。

（二）其次，我们可以看的，现在越来越多的公司，特别是互联网公司，采用的是框架式开发，如ORM框架：


ORM：是一种为了解决面向对象与关系型数据库中数据类型不匹配的技术，它通过描述Java对象与数据库表之间的映射关系，自动将java应用程序中的对象持久化到关系型数据库的表中；

使用ORM框架后，应用程序不再直接访问底层数据库，而是以面向对象的方式来操作持久化对象，而ORM框架则会通过映射关系将这些面向对象的操作转换成底层的SQL操作；

本来ORM框架，是用来屏蔽底层数据库的差异的。结果用着用着，就变成开发不用管sql，只需要通过代码实现就可以。到了后来，一段坏sql是怎么来的，如何产生的，能否加hint，开发完全不知道。

上面的两点，是为了说明一个观点：

dba工作的主要两块业务：
系统级，这个工作被云吃掉了。
代码级，这个工作被框架开发吃掉了。

另外在和一个朋友聊天的过程得知，越来越多的公司上云之后，已经没有招dba的HC了，大部分的数据库运维工作，可以有运维开发人员一起完成，稍有难度的数据库问题，也可以交由云厂商分析解决。这些公司需要的，只是云管理员，或者云架构师。

从google trends搜索了dba jobs和dba，可以一定的角度反映这个问题。

dba将死，云架构师即将到来