一次宕机问题的总结复盘
这是学习笔记的第 2022 篇文章
昨天开了一个会，开完会刚打开电脑就收到了5条报警邮件，提示有4套环境发生了高可用切换，这是一套分布式集群环境，经过了长时间的测试，已经临近上线，因为业务的特殊性，出现了这样一个问题，着实让人尴尬。最开始看到这个问题的时候，是有些奇怪而且略带失望的，因为已经切换超过了2个小时，但是大家似乎都没有意识到这个问题。
因为这个问题还没有正式接入线上业务，所以咱不存在业务影响，但是通过这个问题发现存在着较大的隐患，而且按照这种态势下去，我们的系统迁移结果还是有很多不可控因素，所以早上和团队的同事进行了复盘。
首先简单说明了下这次复盘的主要目的，不是具体针对谁，而是把问题都跑出来，看看有什么好的方案加以解决。
问题的背景：一个分布式集群的4个节点出现了高可用切换，但是因为数据延迟过大，导致切换失败。
对这个问题的过程进行梳理发现，一方面是因为计划外操作导致磁盘空间溢出，另一方面是存在一些配置和监控报警不到位的情况，所以这个问题给我们敲响了警钟。
总体来说，我梳理了如下的一些问题:
监控不到位
报警不到位
不熟悉系统架构
不熟悉业务特点
计划外操作的流程不规范
高可用切换失败的隐患
配置导致的空间隐患
数据安全存在隐患
我来逐个展开一下。
监控不到位，发现目前的集群监控是不完整的，存在一些监控盲点，需要细化和确认，保证监控的有效性。
报警不到位，有些服务器有监控，但是没有配置报警选项，导致问题发生的时候产生了信息隔离。
不熟悉系统架构，因为大部分的管理工作是我这边在做，一旦出现问题，熟悉系统架构的人少，难以形成有效的技术互备力量。
不熟悉业务特点，对于业务不够了解，在问题发生的时候很难定位问题的瓶颈，需要结合业务特点和使用方式来进行综合评估。
计划外操作的流程不规范，比如在集群中执行了负载较高的全表DML操作，会导致集群产生大量的日志。而敏感的操作缺少有效的管理，没有提前告知团队成员，在问题发生之后，也没有关注这个操作的影响范围。
高可用切换失败的隐患，高可用切换失败一方面是因为数据延迟导致，同时需要检查是否已经删除了MHA自动生成的failover标志文件，如果存在，下次切换会失败，造成难以挽回的影响。
配置导致的空间隐患，对于binlog的保留周期需要做定制化配置，比如从原来的7天修改为3天，配置从库为只读状态，避免不合理的写入影响
数据安全存在隐患，目前的数据管理存在隐患，对于业务开放的权限需要做到可控和有效，不能开放过高的权限，避免数据误删除。需要配置一个权限较高的管理员账号方便管理。
信息同步机制，一旦发生了数据切换，我们需要及时提醒业务方，让多方引起重视，而不是默默的处理。
所以上面的问题经过分析之后，发现我们在工作中确实存在着很多的不足和改进空间，而这些也是我们进行数据管理的一些基本规约，即什么该做，什么不该做，需要心中有数，而对于自己的操作需要做到公开透明，至少需要明白这个操作的风险和影响，减少意料之外的影响情况。
这个问题在这个阶段出现着实给我们敲响了警钟，而我们也不能以被动的故障来改进，而是逐步转变思路，变成更加公开透明的问题处理方式，在实际的问题处理中，做到对事不对人。
