生产环境数据丢失、数小时的宕机，这是GitLab给我们带来的不幸而扣人心弦的故事，这个故事告诉我们小事可以变成灾难，比如垃圾邮件、工程师疲劳状态。

整个事件是从1月31日逐渐开始的，直到一条推特的发布彻底确认了GitLab.com有些不对劲了：

我们不小心删除了生产环境数据，可能需要从备份恢复数据。谷歌Doc会有行动注解https://t.co/EVRbHzYlk8
--GitLab.com 状态（@gitlabstatus）2017年2月1日

任务IT从业人员都不愿意听到“删除了生产环境数据”这样的话，但是这种情况又容易发生，这就是为什么备份对于任何生产环境服务来说如此重要了。不幸的是，当团队彻夜奋战尝试恢复服务时，坏消息接踵而来。

在一个帖子里面罗列了发生的事情，麻烦开始于恶意的垃圾邮件攻击，即“通过反复的创建片段方式攻击数据库，导致数据库不稳定”，导致了备份服务出现问题。3小时之后，数据库什么都干不了了，导致GitLab.com站点奔溃。

一位工程师工作到深夜，他的目标是解决问题，但是最终跪倒在一个不幸的错误面前，他犯了一个错误，错误地删除了主节点机器上的数据：

2017年1月31日晚上11点钟（UTC时间），项目组成员1认为pg_basebackup不能正常工作的原因可能是由于PostgreSQL数据目录已经存在（即便它是空的），所以他决定去移除这个目录。很快他就意识到他的移除命令运行在db1.cluster.gitlab.com，而不是db2.cluster.gitlab.com。

2017年1月31日晚上11点27分（UTC时间），这位员工终止了移除文件夹操作，但是已经太迟了。300GB的文件仅剩下4.5GB。

当团队尝试去找到可用的备份文件用于恢复生产环境时，他们发现所有的可选方式都行不通。

LVM（逻辑卷管理）快照默认每24小时运行一次标准备份方式也是24小时运行一次，而且还没有正常工作运行在Azure上的磁盘快照服务不会包含数据库部分AWS的S3上面的备份是空的

碰巧，工程师在执行删除操作之前的6个小时生成了一个LVM快照。如果没有这个神奇的操作，我们会发现更多的数据永远找不回来了。

纵观整个事件过程，GitLab团队保持了完全的透明化，实时发布更新内容到谷歌Doc，这样整个社区都可以紧跟事件。此外，他们也开放了现场视频，直播工程师恢复数据的工作过程。

大约在数据库宕机18个小时之后，GitLab.com恢复在线：

https://t.co/r11UmmDLDE应该已经对外正式恢复了。
--GitLab.com状态（@gitlabstatus）2017年2月1日

社区存在多种评价，包括对团队的支持和批判。一些人发帖给予慰问，并且赞扬GitLab的透明度。黑客新闻用户js2评价这种错误的感受他很熟悉：“如果你干系统管理员工作时间足够长的话，这种错误你也会犯的，你会在错误的机器上执行破坏性的命令。”另外有一些人就不那么仁慈了。

即便GitLab犯错了，他们的痛苦经历也是对社区内部关于测试备份方案重要性的一个提醒，Stack Overflow的工程经理David Haney说：

GitLab处理方式是正确的，可以作为企业的一个很好的案例和学习经验，而不是让别人感觉到神秘的宕机，以及完全没有对外沟通的处理方式。我打赌，这周会进行很多的灾备措施测试，而且这是大家以往并没有想的。所有这一切都是因为GitLab的意外事件带来了的连锁反应。

也有一些人调侃说2月1日应该设立为备份检查日。

GitLab创立于2011年，它是GitHub的开源替代版本。它是一个在GitLab.com上的托管版本，包含自服务的社区版本和企业版本。只有GitLab.com的托管服务收到本次意外事件的影响。

参考英文原文：Fatigue, Spam, and Lack of Backups Take Down GitLab.com