提到云数据库第一个想当然的问题不是云数据库本身，而是云数据库来了，DBA 都没饭吃了。期初我也是这个想法，因为见过不少云数据库的DBA的不专业和对数据库底层以及高可用，接近白痴的知识水平，对于他们，只有两个字，呵呵。
风水轮流转，我也赶上了云数据库的时代洪流，自甘堕落，还是愤愤不平，NO NO NO ，我活的更多姿多彩， 比之前更好玩了。
不过为什么上了云，DBA的职位就不保了的思维定式，深入人心，这个问题先要搞搞清楚。
1 上了云，DBA与数据库底层，以及高可用渐行渐远，属于被架空了状态，如果干上几年的云数据库DBA，估计连实体机上的高可用是什么东西都不知道了，竞争力直线下降。
2 上了云，数据库故障就低了，并且也不需要DBA 去处理了，DBA 天天坐在那里，只需要和云厂商进行沟通就可以了，没事做
3 上了云，云厂商提供的云服务以及智能监控，智能分析，智能操作，DBA只需要点点鼠标，看看指标，喝喝茶水，读读报纸。
最后,云DBA在回归实体不受待见，啥也不会，属于DBA 生态链的底层。
O，really ！
上述理论属于宿命论者对云DBA的定义，实际上是这样吗？
1 认知错误，DBA 就是装装数据库，装个高可用，这就是对DBA最大的存在的错误定义，熟练安装的是操作工。
2 认为云数据库产品让人放心，DBA 看云数据库，就和老丈人看女婿带走亲闺女，只能眼里带着泪，目送着自己的前程远去。
3 云数据库DBA 没发展，什么都不能做主，什么都接触不到，什么都不能操作，只能听云厂商摆布。
呵呵，在我这里，根本不存在。
1 DBA 的工作不是运维工程师，如果只把自己弄懂高可用，在安装一个数据库，作为DBA 生涯的至高点，估计这辈子也吃不上四个菜。DBA 的工作到底是要做什么，自己心里的有数 。
支撑业务7*24小时，安全稳定的运行，这句话看似简单，实际上要做到，不得脱层皮。
我们以 PG 和 MYSQL ，MONGODB为例，
1 PG 在搭建的时候你的SCHEMA 是怎么安排的，public作为默认的schema ，扣10分
2 MYSQL 怎么计算一张表大约在多少行数后，就开始性能衰减，什么公式，怎么计算，不会 扣10分
3 PG autovacuum 怎么能定期跳过某个表，并且在某个时期，可以指定他在轮上autovacuum的操作， 不会 扣10分
4 MYSQL 多个字段做唯一索引，或主键，怎么就能即达到还是多个字段作为主键和唯一索引，但实际上只有一个字段作为唯一索引或主键， 不会 扣10分
5 PG 表怎么设计能避免产生过多的DEAD TUPLES ，提高整体数据库的性能，不会扣10分
6 MYSQL 在不适用慢查询日志的情况下，怎么能获得瞬时和历史的慢查询记录，并且进行分析和类似 PT-QUERY-DIGEST分析的方式，不会扣10分
7 MONGODB 怎么能分析出，每个表占用的内存数，并且计算出，MONGODB 通过内存分配后的内存预留， 不会扣10分
8 MONGODB 设计时，什么时候用嵌套，什么时候用数组，什么时候嵌套加数组，不会扣10分
9 PG autovacuum 过慢，有几个因素产生的问题，怎么解决？ 不会扣10分
10 MYSQL 怎么做到和SQL SERVER 一样，操作事务的时候，在事务操作失败后，部分commit ,部分不commit ？ 不会扣10分
上面这些和数据库的高可用没有半毛钱的关系，但这些都会的主，是高手，还是低手。
所以说，认为DBA就是要搭建高可用就很牛，狭隘了，通往罗马的路，千万条。
认为云数据库让人放心的，呵呵，你用过吗？用过哪家的，是AWS 的还是为人AZURA，或者是阿里云，华为云。
让人省心的主，不存在，首先云厂商的数据库五花八门，依照云管理的方式，对开源的数据库进行了“阉割” 和改造，你必须识别出，他们改造了什么，怎么改造的，改造后，那些对你有利，那些对他们有利，你怎么和他们 argue，争取到自己的利益。
举例开放的参数不够，导致你维护数据库的胳膊折了半只，那你就奋起反抗，说明理由，说明原因，说明他们阻碍了他们的产品的发展。相信没有几个云厂商不会为你正当的 ，为了“他们好“ “主意” 而拒绝你。
同时在云厂商犯错后，你的马上反应，是他的问题，还是我们使用的问题，是他可以改正的，还是根本就是我们需要注意避免入坑的，举例数据库云高可用中，如果主库没有响应了，则此时数据还未从主库传输到从库，那么数据会丢吗？无论是PG 还是 MYSQL ，成型方案千千万，但原理是不变的，即使他是很牛逼的云厂商，照样 呵呵。
与时俱进，学习更多的云数据库的知识，如果你能和他们聊的来，并且能互相促进双方的发展，则人家是很愿意和你沟通和讲授一些知识的，属于互利互惠，人家获得你使用的经验和意见反馈，你的获得更多的云数据库的知识，包含原理等，属于又获得了新生，别眼里就实体机的 老三篇。
至于第三个问题，云数据库DBA没发展，那的怎么看，如果云数据库你没有发展，你实体机的DBA 生涯未必多姿多彩，不是云数据库的问题，是你不行的问题，行的放哪都行，不行的镀金也是一滩烂泥。
怎么能行
1 靠近业务，把握业务与数据库之间的关系，DBA 不是运维，DBA 可以变成架构师，当然你首先不能光会一个数据库吧，如果还是抱着ORACLE 的老资格，那你的确就只能是一个“DBA”。现在的业务中需求点很多，一个数据库大多搞不定，怎么在项目中综合利用多种数据库，降低开发的难度，解决架构的问题，不是你应该考虑得吗？
2 多接触业界的新东西，可能你用不上，但那个是一个解决的方案，看看人家的设计思路，你现在用不上，未必未来用不上，使用产品不要带有抵触的心里，产品的产生，必然有他的需求点，搞清楚需求点，在找需求，不就对上了，此时别人都不OK ，就你知道这个产品对应这个需求很契合，那新鲜的任务不就是你的。
3 云上的数据库运维的特点是什么，要搞清楚，在摒弃了粗放式的发展模式，必须让自己静下心，往细化的方面发展，细节也可以决定很多事情，甚至可以决定一切，找到自己的发力点，并顺藤摸瓜。
4 让自己从一个DBA 变成，架构师，DEVOPS，公司运行数据库的标准的制定者，培训者，需要做的工作很多，给自己的定位多一些，不是遇到问题就加一个索引那么简单，就叫优化，做人可以单纯 ，做事就别那么单纯了。
5 多出来和各种数据库的社区学习，沟通，多替换脑子里面的东西，生活不只是酸甜苦辣，可能还有来自社区或者某些大牛的 “电击”， 让你瞬间能感悟良多。
6 多熟悉云数据库的原理多与厂商进行沟通，获得学习的资料，不要认为他们都对，勇敢的提出自己的问题，质疑，甚至是让他们“整改”。 掌握多种云的特点，未来企业上云减少费用是大概率事件，掌握多个云的特点，产品的特点，是会为未来更加激烈的竞争环节中获得分数的。
综上所述，云数据库吃了DBA的岗位 ？？？？？ 新的岗位上更自在。
