最近在招人，在招人的时候，有不少反思。作为一个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 jobs和dba在5年内的热度，是不断降低的。
那么dba的出路何在？
我个人认为，在未来5年，除了头部企业，也就是云厂商，其他大部分企业将不需要dba这个职业。dba可以有如下选择：
1. 去云厂商，利用自己本身对操作系统、网络、存储的熟悉，对数据库技术的熟悉，对数据库内核对熟悉，发挥作用；
2. 在企业内部，熟悉云架构，熟悉整套基于云服务的持续集成持续发布流程，懂得利用云厂商的各种工具，实现数据流转，成为云架构师；
3. 在企业内部，结合企业业务，进行数据治理、数据整合、数据建模，挖掘数据价值，成为偏业务的数据架构师；
另外，随着基于云的微服务和分布式架构兴起，或许混沌工程测试工程师，也是个不错的选择。关于混沌工程，不妨可以看我最近写的这篇博文。
另外，韩锋老师的这篇《DBA职业发展之路》，也推荐给大家。里面非常详细的介绍了dba的职业选择路线。
云计算、人工智能其实并不遥远，只是我们可能还没察觉到未来已来，就已经被时代抛弃了。你怎么看？