农历大年初四(一月最后的一天)GitLab.com的一个数据库发生了灾难性的事故。经过努力,最终丢失了6个小时(5:20pm UTC ~ 11:25pm UTC,Jan 31,2017 )的数据。“这起事件影响了数据库(包括问题和合并请求),但是没有影响git代码库(代码库和维基)。” 所以对用户来说多少有点安慰,因为并非所有数据全部丢失。所幸GitLab运气不错,损失不是太大,而且公开事故过程,没有躲猫猫,获得大家的好评。但问题还是比想象的严重,值得分析。
1. 让我们简单回顾一下事情的经过 第一次事故
采取的措施:
第二次事故
采取的措施:
第三次事故
2. 问题分析 正如Simon Riggs说,手工删除数据库目录是非常危险的,恢复备份这样操作也很关键。这样的事情应该交给工具去做,所以他顺便为自己的公司2ndQuadrant做了广告(repmgr 3.3,Barman 2.1)。也如左耳朵耗子特别对“人肉运维”吐槽一番“直接到生产线上敲命令是一种非常不好的习惯”,说了一句名言“人管代码,代码管机器,而不是人管机器”。 相对“rm -rf”这样的命令,工具会好多了。即使用工具,也不能解决问题,人在昏头的时候,用工具也会干错事情。所以有人说,这样重要的工作,需要两个人干,一个人操作,另一个人在旁边看着,这样对企业会增大成本,特别是在紧急情况下,不一定能找到人。在本案中,这位同学因为troubleshooting没下班,另外一位值班同学这时是不是该来了?两个人一起商量着解决问题会好多了,灾难就可能不出现了。难道YP童鞋一直埋头干活,没有及时和其他人沟通? 或者像银行那样,遇到高风险的操作,需要上一层主管授权。在troubleshooting时,似乎不现实。重要的操作,还是可以电话请示一下。即使不请示,在技术上可以咨询一下同事,确认一下问题的症结所在,是不是会更好些?而不是自己猜测“可能是pg_basebackup拒绝工作”而盲目操作。即使单独行动,碰到这样关键的问题,这位同学是不是也应该自行检查一遍再提交?对于新型公司,估计平时的培训也不到位,缺少风险意识,维护人员的素质有待提高。 从人、流程看,问题是明显的。但技术问题就更多了,除了上面说的操作和max_wal_senders设置、以及max_connections原来的值,正如Gitlab官在Google DOC描述所碰到的问题,有9项之多,加上max_connections的错误设置正好十项:
可见环境配置、备份、快照等漏洞百出,最终没有损失24小时的数据,或多或少有运气的成分,否则更糟糕。本质上看,也还是人的问题,说明Gitlab管理层只关注用户数增长、业务的发展,而对系统的容错性、可用性/可靠性重视明显不够。许多时候,管理层也是不见棺材不落泪,需要吃一堑长一智,平时对质量不重视,出了问题以后才会重视质量。这次出了问题,倒是好事情,Gitlab会吸取教训,对系统的安全、可靠性会重视起来,完善系统的架构和复制、备份机制等。 当然,最彻底解决问题是通过技术手段来解决,正如左耳朵耗子一再说的“不得不用更好的技术去设计出一个高可用的系统!别无它法。” 如多节点复制的分布式系统、区块链技术等。对于Gitlab 这样的公司,应该有高端人才加盟帮它构建高可用的系统,可以构建良好的发布、运维基础设施。如果缺乏人才,还是可以通过流程、管理等解决。解决一个问题,主要还是从三个方面:
为了方便记忆,三个方面记为PPT。多从这三个方面找原因,多问为什么,采用5 Whys 方法,找出根本原因,加以解决。本问题的深层次原因可能就在思想深处,管理层缺少“可靠性”的质量意识,即使是技术方案的改善,也需要人力、物力的大投入,需要决心去改变系统的架构,这也需要“质量”去驱动。 参考文章:
|
|