最近在西山远程干活，因此我把大厅里的写字台搬到奶奶以前居住的房间里，把电脑摆了起来。房间里的陈设还保留着爷爷奶奶当年结婚时用的家具。在五斗橱上有一个老式座钟，应该还是民国时期爷爷奶奶结婚时置办的。
这是一座德国Junghans的自鸣钟，已经有二十年左右没有用过了。我小时候和奶奶一起居住，那时候就对这座钟感兴趣，也曾经拆装过几次。再次看到这座钟，又有些手痒了。花了十来分钟，这座钟就又走了起来，每半小时敲钟的功能也是完好的。只不过走的有些慢，一天下来就慢了差不多半小时。
机械座钟都是可以调节的，旋转摆锤上的螺丝，调整摆锤的高度就可以纠正走时。小时候爷爷曾经教过我如何调教，现在还能够记起来如何操作。只不过当是爷爷讲的方法太过复杂，要根据每小天快慢的时间根据一个公式计算去旋转螺丝，一圈大致可以调整几十秒到几分钟不等。当是爷爷教授的公式已经完全记不清了，于是我只能凭着感觉去做调整。通过几天调整，居然调教得相当精准，一天下来只快了不到1一分钟。我还想继续调整，不过就相当困难了，不是调快了就是调慢了，总是无法做到严丝合缝。德国荣汉斯的钟表以精准闻名，在真正的专家手里是可以调整得一年不超过1分钟误差的，只不过我的手艺不行，无法做到如此精准了。
除了自己的手艺不行之外，另外一个因素是这台座钟是低配版，调谐螺丝和摆线上没有刻度标识，因此在调整的时候只能凭着感觉大致旋转了多少圈，以度为单位的精准调整就更谈不上了。
实际上调教机械座钟的方法与做数据库运维管理也有类似之处。当我们无法量化分析的时候，就只能依靠两种方式。第一种方式是通过专家传授的经验去做操作，就像当年爷爷教我的那样；第二种方式是通过不断试错，不断逼近正确的结果。
从老专家那边学习技术的时候，如果只是学习到了一个方法，那么还需要自己经过实践去不断摸索量化这个方法的一些细节。比如把钟摆放长多少圈，座钟走慢多少分钟，放短多少度走快多少秒。只有自己掌握了这些技巧，你才算真正的掌握了这项技术。否则你就会像我刚开始去调整这个座钟那样，不是调快了就是调得更慢了。甚至在调整过程中用自己的想法去修正老师傅教你的方法，最后这个技术在你的知识体系里就变得乱七八糟了。
从这个例子也可以看出另外一个重要的要素，那就是数据库本身能够提供的可观测性能力的重要性。高配的荣汉斯座钟的调谐按钮上是有刻度的，摆线上也有刻度，调整的时候，根据系统提供的刻度去做调整就可以了，这个小小的刻度代表了制造厂商的技术水平。很多DBA朋友觉得Oracle好用，国产数据库不好用，有很大的原因是因为国产数据库缺乏这些刻度，因此很难采用数字化的方式去实现管理。数据库管理无法数字化，那就意味着今后要高度依赖原厂工程师来辅助运维，这种商业模式，恐怕是难以长久的。
前阵子分析一个基于PG内核的国产数据库的OOM问题，最终定位是大量的HASH JOIN把work memory撑爆了。于是考虑是否构建一个故障模型，将所有会话的work memory的使用情况统计出来，设置一些规则来进行预警。经过一番分析发现做不到，因为PG内核并没有提供这些统计数据，后来想能不能迂回一下，通过统计当前数据库的SORT和HASH JOIN的数量来近似推断（实际上PG内核的数据库从SORT/HASH JOIN直接计算WORK MEMORY是会有较大误差的），但是我们也无法获得到这些指标，于是就只能退而求其次，根据ACTIVE SESSION的数量，做更加不准的推测了。想要比较精准地预警这个问题，只能依赖国产数据库厂商能在内核中增加这方面的统计信息了。
最近我在研究基于大模型推理的数据库故障预警和根因推理，在完成一些推理模板的时候，我发现以前我们觉得已经对数据库的指标体系做了十分深入的研究，也能够采集到足以数字化描述某些数据库的指标数据。不过面对目前的更加深入和精准的预警和推理，欠缺的数据相当多。以前在人去使用这些工具的时候，缺失的数据可以再去数据库中查找，或者由专家去脑补。而如果我们要让大模型去做精准的推理，这些数据必须都找出来交给大模型，否则大模型就会用幻觉来回应你。在智能化的需求下，数据库运维数字化的要求更高了。
