解读GitLab数据丢失事件背后的媒体传播路径

时间:2017-02-02 栏目:

虽然还在春节假期,但IT人的微博和朋友圈,在昨天(2月1日),因为Gitlab的数据丢失事件,炸开了锅。数据丢失或业务宕机事件已经不止一次两次出现,但鉴于此次事件主角的特殊身份,仍然受到极大的关注,我们一起来回顾下这次事件在各大媒体的传播路径。

关于GitLab(为什么说身份特殊):

GitLab 创办于2014年,总部位于美国旧金山。GitLab 的平台能够实现git仓库管理、代码审查、问题跟踪、集成开发环境、活动信息流和WIkI等功能。此外,平台配合GitLab CI 还能够实现更加简单的持续集成和自动部署。

GitLab孵化于YC,已服务于10万+公司/组织,并在2016年9月获得来自August Capital的2000万美金的B论融资,是硅谷一家明星创业公司。

2.1

公司官网:www.gitlab.com

2月1日10点(美东时间:2017/01/31 18:00)

 

媒介:GitLab官网(Github恢复上线后,官网整理发布于其Bolg)

GitLab发现数据库受到垃圾邮件的攻击,导致服务器出现不稳定的情况。技术人员开始排查和解决问题。

2.2

2月1日13点(美东时间:2017/01/31 21:00)

媒介:GitLab官网(Github恢复上线后,官网整理发布于其Bolg)

GitLab技术人员对数据库进行了升级,升级导致了数据库的写入被锁定lockup,从而使得网站出现了一些时间段的宕机。

2.3

2月1日14点(美东时间:2017/01/31 22:00)

媒介:GitLab官网(Github恢复上线后,官网整理发布于其Bolg)

我们被分页,因为 DB 复制滞后太远,导致不能有效地阻止。发生这种情况是因为在辅助数据库没有及时处理写入。

2.4

2月1日15:27点(美东时间:2017/01/31 23:27)

媒介:GitLab官网(Github恢复上线后,官网整理发布于其Bolg)

GitLab技术人员怀疑 pg_basebackup 失效是因为PostgreSQL 数据库目录(虽然是个空目录)的存在,所以打算删除该目录,但误将删除指令运行在了db1.cluster.gitlab.com上,而非db2.cluster.gitlab.com,从而导致了大量数据的丢失。(300GB只剩下4.5 GB)

2.5

 

2月1日 16:00左右,Twitter

GitLab将GitLab.com下线,并在Twitter上发布相关事件信息和进展。

2.6

这里的7:28 AM, 8:08AM, 8:44AM应当是那位荷兰哥们儿所处的时区,大致对应北京时间的2月1日 16:00左右。

2月1日15:30,微博

微博帐号为ruanrf的用户发微博提到“GitLab.com这次麻烦了,数据库维护时,rm -rf 删了300GB 生产环境数据。等到清醒过来紧急按下ctrl + c,只有4.5GB保留下来。然后恢复备份失败,网站已经宕了10个小时,现在还没恢复。”并提供了报道该事件的国外网站:https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/?mt=1485933661486。微博仍然是个人爆料的首选媒体渠道。

2.7

2月1日16:43,技术社区

开源中国社区官网成为国内首家关注了GitLab误删数据事件的媒体,在其官网发布《Gitlab.com 误删数据,备份恢复失败已宕机 10 小时》。

2.8

 

2月1日16:43-18:00,微信公众号

云头条微信公众号转发了开源中国社区官网的新闻。至此,该事件已从微博和开源中国官网传播至IT类微信公众号。

2月1日18:03,微信公众号

云头条微信公众号发布了《GitLab.com崩溃,rm -rf 删了300GB数据;要命的是,备份偏偏失效》,重点描述了事件最新进展以及网友们关注的为何5套备份/复制方法均失效的原因,并转引了一些微博用户的实时评论。

2.9

2月1日18:10,微博

英方股份蓝微跟进事件,转发了ruanyf的微博,并进行了评论。

2.10

 

2月1日19:57,微博

英方股份蓝微继续跟进事件,发布了《rm -rf 引发的那些血案》,引用了英国发生的一起同是由rm -rf 引起的误删除事件,并给出了一些应对方案。

2.11

 

2月1日21:00左右,YouTube

GitLab在Youtube在线直播整个数据恢复过程,并在Twitter上同步恢复进程,心够大。https://www.youtube.com/watch?v=nc0hPGerSd4

2月1日22:30左右

B站开始转播GitLab数据恢复过程,国内群众开始在线围观,可惜没有字幕翻译。http://live.bilibili.com/19398

2月1日22:07,微信公众号

Oracle微信公众号发布了《五重备份无一生效,还有哪些 rm- rf和GitLab类似的忧伤?》,列举了多类因一系列rm操作引起的误删情形,并分享了防范频发的数据误删除操作在内的6则DBA生存警示。

2.12

 

2月1日22:50,微信公众号

老叶茶馆微信公众号发布了《又搞飞机了,号称有五重备份的GitLab居然也歇了》,认为对备份机制过分信任,却可能没有可靠的备份恢复测试及验证机制,是非常危险的行为。

2.13

2月1日22:58,微信公众号

程序员那些事儿微信公众号发布了《rm -rf 惨案:GitLab误删生产数据!》,重点描述了事件最新进展和来自Solidot、维基、Twitter、微博的一些网友评论。

2.13 2.15

 

2月1日23:09,微信公众号

DBAplus社群微信公众号发布了《99%数据被删除,5类备份全部失效怎么破》,重点描述了在技术层面、运维层面、管理层面从此次事件中可以得到哪些教训。

2.16

 

2月1日23:56,知乎

知乎上创建了《如何评价 2017 年 2 月 1 日 GitLab 数据库被误删?》,1091人关注,52个回答。

2.17

2月2日,各大媒体大范围跟进

大量网站媒体,IT 类微信公众号对事件进行大量的跟进和深入报道。

2月2日凌晨一两点左右

GitLab服务已经恢复,但只恢复至事故发生前6小时的状态,这6小时内的数据还是丢失了,官网已经确认了数据丢失的问题。

2.20

写在最后

从国外媒体微博爆料这次事件,个人微博转引,国内开源社区关注,到几家对事件性新闻较敏感的IT类微信公众号和蓝微的跟进,再到其他IT类媒体的深入报道和知乎的传播,使得事件虽然发生在春节期间,但传播量和关注度依然爆棚,媒体的敬业让人称赞,更让人称赞的还有GitLab透明的故障处理过程:在Twitter公开事件进展,在YouTube上直播数据恢复进程,上线后,在官网公布事件始末,没有任何隐瞒,是一次非常成功的公关处理。

英方作为一家专注于容灾高可用的科技公司,也一直在关注各类数据丢失或业务宕机事件,先进的容灾技术、严谨的实施和在政府、金融、医疗、能源、互联网等领域的容灾实践已经帮助千万家企业提供相关解决方案,帮助其减少数据丢失的风险,降低业务宕机的几率。
I 延伸阅读:

网游行业服务器故障盘点

及时响应,快速服务,为您保驾续航

立即注册

销售咨询:400-0078-655
紧急报修:021-61735936
投诉热线:021-61679076
技术QQ群:532148075
欢迎加入!
隐私声明
当您在本网站进行合作伙伴注册登记,本网站将收集您的相关信息,并保存记录。本网站收集的个人信息包括但不限于:姓名、地址、公司、所在地区、电话号码以及电子邮件地址等。您主动提供的信息越多及越准确,我们就能够更好地为您提供有关服务。
咨询·购买