ஒரு பொறியாளர் GitLab இன் உற்பத்தித் தரவுத்தளத்தை நீக்கிவிட்டார். 300 ஜிகாபைட்டுகள்.
ஜனவரி 31, 2017, 23:27 UTC: ஒரு GitLab பொறியாளர், நீண்ட இரவின் முடிவில் உடைந்த பிரதி ஒன்றை சரிசெய்ய போராடிக் கொண்டிருந்தபோது, db2 க்கு பதிலாக db1 இல் PostgreSQL தரவு கோப்பகத்தை நீக்கிவிட்டார்.
ஜனவரி 31, 2017, 23:27 UTC: ஒரு GitLab பொறியாளர், நீண்ட இரவின் முடிவில் உடைந்த பிரதி ஒன்றை சரிசெய்ய போராடிக் கொண்டிருந்தபோது, db2 க்கு பதிலாக db1 இல் PostgreSQL தரவு கோப்பகத்தை நீக்கிவிட்டார். db1 முதன்மையானது. GitLab.com இன் தரவுத்தளத்தில் சுமார் 300 GB ஒரு நொடி அல்லது இரண்டு நொடிகளில் மறைந்துவிட்டது, மேலும் ஐந்து காப்புப்பிரதி மற்றும் பிரதிபலிப்பு வழிமுறைகளில், எதுவும் வேலை செய்யவில்லை. பிந்தைய ஆய்வு: ஸ்பேம் எழுச்சியில் இருந்து தவறான ஹோஸ்ட்நேம் வரையிலான காலவரிசை, pg_basebackup ஏன் சிக்கியதாகத் தோன்றியது, pg_dump ஏன் சத்தமில்லாமல் தோல்வியடைந்தது (9.6 தரவுத்தளத்தில் 9.2 பைனரிகள், DMARC ஆல் தோல்வி மின்னஞ்சல்கள் திரும்ப அனுப்பப்பட்டன), 6 மணிநேர பழைய ஸ்டேஜிங் ஸ்னாப்ஷாட்டில் இருந்து YouTube இல் நேரலையில் ஒளிபரப்பப்பட்ட 18 மணிநேர மீட்டெடுப்பு, மற்றும் யார் உண்மையில் பழியை ஏற்கிறார்கள். பதிலின் மீதான தீர்ப்பு: SHIP IT.
எழுத்துப்பூர்வ பதிப்பைப் படிக்கவும் (ஆங்கிலம்) ↗
இந்த வீடியோ எதைப் பற்றி விவாதிக்கிறது
- ஜனவரி 31, 2017: முதன்மை தரவு கோப்பகத்தில் rm -Rvf; ~300 GB நீக்கப்பட்டது, 4.5 GB எஞ்சியிருந்தது
- 5 காப்புப்பிரதிகளில் 5 தோல்வியடைந்தது: காலியான S3 பக்கெட் (pg_dump பதிப்பு பொருந்தவில்லை), DB இல் Azure ஸ்னாப்ஷாட்கள் இல்லை, துடைக்கப்பட்ட பிரதி, வெப்ஹூக்குகள் இல்லாத தினசரி LVM நகல்
- பிப்ரவரி 1, 18:00 UTC: GitLab.com 6 மணிநேர பழைய கையேடு ஸ்னாப்ஷாட்டில் இருந்து திரும்பி வந்தது; நேரடி ஆவணம், நேரடி ஒளிபரப்பு, சரிசெய்யும் பட்டியலுடன் குற்றமற்ற பிந்தைய ஆய்வு
மொழிபெயர்க்கப்பட்ட டிரான்ஸ்கிரிப்ட்
அசல் ஆங்கில விளக்கத்திலிருந்து மொழிபெயர்க்கப்பட்டது. கிடைக்கும் ஆடியோ மற்றும் தலைப்புகள் YouTube ஆல் கட்டுப்படுத்தப்படுகின்றன.
0:00 GitLab இல் உள்ள ஒரு பொறியாளர் தவறான தரவுத்தள சேவையகத்தில் rm -rf ஐ இயக்குகிறார், மற்றும் GitLab டாட் காமின் முந்நூறு ஜிகாபைட்கள் ஒரு நொடி அல்லது இரண்டு நொடிகளில் மறைந்துவிடும், ஒரு ஹோஸ்ட்நேமைப் படிக்க எவ்வளவு நேரம் ஆகும் என்பதற்குச் சமம். ஜனவரி 31, 2017, இரவு 11:27. UTC. GitLab தற்செயலாக உற்பத்தித் தரவை நீக்கிவிட்டதாக ட்வீட் செய்கிறது, அதன் சம்பவக் குறிப்புகளை இணையத்தில் வெளியிடுகிறது, மற்றும் மீட்டெடுப்பை YouTube இல் ஒளிபரப்புகிறது, மேடையில் இரண்டாவது நேரடி ஒளிபரப்பு. மறுநாள், எழுத்துப்பூர்வமாக: ஐந்து காப்புப்பிரதி நுட்பங்களில்,
0:25 எதுவும் நம்பகத்தன்மையுடன் செயல்படவில்லை. இது எப்படி நிகழ்கிறது, ஏன் இது சாத்தியம், மற்றும் யார் உண்மையில் பழியை ஏற்கிறார்கள். இது The Daily Diff, பிந்தைய ஆய்வு. மாலை 5:20: ஒரு பொறியாளர் உற்பத்தியின் ஸ்னாப்ஷாட்டை எடுக்கிறார் ஸ்டேஜிங்கில் ஒரு லோட் பேலன்சரை சோதிக்க. மாலை 7:00: ஸ்பேம் தரவுத்தளத்தை தாக்குகிறது, மேலும் ஒரு GitLab ஊழியரை ஹார்ட்-நீக்கும் வேலை ஒரு ட்ரோல் தவறாகப் பயன்படுத்தியதாக அறிவித்தது. இரவு 11:00: பிரதி மிகவும் பின்தங்குகிறது, முதன்மையானது ஏற்கனவே நிராகரித்துவிட்டது
0:48 அதற்குத் தேவையான லாக்; ஒரே வழி, பிரதியை துடைத்து முதன்மையை நகலெடுப்பது மீண்டும். pg_basebackup எந்த வெளியீடும் இல்லாமல் தொங்குகிறது. அது உண்மையில் காத்திருக்கிறது, அமைதியாக, முதன்மைக்காக; யாருக்கும் அது தெரியாது, மற்றும் ரன்புக் சொல்லவில்லை. இரவு பதினொன்று மணிக்கு வெளியேற விரும்பிய பொறியாளர், காலியான தரவு கோப்பகம் தான் பிரச்சனை என்று கருதி அதை நீக்குகிறார். db1 இல். முதன்மையானது. ஒரு நொடி அல்லது இரண்டு நொடிகளுக்குப் பிறகு அவர் கவனிக்கிறார்; தோராயமாக முன்னூறு ஜிகாபைட்களில்,
1:11 4.5 எஞ்சியிருக்கின்றன. காப்புப்பிரதிகள். ஒன்று: pg_dump to S3, தினசரி. பக்கெட் காலியாக உள்ளது. குரோன் வேலை ஒரு தரவுத்தளமும் இல்லாத ஒரு ஆப் சேவையகத்தில் இயங்குகிறது, எனவே தொகுப்பு 9.6 தரவுத்தளத்திற்கான PostgreSQL 9.2 பைனரிகளைத் தேர்ந்தெடுத்து, தோல்வியடைந்து, மின்னஞ்சல்கள் தோல்வி, DMARC இல்லாததால் திரும்ப அனுப்பப்படுகிறது. இரண்டு: Azure டிஸ்க் ஸ்னாப்ஷாட்கள், கோப்பு சேவையகங்களுக்கு செயல்படுத்தப்பட்டது, தரவுத்தளங்களுக்கு அல்ல.
1:32 மூன்று: பிரதி, ஒரு மணி நேரத்திற்கு முன்பு வேண்டுமென்றே துடைக்கப்பட்டது. நான்கு: தினசரி ஸ்னாப்ஷாட், 24 மணி நேரம் பழமையானது, ஒவ்வொரு வெப்ஹூக்கும் ஸ்டேஜிங் ஒத்திசைவால் நீக்கப்பட்டது. ஐந்து: 5:20 மணிக்கு எடுக்கப்பட்ட கையேடு ஸ்னாப்ஷாட், ஒரு தொடர்பில்லாத சோதனைக்கு. அதுதான் வென்றது. மீட்டெடுப்பது என்பது ஸ்டேஜிங் டிஸ்க்கை Azure இன் மலிவான சேமிப்பகத்தில் ஒரு வினாடிக்கு அறுபது மெகாபிட்களில் உற்பத்திக்கு மீண்டும் நகலெடுப்பது: பதினெட்டு மணிநேரம். GitLab டாட் காம் பிப்ரவரி 1 ஆம் தேதி மாலை ஆறு மணிக்கு திரும்பி வருகிறது. UTC, ஆறு மணிநேர தரவு பழமையானது.
1:58 git blame: இரண்டு ஹோஸ்ட்நேம்கள் ஒரு எழுத்து வித்தியாசத்தில், மற்றும் ஐந்து காப்புப்பிரதி அமைப்புகள் யாரும் ஒருபோதும் மீட்டெடுக்கப்படாதவை. பொறியாளர் அல்ல. CEO ஆல் கையெழுத்திடப்பட்ட பிந்தைய ஆய்வு, அவரை அநாமதேயராக வைத்திருக்கிறது, உற்பத்தி வரியில் சிவப்பு நிறத்தை பூசி, தரவு நிலைத்தன்மைக்கு ஒரு உரிமையாளரை நியமிக்கிறது, ஏனெனில் இதுவரை அது இல்லை. தாக்கத்தின் பரப்பளவு: பதினெட்டு மணிநேரம் செயலிழந்தது, ஆறு மணிநேர தரவு நீக்கப்பட்டது, தோராயமாக ஐயாயிரம் திட்டங்கள், ஐயாயிரம் கருத்துகள்,
2:18 ஏழு நூறு புதிய பயனர்கள், மற்றும் ஐயாயிரம் பேர் ஒரு முன்னேற்றப் பட்டியைப் பார்க்கிறார்கள். Hacker News நேரடி ஆவணத்திற்கு 1,162 புள்ளிகள் அளிக்கிறது மற்றும் ஒரு வரிசை அவர்களுக்குத் திரும்பக் கூறுகிறது: ஐந்து காப்புப்பிரதிகளில், எதுவும் இல்லை. தீர்ப்பு, பிந்தைய ஆய்வு: பதிலை SHIP IT. அவர்கள் இந்த சம்பவத்தை பொதுவில் நடத்துகிறார்கள், செயல்முறையைக் குறை கூறுகிறார்கள், மற்றும் சரிசெய்யும் பட்டியலை வெளியிடுகிறார்கள் பிரச்சனை எண்களுடன். திங்கட்கிழமை நடவடிக்கை: ஒரு காப்புப்பிரதியை மீட்டெடுக்கவும். நீங்கள் அதை ஒருபோதும் மீட்டெடுக்கவில்லை என்றால், உங்களிடம் ஒன்று இல்லை.
2:42 நீங்கள் இன்னும் பேச அனுமதிக்கப்படாத சம்பவத்தை எனக்கு அனுப்புங்கள், கருத்துகளில், அல்லது daily diff dot dev இல். அதுதான் இன்றைய வேறுபாடு. நான் Axrisi இலிருந்து Niko. பொறுப்புடன் ஒன்றிணைக்கவும்.
ஆதாரங்கள்
- 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
