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

Lo que cubre este video

• 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 LVM diaria sin webhooks
• 1 de febrero, 18:00 UTC: GitLab.com vuelve de una instantánea manual de 6 horas de antigüedad; documento en vivo, transmisión en vivo, postmortem 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 son controlados por YouTube.

0:00 Un ingeniero en 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 en la plataforma. Al día siguiente, por escrito: de cinco técnicas de respaldo,

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

0:48 el registro que necesita; la única solución es borrar la réplica y copiar el primario de nuevo. pg_basebackup se cuelga sin salida. En realidad está esperando, en silencio, al primario; nadie lo sabe, y el manual de operaciones no lo dice. El ingeniero, quien tenía la intención de salir a las once, decide que el directorio de datos vacío es el problema y lo elimina. En db1. El primario. 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 la falla, 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 de antigüedad, con todos los webhooks eliminados por la sincronización de preparación. Cinco: la instantánea manual de las 5:20, para una prueba no relacionada. Esa gana. Restaurar significa copiar el disco de preparación de nuevo a producción a través del almacenamiento barato de Azure a sesenta megabits por segundo: dieciocho horas. GitLab punto com vuelve el 1 de febrero a las seis p.m. UTC, con seis horas de datos más antiguos.

1:58 git blame: dos nombres de host separados por un carácter, y cinco sistemas de respaldo de los que nadie ha restaurado jamás. No el ingeniero. El postmortem, 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 explosión: 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 viendo una barra de progreso. Hacker News le da al documento en vivo 1,162 puntos y cita una línea de vuelta a ellos: de cinco copias de seguridad, ninguna. Veredicto, postmortem: 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 lo has restaurado, no tienes uno.

2:42 Envíame el incidente del que aún 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