DBA也得转型，从大众汽车说起

下面是一段文字，

在那里，世界上最大的汽车制造商——大众，再度对自己动刀展开大刀阔斧的变革：宣布组建自己的软件部门，这也许是传统汽车产业中最大的软件研发中心。

这个新部门的名称叫做“Digital Car&Service”，一位名叫 Christian Senger 的哥们出任该部门的负责人，同时兼任大众集团“Digital Car&Service”部门负责人。与此同时，Christian Senger 成了大众品牌乘用车的董事会成员。

这是今天我刚刚读到的，对没错大众汽车要玩软件了。世界变化快，你今天还在追赶某汽车大佬的造车技术，转眼他就变个❤。

作为一个数据库er，其实变革不也类似这样，10年前我还只能说出的主流数据库的名字不超过3个，现在的我可以随便就说出10个并且还玩过5  6个，即使这样面对现在的竞争我也不敢抬头说，I am ok.

这就涉及一个DBA转型的问题，怎么从传统的应试DBA转换成服务型DBA在进一步变成数据库的架构师。 可能反对的声音马上就响起。

你会多少，你业务量有多少，你好好管你的数据库不就完了。

非也非也，时代变革了，站在原地如同等死。我还不想那么早光荣。

说说最近我的体会，以前的dba和政府机构一样，等着开发过来找你，审核，修改意见，在审核，在修改，在审核来来往往，浪费时间不说，两者的关系也不会好到哪里。 其实开发对数据库的需求没有那么简单，如果从业务开始，到需求，到分析到编码，一个DBA都跟过来，你就会改变对程序员的看法，一个个看似不合理的表设计，存储过程都有他的故事，而之前dba的做法大多袖手旁观，直到程序上线，一堆bug。最近的一段工作给我的启发，就是在一个需求的开始，如果DBA跟进，就会从DBA的角度来引导开发，在繁花似锦的需求海洋里面，和繁重的程序设计里面，引导出多种经济，不失态的设计，甚至能在双方的讨论中找到数据库和程序最完美的契合。

这就是我认为的变，从等，变为主动出击，在错误的起点就将能想到的坑，填上。这是一个双赢的过程，中间双方都能得到进步，DBA更懂业务逻辑，更贴近开发，如同缓释药剂，而不是到达最后去下猛药，进行抢救。

第二，DBA要满足开发的需求，如同开发尽可能的去满足业务的需求，需求虐我千百遍，我待需求如XX。作为程序的一个归宿和起始点，DBA在选择数据库，或者数据库中有的先进的技术，并且如何运用到程序开发中，如程序员习惯使用传统数据库，而某项需求，你发现nosql,newsql类的数据库更适合，可能会提高程序的开发速度，减少某些坑，这其实倒是DBA更大的价值所在，而不是守株待兔，你说那个就用那个，或者是你就一直用那个。

主题的思想就是，服务需求，而不是程序迁就数据库，那程序员一定不会多觉得DBA的存在是一件必要的事情，或美好的事情。

不断更新知识，在最近和程序员的一段摸爬滚打，程序的架构，程序的开发思路一直都是变化的，并且变化的速度也越来越快，以及里面使用的辅助中间件，变化非常快，更快的随着需求变化的设计思路，设计思路变了，数据库表设计不变的去适应，这样的联姻多半不会完美。

数据库在传统的开发心里是百年不变，就老三样。DBA嘴里就那几条规矩，估计大部分开发都是这么想DBA的，实际是DBA的日子，并不比开发好多少，从硬件，到系统，到简单的脚本，程序，数据库底层原理，上层花里胡哨的各家功能，各种failover,高可用的数据库架构设计，中间件使用，数据归档，数据库安全，加上DBA十几年的定位烂语句的能力，修补他们的能力，再到沟通，交流的软实力，最后为了不被淘汰，也要继续学习新型数据库，数据库原理，眼泪也是哗哗的，没有容易的事情，如果你觉得容易，只是没有深入。

现代数据库上云，新型数据库免维护，少维护，数据库AI，paas,各种花钱就能买来的工具，其实留给运维DBA的时间不多了，路怎么走，是继续走老辙，还是碾压出新辙，只能靠自己。