# Инженер GitLab-ын үйлдвэрлэлийн мэдээллийн санг устгажээ. 300 гигабайт.

Published: 2026-09-10

2017 оны 1-р сарын 31, 23:27 UTC: GitLab-ын инженер, оройжингоо ажиллаж эвдэрхий репликатай зууралдаж байгаад db2-ын оронд db1 дээрх PostgreSQL өгөгдлийн директорыг устгажээ. db1 нь үндсэн сервер байв. GitLab.com-ын мэдээллийн сангийн ойролцоогоор 300 ГБ нэг хоёр секундын дотор алга болж, таван нөөцлөлт болон репликацийн механизмаас аль нь ч ажиллахгүй байв. Постмортем: спамын өсөлтөөс буруу хостны нэр хүртэлх цагийн хуваарь, pg\_basebackup яагаад гацсан мэт харагдсан, pg\_dump яагаад чимээгүй алдаа гаргаж байсан (9.6 мэдээллийн санд 9.2-ын бинари ашигласан, алдааны имэйлүүд DMARC-аас буцаж байсан), YouTube дээр шууд дамжуулсан 6 цагийн өмнөх шатны зурагнаас 18 цагийн сэргээлт, мөн хэн үнэхээр буруутай вэ. Хариу үйлдлийн тухай дүгнэлт: SHIP IT.

Canonical: https://thedailydiff.dev/mn/video/2026-09-10-gitlab-rm-rf/

## Энэ видео юуг хамардаг

- 2017 оны 1-р сарын 31: үндсэн серверийн өгөгдлийн директороос rm -Rvf; ~300 ГБ устгагдаж, 4.5 ГБ үлдсэн
- 5-аас 5 нөөцлөлт амжилтгүй болсон: хоосон S3 бакет (pg\_dump хувилбарын зөрүү), ДБ дээр Azure-ийн зураг байхгүй, реплика устгагдсан, вэбхукгүй өдөр тутмын LVM хуулбар
- 2017 оны 2-р сарын 1, 18:00 UTC: GitLab.com 6 цагийн өмнөх гарын авлагын зурагнаас сэргэсэн; шууд баримт бичиг, шууд дамжуулалт, засварын жагсаалт бүхий буруутгахгүй постмортем

## Орчуулсан бичлэг

Англи хэл дээрх эх хувилбараас орчуулсан. Боломжтой дуу болон хадмал орчуулгыг YouTube хянадаг.

0:00 GitLab-ын инженер буруу мэдээллийн сангийн сервер дээр rm -rf ажиллуулсан, мөн гурван зуун гигабайт GitLab.com нэг хоёр секундын дотор алга болсон, хостны нэр унших хугацаатай ойролцоо. 2017 оны 1-р сарын 31, оройн 11:27, UTC. GitLab үйлдвэрлэлийн өгөгдлөө санамсаргүйгээр устгасан тухай твиттерээр жиргэж, ослын тэмдэглэлээ интернэтэд нээлттэй болгож, сэргээлтийг YouTube дээр шууд дамжуулсан, тухайн платформын хоёр дахь хамгийн их үзэлттэй шууд дамжуулалт. Маргааш нь, бичгээр: таван нөөцлөлтийн техникээс,

0:25 аль нь ч найдвартай ажиллахгүй байсан. Яаж болсон, яагаад боломжтой байсан, мөн хэн үнэхээр буруутай вэ. Энэ бол The Daily Diff, постмортем. Оройн 5:20: инженер үйлдвэрлэлийг зураг авсан шатны орчинд ачаалал тэнцвэржүүлэгчийг шалгах зорилгоор. Оройн 7: мэдээллийн санг спам довтолсон, нэмэлтээр GitLab-ын ажилтныг хатуу устгах ажиллагаа тролл хэлмэгдүүлсэн гэж мэдээлсэн байв. Оройн 11: реплика хэтэрхий хоцорсон тул үндсэн сервер аль хэдийнээ

0:48 шаардлагатай лог файлыг хаясан байв; цорын ганц шийдэл нь репликаг устгаж, үндсэн серверийг дахин хуулах явдал байв. pg\_basebackup ямар ч гаралтгүйгээр гацсан. Үнэн хэрэгтээ энэ нь үндсэн серверийг чимээгүй хүлээж байсан; хэн ч үүнийг мэдээгүй, мөн гарын авлагад дурдагдаагүй. Оройн 11 цагт ажлаа дуусгах гэж байсан инженер хоосон өгөгдлийн директор асуудал байна гэж шийдээд устгажээ. db1 дээр. Үндсэн сервер дээр. Тэр нэг хоёр секундын дараа анзаарсан; ойролцоогоор гурван зуун гигабайтаас,

1:11 4.5 үлдсэн. Нөөцлөлтүүд. Нэг: pg\_dump-ыг S3 руу, өдөр бүр. Баакет хоосон байсан. Крон ажиллагаа мэдээллийн сан байхгүй апп сервер дээр ажилладаг тул багц 9.6 мэдээллийн санд зориулсан PostgreSQL 9.2 бинариг сонгож, амжилтгүй болж, алдааны имэйлийг илгээсэн боловч DMARC байхгүй тул буцсан. Хоёр: Azure дискийн зураг, файлын серверүүдэд идэвхжүүлсэн, мэдээллийн сангуудад биш.

1:32 Гурав: реплика, нэг цагийн өмнө зориудаар устгагдсан. Дөрөв: өдөр тутмын зураг, 24 цагийн өмнөх, шатны орчны синхрончлолоор бүх вэбхукүүд устгагдсан. Тав: 5:20-ийн гарын авлагын зураг, хамааралгүй туршилтад зориулсан. Энэ нь ялсан. Сэргээх гэдэг нь шатны орчны дискийг Azure-ийн хямд хадгалах сангаар секундэд жаран мегабит хурдаар үйлдвэрлэл рүү хуулах явдал юм: арван найман цаг. GitLab.com 2-р сарын 1-нд оройн зургаан цагт сэргэсэн. UTC, зургаан цагийн өгөгдөл хуучин байдлаар.

1:58 git blame: нэг үсгээр ялгаатай хоёр хостны нэр, мөн хэн ч хэзээ ч сэргээж үзээгүй таван нөөцлөлтийн систем. Инженер биш. Постмортем, Гүйцэтгэх захирлаар гарын үсэг зурсан, түүнийг нэргүй үлдээж, үйлдвэрлэлийн команд авах мөрийг улаанаар будаж, өгөгдлийн бат бөх байдалд эзэмшигчийг өгсөн, учир нь өмнө нь энэ нь байхгүй байсан. Үр нөлөөний хүрээ: арван найман цаг ажиллаагүй, зургаан цагийн өгөгдөл алдагдсан, ойролцоогоор таван мянган төсөл, таван мянган сэтгэгдэл, долоон зуун шинэ хэрэглэгч, мөн таван мянган хүн явцын барыг харсан.

2:18 Hacker News шууд баримт бичигт 1,162 оноо өгч, нэг мөрийг тэдэнд эш татсан: таван нөөцлөлтөөс, нэг нь ч үгүй. Дүгнэлт, постмортем: SHIP IT, хариу үйлдлийн хувьд. Тэд ослыг олон нийтэд нээлттэй явуулж, үйл явцыг буруутгаж, засварын жагсаалтыг асуудлын дугааруудын хамт нийтэлсэн. Даваа гарагийн үйлдэл: нөөцлөлтийг сэргээх. Хэрэв та үүнийг хэзээ ч сэргээж байгаагүй бол, танд байхгүй. Одоо хүртэл ярихыг хориглосон ослыг надад илгээнэ үү,

2:42 коммент хэсэгт, эсвэл daily diff dot dev хаягаар. Мөн өнөөдрийн ялгаа энэ байна. Би Axrisi-гийн Нико. Хариуцлагатай нэгдээрэй. Хариуцлагатай нэгдээрэй.

## Эх сурвалжууд

- [GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/) — about.gitlab.com
- [GitLab, "GitLab.com database incident" (Feb 1, 2017)](https://about.gitlab.com/blog/gitlab-dot-com-database-incident/) — about.gitlab.com
- [@gitlabstatus, "We accidentally deleted production data…"](https://twitter.com/gitlabstatus/status/826591961444384768) — twitter.com
- [@gitlabstatus, emergency maintenance notice](https://twitter.com/gitlabstatus/status/826572933304827904) — twitter.com
- [Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)](https://news.ycombinator.com/item?id=13537052) — news.ycombinator.com
- [Hacker News, the postmortem thread (377 points)](https://news.ycombinator.com/item?id=13619714) — news.ycombinator.com