浅谈DBA技术栈的变化

这是学习笔记的第 1778篇文章

之前写过一篇 DBA技能发展变化小结，效果还不错，今天突然想到了一个点，那就是DBA技术栈的发展，我们来简单聊一聊。

在文字面前，最好的方式就是图了。

这是一个相对早期的DBA技术栈的比例图，早期的DBA，对于数据库方向的技术的要求很高，那个时候会开发技术是一种辅助，但是不是必备，相反对于数据库的技能方面的要求除了基本运维的部分之外，还有运维优化。相对于早期而言，对于业务的支持很多都是偏于被动，处于流程支持的末端，一般都是除了问题才找DBA.

这个阶段，相对来说，开始有了较大的变化，一个理念就是分布式和云，分布式让数据库的技术方向也有了新的变化，很多原来的Oracle业务会由MySQL的方案来替代，或者说是商业和开源的一个重新平衡，同时云厂商的推动，让基础运维的价值被平台化，所以很多基础运维的价值没有以前那么高了，相对而言，一些数据库开发方向的技能要求会高一些，比如Oracle中的pl/sql，MySQL方向的运维开发等，这个时候对于业务的输出还是相对有限。

在这个背景下，云开始逐步有了落地的场景，资源开始不会成为瓶颈点，产品的迭代速度也会越来越快，业务多，服务多，自然就需要有更多的技术支撑，比如自动化，半自动化的运维支持，原来的数据库技术方向会有大的变化，从基础运维，运维管理的视角更多走向了运维优化，所以看起来比例差不多，但是里面的内容却在潜移默化中刷新。

技术会越来越成熟，需求也会随着技术成熟而变得越来越复杂，运维需要提供的是一种服务，而不是技术自我感动，很多时候为了产出业务价值，需要更好的支撑业务，效率更高，响应更快，对于技能的迭代来说，传统的运维技能都在刷新，比如原来的开发技能方向差不多就是shell,perl了，但是现在可能会是Python,go,java等开发语言来提供更全面的支持。而数据库的内核技术方向的关注度相比从前会少很多，而在技术架构方面则会有较大的需求。

所以有些大厂已经不叫做DBA了，有些会以新的名称数据架构师来代替，或者其他的数据类职位，核心是把“库”字脱掉。

许多企业现在都是两极化，要么需要高潜新人，要么需要有经验的专家，反而介于两者之家的人会比较尴尬了。

每每感觉懒惰和吃力的时候，就想着再努力一把，数据库技术的发展会越来越成熟，需求会持续存在，但是对人的要求会越来越高。