Depois que o dano foi causado e a situação clareou, o GitLab divulgou um resumo do que deixou o site 18 horas fora do ar, como eles planejam seguir em frente, e porquê todo o incidente aconteceu.
A carga massiva no banco de dados foi primeiro diagnosticado como causada por spam. Mas ao analisar mais a fundo, ficou claro que o incidente foi exagerado por um troll que reportou um funcionário do GitLab por abuso. A conta foi marcada e então acidentalmente deletada, outro funcionário revisou as denúncias de abuso e não percebeu que era de um dos engenheiros do time:
Nós descobrimos posteriormente que parte da carga foi causada por uma tarefa em segundo plano tentando remover um funcionário do GitLab e os dados associados a ele. Esse foi o resultado de sua conta ter sido marcada por abuso e acidentalmente agendada para remoção.
O engenheiro reportado informou que sua conta foi deletada porque "nós recebemos uma denúncia de spam de um usuário que foi criado 10 minutos antes da denúncia ter sido feita. Um erro humano foi feito e todos os meus projetos foram deletados".
Devido ao acréscimo de carga, a replicação do banco de dados primário para o secundário parou pois os segmentos Write-Ahead Log (WAL) foram expurgados pelo primário antes que o secundário os processassem. Infelizmente, o arquivamento WAL — que não permitiria os segmentos serem removidos antes de serem arquivados — não estava ligado.
Já que a replicação parou, o secundário precisou ser refeito. Começar a replicar requer um diretório vazio, então um engenheiro manualmente limpou um diretório. Só que ele não limpou o diretório do secundário (que estava incorreto), ele acidentalmente limpou o diretório do primário.
A infeliz perda do banco de dados primário deveria ter retirado o site do ar durante um breve período, mas as coisas ficariam muito pior para o time do GitLab. Ao tentar restaurar os dados, eles descobriram que os backups não estavam funcionando. Seu principal método de backup, pg_dump, não estava fazendo backup de nada. Estava falhando devido à uma incompatibilidade de versão. Ninguém sabia da falha pois a notificação por e-mail estava sendo bloqueada pois o servidor que recebia as mensagens não suportava DMARC.
Outras opções de backup não estavam disponíveis por diferentes razões. Por exemplo, o time não estava utilizando snapshots de disco do Azure no banco de dados. E mesmo se eles estivessem utilizando, talvez demorasse mais ainda para voltar os dados:
Cada conta de armazenamento tem um limite de aproximadamente 30 TB. Ao restaurar uma imagem utilizando uma máquina na mesma conta, o procedimento geralmente termina de maneira rápida. No entanto, quando se utiliza uma máquina de uma conta diferente o procedimento pode demorar horas senão dias para completar.
A única opção foi restaurar a imagem LVM tirada seis horas antes do incidente.
O time levantou 14 pontos para melhorar seus procedimentos de backup. Em duas semanas desde o incidente, eles começaram a utilizar o WAL-E para arquivar os segmentos WAL em tempo real no AWS S3. O teste da restauração deste tipo de backup demorou menos de duas horas. Além disso, eles estão trabalhando em um sistema para automaticamente testar a restauração de backups do PostgreSQL.