# အင်ဂျင်နီယာတစ်ဦးက GitLab ၏ ထုတ်လုပ်မှုဒေတာဘေ့စ်ကို ဖျက်လိုက်သည်။ 300 gigabytes ။

Published: 2026-09-10

၂၀၁၇ ခုနှစ်၊ ဇန်နဝါရီလ ၃၁ ရက်၊ ၂၃:၂၇ UTC - GitLab အင်ဂျင်နီယာတစ်ဦးသည် ညဉ့်နက်ပိုင်းအထိ အလုပ်လုပ်နေပြီး ပျက်စီးနေသော replica တစ်ခုနှင့် ရုန်းကန်နေရင်း db2 အစား db1 တွင် PostgreSQL ဒေတာလမ်းညွှန်ကို ဖျက်လိုက်သည်။ db1 သည် အဓိကဖြစ်သည်။ GitLab.com ၏ ဒေတာဘေ့စ် 300 GB ခန့်သည် တစ်စက္ကန့် သို့မဟုတ် နှစ်စက္ကန့်အတွင်း ပျောက်ကွယ်သွားပြီး၊ အရန်သိမ်းခြင်းနှင့် ပုံတူကူးခြင်း ယန္တရားငါးခုအနက် တစ်ခုမျှ အလုပ်မလုပ်တော့ပေ။ Postmortem - spam တက်လာချိန်မှ မှားယွင်းသော hostname အထိ၊ pg\_basebackup သည် အဘယ်ကြောင့် ရပ်နေသကဲ့သို့ ဖြစ်နေရသနည်း၊ pg\_dump သည် အဘယ်ကြောင့် တိတ်ဆိတ်စွာ ပျက်ကွက်နေရသနည်း (9.6 ဒေတာဘေ့စ်ပေါ်ရှိ 9.2 binaries များ၊ DMARC ကြောင့် ပျက်ကွက်မှုအီးမေးလ်များ ပြန်လာခြင်း)၊ 6 နာရီသက်တမ်းရှိ staging snapshot မှ 18 နာရီကြာ ပြန်လည်ရယူခြင်းကို YouTube တွင် တိုက်ရိုက်ထုတ်လွှင့်ခြင်း နှင့် မည်သူက တကယ်အပြစ်တင်ခံရသနည်း။ တုံ့ပြန်မှုအပေါ် စီရင်ချက် - SHIP IT ။

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

## ဤဗီဒီယိုတွင် ဖော်ပြထားသောအရာများ

- ၂၀၁၇ ခုနှစ်၊ ဇန်နဝါရီလ ၃၁ ရက် - အဓိက၏ဒေတာလမ်းညွှန်ပေါ်တွင် rm -Rvf ၊ ~300 GB ဖယ်ရှားပြီး 4.5 GB ကျန်ရှိ
- အရန်သိမ်းမှု ၅ ခုအနက် ၅ ခုပျက်ကွက် - S3 bucket လွတ်နေခြင်း (pg\_dump version မကိုက်ညီခြင်း)၊ DB တွင် Azure snapshots မရှိခြင်း၊ replica ပျက်စီးခြင်း၊ webhooks မပါဘဲ နေ့စဉ် LVM ကော်ပီ
- ဖေဖော်ဝါရီ ၁ ရက်၊ ၁၈:၀၀ UTC - GitLab.com သည် ၆ နာရီသက်တမ်းရှိ manual snapshot မှ ပြန်လည်စတင်; တိုက်ရိုက်စာရွက်စာတမ်း၊ တိုက်ရိုက်ထုတ်လွှင့်မှု၊ ပြုပြင်မှုစာရင်းပါသော အပြစ်ကင်းသော postmortem

## ဘာသာပြန်ထားသော စာသားမှတ်တမ်း

မူရင်း အင်္ဂလိပ်စကားပြောမှ ဘာသာပြန်ထားသည်။ ရရှိနိုင်သော အသံနှင့် စာတန်းထိုးများကို YouTube မှ ထိန်းချုပ်ထားသည်။

0:00 GitLab မှ အင်ဂျင်နီယာတစ်ဦးသည် မှားယွင်းသော ဒေတာဘေ့စ်ဆာဗာပေါ်တွင် rm -rf ကို လုပ်ဆောင်ခဲ့သည်၊ ထို့ကြောင့် GitLab.com ၏ ဂစ်ဂါဘိုက်သုံးရာခန့်သည် တစ်စက္ကန့် သို့မဟုတ် နှစ်စက္ကန့်အတွင်း ပျောက်ကွယ်သွားသည်၊ ၎င်းသည် hostname တစ်ခုကိုဖတ်ရန်ကြာချိန်ခန့်ပင်။ ၂၀၁၇ ခုနှစ်၊ ဇန်နဝါရီလ ၃၁ ရက်၊ ည ၁၁ နာရီ ၂၇ မိနစ်၊ UTC တွင်။ GitLab က ထုတ်လုပ်မှုဒေတာများကို မတော်တဆ ဖျက်မိကြောင်း တွစ်တာတွင် ရေးသားခဲ့သည်၊ ၎င်း၏ အဖြစ်အပျက်မှတ်စုများကို အင်တာနက်သို့ ဖွင့်ပြခဲ့ပြီး ပြန်လည်ရယူခြင်းကို YouTube တွင် တိုက်ရိုက်ထုတ်လွှင့်ခဲ့သည်၊ ၎င်းသည် platform ပေါ်ရှိ နံပါတ်နှစ် တိုက်ရိုက်ထုတ်လွှင့်မှုဖြစ်သည်။ နောက်တစ်နေ့တွင် စာဖြင့်ရေးသားဖော်ပြသည် - အရန်သိမ်းနည်းပညာငါးခုအနက်၊

0:25 တစ်ခုမျှ ယုံကြည်စိတ်ချရစွာ အလုပ်မလုပ်ပါ။ မည်သို့ဖြစ်ပျက်ခဲ့သည်၊ အဘယ်ကြောင့် ဖြစ်နိုင်ခဲ့သည်၊ နှင့် မည်သူက အမှန်တကယ် အပြစ်တင်ခံရသည်ကို ဖော်ပြထားသည်။ ၎င်းသည် The Daily Diff, postmortem ဖြစ်သည်။ ညနေ ၅:၂၀ နာရီ - အင်ဂျင်နီယာတစ်ဦးသည် ထုတ်လုပ်မှုကို snapshots ရိုက်ခဲ့သည် staging တွင် load balancer ကို စမ်းသပ်ရန်။ ည ၇ နာရီ - spam များသည် ဒေတာဘေ့စ်ကို ဖိအားပေးသည်၊ ထို့အပြင် GitLab ဝန်ထမ်းတစ်ဦးကို အတင်းအဓမ္မ ဖျက်ပစ်သည့် အလုပ်တစ်ခု troll က အလွဲသုံးစားလုပ်မှုအတွက် တိုင်ကြားခဲ့သည်၊ ည ၁၁ နာရီ - replica သည် နောက်ကျကျန်နေခဲ့သဖြင့် အဓိကသည် လိုအပ်သော log ကို ဖယ်ရှားပြီးဖြစ်သည်။

0:48 တစ်ခုတည်းသော ပြုပြင်နည်းမှာ replica ကို ဖျက်ပြီး အဓိကကို ပြန်ကူးရန်ဖြစ်သည်။ pg\_basebackup သည် output မရှိဘဲ ရပ်တန့်နေသည်။ ၎င်းသည် တကယ်တမ်းတွင် တိတ်ဆိတ်စွာ အဓိကကို စောင့်နေခြင်းဖြစ်သည်၊ မည်သူမျှ မသိခဲ့ကြ၊ ထို့အပြင် runbook တွင်လည်း ဖော်ပြထားခြင်းမရှိပါ။ ည ၁၁ နာရီတွင် အလုပ်ရပ်နားရန် ရည်ရွယ်ခဲ့သော အင်ဂျင်နီယာသည် အချက်အလက်လမ်းညွှန် လွတ်နေခြင်းကို ပြဿနာဟု ဆုံးဖြတ်ပြီး ဖယ်ရှားခဲ့သည်။ ၎င်းကို ဖယ်ရှားခဲ့သည်။ db1 တွင်။ အဓိကတွင်။ သူသည် တစ်စက္ကန့် သို့မဟုတ် နှစ်စက္ကန့်အကြာတွင် သတိပြုမိသည်၊ ဂစ်ဂါဘိုက်သုံးရာခန့်အနက်၊

1:11 4.5 ကျန်ရှိသည်။ အရန်သိမ်းမှုများ။ တစ်ခု - နေ့စဉ် S3 သို့ pg\_dump ။ bucket က ဗလာသက်သက်။ cron job သည် ဒေတာဘေ့စ်မရှိသော app server ပေါ်တွင် လုပ်ဆောင်သည်၊ ထို့ကြောင့် package သည် 9.6 ဒေတာဘေ့စ်အတွက် PostgreSQL 9.2 binaries ကို ရွေးချယ်ပြီး ပျက်ကွက်ကာ အီးမေးလ်ပို့သည်၊ ထိုပျက်ကွက်မှုသည် DMARC မရှိ၍ bounce ပြန်လာသည်။ နှစ်ခု - file server များအတွက် Azure disk snapshots ကို ဖွင့်ထားသည်၊ ဒေတာဘေ့စ်များအတွက် မဟုတ်ပါ။

1:32 သုံးခု - replica ကို တစ်နာရီအကြာက တမင်ဖျက်ထားသည်။ လေးခု - နေ့စဉ် snapshot ၊ ၂၄ နာရီသက်တမ်းရှိသည်၊ staging sync ကြောင့် webhook အားလုံးကို ဖယ်ရှားထားသည်၊ ငါးခု - ညနေ ၅:၂၀ မှ manual snapshot၊ ဆက်စပ်မှုမရှိသော စမ်းသပ်မှုတစ်ခုအတွက်။ ထိုတစ်ခုက အနိုင်ရသည်။ ပြန်လည်ရယူခြင်းဆိုသည်မှာ staging disk ကို Azure ၏ စျေးသက်သာသော စတိုးရေ့ချ်မှတစ်ဆင့် တစ်စက္ကန့်လျှင် မဂ္ဂါဘစ်ခြောက်ဆယ်နှုန်းဖြင့် ထုတ်လုပ်မှုသို့ ပြန်ကူးခြင်း - ၁၈ နာရီကြာသည်။ GitLab.com သည် ဖေဖော်ဝါရီလ ၁ ရက်နေ့ ည ၆ နာရီတွင် ပြန်လည်ရရှိသည်၊ UTC၊ ၆ နာရီသက်တမ်းရှိ ဒေတာများ ပိုမိုဟောင်းနွမ်းသွားသည်။

1:58 git blame - hostname နှစ်ခုသည် စာလုံးတစ်လုံးစီ ကွာခြားသည်၊ ထို့အပြင် မည်သူမျှ ပြန်လည်ရယူဖူးခြင်းမရှိသော အရန်သိမ်းစနစ်ငါးခု။ အင်ဂျင်နီယာတော့ မဟုတ်ဘူး။ CEO လက်မှတ်ထိုးထားသော postmortem သည် သူ့ကို အမည်မဖော်ဘဲ ထားသည်၊ ထုတ်လုပ်မှု prompt ကို အနီရောင်ခြယ်ပြီး ဒေတာတည်တံ့ခိုင်မြဲမှုကို ပိုင်ရှင်ပေးခဲ့သည်၊ အကြောင်းမှာ ယခုအချိန်အထိ ပိုင်ရှင်မရှိခဲ့၍ ဖြစ်သည်။ ထိခိုက်မှုပမာဏ - ၁၈ နာရီ ရပ်တန့်၊ ၆ နာရီကြာ ဒေတာ ပျောက်ဆုံး၊ စီမံကိန်းပေါင်း ငါးထောင်ခန့်၊ မှတ်ချက်ပေါင်း ငါးထောင်ခန့်၊

2:18 အသုံးပြုသူအသစ် ခုနစ်ရာနှင့် progress bar ကိုကြည့်နေသူ ငါးထောင်။ Hacker News သည် live doc ကို 1,162 မှတ် ပေးပြီး စာကြောင်းတစ်ကြောင်းကို ကိုးကားသည် ၎င်းတို့ထံ ပြန်လည်ပေးပို့သည် - အရန်သိမ်းမှု ငါးခုအနက် တစ်ခုမျှမရှိ။ စီရင်ချက်၊ postmortem - တုံ့ပြန်မှုအပေါ် SHIP IT ။ သူတို့သည် အဖြစ်အပျက်ကို လူသိရှင်ကြား လုပ်ဆောင်ခဲ့သည်၊ လုပ်ငန်းစဉ်ကို အပြစ်တင်သည်၊ ထို့အပြင် ပြုပြင်မှုစာရင်းကို ထုတ်ပြန်ခဲ့သည် issue နံပါတ်များနှင့်တကွ။ တနင်္လာနေ့ အရေးယူမှု - အရန်သိမ်းမှုကို ပြန်လည်ရယူပါ။ အကယ်၍ သင်သည် ၎င်းကို တစ်ခါမျှ ပြန်လည်ရယူဖူးခြင်းမရှိလျှင်၊ သင့်တွင် တစ်ခုမှ မရှိပါ။

2:42 သင်ပြောခွင့်မရှိသေးသည့် အဖြစ်အပျက်ကို ကျွန်ုပ်ထံ ပေးပို့ပါ၊ မှတ်ချက်များတွင် သို့မဟုတ် the daily diff dot dev တွင်။ ထိုအရာသည် ယနေ့အတွက် diff ဖြစ်သည်။ ကျွန်တော်က Axrisi မှ Niko ပါ။ တာဝန်ယူမှုရှိစွာ ပေါင်းစည်းပါ။

## ရင်းမြစ်များ

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