Երբ հավելվածը չի աշխատում, վերջին բանը, որ ցանկանում եք լսել ձեր գործընկերներից, «խնդիրը ձեր կողմից է» արտահայտությունն է։ Արդյունքում, օգտվողները տուժում են, և նրանց չի հետաքրքրում, թե թիմի որ մասն է պատասխանատու խափանման համար: DevOps-ի մշակույթը ի հայտ է եկել հենց այնպես, որպեսզի միավորի զարգացումն ու աջակցությունը վերջնական արտադրանքի համար ընդհանուր պատասխանատվության շուրջ:
Ի՞նչ պրակտիկաներ են ներառված DevOps-ի հայեցակարգում և ինչու են դրանք անհրաժեշտ: Ի՞նչ են անում DevOps-ի ինժեներները և ի՞նչ պետք է նրանք կարողանան անել: Այս և այլ հարցերի պատասխանում են EPAM-ի փորձագետները՝ Կիրիլ Սերգեևը՝ համակարգերի ինժեներ և DevOps ավետարանիչ, և Իգոր Բոյկոն՝ առաջատար համակարգերի ինժեներ և ընկերության DevOps թիմերից մեկի համակարգող:
Ինչու՞ է անհրաժեշտ DevOps-ը:
Նախկինում խոչընդոտ կար ծրագրավորողների և աջակցության միջև (այսպես կոչված, գործառնություններ): Պարադոքսալ է հնչում, բայց նրանք ունեին տարբեր նպատակներ և KPI-ներ, չնայած նրանք նույն բանն էին անում: Մշակման նպատակն էր հնարավորինս արագ իրականացնել բիզնեսի պահանջները և դրանք ավելացնել աշխատանքային արտադրանքին: Աջակցությունը պատասխանատու էր հավելվածի կայուն աշխատանքի ապահովման համար, և ցանկացած փոփոխություն վտանգի տակ է դնում կայունությունը: Շահերի բախում կա. DevOps-ը հայտնվեց լուծելու այն:
Ի՞նչ է DevOps-ը:
Դա լավ հարց է, և վիճահարույց հարց. աշխարհը դեռ վերջնականապես համաձայնության չի եկել այս հարցում: EPAM-ը կարծում է, որ DevOps-ը համատեղում է տեխնոլոգիաները, գործընթացները և թիմի ներսում փոխգործակցության մշակույթը: Այս ասոցիացիան նպատակ ունի շարունակաբար արժեք մատուցել վերջնական օգտագործողներին:
Կիրիլ Սերգեև«Կառուցողները գրում են կոդը, փորձարկողները վերանայում են այն, և ադմինիստրատորները տեղադրում են վերջնական արտադրանքը արտադրության մեջ: Երկար ժամանակ թիմի այս հատվածները որոշակիորեն ցրված էին, իսկ հետո գաղափար առաջացավ դրանք միավորել ընդհանուր գործընթացով։ Ահա թե ինչպես են հայտնվել DevOps-ի պրակտիկաները»։
Եկավ այն օրը, երբ մշակողները և համակարգի ինժեներները սկսեցին հետաքրքրվել միմյանց աշխատանքով: Արտադրության և աջակցության միջև պատնեշը սկսեց վերանալ։ Ահա թե ինչպես է առաջացել DevOps-ը, որը ներառում է պրակտիկա, մշակույթ և թիմային փոխազդեցություն:
Ո՞րն է DevOps մշակույթի էությունը:
Փաստն այն է, որ վերջնական արդյունքի պատասխանատվությունը կրում է թիմի յուրաքանչյուր անդամ: DevOps-ի փիլիսոփայության մեջ ամենահետաքրքիրն ու դժվարը հասկանալն է, որ կոնկրետ անձը պատասխանատու է ոչ միայն իր աշխատանքի փուլի համար, այլ պատասխանատու է ամբողջ արտադրանքի աշխատանքի համար: Խնդիրը ոչ մեկի կողմից չէ, այն կիսվում է, և թիմի յուրաքանչյուր անդամ օգնում է լուծել այն:
DevOps մշակույթում ամենակարևորը խնդիրը լուծելն է, այլ ոչ թե պարզապես կիրառել DevOps պրակտիկա: Ավելին, այս պրակտիկան իրականացվում է ոչ թե «ինչ-որ մեկի կողմից», այլ ամբողջ արտադրանքի ընթացքում: Նախագիծն ինքնին DevOps-ի ինժեների կարիք չունի, այն խնդրի լուծման կարիք ունի, և DevOps-ի ինժեների դերը կարող է բաշխվել տարբեր մասնագիտություններ ունեցող թիմի մի քանի անդամների միջև:
Որո՞նք են DevOps պրակտիկայի տեսակները:
DevOps-ի պրակտիկան ներառում է ծրագրաշարի կյանքի ցիկլի բոլոր փուլերը:
Իգոր Բոյկո«Իդեալական դեպքն այն է, երբ մենք սկսում ենք օգտագործել DevOps պրակտիկաները հենց նախագծի մեկնարկից: Ճարտարապետների հետ միասին պլանավորում ենք, թե ինչպիսի ճարտարապետական լանդշաֆտ կունենա հավելվածը, որտեղ այն կտեղակայվի և ինչպես մասշտաբավորվի, և ընտրում ենք հարթակ։ Մեր օրերում նորաձև է միկրոսերվիսային ճարտարապետությունը. դրա համար մենք ընտրում ենք նվագախմբային համակարգ. դուք պետք է կարողանաք կառավարել հավելվածի յուրաքանչյուր տարր առանձին և թարմացնել այն մյուսներից անկախ: Մեկ այլ պրակտիկա է «ենթակառուցվածքը որպես ծածկագիր»: Սա այն մոտեցման անունն է, որի դեպքում ծրագրի ենթակառուցվածքը ստեղծվում և կառավարվում է ծածկագրի միջոցով, այլ ոչ թե սերվերների հետ անմիջական փոխգործակցության միջոցով:
Հաջորդիվ անցնում ենք զարգացման փուլին։ Այստեղ ամենամեծ պրակտիկաներից մեկը CI/CD-ի ստեղծումն է. դուք պետք է օգնեք մշակողներին ինտեգրել փոփոխությունները արտադրանքի մեջ արագ, փոքր մասերում, ավելի հաճախ և առանց ցավի: CI/CD-ն ներառում է կոդի վերանայումը, հիմնականի վերբեռնումը կոդի բազա և հավելվածի տեղակայումը փորձարկման և արտադրական միջավայրերում:
CI/CD փուլերում կոդը անցնում է որակյալ դարպասներով: Նրանց օգնությամբ նրանք ստուգում են, որ կոդը, որը դուրս է գալիս մշակողի աշխատակայանից, համապատասխանում է նշված որակի չափանիշներին: Այստեղ ավելացված է միավորի և միջերեսի փորձարկումը: Արտադրանքի արագ, ցավազուրկ և կենտրոնացված տեղակայման համար կարող եք ընտրել համապատասխան տեղակայման տեսակը:
DevOps-ի պրակտիկանտները նույնպես տեղ ունեն պատրաստի արտադրանքի աջակցության փուլում։ Դրանք օգտագործվում են մոնիտորինգի, հետադարձ կապի, անվտանգության և փոփոխություններ մտցնելու համար: DevOps-ը դիտարկում է այս բոլոր առաջադրանքները շարունակական բարելավման տեսանկյունից: Մենք նվազագույնի ենք հասցնում կրկնվող գործողությունները և ավտոմատացնում դրանք: Սա ներառում է նաև միգրացիաներ, հավելվածների ընդլայնում և կատարողականի աջակցություն»:
Որո՞նք են DevOps-ի պրակտիկայի առավելությունները:
Եթե մենք գրեինք դասագիրք ժամանակակից DevOps պրակտիկայի վերաբերյալ, ապա առաջին էջում երեք կետ կլիներ՝ ավտոմատացում, թողարկումների արագացում և օգտատերերի արագ արձագանք:
Կիրիլ Սերգեև«Առաջին բանը ավտոմատացումն է։ Մենք կարող ենք ավտոմատացնել բոլոր փոխազդեցությունները թիմում. գրել է կոդը - տարածել այն - ստուգել այն - տեղադրել այն - հավաքել արձագանքներ - վերադարձել է սկզբին: Այս ամենը ավտոմատ է:
Երկրորդը թողարկման արագացումն է և նույնիսկ զարգացումը պարզեցնելը: Հաճախորդի համար միշտ կարևոր է, որ ապրանքը հնարավորինս շուտ մտնի շուկա և սկսի օգուտներ տալ ավելի շուտ, քան մրցակիցների անալոգները: Արտադրանքի առաքման գործընթացը կարող է անվերջ բարելավվել՝ կրճատելով ժամանակը, ավելացնելով լրացուցիչ հսկիչ նշաններ, բարելավել մոնիտորինգը:
Երրորդը օգտվողների հետադարձ կապի արագացումն է: Եթե նա մեկնաբանություններ ունի, մենք կարող ենք անմիջապես ճշգրտումներ կատարել և անմիջապես թարմացնել հավելվածը»։
Ինչպե՞ս են կապված «համակարգերի ինժեներ», «շինարարական ինժեներ» և «DevOps ինժեներ» հասկացությունները:
Նրանք համընկնում են, բայց պատկանում են մի փոքր տարբեր ոլորտների:
Համակարգերի ինժեներ EPAM-ում պաշտոն է: Դրանք տարբեր մակարդակներով են՝ կրտսերից մինչև գլխավոր մասնագետ:
Շինարարական ինժեներն ավելի շատ դեր է, որը կարող է իրականացվել նախագծի վրա: Այժմ այսպես են կոչվում CI/CD-ի համար պատասխանատու մարդիկ:
DevOps-ի ինժեները մասնագետ է, ով իրականացնում է DevOps-ի պրակտիկա նախագծի վրա:
Եթե այս ամենը ամփոփենք, ապա կստանանք այսպիսի բան. համակարգային ինժեների պաշտոնում գտնվող անձը խաղում է նախագծի շինարարության ինժեների դերը և ներգրավված է այնտեղ DevOps պրակտիկաների իրականացման մեջ:
Կոնկրետ ի՞նչ է անում DevOps-ի ինժեները:
DevOps-ի ինժեներները միավորում են բոլոր այն մասերը, որոնք կազմում են նախագիծը: Նրանք գիտեն ծրագրավորողների, փորձարկողների, համակարգի ադմինիստրատորների աշխատանքի առանձնահատկությունները և օգնում են պարզեցնել նրանց աշխատանքը։ Նրանք հասկանում են բիզնեսի կարիքներն ու պահանջները, նրա դերը զարգացման գործընթացում և կառուցում են գործընթացը՝ հաշվի առնելով հաճախորդի շահերը:
Մենք շատ ենք խոսել ավտոմատացման մասին. սա այն է, ինչով առաջին հերթին զբաղվում են DevOps-ի ինժեներները: Սա շատ մեծ կետ է, որը, ի թիվս այլ բաների, ներառում է միջավայրի նախապատրաստումը։
Կիրիլ Սերգեև«Նախքան արտադրանքի թարմացումները կիրառելը, դրանք պետք է փորձարկվեն երրորդ կողմի միջավայրում: Այն պատրաստվել է DevOps-ի ինժեներների կողմից։ Նրանք ներդնում են DevOps մշակույթ նախագծի վրա որպես ամբողջություն. նրանք ներկայացնում են DevOps պրակտիկա իրենց նախագծերի բոլոր շերտերում: Այս երեք սկզբունքները՝ ավտոմատացում, պարզեցում, արագացում, բերում են ուր հասնեն»։
Ի՞նչ պետք է իմանա DevOps-ի ինժեները:
Մեծ հաշվով նա պետք է գիտելիքներ ունենա տարբեր ոլորտներից՝ ծրագրավորում, օպերացիոն համակարգերի հետ աշխատանք, տվյալների բազաներ, հավաքում և կոնֆիգուրացիա համակարգեր։ Դրանք լրացվում են ամպային ենթակառուցվածքի, նվագախմբի և մոնիտորինգի համակարգերի հետ աշխատելու ունակությամբ:
1. Ծրագրավորման լեզուներ
DevOps-ի ինժեներները գիտեն ավտոմատացման մի քանի հիմնական լեզուներ և կարող են, օրինակ, ծրագրավորողին ասել. Մենք դրա համար կպատրաստենք կոնֆիգուրացիայի ֆայլ, այն հարմար կլինի և՛ ձեզ, և՛ մեզ կարդալու, և մենք ցանկացած պահի կկարողանանք փոխել այն։ Կտեսնենք նաև, թե ով, երբ և ինչու է դրանում փոփոխություններ անում»։
DevOps-ի ինժեները կարող է սովորել այս լեզուներից մեկը կամ մի քանիսը` Python, Groovy, Bash, Powershell, Ruby, Go: Անհրաժեշտ չէ դրանք խորը մակարդակով իմանալ՝ շարահյուսության հիմունքները, OOP սկզբունքները և ավտոմատացման համար պարզ սցենարներ գրելու ունակությունը բավական են։
2. Օպերացիոն համակարգեր
DevOps-ի ինժեները պետք է հասկանա, թե որ սերվերի վրա է տեղադրվելու արտադրանքը, ինչ միջավայրում է այն աշխատելու և ինչ ծառայությունների հետ է փոխազդելու: Դուք կարող եք ընտրել մասնագիտանալ Windows-ի կամ Linux-ի ընտանիքում:
3. Տարբերակների կառավարման համակարգեր
Առանց տարբերակի կառավարման համակարգի իմացության, DevOps-ի ինժեները ոչ մի տեղ չէ: Git-ն այս պահին ամենահայտնի համակարգերից մեկն է։
4. Ամպային մատակարարներ
AWS, Google, Azure - հատկապես, եթե մենք խոսում ենք Windows-ի ուղղության մասին:
Կիրիլ Սերգեև«Cloud մատակարարները մեզ տրամադրում են վիրտուալ սերվերներ, որոնք հիանալի տեղավորվում են CI/CD-ի մեջ:
Տասը ֆիզիկական սերվերների տեղադրումը պահանջում է մոտ հարյուր ձեռքով գործողություններ: Յուրաքանչյուր սերվեր պետք է ձեռքով գործարկվի, տեղադրվի և կազմաձևվի պահանջվող օպերացիոն համակարգը, տեղադրի մեր հավելվածը այս տասը սերվերների վրա, այնուհետև տասը անգամ կրկնակի ստուգի ամեն ինչ: Ամպային ծառայությունները փոխարինում են այս ընթացակարգը տասը տող կոդով, և լավ DevOps ինժեները պետք է կարողանա աշխատել դրանցով: Սա խնայում է ժամանակ, ջանք և գումար՝ և՛ հաճախորդի, և՛ ընկերության համար»:
5. Նվագախմբի համակարգեր՝ Docker և Kubernetes
Կիրիլ Սերգեև«Վիրտուալ սերվերները բաժանված են կոնտեյներների, որոնցից յուրաքանչյուրում մենք կարող ենք տեղադրել մեր հավելվածը։ Երբ շատ կոնտեյներներ կան, պետք է դրանք կառավարել՝ մեկը միացնել, մյուսն անջատել, ինչ-որ տեղ կրկնօրինակումներ անել: Սա բավականին բարդ է դառնում և պահանջում է նվագախմբային համակարգ:
Նախկինում յուրաքանչյուր հավելված մշակվում էր առանձին սերվերի կողմից. դրա աշխատանքի ցանկացած փոփոխություն կարող է ազդել հավելվածի սպասարկման վրա: Կոնտեյներների շնորհիվ հավելվածները դառնում են մեկուսացված և աշխատում են առանձին՝ յուրաքանչյուրն իր վիրտուալ մեքենայի վրա: Եթե ձախողում է տեղի ունենում, կարիք չկա ժամանակ վատնել՝ պատճառը փնտրելու համար: Ավելի հեշտ է քանդել հին տարան և ավելացնել նորը»։
6. Կազմաձեւման համակարգեր՝ Chef, Ansible, Puppet
Երբ դուք պետք է պահպանեք սերվերների մի ամբողջ նավատորմ, դուք պետք է կատարեք նույն տեսակի բազմաթիվ գործողություններ: Դա երկար ու դժվար է, իսկ ձեռքով աշխատանքը նույնպես մեծացնում է սխալվելու հավանականությունը։ Այստեղ օգնության են հասնում կոնֆիգուրացիայի համակարգերը: Նրանց օգնությամբ նրանք ստեղծում են մի սցենար, որը հեշտ է կարդալ ծրագրավորողների, DevOps-ի ինժեներների և համակարգի ադմինիստրատորների համար: Այս սցենարն օգնում է ավտոմատ կերպով կատարել նույն գործողությունները սերվերների վրա: Սա նվազեցնում է ձեռքով գործառնությունները (և հետևաբար՝ սխալները):
Ինչպիսի՞ կարիերա կարող է կառուցել DevOps-ի ինժեները:
Դուք կարող եք զարգանալ ինչպես հորիզոնական, այնպես էլ ուղղահայաց:
Իգոր Բոյկո«Հորիզոնական զարգացման տեսանկյունից DevOps-ի ինժեներներն այժմ ունեն ամենալայն հեռանկարները: Ամեն ինչ անընդհատ փոխվում է, և դուք կարող եք հմտություններ ձեռք բերել տարբեր ոլորտներում՝ տարբերակների կառավարման համակարգերից մինչև մոնիտորինգ, կոնֆիգուրացիայի կառավարումից մինչև տվյալների բազաներ:
Դուք կարող եք դառնալ համակարգի ճարտարապետ, եթե աշխատողը շահագրգռված է հասկանալ, թե ինչպես է հավելվածն աշխատում իր կյանքի ցիկլի բոլոր փուլերում՝ մշակումից մինչև աջակցություն»:
Ինչպե՞ս դառնալ DevOps-ի ինժեներ:
- Կարդացեք Phoenix Project և DevOps ձեռնարկը: Սրանք DevOps-ի փիլիսոփայության իրական հիմնասյուներն են, որոնցից առաջինը գեղարվեստական ստեղծագործություն է:
- Իմացեք տեխնոլոգիաները վերը նշված ցանկից՝ ինքնուրույն կամ առցանց դասընթացների միջոցով:
- Միացեք որպես DevOps-ի ինժեներ բաց կոդով նախագծի համար:
- Զբաղվեք և առաջարկեք DevOps-ի պրակտիկա ձեր անձնական և աշխատանքային նախագծերում:
Source: www.habr.com