Un ingeniero borró la base de datos de producción de GitLab. 300 gigabytes.

Qué cubre este vídeo

• 31 de enero de 2017: rm -Rvf en el directorio de datos del primario; ~300 GB eliminados, 4,5 GB restantes
• 5 de 5 copias de seguridad fallan: bucket S3 vacío (incompatibilidad de versión de pg_dump), sin instantáneas de Azure en la base de datos, réplica borrada, copia diaria de LVM sin webhooks
• 1 de febrero, 18:00 UTC: GitLab.com de vuelta desde una instantánea manual de 6 horas; documento en vivo, transmisión en vivo, post mortem sin culpa con una lista de soluciones

Transcripción traducida

Traducido de la narración original en inglés. El audio y los subtítulos disponibles están controlados por YouTube.

0:00 Un ingeniero de GitLab ejecuta rm -rf en el servidor de base de datos equivocado, y trescientos gigabytes de GitLab dot com desaparecen en uno o dos segundos, aproximadamente el tiempo que se tarda en leer un nombre de host. 31 de enero de 2017, 11:27 p.m. UTC. GitLab tuitea que eliminó accidentalmente datos de producción, abre sus notas de incidentes a internet y transmite la recuperación en YouTube, la segunda transmisión en vivo más vista de la plataforma. Al día siguiente, por escrito: de cinco técnicas de copia de seguridad,

0:25 ninguna funciona de forma fiable. Cómo sucede, por qué es posible y quién tiene realmente la culpa. Esto es The Daily Diff, post mortem. 5:20 p.m.: un ingeniero toma una instantánea de producción para probar un equilibrador de carga en staging. 7 p.m.: el spam golpea la base de datos, además de un trabajo que elimina por completo a un empleado de GitLab que un troll reportó por abuso. 11 p.m.: la réplica se atrasa tanto que la primaria ya ha descartado

0:48 el registro que necesita; la única solución es borrar la réplica y copiar la primaria de nuevo. pg_basebackup se cuelga sin salida. En realidad está esperando, en silencio, a la primaria; nadie lo sabe, y el manual no lo dice. El ingeniero, que tenía la intención de cerrar sesión a las once, decide que el directorio de datos vacío es el problema y lo elimina. En db1. La primaria. Se da cuenta uno o dos segundos después; de aproximadamente trescientos gigabytes,

1:11 quedan 4,5. Las copias de seguridad. Una: pg_dump a S3, diariamente. El bucket está vacío. El trabajo cron se ejecuta en un servidor de aplicaciones sin base de datos, por lo que el paquete elige binarios de PostgreSQL 9.2 para una base de datos 9.6, falla y envía correos electrónicos con el fallo, que rebota por falta de DMARC. Dos: instantáneas de disco de Azure, habilitadas para los servidores de archivos, no para las bases de datos.

1:32 Tres: la réplica, borrada a propósito hace una hora. Cuatro: la instantánea diaria, de 24 horas, con todos los webhooks eliminados por la sincronización de staging. Cinco: la instantánea manual de las 5:20, para una prueba no relacionada. Esa gana. Restaurar significa copiar el disco de staging de nuevo a producción a través del almacenamiento barato de Azure a sesenta megabits por segundo: dieciocho horas. GitLab.com vuelve el 1 de febrero a las seis de la tarde UTC, con seis horas de datos más antiguos.

1:58 git blame: dos nombres de host con un solo carácter de diferencia, y cinco sistemas de copia de seguridad de los que nadie ha restaurado jamás. No el ingeniero. El post mortem, firmado por el CEO, lo mantiene anónimo, colorea de rojo el aviso de producción y le da un propietario a la durabilidad de los datos, porque hasta ahora no tenía ninguno. Radio de impacto: dieciocho horas de inactividad, seis horas de datos perdidos, aproximadamente cinco mil proyectos, cinco mil comentarios,

2:18 setecientos nuevos usuarios y cinco mil personas observando una barra de progreso. Hacker News le da 1.162 puntos al documento en vivo y les cita una línea: de cinco copias de seguridad, ninguna. Veredicto, post mortem: SHIP IT, sobre la respuesta. Gestionan el incidente en público, culpan al proceso y publican la lista de soluciones con números de incidencia. Acción del lunes: restaurar una copia de seguridad. Si nunca la has restaurado, no tienes ninguna.

2:42 Envíame el incidente del que todavía no se te permite hablar, en los comentarios o en the daily diff dot dev. Y esa es la diferencia de hoy. Soy Niko de Axrisi. Fusionar responsablemente.

Fuentes

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