Insinööri poisti Gitlabin tuotantotietokannan. 300 gigatavua.
31.
31. tammikuuta 2017 klo 23.27 UTC: GitLab-insinööri, taistellen rikkinäistä replikaa vastaan pitkän yön päätteeksi, poistaa PostgreSQL-datakansion db1:ltä db2:n sijaan. db1 on pääkanta. Noin 300 Gt GitLab.comin tietokannasta katoaa sekunnissa tai kahdessa, ja viidestä varmuuskopiointi- ja replikointimekanismista yksikään ei toimi. Jälkianalyysi: aikajana roskapostihuipusta väärään isäntänimeen, miksi pg_basebackup näytti jumittuneen, miksi pg_dump oli epäonnistunut hiljaisesti (9.2 binäärit 9.6 tietokannassa, virhesähköpostit DMARCin palauttamina), 18 tunnin palautus 6 tuntia vanhasta staging-tilannekuvasta suoratoistona YouTubessa, ja kuka todella saa syyt. Tuomio vastauksesta: SHIP IT.
Lue kirjoitettu versio (englanniksi) ↗
Mitä tämä video käsittelee
- 31. tammikuuta 2017: rm -Rvf ensisijaisen datakansioon; ~300 Gt poistettu, 4,5 Gt jäljellä
- 5 viidestä varmuuskopiosta epäonnistuu: tyhjä S3-säiliö (pg_dump-version epäjohdonmukaisuus), ei Azure-tilannekuvia tietokannassa, tyhjennetty replika, päivittäinen LVM-kopio ilman verkkokoukkuja
- 1. helmikuuta klo 18.00 UTC: GitLab.com takaisin 6 tuntia vanhasta manuaalisesta tilannekuvasta; live-dokumentti, live-striimi, syytön jälkianalyysi korjauslistalla
Käännetty transkriptio
Käännetty alkuperäisestä englanninkielisestä selostuksesta. Käytettävissä olevan äänen ja tekstitysten hallinta tapahtuu YouTuben kautta.
0:00 GitLabin insinööri suorittaa rm -rf -komennon väärällä tietokantapalvelimella, ja kolmesataa gigatavua GitLab dot comia katoaa sekunnissa tai kahdessa, suunnilleen siinä ajassa, joka kuluu isäntänimen lukemiseen. 31. tammikuuta 2017, klo 23.27 UTC. GitLab tviittaa, että se poisti vahingossa tuotantodataa, avaa tapausmuistiinpanonsa internetille ja suoratoistaa palautuksen YouTubessa, alustan toiseksi suosituin live-lähetys. Seuraavana päivänä kirjallisesti: viidestä varmuuskopiointitekniikasta,
0:25 yksikään ei toimi luotettavasti. Miten se tapahtuu, miksi se on mahdollista, ja kuka todella saa syyn. Tämä on The Daily Diff, jälkianalyysi. Klo 17.20: insinööri ottaa tilannekuvan tuotannosta testatakseen kuormituksen tasaajaa staging-ympäristössä. Klo 19.00: roskaposti moukaroi tietokantaa, lisäksi tehtävä poistaa GitLab-työntekijän pysyvästi, josta trolli ilmoitti väärinkäytöstä. Klo 23.00: replika jää niin paljon jälkeen, että ensisijainen on jo hylännyt
0:48 tarvitsemansa lokin; ainoa korjaus on pyyhkiä replika ja kopioida ensisijainen uudelleen. pg_basebackup jumittuu ilman tulostetta. Se todella odottaa, hiljaa, ensisijaista; kukaan ei tiedä sitä, eikä käyttöohjeessa sanota. Insinööri, jonka oli tarkoitus lopettaa klo yhdeltätoista, päättää, että tyhjä datakansio on ongelma ja poistaa sen. Db1:ltä. Ensisijaiselta. Hän huomaa sen sekunnin tai kahden kuluttua; noin kolmesta sadasta gigatavusta,
1:11 4,5 on jäljellä. Varmuuskopiot. Yksi: pg_dump S3:een, päivittäin. Säiliö on tyhjä. Cron-työ suoritetaan sovelluspalvelimella ilman tietokantaa, joten paketti valitsee PostgreSQL 9.2 binäärit 9.6 tietokantaan, epäonnistuu ja lähettää sähköpostit epäonnistumisesta, joka palautuu puuttuvan DMARC-tunnisteen vuoksi. Kaksi: Azure-levytilannekuvat, käytössä tiedostopalvelimille, ei tietokannoille.
1:32 Kolme: replika, pyyhitty tarkoituksella tunti sitten. Neljä: päivittäinen tilannekuva, 24 tuntia vanha, kaikki web-koukut poistettu staging-synkronoinnilla. Viisi: manuaalinen tilannekuva klo 17.20, liittymättömään testiin. Tuo voittaa. Palauttaminen tarkoittaa staging-levyn kopioimista takaisin tuotantoon Azuren halvan tallennustilan kautta kuudella megabitillä sekunnissa: kahdeksantoista tuntia. GitLab dot com on takaisin 1. helmikuuta klo 18.00 UTC, kuusi tuntia vanhempaa dataa.
1:58 git blame: kaksi isäntänimeä yhden merkin päässä toisistaan, ja viisi varmuuskopiointijärjestelmää, joista kukaan ei ole koskaan palauttanut. Ei insinööri. Toimitusjohtajan allekirjoittama jälkianalyysi pitää hänet anonyyminä, värjää tuotantokehotteen punaiseksi ja antaa tiedon kestävyydelle omistajan, koska tähän asti sillä ei ollut sellaista. Vahingon laajuus: kahdeksantoista tuntia poissa käytöstä, kuusi tuntia dataa kadonnut, noin viisituhatta projektia, viisituhatta kommenttia,
2:18 seitsemänsataa uutta käyttäjää ja viisituhatta ihmistä seuraamassa edistymispalkkia. Hacker News antaa live-dokumentille 1 162 pistettä ja lainaa yhden rivin takaisin heille: viidestä varmuuskopiosta, ei yhtäkään. Tuomio, jälkianalyysi: ship it, vastauksesta. He suorittavat tapauksen julkisesti, syyttävät prosessia ja julkaisevat korjauslistan ongelmanumeroineen. Maanantain toimenpide: palauta varmuuskopio. Jos et ole koskaan palauttanut sitä, sinulla ei ole sitä.
2:42 Lähetä minulle tapaus, josta sinulla ei vieläkään ole lupaa puhua, kommenteissa tai osoitteessa daily diff dot dev. Ja siinäpä The Daily Diff tältä päivältä. Olen Niko Axrisista. Yhdistä vastuullisesti.
Lähteet
- 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



