Un enxeñeiro borrou a base de datos de produción de GitLab. 300 gigabytes.

Que abrangue este vídeo

• 31 de xan. de 2017: rm -Rvf no directorio de datos do principal; ~300 GB eliminados, 4.5 GB restantes
• Fallan 5 de 5 copias de seguridade: cubo S3 baleiro (desaxuste de versión de pg_dump), sen instantáneas de Azure na BD, réplica borrada, copia LVM diaria sen webhooks
• 1 de febreiro, 18:00 UTC: GitLab.com de volta a partir dunha instantánea manual de 6 horas de antigüidade; documento en directo, transmisión en directo, postmortem sen culpa cunha lista de correccións

Transcrición traducida

Traducido da narración orixinal en inglés. O audio e os subtítulos dispoñibles son controlados por YouTube.

0:00 Un enxeñeiro de GitLab executa rm -rf no servidor de base de datos incorrecto, e trescentos gigabytes de GitLab dot com desaparecen nun segundo ou dous, aproximadamente o tempo que leva ler un nome de host. 31 de xaneiro de 2017, 11:27 p.m. UTC. GitLab tuitea que eliminou accidentalmente datos de produción, abre as súas notas de incidente a internet e transmite a recuperación en YouTube, a segunda transmisión en directo máis vista na plataforma. Ao día seguinte, por escrito: de cinco técnicas de copia de seguridade,

0:25 ningunha funciona de forma fiable. Como ocorre, por que é posible e quen ten realmente a culpa. Isto é The Daily Diff, postmortem. 5:20 p.m.: un enxeñeiro fai unha instantánea de produción para probar un equilibrador de carga en staging. 7 p.m.: spam golpea a base de datos, ademais dun traballo que elimina un empregado de GitLab denunciado por abuso. 11 p.m.: a réplica queda tan atrasada que o primario xa descartou

0:48 o rexistro que necesita; a única solución é borrar a réplica e copiar o primario de novo. pg_basebackup bloquéase sen saída. En realidade está esperando, silenciosamente, polo primario; ninguén o sabe, e o runbook non o indica. O enxeñeiro, que pretendía finalizar ás once, decide que o directorio de datos baleiro é o problema e elimínao. En db1. O primario. Dáse conta un segundo ou dous despois; dos aproximadamente trescentos gigabytes,

1:11 quedan 4.5. As copias de seguridade. Unha: pg_dump a S3, diariamente. O cubo está baleiro. O traballo cron execútase nun servidor de aplicacións sen base de datos, polo que o paquete elixe binarios de PostgreSQL 9.2 para unha base de datos 9.6, falla e envía correos electrónicos do fallo, que son rexeitados por falta de DMARC. Dous: instantáneas de disco de Azure, activadas para os servidores de ficheiros, non para as bases de datos.

1:32 Tres: a réplica, borrada a propósito hai unha hora. Catro: a instantánea diaria, de 24 horas de antigüidade, sen ningún webhook por parte da sincronización de staging. Cinco: a instantánea manual das 5:20, para unha proba non relacionada. Esa gaña. Restaurar significa copiar o disco de staging de novo a produción a través do almacenamento económico de Azure a sesenta megabits por segundo: dezaoito horas. GitLab dot com volve o 1 de febreiro ás seis da tarde UTC, con seis horas de datos menos.

1:58 git blame: dous nomes de host separados por un carácter, e cinco sistemas de copia de seguridade dos que ninguén recuperou xamais. Non o enxeñeiro. O postmortem, asinado polo CEO, manteno no anonimato, colorea de vermello o indicador de produción e dálle un propietario á durabilidade dos datos, porque ata agora non tiña ningún. Radio de explosión: dezaoito horas de inactividade, seis horas de datos perdidos, aproximadamente cinco mil proxectos, cinco mil comentarios,

2:18 setecentos novos usuarios e cinco mil persoas observando unha barra de progreso. Hacker News dálle 1.162 puntos ao documento en directo e cita unha frase que lles devolve: de cinco copias de seguridade, ningunha. Veredicto, postmortem: SHIP IT, sobre a resposta. Executan o incidente en público, culpan ao proceso e publican a lista de correccións con números de incidencia. Acción do luns: restaurar unha copia de seguridade. Se nunca a restauraches, non tes ningunha.

2:42 Envíame o incidente do que aínda non se che permite falar, nos comentarios ou en the daily diff dot dev. E esa é a diferenza de hoxe. Son Niko de Axrisi. Fusiona con 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