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

未分类

摘要： 对于近期发生的GitLab.com的18小时服务中断事故，GitLab的调查报告深入分析了事故的根本原因。报告详述了事故是如何发生并进一步扩大的，以及他们将如何从中吸取经验教训并改进服务。

作者： David Iffland

正文：

在结束故障并清除了问题后，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