Uma réplica ficou para trás — e a produção sofreu o impacto
Em janeiro de 2017, o GitLab.com dependia de um primário PostgreSQL, db1.cluster.gitlab.com, e de uma réplica ativa, db2.cluster.gitlab.com, para resiliência. Essa arquitetura, comum para configurações de alta disponibilidade, visava manter o db2 sincronizado para failover, uma defesa crucial, porém frequentemente frágil.
Naquela noite, um pico de carga fez com que o db2 ficasse tão atrasado que a replicação cessou. A correção padrão: reinicializar o db2 limpando sua pasta de dados e copiando tudo do db1. Um procedimento simples, na teoria.
No entanto, durante essa reinicialização, um engenheiro executou erroneamente o comando rm -rf não no db2, mas no db1, o primário de produção. O comando foi executado por apenas um ou dois segundos antes de ser interrompido, mas o dano estava feito: aproximadamente 300 GB de dados foram excluídos. Isso não foi uma corrupção lenta; foi uma exclusão repentina e catastrófica de dados de produção ativos. As consequências desse único comando mal direcionado logo se revelariam, expondo um problema muito mais profundo.
Cada backup parecia mais seguro do que realmente era
O desastre do GitLab não ocorreu apenas por um passo em falso, mas por um castelo de cartas construído sobre suposições não testadas. A organização acreditava ter uma estratégia de backup robusta, mas cada camada provou ser fatalmente falha, demonstrando que um backup não testado é apenas uma hipótese, não uma proteção.
A confiança em uma exportação diária de pg_dump para o Amazon S3 estava equivocada. O trabalho, destinado a proteger o banco de dados PostgreSQL 9.6, usava estranhamente uma ferramenta pg_dump de uma versão muito mais antiga, PostgreSQL 9.2. Essa incompatibilidade fez com que a exportação falhasse silenciosamente, deixando o bucket S3 vazio.
Crucialmente, ninguém percebeu a falha sistêmica. E-mails de notificação, destinados a sinalizar a falha no trabalho de backup, foram sumariamente rejeitados pelo servidor de e-mail devido a problemas de autenticação. Compondo ainda mais a negligência, snapshots do banco de dados de produção, uma camada fundamental de resiliência, nunca foram habilitados. Snapshots LVM existiam apenas para staging, e os snapshots do Azure Cloud cobriam discos de SO, mas não volumes críticos de banco de dados.
Com o banco de dados primário comprometido e a réplica já limpa durante a tentativa de recuperação, o GitLab enfrentou uma realidade aterrorizante: não existia nenhum backup recente viável. O único caminho de volta era um snapshot manual de aproximadamente seis horas atrás, feito por um engenheiro para um teste de carga não relacionado. Esse golpe de sorte, em vez de qualquer solução de engenharia, ressaltou a precariedade de toda a sua filosofia de backup. Copiar esse snapshot de discos lentos levou cerca de 18 horas, espelhando a duração total da interrupção e destacando o verdadeiro custo da negligência na preparação para recuperação de dados.
A correção aconteceu na frente de 5.000 espectadores
A resposta à crise do GitLab foi uma aula de transparência radical. Os engenheiros compartilharam atualizações em tempo real e solução de problemas publicamente através de um Google Doc, redes sociais e uma transmissão ao vivo no YouTube. Essa decisão transformou uma falha técnica catastrófica em um teste de confiança altamente visível, com mais de 5.000 pessoas assistindo no pico.
A correção, dolorosamente lenta, baseou-se em um snapshot criado manualmente seis horas antes, residente em discos de armazenamento lentos. A restauração desse snapshot consumiu aproximadamente 18 horas, a duração de toda a interrupção. Essa recuperação lenta significou que o GitLab.com ficou fora do ar por um período significativo.
No final, o GitLab perdeu cerca de seis horas de registros do banco de dados. Isso incluiu aproximadamente:
- 5.000 projetos
- 5.000 comentários
- 700 contas de usuário
Os dados do repositório, felizmente, permaneceram intactos em armazenamento separado. Embora o resultado tenha sido doloroso, a demonstração pública de resiliência e honestidade angariou um respeito significativo. Para uma análise mais profunda dos detalhes, consulte o Postmortem of database outage of January 31 - GitLab. Este incidente mudou fundamentalmente a forma como muitos na indústria veem a resposta a incidentes e a transparência radical.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
A lição foi sobre responsabilidade, não culpa
O postmortem do GitLab não buscou um bode expiatório; ele diagnosticou uma falha sistêmica de responsabilidade (ownership). O problema central não foi o erro de um engenheiro, mas a ausência de um papel dedicado à confiabilidade de backups e à verificação rotineira de restauração. Ninguém era responsável, portanto, as salvaguardas críticas atrofiaram.
O incidente catalisou reformas internas significativas. O GitLab implementou testes automatizados de restauração, garantindo que os backups não estivessem apenas presentes, mas funcionais. Eles também fortaleceram as barreiras de acesso à produção, tornando ações destrutivas mais difíceis de serem executadas acidentalmente, e atribuíram responsabilidade explícita pela database reliability a uma equipe dedicada.
Para qualquer organização de engenharia, a lição é clara: atribua um responsável específico pela integridade dos backups. Estabeleça canais de alerta verificados para falhas de backup — não dependa de e-mails que passam despercebidos. Crucialmente, teste regularmente as restaurações para validar sua estratégia de recuperação e implemente salvaguardas robustas para evitar a perda acidental de dados. Seus backups são tão bons quanto sua última restauração verificada.
Perguntas Frequentes
O que causou a interrupção do banco de dados do GitLab em 2017?
Ao corrigir uma réplica que estava atrasada, um engenheiro excluiu acidentalmente dados do banco de dados de produção em vez da réplica.
Por que o GitLab não conseguiu restaurar a partir de seus backups?
A exportação diária falhou porque usou uma versão incompatível da ferramenta Postgres, e os e-mails de falha foram rejeitados. Os snapshots de produção também não estavam disponíveis.
Quanto tempo o GitLab ficou fora do ar?
A recuperação levou cerca de 18 horas, principalmente porque restaurar um snapshot criado manualmente a partir de um armazenamento lento levava tempo.
Quantos dados o GitLab perdeu?
O GitLab perdeu cerca de seis horas de dados do banco de dados, incluindo aproximadamente 5.000 projetos, 5.000 comentários e 700 contas de usuário.
Qual é a principal lição do incidente?
Um backup só é confiável quando as equipes testam regularmente se conseguem restaurá-lo — e alguém é responsável por esse processo.