Una réplica se quedó atrás y la producción sufrió las consecuencias
En enero de 2017, GitLab.com dependía de un primario de PostgreSQL, db1.cluster.gitlab.com, y una réplica activa, db2.cluster.gitlab.com, para su resiliencia. Esta arquitectura, común en configuraciones de alta disponibilidad, tenía como objetivo mantener db2 sincronizado para la conmutación por error, una defensa crucial pero a menudo frágil.
Esa noche, un pico de carga provocó que db2 se quedara tan atrás que la replicación se detuvo. La solución estándar: reinicializar db2 borrando su carpeta de datos y copiando todo desde db1. Un procedimiento simple, en teoría.
Sin embargo, durante esta reinicialización, un ingeniero ejecutó por error el comando rm -rf no en db2, sino en db1, el primario de producción. El comando se ejecutó durante apenas un segundo o dos antes de ser detenido, pero el daño estaba hecho: se eliminaron aproximadamente 300 GB de datos. Esto no fue una corrupción lenta; fue un borrado repentino y catastrófico de datos de producción en vivo. Las consecuencias de este único comando mal dirigido pronto se revelarían, exponiendo un problema mucho más profundo.
Cada copia de seguridad parecía más segura de lo que realmente era
El desastre de GitLab no se originó solo por un paso en falso, sino por un castillo de naipes construido sobre suposiciones no probadas. La organización creía que tenía una estrategia de copia de seguridad sólida, pero cada capa resultó ser fatalmente defectuosa, demostrando que una copia de seguridad no probada es simplemente una hipótesis, no una protección.
La confianza en una exportación diaria de pg_dump a Amazon S3 estaba mal colocada. El trabajo, destinado a salvaguardar la base de datos PostgreSQL 9.6, utilizaba extrañamente una herramienta pg_dump de una versión mucho más antigua, PostgreSQL 9.2. Este desajuste provocó que la exportación fallara silenciosamente, dejando el bucket de S3 vacío.
Crucialmente, nadie detectó el fallo sistémico. Los correos electrónicos de notificación, destinados a señalar el trabajo de copia de seguridad fallido, fueron rechazados sumariamente por el servidor de correo debido a problemas de autenticación. Para agravar la supervisión, las instantáneas de la base de datos de producción, una capa fundamental de resiliencia, nunca se habilitaron. Las instantáneas LVM solo existían para el entorno de staging, y las instantáneas de Azure Cloud cubrían los discos del sistema operativo pero no los volúmenes críticos de la base de datos.
Con la base de datos primaria comprometida y la réplica ya borrada durante el intento de recuperación, GitLab se enfrentó a una realidad aterradora: no existía ninguna copia de seguridad reciente viable. El único camino de regreso era una instantánea manual de aproximadamente seis horas de antigüedad, tomada por un ingeniero para una prueba de carga no relacionada. Este golpe de suerte, más que cualquier solución de ingeniería, subrayó la precariedad de toda su filosofía de copia de seguridad. Copiar esta instantánea desde discos lentos tomó alrededor de 18 horas, reflejando la duración total de la interrupción y destacando el verdadero costo de la falta de preparación para la recuperación de datos.
La solución se desarrolló frente a 5,000 espectadores
La respuesta a la crisis de GitLab fue una clase magistral de transparencia radical. Los ingenieros compartieron actualizaciones y resolución de problemas en tiempo real públicamente a través de un Google Doc, redes sociales y una transmisión en vivo de YouTube. Esta decisión convirtió un fallo técnico catastrófico en una prueba de confianza altamente visible, con más de 5,000 personas observando en el pico.
La solución, dolorosamente lenta, se basó en una instantánea creada manualmente seis horas antes, alojada en discos de almacenamiento lento. Restaurar esta instantánea consumió aproximadamente 18 horas, la duración de toda la interrupción. Esta lenta recuperación significó que GitLab.com estuvo fuera de servicio durante un período significativo.
En última instancia, GitLab perdió alrededor de seis horas de registros de la base de datos. Esto incluyó aproximadamente:
- 5,000 proyectos
- 5,000 comentarios
- 700 cuentas de usuario
Los datos del repositorio, afortunadamente, permanecieron intactos en un almacenamiento separado. Aunque el resultado fue doloroso, la muestra pública de resiliencia y honestidad obtuvo un respeto significativo. Para profundizar en los detalles, consulte el Postmortem of database outage of January 31 - GitLab. Este incidente cambió fundamentalmente la forma en que muchos en la industria ven la respuesta a incidentes y la transparencia radical.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
La lección fue la responsabilidad, no la culpa
El postmortem de GitLab no buscó un chivo expiatorio; diagnosticó un fallo sistémico de responsabilidad. El problema central no fue el error de un ingeniero, sino la ausencia de un rol dedicado a la fiabilidad de las copias de seguridad y a la verificación rutinaria de las restauraciones. Nadie era responsable, por lo que las salvaguardas críticas se atrofiaron.
El incidente catalizó importantes reformas internas. GitLab implementó pruebas de restauración automatizadas, asegurando que las copias de seguridad no solo estuvieran presentes, sino que fueran funcionales. También reforzaron las medidas de seguridad para el acceso a producción, haciendo que las acciones destructivas fueran más difíciles de realizar accidentalmente, y asignaron la responsabilidad explícita de la fiabilidad de la base de datos a un equipo dedicado.
Para cualquier organización de ingeniería, la lección es clara: asigne un propietario específico para la integridad de las copias de seguridad. Establezca canales de alerta verificados para los fallos de copia de seguridad; no dependa de correos electrónicos que pasan desapercibidos. Fundamentalmente, pruebe regularmente las restauraciones para validar su estrategia de recuperación e implemente salvaguardas robustas para evitar la pérdida accidental de datos. Sus copias de seguridad son tan buenas como su última restauración verificada.
Preguntas frecuentes
¿Qué causó la interrupción de la base de datos de GitLab en 2017?
Mientras reparaba una réplica que se había quedado atrás, un ingeniero eliminó accidentalmente datos de la base de datos de producción en lugar de la réplica.
¿Por qué GitLab no pudo restaurar desde sus copias de seguridad?
La exportación diaria falló porque utilizó una versión incompatible de la herramienta Postgres, y los correos electrónicos de error fueron rechazados. Las instantáneas (snapshots) de producción tampoco estaban disponibles.
¿Cuánto tiempo estuvo GitLab fuera de servicio?
La recuperación tomó alrededor de 18 horas, en gran parte porque restaurar una instantánea creada manualmente desde un almacenamiento lento tomó tiempo.
¿Cuántos datos perdió GitLab?
GitLab perdió alrededor de seis horas de datos de la base de datos, incluyendo aproximadamente 5,000 proyectos, 5,000 comentarios y 700 cuentas de usuario.
¿Cuál es la lección principal del incidente?
Una copia de seguridad solo es confiable cuando los equipos prueban regularmente que pueden restaurarla, y alguien es responsable de ese proceso.