Gitlab.com针对误删数据的原因调查及事故处理跟踪

摘要
2017年1月31日太平洋时间晚上，GitLab通过推特发文承认300GB生产环境数据因为UNIX SA的误操作，已经被彻底删除（后发文补充说明已经挽回部分数据），引起业界一片哗然。本文对GitLab做了初步介绍，并继续追踪GitLab在2月1日发布的申明，弄清楚事故发生时的各种问题根本原因。最后摘录了一些网友的跟帖，大多数人都对GitLab表达了自己的支持和宽容。

GitLab背景
GitLab是基于 Ruby on Rails 开发的一个开源的版本管理系统，它实现了一个自托管的Git项目仓库，支持通过Web界面进行访问公开的或者私人项目。

GitLab拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序进行交流。此外，GitLab提供了一个代码片段收集功能，可以轻松实现代码复用，便于日后有需要的时候进行查找。

自2012年上线以来，GitLab已经被超过10万个公司或组织使用，包括IBM、Alibaba.com、UBer、Intel、VMWare等等。2017年1月31日（太平洋时间）晚上，GitLab通过推特发文承认300GB生产环境数据因为UNIX SA的误操作，已经被彻底删除（后发文补充说明已经挽回部分数据），引起业界一片哗然。

事故发生后GitLab申明
申明指出GitLab的一个数据库出现了异常，导致GitLab.com丢失6个小时的数据库数据（问题、合并请求、用户、注释等等）。申明还指出丢失生产环境数据是不可以接受的错误，5天之内GitLab将对外发布错误发生及保护措施失效的原因，并将发布一系列措施避免悲剧再次发生。

申明中显示，2017年2月1日 18:14（UTC时间），GitLab.com恢复在线。通过使用一个之前的6小时备份数据库，GitLab申明1月31日下午17:20（UTC时间）至晚上23:25（UTC时间）之间的数据已经被恢复并可以在生产环境使用，包括项目、问题、合并请求、用户、注释等等。

申明中进一步还原了事故发生过程：

• 2017年1月31日傍晚18:00（UTC时间），发现垃圾邮件发送者正在通过创建片段方式攻击数据库，目的是让数据库不稳定。工作人员随即开始寻找问题并准备应对方案。
  

• 2017年1月31日18:00-21:00（UTC时间），YP正在Staging环境安装pgpool和备份工具，为了拿到最新的生产环境数据他创建了一个LVM快照，这个快照会用于Staging环境，他希望可以重用这个快照用于引导其他的副本。这个操作在丢失数据前的6小时完成。

  副本启用的过程中发现存在问题，并且需要消耗大量时间（根据估计仅仅是初始化pg_basebackup同步过程就需要耗时20个小时以上）。LVM快照在工作人员可以修复问题之前又不能再其他副本上使用。整个修复过程都被这个问题耽搁下来。

• 2017年1月31日21:00（UTC时间），开始出现锁定数据库写操作，并引起一些停机情况。进一步进行处理，措施包括锁定垃圾邮件的发送IP、删除一个用户并启用仓库（造成47000个IP使用了相同的账户签名，进而导致数据库高负载）、删除垃圾邮件用户。这些操作之后PostgreSQL数据库负载回归正常，一些手动操作上线之后逐渐追赶上了问题数据处理速度。
  

• 2017年1月31日22:00（UTC时间），数据库备份进展出现落后情况，查明造成原因是备份数据库写入操作时出现异常，导致没有跟上备份节奏。
  采取处理措施包括：尝试修复db2数据库，这时候备份落后了大概4GB。然后db2集群开始拒绝执行备份作业，db2集群拒绝连接到db1，调整max_wal_senders为db2，重启PostgreSQL数据库，随即PostgreSQL数据库提醒存在很多打开的连接，并拒绝启动服务。管理人员随即调整max_connections参数从8000至2000个，PostgreSQL随即启动。注意，此时db2集群依然拒绝执行备份，处于未知原因的挂起状态。
  
  

• 2017年1月31日23:00，工作人员感觉pg_basebackup拒绝执行的原因是PostgreSQL数据文件夹已经存在，所以决定去移除这个文件夹。执行rm操作之后，该工作人员意识到命令正在db1.cluster.gitlab.com执行，而不是db2.cluster.gitlab.com。

• 2017年1月31日23:27，工作人员终止了删除操作，300GB的数据仅剩余4.5GB。
• 立即决定下线GitLab.com并将事故通过推特向外公布。

申明进一步对遇到的问题逐一解释，包括：

• LVM镜像默认每24小时执行一次。工作人员事故发生6小时之前手动执行了一次。
• 常规备份也是24小时执行一次。工作人员没有手动解决这个问题。
• PostgreSQL9.2的二进制文件开始运行，导致pg_dump失败。由于数据库版本设置为PostgreSQL9.6，最终导致SQL备份不启用。
• Azure上的磁盘镜像只是针对NFS服务器，没有针对数据库服务器。
• 同步过程移除了webhooks。
• 复制过程容易出错，依赖于一系列Shell脚本，而这些脚本的注释很差。
• 备份到S3的过程没有正常工作。
• 综上所述，5个备份/复制技术都没有正常工作。我们最终启用6小时之前的备份。
• pg_basebackup需要等待主机启动复制过程完毕，这个过程需要10分钟。这个过程会导致我们认为复制过程卡住了。使用strace命令也看不出什么问题原因。

声明中也说明了恢复过程的执行步骤：
1. 2017年2月1日00:36，备份db1.staging.gitlab.com数据。
2. 2017年2月1日00:55，挂载db1.staging.gitlab.com到db1.cluster.gitlab.com。从/var/opt/gitlab/postgresql/data/拷贝数据到生产环境/var/opt/gitlab/postgresql/data/。
3. 2017年2月1日01:05，nfs-share01服务器被征用作为临时备份服务器，放置于/var/opt/gitlab/db-meltdown。
4. 2017年2月1日01:18，包括还存在的生产环境数据，包括pg_xlog，命名为20170131-db-meltodwn-backup.tar.gz。

下面这张图显示了删除和随后恢复事件的时间。

数据恢复之后的措施建议

1. 为不同的环境改变Linux终端的格式或者颜色，例如红色代表生产环境，黄色代表测试环境。针对所有用户在shell提示符处显示机器的完整名字，例如db1.staging.gitlab.com，而不是仅仅是“db1”。
2. 针对postgresql的文件夹拒绝执行rm -rf这样的命令？可以设置命令执行保护或者针对数据库文件夹有对应的备份措施。
3. 为备份增加提醒：检查S3仓库之类的体型。增加图形化界面，显示时间变化后的备份大小，当下降超过10%时发出警报。
4. 找出为什么PostgreSQL在max_connections被设置为8000之后突然出现问题，这个设置在2016年5月13日就已经完成了。因为这个问题的突然出现导致了其他很多问题。
5. 通过WAL归档增加备份阈值，这个方法对审计失败也许有用。
6. 针对上线产品创建常见问题查找指南手册。
7. 从一个数据中心移动数据到另一个数据中心可以通过AxCopy完成：微软声称这个工具比rsync要快很多。
8. 看上去这是Windows上面的问题，但是没有任何Windows专家参与。

申明最后感谢了推特和其他地方网友给出的技术支持。

网友回复
“keturu ta”的评价

我们在日本工作，我们能够理解你们的痛苦和精神上的挫折。我们会一如既往地支持你们。

“Axel Dreyfus”的评价

现在已经很少看到这么开放的工作态度了。祝你们好运，永远支持你们。千万不要针对那个UNIX SA，他已经瘦了20磅（开玩笑）。

“Neer”的评价

这样的事故对于任何人都有可能发生，我鼓励涉及团队不要有挫折感。这篇文章已经开始在社交媒体上流传开来了，让我感到这是一家非常公开和透明的公司。我之前没有听说过这个产品，但是从此以后我会开始使用它。

“Codepotato”的评价

感谢这样的全面解释。问题发生确实让人感觉很丢脸，但是同时也体现了你们对外的开放态度。当务之急我们需要找到办法提升恢复速度。

总结
事故处理过程中，GitLab采用了开放的态度，事故发生后第一时间对外公布，并对处理过程进行现场直播，让全世界所有程序员都有机会一起参与恢复过程。GitLab也针对网友提出的关于肇事工作人员如何处理问题进行了官方回应，表态不会因为这次事件解雇事故相关技术人员。正是由于这样的开放性姿态，网友并没有对事故的发生而进行谩骂、嘲讽，而是一起通过网络对GitLab进行鼓励，对处理事故团队提供积极的技术建议。这样的处理方式可以作为IT公司生产环境经典解决案例被写入教科书。