题目很炸裂,我知道。这世界说真话的越来越少了，大放厥词的是越来越多，比如说上云后,AI,数据智能替代DBA的，这里我只想说一句，放屁！
我就以一个事例来粉碎那些大放厥词的人的胡说八道,昨天上午因为一组PostgreSQL数据库切换可用区的问题,我沟通了一个上午，更换可用区需要先升级小版本,按理说升级数据库那不是太简单了，上云了点击一个按钮就完毕了，有AI就更好了,不连人都不需要了吗？
我就一句话问说这话的人，你干过吗？来我这个干过的给你讲讲流程是怎么样的
1 确认需要升级的数据库的主机
2 列出升级的计划，和与业务冲突的地方，以及时间安排
2.5 查询当前数据库的到升级版本的check list ,看有没有与当前业务运行冲突的部分,比如SQL类的改变,或者对性能上激进的优化等等,这些都要备注,并前期沟通.
3 进行操作测试和升级后的业务稳定性测试
4 进行生产的边缘服务器的升级，升级失败，根据提示开单，沟通。
沟通，提供必要的信息，等待回复
沟通中，对当前的问题进行深究，升级的方式方法，以及版本信息的再次确认和发现问题后的后续问题的提出。
发现是产品方有BUG。
发现新问题， 数据库中存在dblink,根据升级条例无法升级,升级数据库版本需要和客户沟通dblink使用的方法
客户确认,dblink 不在使用列表,不需要考虑dblink,客户要删除dblink,发现权限不够,虽然已经使用了最高的管理员权限
服务确认,发现是升级版本后,将原有的owner覆盖为,云系统的管理员的权限,客户无法删除,可以提单删除
客户和公司开发部门确认没有dblink的功能在使用
5 升级小版本的渠道与升级版本的渠道不一致,需要走人工API界面
6 客户不知道这个界面的使用方式,进行沟通学习,误操作 产品了
7 客户通知服务人员,误操作,需要终止升级操作
8 服务人员终止操作
9 API 界面并不智能与贴近正常人工使用方式,客户要写一个自己的操作方案让服务人员确认
10 确认完毕,可以终于可以确认操作的正确性.
此时已经从9:00到11:00了(这还不算前天下午沟通的3个小时),这还只是一个数据库事例的小版本升级,OK ,我后面还有41个事例等我呢,问题到此为止,我连一个产品都没有升级成功呢! 更有意思的,42个实例,我可用区迁移的方式就分4大类,6小步骤. (比我升级实体机还麻烦和累)
写到这里,那些在说 AI ,人工智能的,在鼓吹,以后没有DBA ,都可以自助服务的People们,我们都来看看是那些人
1 你们没有干过DBA,或者很长时间离开了工作岗位,只是通过臆想来想出来的,上云后不需要DBA
2 别有用心的人,通过这样的方式.来让企业和核心数据库管理人员之间产生隔阂,好渔翁之利,比如智能化的产品收割一波,或者脱离了专业DBA ,好对企业进行肆无忌惮的蒙骗和财富收割. 你们自己的产品什么样 ,自己心里没点数吗?
3 纯粹的博眼球的文章,比如某国外的,淡着他就好
事实上了云的公司和DBA 是怎么样的,是完全智能化了,是完全脱离DBA了,有没有人说真话,我们这里上云了devops 二开的工作就没停过,60%都是对接云数据库不专业和无法满足我们需求的工作。同时以为上云了，就脱离主机了，你不要忘记不懂云上的架构，你一定被人骗坑宰，那是全方位的，有那个大公司，那么傻都信任你云上的说辞。只能请道高一尺，魔高一丈的 狠角色和你们一起纠缠。怎么在云里面做偷手，怎么计算使用那种方式，省更多的钱，用什么技术打败云的另一个技术，怎么戳破你胡说八道的技术解释,怎么和云上的people进行有效沟通,DBA的工作减少了A ,但添加了 B C D ,并还需要变得更聪明和能应对各种的质询,那妥妥的是从把我这个 I 人 变成了 E人, 让我真的是 INTJ 全面发展。
还有，那些写智能替换DBA，或者那些云厂商的销售们，你们哪个能说出一些实际的案例，（除了硬件不用维护），其他的部分你们哪里智能了 AI了，那些不都是你们，乱收费的新篇章吗？
希望一些企业的领导者，也不要光看一些，嘴炮和胡说八道的写手的满嘴胡天，你到底下看看，你上云了是如他们所说的那样，安然无恙吗？没有我们，你和地狱的距离一步之遥！
Austindatabases 公众号，主要围绕数据库技术（PostgreSQL, MySQL, Mongodb, Redis, SqlServer，PolarDB, Oceanbase 等）和职业发展，国外数据库大会音译,国外大型IT信息类网站文章翻译，等，希望能和您共同发展。
