数据库管理319期 2025-05-01
数据库管理-第319期 工作的目的是什么（20250501）
作者：胖头鱼的鱼缸（尹海文） Oracle ACE Pro: Database PostgreSQL ACE Partner 10年数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVP，ITPUB认证专家 圈内拥有“总监”称号，非著名社恐（社交恐怖分子） 公众号：胖头鱼的鱼缸 CSDN：胖头鱼的鱼缸（尹海文） 墨天轮：胖头鱼的鱼缸 ITPUB：yhw1809。 除授权转载并标明出处外，均为“非法”抄袭
本期不分节。
在已经过去的四月份，基本上算是过去几年工作中最累的一个月，首先因为基础环境硬件的问题，前前后后通宵了好几次，还因为存储异常做了容灾倒换和环境重建的工作；另一方面因为团队有人陪产假，不少事情压回到了自己身上，期间也发现了团队中一些之前工作中的纰漏，完成了糟心的擦屁股工作；当然，最重要的原因还是，因为一些环境因素我似乎有点不明白工作的目的到底是什么了。
从最早从园林设计进入IT运维这个航道的时候，就听到说，运维的目的是解决需求，其实我觉得绝大多数工作的目的都是解决或者满足需求。比如我现在做数据库维护工作，我认为最大的目的稳定不出问题，当然这里面也会出现2个维度：
- 尽可能不出异常。这里主要包含尽量不出故障和性能问题，我以前文章也有讲过，维护是一个持续的过程，需要在这过程中不断地通过巡检、监控发现潜在问题和隐患并及时处理，比如发现SQL运行变慢或者时间很长，就要及时和写代码的人反馈，在其可能造成更大影响之前将其抹杀掉，而不是积累一定量后才联系处理；对应的硬件隐患亦是如此，不能因为大多数硬件都有冗余而不重视，如果真是屋漏偏逢连夜雨，哭都来不及。
- 尽可能快的处理异常。要说完全不出问题，那是不可能的，毕竟数据库和业务应用的代码都是人写的，可能会有不合理代码或BUG，全新的硬件也是可能有问题的。我们也要做到事前准备和快速处理：比如我们要准备好容灾环境并通过验证、演练等手段确保其可用，当数据库异常后能够正常切换确保业务快速恢复；比如出现性能异常时，有快速排查并解决问题的手段，比如针对不同问题有现成的代码、语句或脚本；有足够的监控、告警手段，能快速知晓问题并通过更全面的手段排查；有备份，能够做历史数据恢复或极端灾难恢复等等。
其实上面2点在很多场合下不一定能完全实现，最简单的就是因为没钱，搞不起容灾，加不上备份，甚至连个维护人员都没有，如果再加上写代码的人能力不行，要想达到业务稳定是非常难的。回到数据库维护工作本身，除了要有足够的技术能力以外，还需要对数据库牵扯的到几乎所有内容，比如硬件、网络、操作系统、中间件及常见的数据库使用方式与习惯有所了解；还需要有足够的沟通能力，除了技术对技术的讲清楚技术相关的问题，还要给那些不懂技术的人以通俗易懂的方式讲清楚技术，有些时候还要想尽办法去解决一些难缠的人。
当环境合适的情况下，以足够的能力让维护工作实现较高的稳定性之后，往往会发现，做维护工作的人闲下来了，这时候维护工作往往会比较危险了，特别是在一些不怎么懂技术的人眼中，就会觉得，现在已经稳定不出问题了，那么做维护工作的人是不是可以干掉了，当以降本增效的目的干掉这些人之后，最后往往带来的是“降本增笑”。
即便是在重视维护工作的地方，在足够稳定的条件下，维护工作的价值似乎也很难体现出来，因为维护工作本身大多数是成本投入，一般不会和ToB、ToC的业务系统所代表的投资/资本投入那样带来实打实的收益，上面领导理解还好，如果不理解的话，那大概率又会绕回上一节的现象，只不过不是干掉而是无限制的降低维护方面的投入。在这个情形下，有些人就会想尽办法去创造成绩，里面有一些合理的方式方法是可行的，但和原有的工作内容一样，不容易体现出成绩；那么“铤而走险”在已经稳定的基础上去走钢丝，成为稳定方程式中新增的不稳定变量，也是容易做出一些问题的。
回到开头说到的需求二字，需求不同目的不同：如果我是产品经理，那么我肯定以功能满足业务需求为目的工作；如果我是业务开发人员，我会以实现功能需求为目的工作；但我是维护人员，我一定以稳定为需求作为工作目的。
本文该结束了，似乎还有个问题没有解答，那就是为啥我会为工作目的而迷茫，这就不点明了，总之在前面说到的某个场景或阶段上。其实工作本身的需求就是实现不工作。
老规矩，不知道写了些啥。
