# Mhandisi alifuta hifadhidata ya uzalishaji ya GitLab. Gigabytes 300.

Published: 2026-09-10

Januari 31, 2017, 23:27 UTC: mhandisi wa GitLab, akipambana na nakala iliyovunjika mwishoni mwa usiku mrefu, anaondoa saraka ya data ya PostgreSQL kwenye db1 badala ya db2. db1 ndiyo msingi. Karibu GB 300 za hifadhidata ya GitLab.com zimepotea kwa sekunde moja au mbili, na kati ya mifumo mitano ya chelezo na urudufishaji, hakuna hata mmoja anayefanya kazi. Uchunguzi wa baada ya tukio: ratiba kutoka kwa ongezeko la barua taka hadi jina la seva lisilofaa, kwa nini pg\_basebackup ilionekana kukwama, kwa nini pg\_dump ilikuwa ikishindwa kimya kimya (9.2 faili za binary kwenye hifadhidata ya 9.6, barua pepe za kushindwa zilizokataliwa na DMARC), urejeshaji wa saa 18 kutoka kwenye picha ya staging ya saa 6 iliyopita iliyopakia moja kwa moja kwenye YouTube, na nani hasa anapaswa kulaumiwa. Hukumu juu ya majibu: SHIP IT.

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

## Nini video hii inashughulikia

- Jan 31, 2017: rm -Rvf kwenye saraka ya data ya msingi; ~300 GB ziliondolewa, 4.5 GB zilibaki
- Chelezo 5 kati ya 5 zimeshindwa: kikasha tupu cha S3 (kutolingana kwa toleo la pg\_dump), hakuna picha za Azure kwenye DB, nakala iliyofutwa, nakala ya LVM ya kila siku bila webhooks
- Feb 1, 18:00 UTC: GitLab.com imerejeshwa kutoka kwenye picha ya staging ya saa 6 iliyopita; waraka wa moja kwa moja, mtiririko wa moja kwa moja, uchunguzi wa baada ya tukio bila lawama na orodha ya marekebisho

## Nakala iliyotafsiriwa

Imetafsiriwa kutoka simulizi asili ya Kiingereza. Sauti na manukuu yanayopatikana yanadhibitiwa na YouTube.

0:00 Mhandisi wa GitLab anaendesha rm -rf kwenye seva isiyofaa ya hifadhidata, na gigabytes mia tatu za GitLab dot com zinatoweka kwa sekunde moja au mbili, kama muda unaochukua kusoma jina la seva. Januari 31, 2017, 11:27 jioni. UTC. GitLab inatweet kwamba ilifuta data ya uzalishaji kwa bahati mbaya, inafungua maelezo yake ya tukio kwa mtandao, na inatiririsha urejeshaji kwenye YouTube, mtiririko wa pili kwa ukubwa kwenye jukwaa. Siku inayofuata, kwa maandishi: kati ya mbinu tano za chelezo,

0:25 hakuna hata moja inayofanya kazi kwa uhakika. Inavyotokea, kwa nini inawezekana, na nani hasa anapaswa kulaumiwa. Huu ni The Daily Diff, uchunguzi wa baada ya tukio. 5:20 jioni: mhandisi anachukua picha ya uzalishaji ili kujaribu kipakiaji cha mizani katika staging. 7 jioni: barua taka zinagonga hifadhidata, pamoja na kazi inayofuta kabisa mfanyakazi wa GitLab iliyotajwa na troll kwa matumizi mabaya. 11 jioni: nakala inaanguka nyuma sana kiasi kwamba msingi tayari umefuta

0:48 logi inayohitaji; suluhisho pekee ni kufuta nakala na kunakili msingi tena. pg\_basebackup inakwama bila pato. Kwa kweli inasubiri, kimya kimya, kwa msingi; hakuna anayejua hilo, na kitabu cha mwongozo hakisemi. Mhandisi, aliyekusudia kumaliza kazi saa kumi na moja, anaamua kuwa saraka tupu ya data ndiyo shida na anaiondoa. Kwenye db1. Msingi. Anaona sekunde moja au mbili baadaye; kati ya gigabytes mia tatu hivi,

1:11 4.5 zimebaki. Chelezo. Moja: pg\_dump kwa S3, kila siku. Kikasha ni tupu. Kazi ya cron inaendeshwa kwenye seva ya programu isiyo na hifadhidata, kwa hivyo kifurushi kinachukua faili za binary za PostgreSQL 9.2 kwa hifadhidata ya 9.6, inashindwa, na inatuma barua pepe kushindwa, ambayo inarudishwa kwa kukosekana kwa DMARC. Mbili: picha za diski za Azure, zimewezeshwa kwa seva za faili, sio hifadhidata.

1:32 Tatu: nakala, ilifutwa kwa makusudi saa moja iliyopita. Nne: picha ya kila siku, ya saa 24, kila webhook imeondolewa na usawazishaji wa staging. Tano: picha ya mwongozo kutoka 5:20, kwa jaribio lisilohusiana. Hiyo inashinda. Kurejesha kunamaanisha kunakili diski ya staging kurudi kwenye uzalishaji kupitia hifadhi ya bei nafuu ya Azure kwa megabiti sitini kwa sekunde: saa kumi na nane. GitLab dot com imerudi Februari 1 saa sita jioni UTC, data ya saa sita imepitwa na wakati.

1:58 git blame: majina mawili ya seva tofauti kwa herufi moja, na mifumo mitano ya chelezo hakuna mtu aliyewahi kurejesha kutoka. Sio mhandisi. Uchunguzi wa baada ya tukio, uliosainiwa na Mkurugenzi Mtendaji, unamfanya asijulikane, unaweka rangi nyekundu kwenye kidokezo cha uzalishaji, na unampa mmiliki wa kudumu kwa data, kwa sababu hadi sasa haikuwa na mmiliki. Eneo la athari: masaa kumi na nane yamepungua, data ya saa sita imepotea, karibu miradi elfu tano, maoni elfu tano,

2:18 watumiaji wapya mia saba, na watu elfu tano wakitazama upau wa maendeleo. Hacker News inatoa waraka wa moja kwa moja pointi 1,162 na inanukuu mstari mmoja kuwarudishia: kati ya chelezo tano, hakuna hata moja. Hukumu, uchunguzi wa baada ya tukio: SHIP IT, juu ya majibu. Wanaendesha tukio hadharani, wanalalamikia mchakato, na kuchapisha orodha ya marekebisho pamoja na namba za suala. Kitendo cha Jumatatu: rejesha chelezo. Ikiwa haujawahi kuirejesha, huna moja.

2:42 Nitumie tukio ambalo bado huruhusiwi kulizungumzia, katika maoni, au kwa the daily diff dot dev. Na hiyo ndiyo diff ya leo. Mimi ni Niko kutoka Axrisi. Unganisha kwa uwajibikaji.

## Vyanzo

- [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