梳理工作的一点小结-20220309

最近在梳理工作的时候，做了一些小结。

首先是对于工作情况的量化，如果我们只是说自己做了什么什么事情，可能洋洋洒洒几十页ppt，也会让别人看得云里雾里，如果不是这个专业方向的人，基本都会有点晕菜，所以对于这个事情的抓手就是需要有一个参考基准，有了这个基准，你所做的事情都有一个对比，到底是多了还是少了，多了多少，少了多少，具体哪些多了，哪些少了都可以通过数字量化得到答案。

比如对于数据库服务能力的量化，我是选用了信通院开发的这个模型，通过评估惊人的发现我们做了很多的建设和改进工作，但是总体服务能力竟然没有明显的提升，反而还有2%的降低，如下图所示：

经过分析我做了如下的三点补充说明：

• 服务规模增长，标准有所降低，比如管理100台数据库和管理200台是有明显的差异的

• 现有支撑能力值不是恒定不变，投入少相对分数很可能下降，如果有些服务已经比较稳定，投入的精力和时间较少，我觉得分值就应该适度降低，不应该存在指涨不降的情况。

• 需求升级，原来可用的功能会存在一些限制或者瓶颈，比如SQL审核，慢日志管理功能，4年前还是比较领先的方案，但是现在数据库版本都更新这么快了，有很多基础建设能力还没有完全跟上

所以对此我的策略是补足短板和巩固核心目标，我们在去年的时候就开始着手数据库标准化的建设，所幸的是这个事情一直坚持了下来，只是有些形式还没有明确。

其次，感受比较深的是对于数据库技术战略规划，这是很多公司都相对来说忽略的，目前的数据库大环境是相对复杂的，主要是公有云和国产化的热潮，如果说得直白一些，设想如果业务都使用公有云了，那么在私有云环境中我们能够存活下来的主要依据应该是什么？经过前期的一些测算，显然成本不是一个很合理的考虑。还有国产化，假设有一天数据库技术遇到了卡脖子的情况，我们的业务还能不能够玩得转，我们是否完全强依赖于国外开源技术，在技术战略层面，我们是否有足够的考虑和长足的规划。无论如何这一步都得迈出去，只是这是你主动迈出的还是被踢了一脚不得已而为之。

第三点是对于数据库基础建设和服务化建设的思考，如果说得有凡尔赛一些，我们现在的一大困扰是很多问题都是想在了业务前面，通常会有半年左右的一个适应期，大部分的情况下，我们通过架构和设计的方式让业务少走了一些弯路，但是让人纠结的是，这种情况下问题还没有出现，还压根没有发生，我们就已经扑灭了小火苗，所以一切都是那么违和，回过头来，你的价值是什么？用一把看得见的尺子来衡量，一句话就可以让我们哑口无言。同时服务化建设的工作是一个相对漫长的工作，如果拼纯研发能力，数据库方向是不占有绝对优势的，但是如果按照中台的设计模式，其实有些思路是和运维口不是很匹配的。如何体现价值，其中的一个出口就是计量计费，用了多少量，用了什么服务，通过计量计费的方式来摊分成本，这种情况下的服务化能力都有了一个基准，当然这一步要真的搞起来，而且搞透，就会发现是多处拔毛，留下来的成本可能也没有想象的那么多，假设有100个数据库（主从算1个），假设RDS每月需要600元，私有云自建成本是300元，那么系统资源，网络，IDC的成本都摊上之后假设剩下了100元，那么私有云的运维管理按照100个的规模只有1万元左右，这个成本就相当尴尬了。这是一个比较笼统的账目，只是在考虑能够解决的困惑多一些还是带来的困惑更多一些。

第四点就是中年危机，我对这个问题的看法就相当于你突然醒来，发现自己已经在一辆公交车上了，或者你开车时错过了路口，那么一切都是规定好的，你只能乖乖继续向前走，然后找一个合适的路口掉头重来。所以与其说是危机，倒不如说是像是经历一个又一个毕业典礼，记得前几天有同事问我说，我为什么考虑读在职研究生，我只是淡淡的说了一句，算是补充一段记忆，当然这句话有很多没说完的下半句。最近也突然想起了很多读过的大道理，换一种心理状态读起，竟然带给了我全新的感受，这是一种从不理解，懒得理解到信服的态度转变。