Një inxhinier fshiu bazën e të dhënave të prodhimit të GitLab. 300 gigabajt.
31 janar 2017, 23:27 UTC: një inxhinier i GitLab, duke luftuar një replikë të prishur në fund të një nate të gjatë, heq drejtorinë e të dhënave të PostgreSQL në db1 në vend të db2.
31 janar 2017, 23:27 UTC: një inxhinier i GitLab, duke luftuar një replikë të prishur në fund të një nate të gjatë, heq drejtorinë e të dhënave të PostgreSQL në db1 në vend të db2. db1 është primari. Rreth 300 GB të bazës së të dhënave të GitLab.com janë zhdukur në një sekondë ose dy, dhe nga pesë mekanizmat e kopjimit dhe replikimit, asnjë nuk funksionon. Postmortem: afati kohor nga rritja e spam-it te emri i gabuar i hostit, pse pg_basebackup dukej i ngecur, pse pg_dump kishte dështuar në heshtje (binaret 9.2 në një bazë të dhënash 9.6, emailet e dështimit të refuzuara nga DMARC), restaurimi 18-orësh nga një pamje paraprake 6-orëshe e transmetuar drejtpërdrejt në YouTube, dhe kush e mban vërtet fajin. Vendimi për përgjigjen: SHIP IT.
Lexoni edicionin e shkruar (anglisht) ↗
Çfarë mbulon kjo video
- 31 janar 2017: rm -Rvf në drejtorinë e të dhënave primare; ~300 GB u hoqën, 4.5 GB mbeten
- 5 nga 5 kopjet dështojnë: S3 bucket bosh (mos-përputhje versioni pg_dump), pa pamje Azure në DB, replikë e fshirë, kopje ditore LVM pa webhooks
- 1 shkurt, 18:00 UTC: GitLab.com rikthehet nga një pamje paraprake manuale 6-orëshe; dokument i drejtpërdrejtë, transmetim i drejtpërdrejtë, postmortem pa faj me një listë rregullimesh
Transkript i përkthyer
Përkthyer nga tregimi origjinal në anglisht. Audio dhe titrat e disponueshme kontrollohen nga YouTube.
0:00 Një inxhinier në GitLab ekzekuton rm -rf në serverin e gabuar të bazës së të dhënave, dhe treqind gigabajtë të GitLab dot com zhduken në një sekondë ose dy, përafërsisht sa kohë duhet për të lexuar një emër hosti. 31 janar 2017, ora 23:27 UTC. GitLab njofton se aksidentalisht fshiu të dhënat e prodhimit, hap shënimet e incidentit në internet dhe transmeton rikuperimin në YouTube, transmetimi i dytë më i ndjekur drejtpërdrejt në platformë. Ditën tjetër, me shkrim: nga pesë teknikat e kopjimit,
0:25 asnjëra nuk funksionon me besueshmëri. Si ndodh, pse është e mundur dhe kush e merr vërtet fajin. Ky është The Daily Diff, postmortem. Ora 17:20: një inxhinier krijon një pamje të prodhimit për të testuar një balancues ngarkese në staging. Ora 19:00: spami godet bazën e të dhënave, plus një punë që fshin rëndë një punonjës të GitLab një troll i raportuar për abuzim. Ora 23:00: replika mbetet aq shumë prapa saqë primari ka hedhur tashmë
0:48 logun që i duhet; rregullimi i vetëm është fshirja e replikës dhe kopjimi i primarit përsëri. pg_basebackup ngec pa dalje. Në fakt po pret, në heshtje, për primarin; askush nuk e di këtë, dhe libri i udhëzimeve nuk e thotë. Inxhinieri, i cili synonte të largohej në orën njëmbëdhjetë, vendos që drejtoria e të dhënave bosh është problemi dhe e heq atë. Në db1. Primarin. Ai e vëren një ose dy sekonda më vonë; nga rreth treqind gigabajtë,
1:11 Mbeten 4.5. Kopjet. Një: pg_dump në S3, çdo ditë. Kova është bosh. Puna cron ekzekutohet në një server aplikacioni pa bazë të dhënash, kështu që paketa zgjedh binarët e PostgreSQL 9.2 për një bazë të dhënash 9.6, dështon dhe dërgon email dështimin, i cili refuzohet për DMARC-un që mungon. Dy: pamjet e diskut Azure, të aktivizuara për serverët e skedarëve, jo bazat e të dhënave.
1:32 Tre: replika, e fshirë qëllimisht një orë më parë. Katër: pamja ditore, 24 orëshe, çdo webhook i hequr nga sinkronizimi i staging. Pesë: pamja manuale nga ora 17:20, për një test të palidhur. Ai fiton. Restaurimi nënkupton kopjimin e diskut të staging-ut përsëri në prodhim mbi ruajtjen e lirë të Azure me gjashtëdhjetë megabitë për sekondë: tetëmbëdhjetë orë. GitLab dot com kthehet më 1 shkurt në orën gjashtë pasdite UTC, gjashtë orë më i vjetër i të dhënave.
1:58 git blame: dy emra hosti një karakter larg, dhe pesë sisteme kopjimi nga të cilat askush nuk ka restauruar ndonjëherë. Jo inxhinieri. Postmortem-i, i nënshkruar nga CEO, e mban anonim, ngjyros të kuqe kërkesën e prodhimit dhe i jep qëndrueshmërisë së të dhënave një pronar, sepse deri tani nuk kishte asnjë. Rrezja e shpërthimit: tetëmbëdhjetë orë jashtë funksionit, gjashtë orë të dhëna të humbura, përafërsisht pesë mijë projekte, pesë mijë komente,
2:18 shtatëqind përdorues të rinj dhe pesë mijë njerëz që shohin një shirit progresi. Hacker News i jep dokumentit të drejtpërdrejtë 1,162 pikë dhe citon një rresht mbrapa atyre: nga pesë kopje, asnjë. Vendimi, postmortem: SHIP IT, për përgjigjen. Ata e drejtojnë incidentin publikisht, fajësojnë procesin dhe publikojnë listën e rregullimeve me numra çështjesh. Veprimi i së hënës: rivendosni një kopje. Nëse nuk e keni rivendosur kurrë, nuk keni një të tillë.
2:42 Më dërgoni incidentin për të cilin nuk ju lejohet ende të flisni, në komente, ose në the daily diff dot dev. Dhe kjo është diferenca për sot. Unë jam Niko nga Axrisi. Bashkohuni me përgjegjësi.
Burimet
- 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
