Um engenheiro deletou o banco de dados de produção do GitLab. 300 gigabytes.

O que este vídeo aborda

• 31 de janeiro de 2017: rm -Rvf no diretório de dados do primário; ~300 GB removidos, 4,5 GB restantes
• 5 de 5 backups falham: bucket S3 vazio (incompatibilidade de versão do pg_dump), sem snapshots do Azure no DB, réplica apagada, cópia LVM diária sem webhooks
• 1 de fevereiro, 18:00 UTC: GitLab.com de volta de um snapshot manual de 6 horas; doc ao vivo, transmissão ao vivo, postmortem sem culpa com uma lista de correções

Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

0:00 Um engenheiro do GitLab executa rm -rf no servidor de banco de dados errado, e trezentos gigabytes do GitLab dot com desaparecem em um ou dois segundos, mais ou menos o tempo que leva para ler um nome de host. 31 de janeiro de 2017, 23h27 UTC. O GitLab tuíta que acidentalmente excluiu dados de produção, abre suas notas de incidente para a internet e transmite a recuperação no YouTube, a segunda transmissão ao vivo mais assistida na plataforma. No dia seguinte, por escrito: das cinco técnicas de backup,

0:25 nenhuma está funcionando de forma confiável. Como acontece, por que é possível e quem realmente é o culpado. Este é o The Daily Diff, postmortem. 17h20: um engenheiro faz um snapshot da produção para testar um balanceador de carga no ambiente de staging. 19h: spam atinge o banco de dados, mais um trabalho que apaga permanentemente um funcionário do GitLab um troll denunciado por abuso. 23h: a réplica fica tão atrasada que o primário já descartou

0:48 o log que precisa; a única correção é apagar a réplica e copiar o primário novamente. pg_basebackup trava sem saída. Na verdade, está esperando, silenciosamente, pelo primário; ninguém sabe disso, e o runbook não diz. O engenheiro, que pretendia sair às onze, decide que o diretório de dados vazio é o problema e o remove. No db1. O primário. Ele percebe um ou dois segundos depois; dos aproximadamente trezentos gigabytes,

1:11 4,5 permanecem. Os backups. Um: pg_dump para S3, diariamente. O bucket está vazio. O cron job é executado em um servidor de aplicativo sem banco de dados, então o pacote seleciona binários do PostgreSQL 9.2 para um banco de dados 9.6, falha e envia e-mails a falha, que retorna por falta de DMARC. Dois: snapshots de disco do Azure, ativados para os servidores de arquivos, não para os bancos de dados.

1:32 Três: a réplica, apagada propositalmente há uma hora. Quatro: o snapshot diário, com 24 horas de idade, cada webhook removido pela sincronização de staging. Cinco: o snapshot manual das 17h20, para um teste não relacionado. Esse vence. Restaurar significa copiar o disco de staging de volta para a produção usando o armazenamento barato do Azure a sessenta megabits por segundo: dezoito horas. O GitLab dot com volta em 1º de fevereiro às seis da tarde UTC, com seis horas de dados mais antigos.

1:58 git blame: dois nomes de host com um caractere de diferença, e cinco sistemas de backup dos quais ninguém nunca restaurou. Não o engenheiro. O postmortem, assinado pelo CEO, o mantém anônimo, colore o prompt de produção de vermelho e atribui um proprietário à durabilidade dos dados, porque até então não havia nenhum. Raio de impacto: dezoito horas de inatividade, seis horas de dados perdidos, aproximadamente cinco mil projetos, cinco mil comentários,

2:18 setecentos novos usuários e cinco mil pessoas assistindo a uma barra de progresso. O Hacker News dá ao documento ao vivo 1.162 pontos e cita uma frase de volta a eles: dos cinco backups, nenhum. Veredito, postmortem: ship it, sobre a resposta. Eles conduzem o incidente em público, culpam o processo e publicam a lista de correções com números de issue. Ação de segunda-feira: restaurar um backup. Se você nunca o restaurou, você não tem um.

2:42 Envie-me o incidente sobre o qual você ainda não pode falar, nos comentários, ou em the daily diff dot dev. E essa é a diferença de hoje. Sou Niko da Axrisi. Faça o merge com responsabilidade.

Fontes

1. GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
2. GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
3. @gitlabstatus, "We accidentally deleted production data…"twitter.com
4. @gitlabstatus, emergency maintenance noticetwitter.com
5. Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
6. Hacker News, the postmortem thread (377 points)news.ycombinator.com