+− THE DAILY DIFFdev & AI news
Videoposnetki / postmortem
SHIP IT

Inženir je izbrisal GitLabovo produkcijsko bazo podatkov. 300 gigabajtov.

Objavljeno 10. sep. 2026 · 2:53 · Niko from Axrisi

31.

31. januar 2017, 23:27 UTC: inženir GitLaba, ki se je po dolgi noči boril z pokvarjeno repliko, je namesto db2 odstranil podatkovni imenik PostgreSQL na db1. db1 je primarni strežnik. Približno 300 GB baze podatkov GitLab.com je izginilo v sekundi ali dveh, od petih mehanizmov za varnostno kopiranje in replikacijo pa ni deloval nobeden. Postmortem: časovnica od vrha neželene pošte do napačnega imena gostitelja, zakaj se je pg_basebackup zdelo zataknjeno, zakaj je pg_dump tiho odpovedoval (9.2 binarne datoteke na bazi podatkov 9.6, neuspešna e-poštna sporočila, ki jih je odbil DMARC), 18-urna obnova iz 6-ur starega posnetka vmesnega okolja, ki se je prenašal v živo na YouTubu, in kdo je resnično kriv. Sodba o odzivu: SHIP IT.

Preberi pisno izdajo (angleščina) ↗

Kaj zajema ta videoposnetek

  • 31. januar 2017: rm -Rvf na podatkovnem imeniku primarnega strežnika; odstranjenih ~300 GB, ostalo 4,5 GB
  • 5 od 5 varnostnih kopij odpove: prazen S3 vedro (neskladje različic pg_dump), brez Azure posnetkov na DB, izbrisana replika, dnevna LVM kopija brez spletnih kljuk
  • 1. februar 18:00 UTC: GitLab.com se vrne iz 6-ur starega ročnega posnetka; dokument v živo, prenos v živo, postmortem brez krivde s seznamom popravkov

Preveden prepis

Prevedeno iz izvirnega angleškega pripovedovanja. Razpoložljivi zvok in podnapisi so nadzorovani s strani YouTuba.

0:00 Inženir pri GitLabu zažene rm -rf na napačnem strežniku zbirke podatkov, in tristo gigabajtov GitLab dot com izgine v sekundi ali dveh, približno toliko časa, kot je potrebno za prebranje imena gostitelja. 31. januar 2017, 23:27 UTC. GitLab tvitne, da je pomotoma izbrisal produkcijske podatke, odpre svoje zapiske o incidentu internetu in prenaša okrevanje na YouTubu, drugi prenos v živo na platformi. Naslednji dan, pisno: od petih tehnik varnostnega kopiranja,

0:25 nobena ne deluje zanesljivo. Kako se zgodi, zakaj je to mogoče in kdo je dejansko kriv. To je The Daily Diff, postmortem. 17:20: inženir posname produkcijo za testiranje razbremenilca obremenitve v vmesnem okolju. 19:00: neželena pošta udari po zbirki podatkov, plus opravilo, ki trdo izbriše zaposlenega v GitLabu, ki ga je trol prijavil za zlorabo. 23:00: replika zaostane tako daleč, da je primarni strežnik že zavrgel

0:48 dnevnik, ki ga potrebuje; edini popravek je izbris replike in ponovno kopiranje primarnega strežnika. pg_basebackup se zatakne brez izpisa. Dejansko čaka, tiho, na primarnega; nihče tega ne ve, in priročnik tega ne navaja. Inženir, ki naj bi se odjavil ob enajstih, se odloči, da je prazen podatkovni imenik problem in ga odstrani. Na db1. Primarni strežnik. Opazi sekundo ali dve kasneje; od približno tristo gigabajtov,

1:11 ostane 4,5. Varnostne kopije. Ena: pg_dump na S3, dnevno. Vedro je prazno. Cron opravilo se izvaja na strežniku aplikacij brez baze podatkov, zato paket izbere PostgreSQL 9.2 binarne datoteke za bazo podatkov 9.6, odpove in pošlje e-pošto o napaki, ki se odbije zaradi manjkajočega DMARC-ja. Dve: Azure posnetki diskov, omogočeni za datotečne strežnike, ne za baze podatkov.

1:32 Tri: replika, namerno izbrisana pred eno uro. Štiri: dnevni posnetek, star 24 ur, vsak spletni kavelj odstranjen s strani sinhronizacije vmesnega okolja. Pet: ročni posnetek iz 17:20, za nepovezan test. Ta zmaga. Obnovitev pomeni kopiranje diska vmesnega okolja nazaj v produkcijo prek cenejšega Azurejevega pomnilnika s hitrostjo šestdeset megabitov na sekundo: osemnajst ur. GitLab dot com se vrne 1. februarja ob šestih zvečer UTC, šest ur podatkov starejših.

1:58 git blame: dve imeni gostitelja, ločeni za en znak, in pet sistemov za varnostno kopiranje, iz katerih nihče ni nikoli obnovil. Ne inženir. Postmortem, podpisan s strani CEO-ja, ga ohranja anonimnega, obarva produkcijski poziv rdeče in dodeli lastnika trajnosti podatkov, ker ga do zdaj ni imela. Radij eksplozije: osemnajst ur nedelovanja, šest ur podatkov izgubljenih, približno pet tisoč projektov, pet tisoč komentarjev,

2:18 sedemsto novih uporabnikov in pet tisoč ljudi, ki gledajo vrstico napredka. Hacker News da dokumentu v živo 1.162 točk in jim citira eno vrstico nazaj: od petih varnostnih kopij, nobena. Sodba, postmortem: SHIP IT, glede odziva. Incident so izvedli javno, obtožili proces in objavili seznam popravkov s številkami težav. Ponedeljkova akcija: obnovi varnostno kopijo. Če je še nikoli niste obnovili, je nimate.

2:42 Pošljite mi incident, o katerem še vedno ne smete govoriti, v komentarjih ali na the daily diff dot dev. In to je diff za danes. Sem Niko iz Axrisi. Združujte odgovorno.

Viri

  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

Povezani videoposnetki