曾经在小学的时候看过一个故事。
具体内容,也就是到底当时每个人都做了什么,我记不太清了。依稀记得,那些船员做的都不是什么严重的事,甚至不能说做错了,但是结局却令人唏嘘。
故事,对我影响特别深重。
我从小长江边长大,小时候村里很多人扔垃圾都扔到江里,觉得流动的江水能带走垃圾,保持村子的干净。有次妈妈让我去江边扔垃圾,我犹豫了,她说:“大家都这样,靠你一个人世界就干净了?”当时的我妥协了,乖乖去了江边。
后来我才知道,就因为大家都这么想“我只是一点点”,所以不好才那样深,深到其他人再想挽救都无能为力。
故事我如今靠着百度,又找到了,可以看看:
每人只错一点点
巴西海顺远洋运输公司门前立着一块高5米宽2米的石头,上面密密麻麻地刻满葡萄牙文,记载了当年“环大西洋”号海轮沉船事故的原因。
当时事故发生后,巴西海顺远洋运输公司派出的救援船到达出事地点,但“环大西洋”号海轮消失了,21名船员不见了,海面上只有一个救生电台有节奏地发着求救的摩氏码。救援人员看着平静的大海发呆,谁也想不明白在这个海况极好的地方到底发生了什么,从而导致这条最先进的船沉没。这时有人发现电台下面绑着一个密封的瓶子,里面有一张纸条,上面这样写着:
一水理查德:3月21日,我在奥克兰港私自买了一个台灯,想给妻子写信时照明用。
二副瑟曼:我看见理查德拿着台灯回船,说了句这个台灯底座轻,船晃时别让它倒下来,但没有干涉。
三副帕蒂:3月21日下午船离港,我发现救生筏施放器有问题,就将救生筏绑在架子上。
二水戴维斯:离港检查时,发现水手区的闭门器损坏,用铁丝将门绑牢。
二管轮安特耳:我检查消防设施时,发现水手区的消防栓锈蚀,心想还有几天就到码头了,到时候再换。
船长麦凯姆:起航时,工作繁忙,没有看甲板部和轮机部的安全检查报告。
机匠丹尼尔:3月23日上午理查德和苏勒的房间消防探头连续报警,我和瓦尔特曼进去后,未发现火苗,判定探头误报警,拆掉交给惠特曼,要求换新的。
大管轮惠特曼:我说正忙着,等一会儿拿给你们。 服务生斯科尼:3月23日13点到理查德房间找他,他不在,坐了一会儿,随手开了他的台灯。
机电长科恩:3月23日14点我发现跳闸了,因为这是以前也出现过的现象,没多想,就将阀合上,没有查明原因。
三管轮马辛:感到空气不好,先打电话到厨房,证明没有问题后,又让机舱打开通风口。
管事戴思蒙:14点半,我召集所有不在岗位的人到厨房帮忙做饭,晚上会餐。
最后是船长麦凯姆写的话:19点半发现火灾时,理查德和苏勒的房间已经烧穿,一切糟糕透了,我们没有办法控制火情,而且火越来越大,直到整条船上都是火。我们每个人都犯了一点错误,但酿成了船毁人亡的大错。
今天之所以又想到这个事,是因为我的一个DBA 朋友,她所在环境发生的一起生产故障。
究其根本,其实也是这个原因。
早上她告诉我,她可能得引咎辞职了。我问她为什么,她说她造成一起严重的生产故障:
“我新搭建的主从,只是从库没有配置 read-only 。”
我听到这句话的时候,隐约是知道为什么。陆续沟通过程中,我才了解到就这么一个参数的“不存在”,造成了多么严重的损失。
也是沟通中慢慢了解到这个事故的发生,原来有那么多“同伙”,并且每个看起都不会造成那么大的影响,主要方面是以下几点:
-
数据库主要参数配置及权限不够细致严谨。在我理解里,只是slave节点没有 read-only
在这个事件里关系不是很严重。因为我个人习惯对权限控制比较重视。slave上的连接,用户该有的权限不多给。所以开发连接从库,不应该有修改数据的能力。
可能很多环境中,大家也觉得这个不是很严重,由于mysql
库是在主从同步的范围中的,主从用户权限等都是一样的。会从应用限制连接写实例,也就是应用配置的连接决定了是否实例有read-only
的属性。
因为一直以来工作的环境都是通过限制连接控制写入的节点的,可能我朋友想当然觉得主从是两个不同实例,一直的工作经验也没有这块的限制,都是在开发那边做好对应的连接配置了,只要他们正常使用,是不会有问题的。算未考虑到人的行为的不可控性,如果开发那边犯错,数据库就很危险了。 -
运维监控配置有问题。他们公司各个服务器和应用也有部署监控。理论上她的主从实例配置存在问题,导致从库写入数据、主从同步失效就会有告警,但是刚好运维的监控配置有问题,没有及时报警。导致整个问题一直经过很久很久、开发同事查询数据才发现主从数据不一致,这才知道主从同步早就断开了。
-
开发人员进行数据库实例连接配错误。开发人员也应该熟悉数据库基本架构、知道主从实例的情况。清楚明白各自负责的应用需求是什么,比如只是报表执行查询操作,或者连接前端、后端程序有数据交互、用户数据写入等。如果只是查询类需求,那么该应用配置里连接的该是
slave
;如果有写入需求,连接master
。可刚好,他们的开发同事配置错误,有写入需求的某些应用被配置连到了slave
上了,由于slave
又未设置read-only
参数,导致主实例和从实例都有数据写入成功。
最终的结果是:主/从节点都有相当量的写入,某大区数据仓数据混乱。
看似 dba只是没有配置 read-only
。即使没有限制从实例不可写入,但只要开发连接没有错、运维监控无故障能及时发现及时止损,这个环境是健康的;
开发只是连接错实例,如果 dba 将 slave
的参数 read-only
处理好了,或者用户权限控制合适了,就算连错了也无妨、运维有问题也不怕;
运维只是新增的主/从实例服务器的监控配置错误,如果 DBA 和开发人员都谨慎小心、正确完整操作,压根不需要告警,更别说需要背这个“数据仓数据混乱”的锅。
后来我问她,他们的操作是否只有单人确认、有没有经过 AB 角的检查核对。她告诉我没有。“其实我们这里 DBA 之间很少有沟通,除非想到一个事主动问。丢个脚本什么注释都没有,全靠猜。”。
关于这点我也是比较在意。飞哥说过“最好的沟通就是零沟通”,但是要达到这个,是需要大家有个共识,并且完成前期的沟通、知识储备。
否则每次处理一个事务都需要非常多的沟通。沟通太多容易有摩擦,更浪费时间成本,也考验共事者的耐心。所以,当某个人所掌握的模块有了变更,最好的做法是跟相关的人,AB 角色、有需求上游或者下游进行适当沟通,确保当需要对此模块进行操作的时候,大家比较快进入操作流程注意的共识。
往往成就你的,大多不是特别大“机遇”,好比彩票中了五百万。
往往毁掉现有成就的,也不一定是很大的“灾难”。
细节决定成败。