经济学原理指导 “云DBA” 体现高于现有DBA的价值方法

最近比较忙，没有时间把上次的《经济学原理指导云DBA价值利益最大化》文字化，有些同学一直问到底那天北京大风那天到底都说了什么，今天总结一下。

经济学原理指导云DBA价值利益最大化

在我们的工作中，不少技术人员容易走一个路径，或者大部分技术人员都愿意或必然走的一个路径，只会低头走路，不会抬头看天。这样的人非常多，吃亏的更多，这都因为，只会技术思维，方向是错误的，你越努力你越死的快。

今天我们要来说说一个技术人员，在工作中如何体现自己的价值，做一个有智慧的技术人员。

脑子要活

脑子要活

在技术人员的工作生涯中，早期是技术的积累的阶段，这段时期着重术的积累，具体也就是数据库技术的积累，比如常见的，SQL优化技术，数据库的调优，安装，高可用，等等，因为这些都是初级数据库技术人员最容易接触和掌握的，这些也是数据库通用的技术门类。而到了一定的年纪和接触的知识多了，掌握了更多的工作经验，工作的方式就要从术的学习，逐步往道上进行转移了，如数据库选型，数据库技术方面的比对，数据库的SRE，这属于术积累后的归纳的状态。如果早期技术人员“挑食”，属于他的道的总结的时间就会推移，因为见的世面少，自然就会阻碍知识的素材积累，导致道的总结延后。

为什么得出这个结论或者有这样的结果，这就要从工作的目的来说，每个人工作的目的是什么？ 大部分人都是要通过自己的工作来养家糊口，或者走上职业生涯的巅峰。从知识的角度，DBA，乃至IT技术从大的知识门类来说，与更广阔的知识门类如：哲学，经济学，人文等相比都是渺小的，这些大的理论和学科是指导社会，人类发展的理论。所以在术的积累后，就要混合着这些通用的理论来发展自己的道。

经济学10大原理

经济学10大原理

在发展的道路上，不少人都会质疑自己，自己的付出和收获不一致，不匹配，我会装了MySQL,PG,ORACLE ,我会做这些数据库的高可用，解决很难的BUG问题，甚至我可以发现BUG并给官方提出问题，我已经很专业了，为什么我的收获还是不多，或自认为不匹配。

付出与收获

付出与收获

到了这个阶段，通过数据库技术，或者IT技术是无法回答你这个问题的，IT技术不属于普世真理。今天我们就用经济学的10大原理中的两条来解释，云DBA的工作方法和获取更大价值的方法。

首先你要明确，你的价值不是你自己定义的，是你服务的人，或者提供你薪酬的人所定义的，你所付出的产生的价值的大小也是他们定义的，这点你不要搞错了。

在工作和生活中我们持续对一件事投入，最终成为这方面的专家，从经济学的原理中，持续不断投入，从经济学10大原理的边际效用原理中解释，超过一定限度的努力是无效或者在持续降低你的努力所带来的价值，在经济学里面这叫 “边际效应递减”！

边际效应递减 (Diminishing Marginal Effect / Diminishing Marginal Utility / Diminishing Returns)

边际效应递减是一个非常重要的经济学原理，它指出随着某种投入量的持续增加，在其他条件不变的情况下，增加的每一单位投入所带来的额外效应（边际效应）会逐渐减小。 最终，边际效应甚至可能变为零或负值。

（从这条原理可以推到出，某些人在错误的方法下越努力，越倒霉的道理）

云DBA的工作价值

云DBA的工作价值

这点在云DBA上带来的体验非常明显，因为上云后，一些传统的工作，如备份的搭建，数据库的安装，甚至简单的SQL的优化等工作都在持续的被替代简化，我们除了抱怨以外，当然抱怨是无效的。我们还可以做什么，我们需要追求自己的价值最大化，也就是找寻边际效应递减前的 X Y 轴的顶点的位置。

这里有一些同学，提出我们将线下的工作方式拿到线上来，比如我在线上还在用ECS装数据库，搭建高可用，我延续我之前的路径，这样我就不会被替代了。

但从经济学的原理中，这恰恰是在自断后路，或者把自己往死路上逼。为什么这样说，我们这里就要讨论你存在的价值。

首先上云后，你的价值并不在数据库的传统运维，传统的数据库产品无论是 ORACLE , PG, MYSQL ，SQL SERVER 这些数据库在线下都有自己无法解决的问题，如主从节点的数据无法在数据写入的一刻一致，在很多情况下都要通过业务，应用，程序，架构来解决。数据库装机侠在线下数据库运维是一个必选项，这类运维类的DBA 是有市场和价值的，虽然价值不高，尤其在公司稳定运营了一段时间后，这类DBA会被消减或“被离职”，企业管理人员不是傻子，一个企业稳定后，是不会留下只会安装数据库高可用，等等的运维类DBA，他们不会在为企业产生后续的价值，这类DBA 哪怕在传统企业，企业稍微有变动，他们就是被“下架”的首选。

到了云上，还以此为生的人员，很快就会没有市场，云上的数据库运维管理比他要出色的多，这样的人的价值沦陷的会很快，这类人有几个特征

1 数据库就会1 -2个

2 数据库理解层面永远不会和业务有关系，和架构有关系，和开发有关系

3 拿的出手的技术，大多是数据库高可用，安装数据库，等可容易复制的简单技术。

所以云上的DBA人员必须选择更换赛道，寻找新的体现价值的方式。

1、解决原有数据库技术架构无法解决的问题

2、通过更新的技术来满足业务开发的新的需求

3、通过更新的技术来降低运营成本，这里包含人力成本

再次提示，云上自建数据库的价值在哪里？ 自己好好想想，解决了什么问题，老板认为你有没有价值，值多钱？？？ 可持续吗？ 可复制吗？

以上问题实际上在 《打破DBA的局限：像架构师一样思考，提升你的技术价值-- 访蚂蚁金服P9 朱春茂》 这篇文章有体现，可以看看蚂蚁金服P9的架构师对这方面的理解和认知是怎样的。

既然原有的数据库技术有无法解决，业务开发技术的问题，或者架构复杂性的问题，寻找新的技术解决原有的问题，所带来的价值远远要高于，一个DBA装机侠所带来的价值。

举例

举例

如上中，如果坚持使用POSTGRESQL，无论是自建，还是RDS产品都无法解决POSTGRESQL数据库原理所带来的自身问题，当然更换成MYSQL也无济于事，因为还有OLAP的需求。作为云DBA必须具有拓展的意识，也就是要走到架构师，开发人员的前面，通过云上数据库自有的新技术来解决问题。

举例，我们采用了POALRDB ,TDSQL, GAUSSDB， 这些数据库产品部分兼容POSTGRESQL的数据库产品，同时这类数据库产品本身都具有 HTAP的解决方案，所以第一个问题，OLAP的问题可以通过这些云原生数据库自有的HTAP的方案来解决，

同时令人头疼的 VACUUM操作，在这些云数据库上，如POLARDB 通过共享存储POLAR STORE的更高效的IO，存储层的辅助优化VACUUM操作，更散的数据存储等来降低VACUUM本身带来的集中爆发IO带来的性能困扰的问题。同时包含 TDSQL FOR POSTGRESQL 这类数据库产品都有读写节点，这些节点都有多个只读节点，那么大量的读将只产生于读节点，写节点的在VACUUM带来的消耗是不会影响读节点的，且部分数据库产品解决了写库和读库的数据一致性问题，华为的 guassdb for POSTGRESQL 使用的是 GAUSSDB 自研的 Kernel 版本，华为云可能有能力在存储引擎层面进行更深度的优化，例如改进死亡元组的标记和回收机制，从而更高效地进行清理。

同时辅助本身POSTGRESQL我们掌握的VACUUM 优化的技术，很可能原来的问题就不在是问题了。 但这些都是要使用我们今天提到的第二个经济学原理中的一个分支。

尾部事件

尾部事件

尾部事件是经济学10大原理中的 第四大经济学原理，政府行为有时候可以改善市场表现引申而来的，尾部效应的解释为，将努力的重点进行打散，很多事情做了100%但获得收获的可能只有10%，所以我们需要扩大我们的努力面，也就是做200% ，可能获得会超过10% 。 这点在巴菲特的身上可以找到具体的案例。巴菲特在人生的投资中，只有10%是获利的，但如果他不去做100% 或者 1000% 可能他连10%的收获都没有，换算到DBA身上，如果云DBA还只在传统的数据库上动脑筋，如ORALCE，POSTGRESQL ,MYSQL 等传统数据库身上，获得的收益会越来越少？ 因为你会的太少了，能解决的高级问题，太单一了。

DBA 怎么变得更强-应对架构师提出高并发问题？

巴菲特

巴菲特

解决问题的能力

解决问题的能力

云上DBA比拼的是解决问题的能力，和解决问题的方法的最优选，而不是某个专项的技术，只有掌握更多的数据库产品，才能给出更多的解决方案，在更多的解决方案中寻找最优解，也才能在日益竞争压力变大，和工作项目被剥夺的云上环境中，获得自己能持续站立的“能力”。

云DBA，应该具有更多的数据库产品知识，对公司业务的特点分析总结，与对应的数据库产品匹配的能力，及运用新数据库解决原有问题的能力。

云DBA的价值

云DBA的价值

当然这里需要注意的是，任何极端的做法都不会获得好的结果，我们还需要理解

1 云厂商通常不会公开所有底层的优化细节。 这些都是它们的核心技术竞争力。

2 不同地域、不同版本的产品，其优化策略可能也会有所差异。

3 用户在使用时，仍然需要关注相关的监控指标和配置选项，并根据自己的业务特点进行调整。

4 云厂商的云原生数据库都有自己看家的本事，跟踪这些新的技术能力，并进行评判针对当前的业务，或架构是否有利，是云DBA需要进行的工作。

选择更加靠谱且可靠的云技术，是云DBA的另一项功课，也就是选择中不踩坑，少踩坑的能力，这点今天就不说了，找时间再说。