Un enginyer va eliminar la base de dades de producció de GitLab. 300 gigabytes.

Què cobreix aquest vídeo

• 31 de gener de 2017: rm -Rvf al directori de dades del primari; ~300 GB eliminats, 4,5 GB restants
• 5 de 5 còpies de seguretat fallen: cub S3 buit (discrepància de versió de pg_dump), sense instantànies d'Azure a la base de dades, rèplica esborrada, còpia LVM diària sense webhooks
• 1 de febrer, 18:00 UTC: GitLab.com torna d'una instantània manual de 6 hores; document en viu, transmissió en directe, postmortem sense culpa amb una llista de correccions

Transcripció traduïda

Traduït de la narració original en anglès. L'àudio i els subtítols disponibles estan controlats per YouTube.

0:00 Un enginyer de GitLab executa rm -rf al servidor de base de dades equivocat, i tres-cents gigabytes de GitLab dot com desapareixen en un segon o dos, aproximadament el temps que es triga a llegir un nom d'amfitrió. 31 de gener de 2017, 23:27 h. UTC. GitLab tuiteja que ha eliminat accidentalment dades de producció, obre les seves notes d'incidència a internet i transmet la recuperació a YouTube, la segona transmissió en directe més vista a la plataforma. L'endemà, per escrit: de cinc tècniques de còpia de seguretat,

0:25 cap funciona de manera fiable. Com passa, per què és possible i qui realment en té la culpa. Això és The Daily Diff, postmortem. 17:20 h.: un enginyer fa una instantània de producció per provar un balancejador de càrrega en staging. 19:00 h.: l'spam ataca la base de dades, a més d'una tasca que elimina definitivament un empleat de GitLab que un troll va denunciar per abús. 23:00 h.: la rèplica es queda tan endarrerida que el primari ja ha descartat

0:48 el registre que necessita; l'única solució és esborrar la rèplica i copiar el primari de nou. pg_basebackup es penja sense sortida. En realitat està esperant, en silenci, el primari; ningú ho sap, i el llibre de procediments no ho diu. L'enginyer, que volia acabar a les onze, decideix que el directori de dades buit és el problema i el suprimeix. A db1. El primari. Ho nota un segon o dos després; d'aproximadament tres-cents gigabytes,

1:11 en queden 4,5. Les còpies de seguretat. Una: pg_dump a S3, diàriament. El cub està buit. La tasca cron s'executa en un servidor d'aplicacions sense base de dades, de manera que el paquet tria binaris de PostgreSQL 9.2 per a una base de dades 9.6, falla i envia correus electrònics la fallada, que rebota per falta de DMARC. Dos: instantànies de disc d'Azure, habilitades per als servidors de fitxers, no les bases de dades.

1:32 Tres: la rèplica, esborrada a propòsit fa una hora. Quatre: la instantània diària, de 24 hores, cada webhook eliminat per la sincronització d'staging. Cinc: la instantània manual de les 17:20, per a una prova no relacionada. Aquesta guanya. Restaurar significa copiar el disc d'staging de nou a producció a través de l'emmagatzematge barat d'Azure a seixanta megabits per segon: divuit hores. GitLab dot com torna l'1 de febrer a les divuit hores UTC, sis hores de dades més antigues.

1:58 git blame: dos noms d'amfitrió separats per un caràcter, i cinc sistemes de còpia de seguretat dels quals ningú ha restaurat mai. No l'enginyer. El postmortem, signat pel CEO, el manté anònim, coloreja de vermell l'indicador de producció i dóna un propietari a la durabilitat de les dades, perquè fins ara no en tenia cap. Radi de blast: divuit hores caigut, sis hores de dades perdudes, aproximadament cinc mil projectes, cinc mil comentaris,

2:18 set-cents usuaris nous i cinc mil persones observant una barra de progrés. Hacker News dóna al document en viu 1.162 punts i cita una línia de tornada: de cinc còpies de seguretat, cap. Veredicte, postmortem: ship it, sobre la resposta. Gestionen l'incident en públic, culpen el procés i publiquen la llista de correccions amb números d'incidència. Acció de dilluns: restaurar una còpia de seguretat. Si mai l'heu restaurat, no en teniu cap.

2:42 Envieu-me l'incident del qual encara no se us permet parlar, als comentaris, o a the daily diff dot dev. I aquesta és la diferència d'avui. Sóc en Niko d'Axrisi. Fusioneu amb responsabilitat.

Fonts

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