Slack-ում օգտագործվող նախագծի տեղակայման մեթոդաբանություն

Նոր նախագծի թողարկումը արտադրության մեջ բերելը պահանջում է զգույշ հավասարակշռություն տեղակայման արագության և լուծման հուսալիության միջև: Slack-ը գնահատում է արագ կրկնությունները, կարճ հետադարձ կապի ցիկլերը և օգտատերերի հարցումներին արագ արձագանքելը: Բացի այդ, ընկերությունն ունի հարյուրավոր ծրագրավորողներ, ովքեր ձգտում են հնարավորինս արդյունավետ լինել:

Նյութի հեղինակները, որոնց թարգմանությունը մենք այսօր հրապարակում ենք, ասում են, որ ընկերությունը, որը ձգտում է հավատարիմ մնալ նման արժեքներին և միևնույն ժամանակ աճում է, պետք է մշտապես բարելավի իր նախագծերի տեղակայման համակարգը։ Ընկերությունը պետք է ներդրումներ կատարի աշխատանքային գործընթացների թափանցիկության և հուսալիության մեջ՝ դա անելով ապահովելու համար, որ այդ գործընթացները համապատասխանեն ծրագրի մասշտաբին: Այստեղ մենք կխոսենք Slack-ում մշակված աշխատանքային հոսքերի և որոշ որոշումների մասին, որոնք ընկերությանը ստիպել են օգտագործել այսօր գոյություն ունեցող նախագծերի տեղակայման համակարգը:

Ինչպես են այսօր աշխատում նախագծի տեղակայման գործընթացները

Slack-ում յուրաքանչյուր PR (ձգման հարցում) պետք է ենթարկվի կոդի վերանայման և պետք է հաջողությամբ անցնի բոլոր թեստերը: Միայն այս պայմանները կատարելուց հետո ծրագրավորողը կարող է իր կոդը միավորել նախագծի գլխավոր ճյուղին: Այնուամենայնիվ, այս կոդը տեղադրվում է միայն աշխատանքային ժամերին, Հյուսիսային Ամերիկայի ժամանակով: Արդյունքում, քանի որ մեր աշխատակիցները գտնվում են իրենց աշխատավայրում, մենք լիովին պատրաստ ենք լուծելու ցանկացած անսպասելի խնդիր:

Ամեն օր մենք իրականացնում ենք մոտ 12 պլանային տեղակայում։ Յուրաքանչյուր տեղակայման ընթացքում ծրագրավորողը, որը նշանակված է որպես տեղակայման առաջատար, պատասխանատու է նոր կառուցվածքը արտադրության մեջ մտցնելու համար: Սա բազմաքայլ գործընթաց է, որն ապահովում է հավաքի սահուն արտադրությունը: Այս մոտեցման շնորհիվ մենք կարող ենք հայտնաբերել սխալները, նախքան դրանք կազդեն մեր բոլոր օգտատերերի վրա: Եթե ​​չափազանց շատ սխալներ կան, ապա հավաքի տեղակայումը կարող է հետ գլորվել: Եթե ​​թողարկումից հետո հայտնաբերվի կոնկրետ խնդիր, ապա դրա համար հեշտությամբ կարող եք շտկել:

Checkpoint համակարգի ինտերֆեյս, որն օգտագործվում է Slack-ում՝ նախագծերի տեղակայման համար

Արտադրության մեջ նոր թողարկում տեղադրելու գործընթացը կարելի է համարել չորս քայլից բաղկացած:

▍1. Ազատման մասնաճյուղի ստեղծում

Յուրաքանչյուր թողարկում սկսվում է թողարկման նոր ճյուղով, որը մեր Git պատմության մի կետն է: Սա թույլ է տալիս պիտակներ հատկացնել թողարկմանը և տրամադրում է մի վայր, որտեղ դուք կարող եք ուղիղ շտկումներ կատարել այն սխալների համար, որոնք հայտնաբերվել են թողարկումը թողարկելու պատրաստման գործընթացում:

▍2. Տեղակայում բեմական միջավայրում

Հաջորդ քայլը ժողովը տեղակայելն է բեմադրող սերվերների վրա և կատարել ավտոմատ թեստ՝ նախագծի ընդհանուր կատարման համար (ծխի թեստ): Բեմական միջավայրը արտադրական միջավայր է, որը չի ընդունում արտաքին տրաֆիկ։ Այս միջավայրում մենք լրացուցիչ ձեռքով փորձարկում ենք կատարում: Սա մեզ լրացուցիչ վստահություն է տալիս, որ փոփոխված նախագիծը ճիշտ է աշխատում: Միայն ավտոմատացված թեստերը բավարար չեն այս մակարդակի վստահություն ապահովելու համար:

▍3. Տեղադրում փորձնական և դեղձանիկ միջավայրում

Արտադրության տեղակայումը սկսվում է փորձնական միջավայրից, որը ներկայացված է մի շարք հյուրընկալողներով, որոնք սպասարկում են մեր ներքին Slack աշխատանքային տարածքները: Քանի որ մենք շատ ակտիվ Slack-ի օգտատերեր ենք, այս մոտեցումը օգնեց մեզ հայտնաբերել շատ սխալներ տեղակայման սկզբում: Այն բանից հետո, երբ մենք համոզվեցինք, որ համակարգի հիմնական ֆունկցիոնալությունը չի խախտվել, ժողովը տեղակայվում է դեղձանիկ միջավայրում: Այն ներկայացնում է համակարգեր, որոնք կազմում են արտադրական տրաֆիկի մոտավորապես 2%-ը:

▍4. Աստիճանական թողարկումը դեպի արտադրություն

Եթե ​​նոր թողարկման մոնիտորինգի ցուցիչները պարզվում են, որ կայուն են, և եթե նախագիծը դեղձանիկ միջավայրում տեղակայելուց հետո մենք որևէ բողոք չենք ստացել, մենք շարունակում ենք աստիճանաբար արտադրական սերվերները տեղափոխել նոր թողարկում: Տեղակայման գործընթացը բաժանված է հետևյալ փուլերի՝ 10%, 25%, 50%, 75% և 100%: Արդյունքում, մենք կարող ենք դանդաղորեն փոխանցել արտադրական տրաֆիկը համակարգի նոր թողարկմանը: Միևնույն ժամանակ, մենք ժամանակ ունենք հետաքննելու իրավիճակը, եթե որևէ անոմալիա հայտնաբերվի։

▍Իսկ եթե տեղակայման ժամանակ ինչ-որ բան սխալ լինի:

Կոդում փոփոխություններ կատարելը միշտ վտանգ է ներկայացնում: Բայց մենք դրան հաղթահարում ենք լավ պատրաստված «տեղակայման առաջնորդների» առկայության շնորհիվ, ովքեր ղեկավարում են նոր թողարկումը արտադրության մեջ մտցնելու գործընթացը, վերահսկում են մոնիտորինգի ցուցիչները և համակարգում ծրագրավորողների աշխատանքը, որոնք թողարկում են կոդը:

Այն դեպքում, երբ ինչ-որ բան իսկապես սխալ է ընթանում, մենք փորձում ենք հնարավորինս շուտ բացահայտել խնդիրը: Մենք ուսումնասիրում ենք խնդիրը, գտնում ենք այն PR-ը, որն առաջացնում է սխալներ, հետ ենք գլորում այն, մանրակրկիտ վերլուծում և ստեղծում նոր կառուցվածք: Ճիշտ է, երբեմն խնդիրն աննկատ է մնում, քանի դեռ նախագիծը չի մտնում արտադրության մեջ: Նման իրավիճակում ամենակարեւորը ծառայության վերականգնումն է։ Հետևաբար, նախքան խնդրի ուսումնասիրությունը սկսելը, մենք անմիջապես վերադառնում ենք նախորդ աշխատանքային կառուցվածքին:

Տեղակայման համակարգի շինանյութեր

Եկեք նայենք այն տեխնոլոգիաներին, որոնք ընկած են մեր նախագծերի տեղակայման համակարգի հիմքում:

▍Արագ տեղակայումներ

Վերևում նկարագրված աշխատանքային հոսքը, հետահայաց հայացքով, կարող է որոշակիորեն ակնհայտ թվալ: Բայց մեր տեղակայման համակարգը միանգամից այդպես չդարձավ:

Երբ ընկերությունը շատ ավելի փոքր էր, մեր ամբողջ հավելվածը կարող էր աշխատել 10 Amazon EC2 օրինակների վրա: Այս իրավիճակում նախագծի տեղակայումը նշանակում էր օգտագործել rsync՝ բոլոր սերվերները արագ համաժամեցնելու համար: Նախկինում նոր կոդը արտադրությունից ընդամենը մեկ քայլ էր հեռու՝ ներկայացված բեմական միջավայրով: Համագումարները ստեղծվեցին և փորձարկվեցին նման միջավայրում, իսկ հետո անմիջապես անցան արտադրության: Շատ հեշտ էր հասկանալ նման համակարգը, այն թույլ էր տալիս ցանկացած ծրագրավորողի ցանկացած պահի տեղակայել իր գրած կոդը:

Բայց քանի որ մեր հաճախորդների թիվը մեծանում էր, այնքան մեծանում էր ծրագրին աջակցելու համար պահանջվող ենթակառուցվածքի մասշտաբները: Շուտով, հաշվի առնելով համակարգի մշտական ​​աճը, մեր տեղակայման մոդելը, որը հիմնված էր սերվերներին նոր կոդ մղելու վրա, այլևս չէր անում իր աշխատանքը: Մասնավորապես, յուրաքանչյուր նոր սերվեր ավելացնելը նշանակում էր տեղակայումն ավարտելու համար պահանջվող ժամանակի ավելացում: Նույնիսկ rsync-ի զուգահեռ օգտագործման վրա հիմնված ռազմավարություններն ունեն որոշակի սահմանափակումներ:

Մենք ի վերջո լուծեցինք այս խնդիրը՝ անցնելով ամբողջովին զուգահեռ տեղակայման համակարգի, որը նախագծված էր հին համակարգից տարբերվող: Մասնավորապես, այժմ մենք չենք ուղարկել կոդ սերվերներին՝ օգտագործելով համաժամացման սկրիպտը։ Այժմ յուրաքանչյուր սերվեր ինքնուրույն ներբեռնեց նոր ժողովը՝ իմանալով, որ դա պետք է աներ՝ հետևելով հյուպատոսի բանալին փոփոխությանը: Սերվերները զուգահեռաբար բեռնել են կոդը: Սա մեզ թույլ տվեց պահպանել տեղակայման բարձր արագություն նույնիսկ համակարգի մշտական ​​աճի միջավայրում:

1. Արտադրության սերվերները վերահսկում են Consul բանալին: 2. Բանալին փոխվում է, սա սերվերներին ասում է, որ նրանք պետք է սկսեն ներբեռնել նոր կոդ: 3. Սերվերները ներբեռնում են tarball ֆայլեր հավելվածի կոդով

▍Ատոմային տեղակայումներ

Մեկ այլ լուծում, որն օգնեց մեզ հասնել բազմաշերտ տեղակայման համակարգին, ատոմային տեղակայումն էր:

Նախքան ատոմային տեղակայումները օգտագործելը, յուրաքանչյուր տեղակայումը կարող է հանգեցնել մեծ թվով սխալի հաղորդագրությունների: Փաստն այն է, որ նոր ֆայլերը արտադրական սերվերներին պատճենելու գործընթացը ատոմային չէր: Սա հանգեցրեց կարճ ժամանակի պատուհանի, որտեղ նոր գործառույթներ կանչող կոդը հասանելի էր նախքան իրենց գործառույթների հասանելիությունը: Երբ նման կոդը կանչվեց, այն հանգեցրեց ներքին սխալների վերադարձմանը: Սա դրսևորվեց ձախողված API հարցումներով և կոտրված վեբ էջերով:

Այս խնդրի վրա աշխատող թիմը լուծեց այն՝ ներմուծելով «տաք» և «սառը» դիրեկտորիաների հայեցակարգը: Թեժ գրացուցակի կոդը պատասխանատու է արտադրական տրաֆիկի մշակման համար: Իսկ «սառը» գրացուցակներում կոդը, քանի դեռ համակարգը աշխատում է, միայն պատրաստվում է օգտագործման համար: Տեղադրման ընթացքում նոր կոդը պատճենվում է չօգտագործված սառը գրացուցակում: Այնուհետև, երբ սերվերի վրա ակտիվ գործընթացներ չկան, կատարվում է ակնթարթային գրացուցակի անջատում:

1. Հավելվածի կոդը հանելը «սառը» գրացուցակի մեջ: 2. Համակարգի անցում «սառը» գրացուցակի, որը դառնում է «տաք» (ատոմային աշխատանք)

Արդյունքները. շեշտադրումը դեպի հուսալիություն

2018 թվականին նախագիծն այնպիսի մասշտաբի հասավ, որ շատ արագ տեղակայումը սկսեց վնասել արտադրանքի կայունությանը։ Մենք ունեինք շատ առաջադեմ տեղակայման համակարգ, որի մեջ մենք ներդրեցինք շատ ժամանակ և ջանք: Մեզ անհրաժեշտ էր միայն վերակառուցել և բարելավել մեր տեղակայման գործընթացները: Մենք վերածվել ենք բավականին մեծ ընկերության, որի մշակումներն օգտագործվել են ամբողջ աշխարհում՝ անխափան հաղորդակցություններ կազմակերպելու և կարևոր խնդիրներ լուծելու համար։ Ուստի հուսալիությունը դարձավ մեր ուշադրության կենտրոնում:

Մենք պետք է ավելի ապահով դարձնեինք Slack-ի նոր թողարկումների տեղակայման գործընթացը: Այս կարիքը մեզ մղեց բարելավելու մեր տեղակայման համակարգը: Փաստորեն, մենք վերևում քննարկեցինք այս բարելավված համակարգը: Համակարգի խորքերում մենք շարունակում ենք օգտագործել արագ և ատոմային տեղակայման տեխնոլոգիաները։ Փոխվել է տեղակայման եղանակը. Մեր նոր համակարգը նախագծված է աստիճանաբար նոր կոդ տեղակայելու տարբեր մակարդակներում, տարբեր միջավայրերում: Այժմ մենք օգտագործում ենք ավելի առաջադեմ օժանդակ գործիքներ և համակարգի մոնիտորինգի գործիքներ, քան նախկինում: Սա մեզ հնարավորություն է տալիս բռնելու և ուղղելու սխալները շատ ավելի վաղ, քան դրանք վերջնական օգտագործողին հասնելու հնարավորություն կունենան:

Բայց մենք չենք պատրաստվում դրանով կանգ առնել։ Մենք մշտապես կատարելագործում ենք այս համակարգը՝ օգտագործելով ավելի առաջադեմ օժանդակ գործիքներ և աշխատանքի ավտոմատացման գործիքներ։

Հարգելի ընթերցողներ: Ինչպե՞ս է աշխատում նոր նախագծերի թողարկումների տեղակայման գործընթացը, որտեղ դուք աշխատում եք:

Source: www.habr.com