转载

GitLab事故之技术详叙:抢救后恢复在线,已确定下一步计划

本文对GitLab事件进行了全盘回顾,继续追踪GitLab在2月1日发布的申明,追溯各种问题根本原因。然后陈列了恢复在线后,GitLab声明了哪些下一步举措。最后摘录了一些网友在Twitter和YouTube的评论,大多数人都对GitLab表达了自己的支持和宽容。

事件总览

2017年1月31日18:00(UTC时间),GitLab通过推特发文承认300GB生产环境数据因为UNIX SA的误操作,已经被彻底删除(后发文补充说明已经挽回部分数据),引起业界一片哗然。

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

GitLab背景

GitLab目前是硅谷一颗冉冉升起的新星,它估值3.29千万美元并且存放着宝贵的用户数据。

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

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

自2012年上线以来,GitLab已经被超过10万个公司或组织使用,包括IBM、Alibaba.com、Uber、Intel、VMWare等等。

事件影响

一句话概述

GitLab申明指出其一个数据库出现了异常,导致GitLab.com丢失6个小时的数据库数据(问题、合并请求、用户、注释等等),不过Git / wiki存储库和自托管安装不受影响。

五点详情

  1. 大约6个小时的数据丢失
  2. 大约丢失5037个项目(其中4613个常规项目,74个fork, 350个import)。由于Git的repository没有任何损失,所以GitLab可以重建数据事故之前已经存在的用户/组的全部项目,但是并不能修复事故中的任何问题。
  3. 丢失了大约4979(即5000)左右的注释。
  4. 可能丢失了707个用户,很难准确进行评估(部分源自Kibana记录)
  5. 受影响的时间点:1月31日17:20之后创建的数据

Offline前的种种挣扎

首次事故:垃圾邮件用户的数据库负载的峰值

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

GitLab事故之技术详叙:抢救后恢复在线,已确定下一步计划

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

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

2017年1月31日21:00(UTC时间),开始出现锁定数据库写操作,并引起一些停机情况。进一步进行处理,措施包括锁定垃圾邮件的发送IP、删除一个用户并启用仓库(造成47000个IP使用了相同的账户签名,进而导致数据库高负载)、删除垃圾邮件用户。

GitLab事故之技术详叙:抢救后恢复在线,已确定下一步计划

第二个事故:复制延迟触发警报

2017年1月31日22:00(UTC时间),数据库备份进展出现落后情况,查明造成原因是备份数据库写入操作时出现异常,导致没有跟上备份节奏。

采取处理措施包括:尝试修复db2数据库,这时候备份落后了大概4GB。然后db2集群开始拒绝执行备份作业,db2集群拒绝连接到db1,调整max_wal_senders为db2,重启PostgreSQL数据库,随即PostgreSQL数据库提醒存在很多打开的连接,并拒绝启动服务。管理人员随即调整max_connections参数从8000调整至2000,PostgreSQL随即启动。注意,此时db2集群依然拒绝执行备份,处于未知原因的挂起状态。

GitLab事故之技术详叙:抢救后恢复在线,已确定下一步计划

GitLab事故之技术详叙:抢救后恢复在线,已确定下一步计划

第三个事故:误删操作

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

2017年1月31日23:27(UTC时间),工作人员(team-member-1 )终止了删除操作,300GB的数据仅剩余4.5GB。

下线,进入紧急状态

GitLab决定下线GitLab.com并将事故通过推特向外公布,并且通过YouTube对外进行了修复过程的直播。

GitLab事故之技术详叙:抢救后恢复在线,已确定下一步计划

思考,罗列问题清单

GitLab进一步对遇到的问题进行梳理和逐一解释,包括:

  • ** LVM镜像**默认每24小时执行一次。工作人员(team-member-1 )事故发生6小时之前手动执行了一次。

  • 常规备份也是24小时执行一次,但是工作人员(team-member-1 )无法确定存放于何处。另外一名工作人员(team-member-2)认为这意味着失效,因为产生的文件只有几个字节。

    一名工作人员(Team-member-3):PostgreSQL9.2的二进制文件开始运行,导致pg_dump失败。由于数据库版本设置为PostgreSQL9.6,最终导致 SQL备份 不启用。

  • Azure上的 磁盘镜像 只是针对NFS服务器,没有针对数据库服务器。

  • 同步过程移除了webhooks。除非我们可以从过去24小时的常规备份中提取这些内容,否则将丢失。

  • 复制过程极度脆弱,很易出错,依赖于一系列Shell脚本,而这些脚本的注释很差。

  • S3 备份过程没有正常工作。

  • 当备份失败时,没有可靠的警报/分页,在dev host上面现在也看到这一点

综上所述,5个备份/复制技术都没有正常工作。无奈之下,我们最终启用6小时之前的备份。

pg_basebackup需要等待主机启动复制过程完毕,这个过程需要10分钟。这个过程会导致我们认为复制过程卡住了。使用strace命令也看不出什么问题原因。

行动, 恢复过程

GitLab的官方声明中说明了恢复过程的执行步骤:

  1. ** 2017年2月1日00:36**(UTC时间),备份db1.staging.gitlab.com数据。

  2. ** 2017年2月1日00:55**(UTC时间),挂载db1.staging.gitlab.com到db1.cluster.gitlab.com。从/var/opt/gitlab/postgresql/data/拷贝数据到生产环境/var/opt/gitlab/postgresql/data/。

  3. 2017年2月1日01:05(UTC时间),nfs-share01服务器被征用作为临时备份服务器,放置于/var/opt/gitlab/db-meltdown。

  4. 2017年2月1日01:18(UTC时间),包括还存在的生产环境数据,包括pg_xlog,命名为20170131-db-meltodwn-backup.tar.gz。

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

GitLab事故之技术详叙:抢救后恢复在线,已确定下一步计划

未完,GitLab下一步打算

Todo list

  1. 为不同的环境改变Linux终端的格式或者颜色,例如红色代表生产环境,黄色代表测试环境。针对所有用户在shell提示符处显示机器的完整名字,例如db1.staging.gitlab.com,而不是仅仅是“db1”。: https://gitlab.com/gitlab-com/infrastructure/issues/1094

  2. 针对postgresql的文件夹拒绝执行rm -rf这样的命令?可以设置命令执行保护或者针对数据库文件夹有对应的备份措施。

  3. 为备份增加提醒:检查S3仓库之类的体型。增加图形化界面,显示时间变化后的备份大小,当下降超过10%时发出警报。: https://gitlab.com/gitlab-com/infrastructure/issues/1095

  4. 找出为什么PostgreSQL在max_connections被设置为8000之后突然出现问题,这个设置在2016年5月13日就已经完成了。因为这个问题的突然出现导致了其他很多问题。 https://gitlab.com/gitlab-com/infrastructure/issues/1096

  5. 通过WAL归档增加备份阈值,这个方法对审计失败也许有用。 https://gitlab.com/gitlab-com/infrastructure/issues/1097

  6. 针对上线产品创建常见问题查找指南手册。

  7. 从一个数据中心移动数据到另一个数据中心可以通过AxCopy完成:微软声称这个工具比rsync要快很多。看上去这是Windows上面的问题,但是没有任何Windows专家参与。

五天内公开自省报告

GitLab官方申明指出丢失生产环境数据是不可以接受的错误,5天之内GitLab将对外发布错误发生及保护措施失效的原因,并将发布一系列措施避免悲剧再次发生。

网友们的关注

GitLab致谢网友

GitLab申明最后感谢了共计42位网友的外援,他们通过Twitter和其他渠道上给出的技术建议。

网友留言

“keturu ta”的评价

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

“Axel Dreyfus”的评价

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

“Neer”的评价

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

“Codepotato”的评价

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

公开,直播修复过程

除了在网络上对事故进行文字说明,GitLab还在YouTube上直播了其数据库修复过程。该过程视频时长8小时,共计有32万人次观看。 https://www.youtube.com/watch?v=nc0hPGerSd4

GitLab事故之技术详叙:抢救后恢复在线,已确定下一步计划

写在后面

事故处理过程中,GitLab采用了开放的态度,事故发生后第一时间对外公布,并对处理过程进行现场直播,让全世界所有程序员都有机会一起参与恢复过程。GitLab也针对网友提出的关于肇事工作人员如何处理问题进行了官方回应,表态不会因为这次事件解雇事故相关技术人员。

正是由于这样的开放性姿态,网友并没有对事故的发生而进行谩骂、嘲讽,而是一起通过网络对GitLab进行鼓励,对处理事故团队提供积极的技术建议。这样的处理方式可以作为IT公司生产环境经典解决案例被写入教科书。

参考资料

https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/

https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/

感谢木环对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ,@丁晓昀),微信(微信号: InfoQChina )关注我们。

原文  http://www.infoq.com/cn/news/2017/02/Technical-details-accident-GitLa
正文到此结束
Loading...