这是学习笔记的第 2022 篇文章
昨天开了一个会,开完会刚打开电脑就收到了5条报警邮件,提示有4套环境发生了高可用切换,这是一套分布式集群环境,经过了长时间的测试,已经临近上线,因为业务的特殊性,出现了这样一个问题,着实让人尴尬。最开始看到这个问题的时候,是有些奇怪而且略带失望的,因为已经切换超过了2个小时,但是大家似乎都没有意识到这个问题。
因为这个问题还没有正式接入线上业务,所以咱不存在业务影响,但是通过这个问题发现存在着较大的隐患,而且按照这种态势下去,我们的系统迁移结果还是有很多不可控因素,所以早上和团队的同事进行了复盘。
首先简单说明了下这次复盘的主要目的,不是具体针对谁,而是把问题都跑出来,看看有什么好的方案加以解决。
问题的背景:一个分布式集群的4个节点出现了高可用切换,但是因为数据延迟过大,导致切换失败。
对这个问题的过程进行梳理发现,一方面是因为计划外操作导致磁盘空间溢出,另一方面是存在一些配置和监控报警不到位的情况,所以这个问题给我们敲响了警钟。
总体来说,我梳理了如下的一些问题:
我来逐个展开一下。
所以上面的问题经过分析之后,发现我们在工作中确实存在着很多的不足和改进空间,而这些也是我们进行数据管理的一些基本规约,即什么该做,什么不该做,需要心中有数,而对于自己的操作需要做到公开透明,至少需要明白这个操作的风险和影响,减少意料之外的影响情况。
这个问题在这个阶段出现着实给我们敲响了警钟,而我们也不能以被动的故障来改进,而是逐步转变思路,变成更加公开透明的问题处理方式,在实际的问题处理中,做到对事不对人。