Un ingegnere ha eliminato il database di produzione di GitLab. 300 gigabyte.
31 gennaio 2017, 23:27 UTC: un ingegnere di GitLab, alle prese con una replica rotta alla fine di una lunga notte, rimuove la directory dei dati di PostgreSQL su db1 invece di db2.
31 gennaio 2017, 23:27 UTC: un ingegnere di GitLab, alle prese con una replica rotta alla fine di una lunga notte, rimuove la directory dei dati di PostgreSQL su db1 invece di db2. db1 è il primario. Circa 300 GB del database di GitLab.com scompaiono in uno o due secondi, e dei cinque meccanismi di backup e replica, nessuno funziona. Postmortem: la cronologia dal picco di spam al nome host sbagliato, perché pg_basebackup sembrava bloccato, perché pg_dump falliva silenziosamente (binari 9.2 su un database 9.6, e-mail di errore respinte da DMARC), il ripristino di 18 ore da uno snapshot di staging di 6 ore trasmesso in diretta su YouTube, e chi è veramente il responsabile. Verdetto sulla risposta: SHIP IT.
Leggi l'edizione scritta (inglese) ↗
Contenuto di questo video
- 31 gennaio 2017: rm -Rvf sulla directory dei dati del primario; ~300 GB rimossi, 4,5 GB rimasti
- 5 backup su 5 falliscono: bucket S3 vuoto (mancata corrispondenza della versione di pg_dump), nessuno snapshot Azure sul DB, replica cancellata, copia LVM giornaliera senza webhook
- 1 febbraio, 18:00 UTC: GitLab.com di nuovo online da uno snapshot manuale di 6 ore; documento live, streaming live, postmortem senza colpe con una lista di correzioni
Trascrizione tradotta
Tradotto dalla narrazione originale inglese. L'audio e i sottotitoli disponibili sono controllati da YouTube.
0:00 Un ingegnere di GitLab esegue rm -rf sul server di database sbagliato, e trecento gigabyte di GitLab dot com svaniscono in uno o due secondi, circa il tempo necessario per leggere un nome host. 31 gennaio 2017, 23:27 UTC. GitLab twitta di aver accidentalmente eliminato dati di produzione, apre le sue note sull'incidente a internet e trasmette il recupero su YouTube, la seconda trasmissione in diretta più vista sulla piattaforma. Il giorno dopo, per iscritto: su cinque tecniche di backup,
0:25 nessuna funziona in modo affidabile. Come succede, perché è possibile e chi è effettivamente il responsabile. Questo è The Daily Diff, postmortem. 17:20: un ingegnere fa uno snapshot della produzione per testare un bilanciatore di carico in staging. 19:00: lo spam martella il database, più un lavoro che elimina definitivamente un dipendente di GitLab segnalato da un troll per abuso. 23:00: la replica è talmente indietro che il primario ha già scartato
0:48 il log di cui ha bisogno; l'unica soluzione è cancellare la replica e copiare il primario di nuovo. pg_basebackup si blocca senza output. In realtà sta aspettando, silenziosamente, il primario; nessuno lo sa, e il runbook non lo dice. L'ingegnere, che intendeva smettere alle undici, decide che la directory dei dati vuota è il problema e la rimuove. Su db1. Il primario. Se ne accorge uno o due secondi dopo; di circa trecento gigabyte,
1:11 ne rimangono 4,5. I backup. Uno: pg_dump su S3, giornaliero. Il bucket è vuoto. Il cron job viene eseguito su un server applicativo senza database, quindi il pacchetto seleziona binari PostgreSQL 9.2 per un database 9.6, fallisce e invia un'e-mail del fallimento, che viene respinta per DMARC mancante. Due: snapshot del disco Azure, abilitati per i file server, non i database.
1:32 Tre: la replica, cancellata di proposito un'ora fa. Quattro: lo snapshot giornaliero, vecchio di 24 ore, ogni webhook rimosso dal sync di staging. Cinque: lo snapshot manuale delle 17:20, per un test non correlato. Questo vince. Ripristinare significa copiare il disco di staging in produzione tramite lo storage economico di Azure a sessanta megabit al secondo: diciotto ore. GitLab dot com è di nuovo online il 1° febbraio alle 18:00 UTC, sei ore di dati più vecchi.
1:58 git blame: due nomi host distanti un carattere, e cinque sistemi di backup da cui nessuno ha mai ripristinato. Non l'ingegnere. Il postmortem, firmato dal CEO, lo mantiene anonimo, colora di rosso il prompt di produzione e assegna la durabilità dei dati a un proprietario, perché fino ad ora non ne aveva nessuno. Raggio d'azione: diciotto ore di inattività, sei ore di dati persi, circa cinquemila progetti, cinquemila commenti,
2:18 settecento nuovi utenti e cinquemila persone che guardano una barra di avanzamento. Hacker News dà al documento live 1.162 punti e ne cita uno linea indietro: su cinque backup, nessuno. Verdetto, postmortem: SHIP IT, sulla risposta. Gestiscono l'incidente in pubblico, incolpano il processo e pubblicano la lista di correzioni con i numeri di emissione. Azione del lunedì: ripristinare un backup. Se non l'hai mai ripristinato, non ne hai uno.
2:42 Inviami l'incidente di cui non ti è ancora permesso parlare, nei commenti, o a the daily diff dot dev. E questa è la differenza per oggi. Sono Niko di Axrisi. Merge responsabilmente.
Fonti
- GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
- GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
- @gitlabstatus, "We accidentally deleted production data…"twitter.com
- @gitlabstatus, emergency maintenance noticetwitter.com
- Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
- Hacker News, the postmortem thread (377 points)news.ycombinator.com
