GitLab工程师疑过劳　误删300GB资料剩4.5GB

知名程式源码代管服务网站GitLab在年初四（1月31日）晚上出现危机，大量资料忽然流失，震惊全球。

据台湾《科技新报》报导， 工作至深夜的GitLab工程师疑似过劳，误删300GB资料至剩下 4.5GB，遗失了大约6 小时的资料。

估计受到影响的有 4,613 个常规专案、74 个专案分叉（fork）和 350 个导入（import），总共 5037 个项目，可能丢失707 个用户。

 

当晚 GitLab 的工程师们已经花了很长时间对抗垃圾讯息的发送者（spammer），这些大量垃圾讯息已经严重影响到资料库的稳定性跟服务速度，甚至严重到锁死资料库的写入功能。

更严重的是二号资料库连复制都有困难了，跟上线的一号资料库的同步已经严重延迟，甚至拒绝连线一号资料库。

线上处理的工程师里，有一位工程师的时区位于荷兰，当时荷兰已是深夜，身心俱疲的他决定把不听话的二号资料库资料全部删除再重建。

他本意是要对二号资料库伺服器特定目录下 rm -rf（Unix 系的指令，不经 double check 就可以强制删除所在目录下的所有资料）指令，结果执行 1 秒或 2 秒后，猛然发现目标伺服器弄错了，是正在线上服务中的一号伺服器而不是有问题的二号！

这就好像空难电影里，双引擎客机要处理故障的右引擎时，却把维持飞机动力的左引擎给关掉了。

亡羊补牢为时不晚

GitLab 成立于 2014 年，获得 2000 万美元的风险投资，客户包含 IBM、Macy’s、ING、NASA 、VMWare 等。在本周，这些投资者的内心恐怕比其用户更加忐忑不安。

GitLab 这事件发生以后，突显了几个议题，除了网站资料备份机制的漏洞，可能还有工程师的超时工作（导致判断失常）以及工作纪律问题：sudo rm -rf 这样最高权限不经 double check 就强制执行的指令，在使用时应该要有适当的 sop 或更好的权限防呆。这事件反映出，除软硬体设备外，人员的良善管理更为重要。

亡羊补牢为时不晚，GitLab 展现诚意以 YouTube 直播与 Twitter 将讯息公诸于网路，但是看来 GitLab 必须非常努力，才能挽回客户与投资者对该公司的信心。对其他仰赖资讯科技的公司而言，相信这也是很好的借镜。