调查报告深入揭示了 GitLab.com 服务中断 18 小时的根本原因

在结束故障并清除了问题后，GitLab 给出一个帖子，总结了导致长达 18 小时服务中断的原因、他们计划如何继续发展，以及整个事故是如何发生的。

数据库的高负载在一开始被诊断为大量垃圾邮件的涌入。但是在进一步审查后，明确了是由于无事生非的家伙将一位 GitLab 员工举报为滥用，事故因此而恶化了。另一位员工在审查滥用报告时并没有意识到被举报的账号其实是团队中一位工程师的账号，因此意外地删除了该账号：

我们随后发现这一部分负载是由一个后台任务试图去移除 GitLab 员工及其相关数据所导致的。这就是他们的账号被标识为滥用并意外地被删除的结果。

根据作为当事人的工程师在故障报告中的记录，他的账号被删除是因为“我们收到来自一位用户的垃圾邮件报告，该用户是在发出垃圾邮件报告的10 分钟前创建的。这就产生了人为错误，删除了我的所有项目。”

由于数据库负载的加重，预写式日志 (WAL，Write-Ahead Log) 在得到从数据库处理之前就被主数据库清洗掉了，导致主数据库停止向从数据库复制。不幸的是，WAL 归档也并未被打开。WAL 归档会要求数据段在得到移除许可前被归档。

由于复制已经停止了，需要对从数据库做一次重建。启动复制需要一个空的数据目录，因此一位工程师手工清理干净了一个目录。但该目录并非是从数据库的数据目录，他意外地清除了主数据库的数据目录。

虽然主数据库的不幸损失应该只会让站点关闭一小段时间，但是对于GitLab 团队而言事情更糟。在努力恢复数据的过程中，团队发现自己的备份无法工作。作为备份的主要方法的 pg_dump 由于版本不匹配的问题而不能运行，因此并未备份任何东西。没有人知道存在这个失败，通知邮件因为不支持 DMARC 被服务器拒收。

其它的备份方法也因为各种原因而无法使用，团队并未对数据库使用 Azure 磁盘快照。即使使用了磁盘快照，在线取回数据也将花费很长的时间：

每个存储账号的限制大概为 30TB。恢复快照时使用同一存储账号中的主机通常会完成得很快。但是当用在不同存储账号中的主机时，完成该过程将需要数小时乃至数天。

唯一的方法是恢复事故发生之前六个小时的 LVM 快照。

团队在改进他们的修复恢复过程中碰上了 14 个问题，最终完成了快照的恢复。他们在事故发生后两个星期中实现了 WAL-E ，功能是将 WAL 数据段实时地归档到 AWS S3。对一次恢复的测试表明，这种备份类型在两个小时以内就可以恢复到指定的时间点。此外，他们正在实现一个自动测试PostgreSQL 备份恢复的系统。

查看英文原文： GitLab.com Postmortem Digs into Root Causes of 18 Hour Outage

感谢薛命灯对本文的审校。

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