Ինժեները ջնջել է GitLab-ի արտադրական տվյալների բազան: 300 գիգաբայթ։
2017 թվականի հունվարի 31-ին, ժամը 23:27 UTC.
2017 թվականի հունվարի 31-ին, ժամը 23:27 UTC. GitLab-ի ինժեները, երկար գիշերվա վերջում պայքարելով կոտրված պատճենի հետ, հեռացնում է PostgreSQL-ի տվյալների գրացուցակը db1-ից՝ db2-ի փոխարեն: db1-ը հիմնականն է։ GitLab.com-ի տվյալների բազայի մոտ 300 ԳԲ անհետանում է մեկ-երկու վայրկյանում, և հինգ կրկնօրինակման ու պատճենահանման մեխանիզմներից ոչ մեկը չի աշխատում։ Հետմահու. ժամանակագրությունն աղբի պիկից մինչև սխալ հոսթի անունը, թե ինչու էր pg_basebackup-ը խրված թվում, թե ինչու էր pg_dump-ը լուռ ձախողվում (9.2 երկուական ֆայլեր 9.6 տվյալների բազայի վրա, ձախողման էլ. նամակները հետ էին շպրտվում DMARC-ի կողմից), 18-ժամյա վերականգնումը 6-ժամյա հնության փուլային նկարից, որը հեռարձակվում էր YouTube-ով, և թե ով է իրականում մեղավոր։ Արձագանքի վճիռը՝ SHIP IT։
Կարդացեք գրավոր տարբերակը (անգլերեն) ↗
Ինչ է ընդգրկում այս տեսանյութը
- 2017թ. հունվարի 31. rm -Rvf հիմնականի տվյալների գրացուցակում. ~300 ԳԲ հեռացված, 4.5 ԳԲ մնացած։
- 5 կրկնօրինակումներից 5-ը ձախողվում են. դատարկ S3 պահեստ (pg_dump տարբերակի անհամապատասխանություն), տվյալների բազայում Azure նկարներ չկան, ջնջված պատճեն, ամենօրյա LVM պատճեն առանց վեբ հանգույցների։
- Փետրվարի 1, 18:00 UTC. GitLab.com-ը վերականգնված է 6-ժամյա հնության ձեռքով արված նկարից. կենդանի փաստաթուղթ, կենդանի հոսք, անմեղ հետմահու վերլուծություն շտկումների ցուցակով։
Թարգմանված արձանագրություն
Թարգմանվել է բնօրինակ անգլերեն պատմությունից։ Հասանելի աուդիո և ենթագրերը վերահսկվում են YouTube-ի կողմից։
0:00 GitLab-ի ինժեներն անսպասելիորեն գործարկում է rm -rf հրամանը սխալ տվյալների բազայի սերվերի վրա, եւ GitLab dot com-ի երեք հարյուր գիգաբայթ տեղեկատվություն անհետանում է մեկ-երկու վայրկյանում, մոտավորապես այնքան ժամանակ է պետք, որքան անհրաժեշտ է հոսթի անուն կարդալու համար։ 2017 թվականի հունվարի 31-ը, ժամը 11:27 երեկոյան, UTC. GitLab-ը թվիթ է անում, որ պատահաբար ջնջել է արտադրական տվյալները, բացում է իր միջադեպի նշումները ինտերնետի համար և հեռարձակում վերականգնումը YouTube-ում, հարթակի երկրորդ ամենադիտված ուղիղ հեռարձակումը։ Հաջորդ օրը, գրավոր. հինգ կրկնօրինակման տեխնիկաներից,
0:25 ոչ մեկը հուսալիորեն չի աշխատում։ Ինչպես է դա տեղի ունենում, ինչու է հնարավոր, և ով է իրականում մեղավոր։ Սա The Daily Diff-ն է, հետմահու վերլուծություն։ Երեկոյան 5:20. ինժեներն արտադրությունից լուսանկար է անում ՝ փորձարկելու բեռնվածության հավասարակշռիչը փուլային միջավայրում։ Ժամը 7 երեկոյան՝ սպամը հարվածում է տվյալների բազային, գումարած մի աշխատանք, որը կոշտ ջնջում է GitLab-ի աշխատակցին մի տրոլի, որին հայտնել էին չարաշահման համար։ Երեկոյան 11-ին. պատճենը այնքան է հետ մնում, որ հիմնականն արդեն մերժել էր
0:48 անհրաժեշտ լոգը. միակ շտկումը պատճենը ջնջելն ու հիմնականը նորից պատճենելն է: pg_basebackup-ը կախվում է առանց ելքի։ Այն իրականում լուռ սպասում է հիմնականին. ոչ ոք դա չգիտի, և գործարկման ուղեցույցը չի ասում։ Ինժեները, ով մտադիր էր դուրս գալ ժամը տասնմեկին, որոշում է, որ դատարկ տվյալների գրացուցակը խնդիրն է և հեռացնում է այն։ Db1-ի վրա։ Հիմնականը։ Նա նկատում է մեկ-երկու վայրկյան անց. մոտ երեք հարյուր գիգաբայթից,
1:11 4.5-ը մնացել է։ Կրկնօրինակները։ Մեկ. pg_dump դեպի S3, ամենօրյա։ Պահեստը դատարկ է։ Cron աշխատանքը գործում է հավելվածի սերվերի վրա՝ առանց տվյալների բազայի, ուստի փաթեթը ընտրում է PostgreSQL 9.2 երկուական ֆայլեր 9.6 տվյալների բազայի համար, ձախողվում է և էլեկտրոնային նամակներ է ուղարկում ձախողման մասին, որոնք հետ են մերժվում DMARC-ի բացակայության պատճառով: Երկու. Azure սկավառակի նկարներ, միացված ֆայլային սերվերների համար, ոչ թե տվյալների բազաների։
1:32 Երեք. պատճենը, մեկ ժամ առաջ հատուկ ջնջված։ Չորս. ամենօրյա նկարը, 24 ժամականի հնության, յուրաքանչյուր վեբհանգույց հեռացված է փուլային սինխրոնիզացիայի կողմից։ Հինգ. ձեռքով արված նկարը ժամը 5:20-ից, անկապ թեստի համար։ Այդ մեկը հաղթում է։ Վերականգնումը նշանակում է փուլային սկավառակը կրկնօրինակել արտադրության մեջ Azure-ի էժան պահեստի վրայով՝ վաթսուն մեգաբիթ/վայրկյան արագությամբ. տասնութ ժամ։ GitLab dot com-ը վերադառնում է փետրվարի 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)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



