Gitlab:一场“删库”血案引发的反思

王琼瑶
原创 4541       2017-02-13  

过年期间,一条Gitlab误删数据的新闻占领了各大科技网站的头条。一切令人惊叹感慨,一切又让人似曾相似。回首2016年,网络重大异常事件其实并不罕见。

<< 2016.03
全球三分之二网站服务器用的开源加密工具OpenSSL爆出“水牢漏洞”。
<<  2016.04
土耳其因数据库漏洞,近5000万公民信息遭泄露。
<< 2016.09
雅虎曝史上最大规模信息泄露,5亿用户资料被窃。
<< 2016.10
Dyn DNS遭到了大规模DDoS攻击,美国大半互联网下线。
<< 2016.11
德国电信路由设备的维护界面暴露,90万家庭断网。
<< 2016.12

黑客伪造用户证书攻击俄罗斯央行,3100万美元不翼而飞。

2017年1月,“Gitlab误删库事件”再掀血案,再次挑动起业界对信息安全和重大风险的敏感神经。



【事件回顾】

Gitlab对整个事件的回顾和处理进行实时更新,让我们可以清晰地看到整个事件的发生过程:Gitlab的一位系统管理员在给线上数据库做负载均衡工作时,遭受了DDoS攻击。在阻止了攻击之后,运维人员发现了数据库不同步的问题,便开始修复,在修复过程中,错误地在生产环境上执行了数据库目录删除命令,导致300GB数据被删除,Gitlab被迫下线。在恢复的过程中,他们发现只有db1.staging的数据库可以用于恢复,而其它的5种备份机制都不可用。db1.staging 是6小时前的数据,而且传输速率有限,导致恢复进程缓慢,Gitlab 最终丢掉了差不多6个小时的数据。

面对这样的异常事件,技术上的分析不是我们想讨论的,真正值得探讨的是:在风险无处不在的金融市场,我们该如何对重大异常进行反思,从而做到更好地预防和处理异常和故障。



【如何反思异常】

不管是传统的工业领域,还是IT行业,异常的预防和处理都是一项重要课题。当异常和故障发生时,如何及时追究问题发生的原因,妥善解决和处理异常,并总结原因预防故障再次发生,体现出一家公司服务意识、技术能力和市场竞争力。


在Gitlab故障回顾的blog中提到要写“Ask 5 Whys”其实在分析和反思故障的过程中,很多IT企业会用“Ask 5 Whys”,例如亚马逊。5Why分析法是由丰田创始人丰田佐吉提出的,就是对一个问题点连续以5个“为什么”来自问,以追究其根本原因,在实际运用中问题并不限于5个。这一方法在丰田汽车公司被广泛应用,是一项必须的培训内容。丰田汽车的大野耐一曾举了一个找出停机原因的经典案例:

>>问题一:为什么机器停了?
答案一:因为机器超载,保险丝烧断了。
>>问题二:为什么机器会超载?
答案二:因为轴承的润滑不足。
>>问题三:为什么轴承会润滑不足?
答案三:因为润滑泵失灵了。
>>问题四:为什么润滑泵会失灵?
答案四:因为它的轮轴耗损了。
>>问题五:为什么润滑泵的轮轴会耗损?
答案五:因为杂质跑到里面去了。

经过连续五次不停地问“为什么”,才找到问题的真正原因和解决的方法,在润滑泵上加装滤网。如果员工没有以这种追根究底的精神来发掘问题,他们很可能只是换根保险丝草草了事,真正的问题还是没有解决。5why法的关键所在:鼓励解决问题的人要努力避开主观或自负的假设和逻辑陷阱,从结果着手,沿着因果关系链条,顺藤摸瓜,直至找出原有问题的根本原因。


当我们的IT系统发生异常时,需要问自己:为什么会发生?为什么没有发现?为什么没有从系统上预防事故?每个层面连续5次或N次的询问,得出最终结论。只有以上三个层面的问题都探寻出来,才能发现根本问题,并寻求解决。例如Gitlab事件,需要问很多问题:为什么会出现数据库不同步?为什么会丢失数据?为什么轻易在生产环境上执行删除命令?为什么运维过程如此混乱?为什么备份机制都失效?为什么备份失效平时未检查?只有把这些问题一个个搞清楚,一个个进行5why分析,才能把问题和隐患一个个解决。



【优化异常处理流程】

当异常发生后,需要一套完备的流程来处理异常,保证快速反馈问题,及时跟进技术人员,确定行动计划,拿出解决方案,落实回访与总结。


在Gitlab事件中技术人员对异常的处理有些杂乱无章,当受到DDoS攻击后,出现数据库使用飙高这一异常,在解决攻击后引发了另一项异常(数据无法同步),在处理数据同步异常时又出现误删数据库,最后在数据恢复过程中发现集中备份机制都失效,可以说是在处理一个异常的过程中反而引发了更多的异常,最终备份机制这一解决方案也失效。虽然这不完全是流程上的问题,但可以看到处理流程的混乱引发了更多的问题。一套完备的流程会更有利于问题的解决。


异常的类型和性质并非千篇一律,需要根据异常发生的情况不断对处理流程进行优化,以更好地应对不同类型的问题。



【自我审视和树立风险意识】

在Gitlab事件中,有两个致命的问题引发最大的关注,一是运维人员删除数据库的命令错误的敲在了生产环境上,另一个是恢复数据时5种备份机制全部失效。大家奇怪的是,运维人员在处理问题时,没有任何限制就可以在生产环境上执行删除目录这样高危的操作,然后5种备份机制全部失效在平时为何没有发现。这两个问题暴露出Gitlab的很多问题,而有些问题是可以防患于未然的,我们在平时的工作中需要经常自我审视,审视产品质量,审视流程和规则,审视自身能力,审视风险隐患。


有些问题可以靠技术预防,有些问题可以靠流程和规则预防,例如误删数据库的运维人员,可以用自动化运维、智能运维来代替“人肉运维”,避免低级错误;可以通过规范的流程和规则来避免误删数据这样的失误;通过平时的测试和演练来检查备份方案是否有效。很多问题是可以在平时预防的。


金融市场的风险无处不在,有经济客观存在的风险,也有主观失误的风险(例如乌龙指),为金融市场服务的技术也会存在风险,我们要在平时的工作中树立风险意识,经常审视自我发现问题,开发更高质量的产品,不要因产品和技术的不到位影响市场的稳定和企业的发展,避免出现像Gitlab误删数据这样的“技术乌龙指”。



【敢于直面故障和异常】

当异常发生时,我们需要以积极的心态去面对,勇于承担责任,而不是掩盖和逃避,有些企业在异常发生后遮遮掩掩推脱责任,反而失去用户的信任。我们应该直面问题,拥抱客户拥抱监管,用心解决问题,对客户负责,对社会负责。
 

任何程序都会有Bug,任何系统都会有异常,Gitlab只是一个缩影,提醒我们需要时刻注意风险,积极总结和反思,预防那些可以避免的异常,妥善处理已经发生的异常,让产品更好地服务客户。


版权所有 侵权必究

如需转载请联系

0571-28829811

恒生技术之眼原创文章,未经授权禁止转载。详情见转载须知

联系我们

恒 生 技 术 之 眼