云和自治 会 “杀死” DBA

多年前就有很多某项功能会剥夺 DBA 的职位声音，包含 云，数据库上云后就不在需要 DBA ，或者相关的工作者，将一切都“扔”给云服务厂商。

起初我也是很反感也很怕这样的声音，并且希望他们都能闭嘴。但总不能掩耳盗铃，什么都怕。自己长了脑袋，多思考一下，多问几个问题，总比脑子在别人的，裤裆上挂着要好。

1 说这些话的人是谁？

无疑说这些话的，有两方面，1 数据库厂商，尤其ORACLE 的厂商叫嚣的厉害，听到最多的声音也是从ORACLE 发出的，上了19C 数据库自治，不在需要高水准的DBA ，一切让ORACLE 数据库自己来管理。

2 云厂商，数据上云后，云负责管理你的数据库，你的程序，你的一切，保证SLA 4个9,甚至更高的水平。

相信的人也不少，甚至一大部分的老DBA 都开始想着，自己的后路了。事实上想想这些话的目的和要“生效” 的人群就知道这里面的“可笑的地方”。

1  数据库自治，其中提出可以对数据库进行优化，进行自主式的管理，而说出这些话的人，很少是来自于资深的 DB LEVEL ，大部分都是某数据库厂商的顾问和开发人员。  

这样有利的有两点，1 提升一些没有DBA 的客户的 心理防线，由于成本问题，DBA 一般都不会太便宜，因为DBA 是一个需要经验积累和自我强驱动的一个工作。为了降低成本，将公司的重要的数据库的安全，和文档，交个一个资深的DBA 是大多数大公司的选择，因为实在是承受不起 数据上任何的丢失和损失所造成的风险。

而大部分小公司一般从来对DBA 只能是听说过的水平，所以用上这样的数据库，或许心理可有有点安慰，或者甚至是“自豪”， 我们公司已经不再需要 DBA 作为一个卖点。说这样话，做这样事的，大多是没有吃过亏，或者吃过后，还是付不起一个DBA的salary， 只能继续酸了。

如果一个数据库能进行自我管理那如何管理，这一定和 AI 和机器学习有关，想想里面的道理，一定是做了多个性能的锚点，和历史性的比对，然后对数据库进行一个相关的参数调整，以及某些关键点的自我处理。但这有多靠谱，以及这些点到底是不是你的单位，以及你要部署数据库上的软件上做出来的，那就没有人知道了，不出问题那是幸运，出了问题，或许人家一句，你的这个情况特殊，或已经超出自治的范围，而被掩盖。

2 数据上云，数据库上云已经很多年了，并且有的报道说中国90%的数据都上云了，且不说这90% 是怎么计算出来的，先说说什么数据可以上云。

1 国家监管不到的，金融，医疗，征信，等这些数据库上云是有要求的，尤其在当今，个人信息盗取泛滥，这些行业的数据要上云，哪里是那么容易，你先得看看，国家允许你上云吗？  所以上云的数据也是有范围的，不是什么都可以上。

2  上云的都是什么数据，在经历的几家公司，基本上都没有将业务数据上云的，或许是公司体量都不小，或者触及关键行业，而数据上云就能保证数据库的安全和稳定，相关的失败案例就不多说，大多数的公司的数据上云也大多是非关键业务的数据。

在这样的情况下，云终结了DBA，未免有点言过其实，另外即使是数据上云，也是有大把的公司继续雇佣 DBA 来操作云数据库，如果狭隘的将DBA = 运维DBA 可能会得出这样的结论。而实际上 DBA 本身的功能不仅仅是运维，DBA 可以参与软件项目，提供相关的软件架构中，数据库的架构和相关软件开发中涉及数据库的一些专业支持，提高软件的开发的速度，降低一些人为因素造成的设计缺陷等等，这些万万不能是 数据库自治和 云数据库能给你带来的“附加值”。

曾经听到某个“笑话”，某单位将数据上云，使用了某云的MYSQL数据库，而在使用期间，频繁出现故障，系统运行缓慢，而打给云服务商后，给出的答复是，数据库的性能与工作的负载不匹配，大量的查询都是在走I/O，被告知是内存不足，让客户提高一个数据库的等级，提供更好的性能。

而后面这个单位在提高一个等级的服务器后，发现故障没有好2天又开始了，后来实在无奈，只能找到 其他公司的DBA 给看看，结果是，这个云的MYSQL 的INNODB_BUFFER_POOL_SIZE 默认是128MB ，而且你给多大的内存，默认都是128 ，这是需要你自己的调节的，而不调节，加在大的内存也是无效。

所以即使是云时代，你依然需要一个DBA ，为你弄懂那些厂商的套路，让你少吃点亏，少走点弯路。

所以一个相关的职位必然有它存在的必要，但反过来，如果DBA 这个职业停滞不前，本着千年不变的思维，那这个职业还会继续，而抱着这样观念的人，就会被淘汰。所以云和数据库自治不会杀死 DBA 这个职业，但会杀死知识更新慢，停滞不前的DBA。淘汰年年有，千万别到我家，咋办，run  keep moving.