以前在甲方做DBA的时候，每年一个很重要的KPI就是成本控制。去年业务增长了10%，如果数据库的成本涨了20%，那这项的分数恐怕就高不了，除非我能拿出更加有说服力的报告。久而久之，也让我养成了很多习惯，用研发或者业务项目经理的话形容，就是我越来越抠了。然而公司系统的使用成本，和个人消费还是差异很大的。奶茶我用蜜雪冰城替掉更贵的品牌，咖啡用便利蜂机器打出来的替掉星巴克，实际上对我不会有太大的差异。然而公司的数据库使用成本，如果在不该省的地方省，拆东墙补西墙的时候，很可能要花费更大的代价把东墙补回来。分享几点我过去成本控制的心得，也许对各位有所帮助。
1.合理利旧
在信息化时间比较久的企业，大量老旧设备是不可避免的。而且很多公司有严格的规定，生产环境的设备使用年限不得超过x年。例如金融行业，核心系统可能不能超过4年，每年年初就会有专门负责的同事发邮件，今年需要下线的设备列表。对我来说，最痛苦的莫过于看到服务器和存储需要替换。这些都需要以停机作为代价。
但是有趣的是，替换下来的设备怎么利旧，往往没有那么完善的机制。我就亲眼见过下架的服务器放在库房两年，直到被拉走销毁。因为这些都是固定资产，所以报批流程到销毁往往按月甚至年来计算。后来我问领导，库房里的设备能不能拿出来用，领导说这些机器过一段可能就批量销毁，你拿来干什么？我说拿来测试总可以吧，这么多POC短期需求，总不能用咱们的新设备。领导同意了，因为不涉及到生产环境，所以流程上也容易很多。当周就把机器重新上架配好ip，在测试环境用了起来。
再后来甚至一些非核心系统的灾备服务器，都用它们来顶两年。性能一般不需要考虑太多，只保证可用性即可。甚至一些性能还不错的服务器，我们可以把它灾备以外的算力拿出来做UAT用，一年下来我写述职报告的时候，列举了具体的数字和使用情况，客观上给公司确实节省了成本。
2.合理维保
数据库的成本除了硬件就是软件，尤其Oracle按照cpu收费的时候，每年结算价格的时候，不了解的同事都会问，怎么这么多？如果用的是一体机，那更了不得，软硬件都加起来费用更是高的吓人。
我们曾经有一台老旧的Exadata，当初买的时候花了1000多万。用到第五年的时候已经成了灾备+UAT的的用途。除了买原厂维保，往往还得买人天服务来应急，一年下来也几十万，这钱都可以买不少硬件或者更多的软件授权。但是因为当初购买成本太高，而且自身性能即便放在当下也仍然还可以，作为公司固定资产走报废流程总觉得不太合适。于是我和领导商量，干脆找了个集成商，把服务范围圈定在更换备件和基础维修上，SLA的级别要求不高，一下子省出来不少预算。把这个钱摊到了存储里，让每年采购存储扩容维护等等更加充裕一些。
对于一些已经业务量非常小的应用系统，我会从监控系统收集它过去半年的负载情况，和相关的项目经理沟通，将这些数据迁移到共享的数据库实例中，以不同的用户、schema或者pdb的方式留存。替换下来的设备也就不用再付给数据库厂商软件授权或者售后维保。甚至一些僵尸系统，一年新的业务数据增量可以忽略不计，唯一刚需就是按月出个报表的时候，我都直接问，要不改用excel试试？
比较头疼的是人天服务，这类成本很难准确评估，尤其是在业务变化很大的时候。赶上一次可能就把今年的配额吃掉一半甚至更多。于是我和业务部门进行沟通，每年由IT部门出具一个最基本的人天服务成本。如果业务部门因为自身业务发生重大变化而带来需求激增的时候，这部分成本由业务部分承担。一开始业务部门不太同意，因为他们也是有自己的预算压力。这其中进行了多次拉锯，甚至我把IT部门大领导都拉入，多方博弈之后，对方总算决定分摊其中一部分。
这件事倒是给领导带来的新思路，数据库名义上是IT部门在维护使用，但是实际是给各个业务线服务，每年分摊一些是合情合理的。等到我离职前，it部门需要承担的数据库软件预算，已经少于50%，剩下的都是根据上一年的统计情况，按比例分摊给了各个业务条线，也算是意外惊喜。
3.平替迁移
从商业数据库迁移到开源数据库，是降低成本的一个办法。实际情况是，这类需求往往不是DBA自主决定。而是多方面讨论综合权衡的结果。这种机会甚至是可遇不可求的。
如同我开头说的，这不是换一杯奶茶或者咖啡那么容易。既要对不同数据库之间的特性有一定程度的认知，又要能够对业务有一定了解，后续还要面对各种风险，这是所有节约成本方式里，风险最高的，也是能够让DBA成长最快的。
在一开始迁移的时候，我会找项目经理确认，这个应用系统针对不同数据库的兼容性。如果厂商内部就有各种迁移方案最好不过。如果没有，真的就得花一番功夫，仔细捋顺每个细节，小到一个建表的DDL，大到整个业务逻辑的执行情况。同时在迁移的时候，还要做好短期内回退的准备。真的遇到过跑了快一周发现某个业务逻辑不通，短时间内又无法修复的情况。把数据逆向回流，确保数据的正确性与实时性，当时也是花费了我们很大功夫。
我仍然想强调一下，用开源和国产替掉国外商业数据库，固然是一件很有挑战并且很值得鼓励的事情，但是这其中的难度以及承担的责任和风险都是无法准确评估出来的。不要为了替换而替换，永远记住数据库是为应用系统服务的，应用系统是为业务服务的。
4.人力成本
说实话，这是个很头疼的问题，因为人力成本往往和自己的个人收益正相关。一年的人力成本就那么多，别的同事涨薪或者多招一个同事对你的涨薪就有影响。
好在这事拍板权不在我手里，我只是负责提建议。在招人和涨薪这件事情上，我个人更倾向于提高自身能力，给公司创造更多价值，从而多拿些钱，而不是去招人。可能也是打工人思维，个人成长了，带来更多价值了，理应获得更多的回报。也见过有的公司用有限的人力成本用招来新人，薪资和现在的DBA差不多，并且原来的员工多年得不到涨薪。这件事情发生在我身上的话，是无法接受的。原有的人员配置接近承担工作量上限的时候，我才会建议领导考虑招新人。
当然，这一切都是建立在大家是在不断成长的情况下。也确实遇到过其他同事常年吃老本，躺在功劳簿上混日子。面对这种情况，也许招个新人才是更合适的。
如今跳出之前的岗位，旁观者视角来看，其实仍然有很多地方值得改进。如果以后有机会，可以帮助一个朋友或者一家企业去构建自己的数据库体系和团队，我会把自己以前有关成本控制的心得分享给他们。
