Ingeniari batek GitLab-en produkzio datu-basea ezabatu zuen. 300 gigabyte.

Bideo honek zer jorratzen duen

• 2017ko urtarrilaren 31: rm -Rvf primary-aren datu-direktorioan; ~300 GB ezabatu, 4.5 GB geratzen dira
• 5 babeskopiatatik 5ek huts egiten dute: S3 ontzi hutsa (pg_dump bertsio desadostasuna), ez dago Azure snapshot-ik DB-an, erreplika ezabatuta, eguneroko LVM kopia webhook-rik gabe
• Otsailak 1, 18:00 UTC: GitLab.com martxan berriro 6 orduko eskuzko snapshot batetik; zuzeneko dokumentua, zuzeneko igorpena, errugabeen postmortem konponbide zerrenda batekin

Itzulitako transkripzioa

Jatorrizko ingelesezko narraziotik itzulia. Eskuragarri dauden audioa eta azpitituluak YouTube-k kontrolatzen ditu.

0:00 GitLab-eko ingeniari batek rm -rf exekutatzen du datu-base zerbitzari okerrean, eta hirurehun gigabyte GitLab dot com desagertzen dira segundo batean edo bitan, hostname bat irakurtzeko behar den denbora inguru. 2017ko urtarrilaren 31a, gaueko 11:27ak. UTC. GitLab-ek txio egiten du nahi gabe produkzio datuak ezabatu dituela, bere intzidentzia oharrak interneti irekitzen dizkio, eta berreskurapena YouTube-n zuzenean igortzen du, plataformako bigarren zuzeneko igorpena. Hurrengo egunean, idatziz: bost babeskopia tekniketatik,

0:25 bat ere ez da fidagarritasunez funtzionatzen. Nola gertatzen den, zergatik den posible, eta nori dagokion benetan errua. Hau The Daily Diff da, postmortem. Arratsaldeko 5:20: ingeniari batek produkzioaren snapshot bat egiten du staging-eko karga-balantza bat probatzeko. Arratsaldeko 7ak: spamak datu-basea joz, gehi lan bat GitLab-eko langile bat gogor ezabatzen troll batek abusuagatik salatu zuena. Gaueko 11ak: erreplika atzean geratzen da, hainbesteraino ezen primary-ak dagoeneko baztertu baitu

0:48 behar duen log-a; konponbide bakarra erreplika ezabatzea eta primary-a berriro kopiatzea da berriro. pg_basebackup-ek huts egiten du irteerarik gabe. Egia esan, isil-isilik zain dago, primary-aren zain; inork ez daki hori, eta runbook-ak ez du esaten. Ingeniariak, hamaiketan amaitzekoa zenak, datu-direktorio hutsa dela arazoa erabakitzen du eta ezabatu egiten du. db1-en. The primary. Segundo bat edo bi geroago konturatzen da; gutxi gorabehera hirurehun gigabyte-tatik,

1:11 4.5 geratzen dira. Babeskopiak. Bat: pg_dump S3-ra, egunero. Ontzia hutsik dago. Cron lana aplikazio zerbitzari batean exekutatzen da datu-baserik gabe, beraz, paketeak PostgreSQL 9.2 binarioak hautatzen ditu 9.6 datu-base baterako, huts egiten du, eta mezu elektronikoak bidaltzen ditu hutsegitea, DMARC falta delako errebotea egiten duena. Bi: Azure disko snapshot-ak, fitxategi-zerbitzarietarako gaituta, ez datu-baseetarako.

1:32 Hiru: erreplika, nahita ezabatua ordu bat lehenago. Lau: eguneroko snapshot-a, 24 orduko zahartasuna, webhook guztiak kenduta staging sinkronizazioagatik. Bost: 5:20ko eskuzko snapshot-a, proba ez-erlazionatu baterako. Horrek irabazten du. Berreskuratzeak staging diskoa produkziora kopiatzea esan nahi du Azure-ren biltegiratze merkearen bidez hirurogei megabit segundoko: hemezortzi ordu. GitLab dot com otsailaren 1ean dago berriro martxan arratsaldeko seietan UTC, sei orduko datu zaharragoak.

1:58 git blame: bi hostname karaktere bakar bateko desberdintasunarekin, eta bost babeskopia sistema inork ez duela inoiz berreskuratu. Ez ingeniaria. Postmortem-ak, zuzendari nagusiak sinatuta, anonimo mantentzen du, produkzioaren prompt-a gorriz margotzen du, eta datuen iraunkortasunari jabe bat ematen dio, ordura arte ez zuelako bat ere. Blast radius: hemezortzi ordu behera, sei orduko datuak galdu, gutxi gorabehera bost mila proiektu, bost mila iruzkin,

2:18 zazpiehun erabiltzaile berri, eta bost mila pertsona aurrerapen barra bat ikusten. Hacker News-ek zuzeneko dokumentuari 1.162 puntu ematen dizkio eta bat aipatzen du lerro bat atzera: bost babeskopiatatik, bat ere ez. Epaia, postmortem: SHIP IT, erantzunaren inguruan. Intzidentzia publikoki kudeatzen dute, prozesua erruztatzen dute, eta konponbide zerrenda argitaratzen dute arazo zenbakiekin. Asteleheneko ekintza: babeskopia bat berreskuratu. Inoiz berreskuratu ez baduzu, ez duzu bat ere.

2:42 Bidali ezin duzun intzidentzia hori, iruzkinetan, edo daily diff dot dev helbidera. Eta hori da gaurko diff-a. Niko naiz Axrisi-koa. Fusio arduratsua.

Iturriak

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