生产环境数据丢失、数小时的宕机，这是 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
感谢木环对本文的审校。
给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们。
注册/登录 InfoQ 发表评论