DevOps-ը դարձել է շատ տարածված թեմա վերջին մի քանի տարիների ընթացքում: Շատերը երազում են միանալ դրան, բայց, ինչպես ցույց է տալիս պրակտիկան, հաճախ միայն աշխատավարձի մակարդակի պատճառով։
Որոշ մարդիկ իրենց ռեզյումեում նշում են DevOps-ները, թեև միշտ չէ, որ գիտեն կամ հասկանում են տերմինի էությունը: Ոմանք կարծում են, որ Ansible-ը, GitLab-ը, Jenkins-ը, Terraform-ը և այլն (ցանկը կարելի է շարունակել ըստ ճաշակի) ուսումնասիրելուց հետո դուք անմիջապես կդառնաք «դևոպսիստ»։ Սա, իհարկե, ճիշտ չէ։
Վերջին մի քանի տարիների ընթացքում ես հիմնականում ներգրավված եմ եղել տարբեր ընկերություններում DevOps-ի ներդրմամբ։ Մինչ այդ նա աշխատել է ավելի քան 20 տարի՝ համակարգային ադմինիստրատորից մինչև ՏՏ տնօրեն։ Ներկայումս DevOps-ի առաջատար ինժեներ Playgendary-ում:
Ով է DevOps-ը
Հոդված գրելու գաղափարն առաջացել է մեկ այլ հարցից հետո՝ «ո՞վ է DevOps»-ը։ Դեռևս հաստատված ժամկետ չկա, թե դա ինչ կամ ով է։ Որոշ պատասխաններ արդեն սրա մեջ են . Սկզբում ես դրանից առանձնացնեմ հիմնական կետերը, իսկ հետո կկիսվեմ իմ դիտարկումներով ու մտքերով։
DevOps-ը մասնագետ չէ, որին կարելի է աշխատանքի ընդունել, կոմունալ ծառայությունների մի շարք և ինժեներներով մշակողների բաժին չէ:
DevOps-ը փիլիսոփայություն և մեթոդաբանություն է:
Այլ կերպ ասած, դա պրակտիկաների մի շարք է, որն օգնում է մշակողներին ակտիվորեն համագործակցել համակարգի ադմինիստրատորների հետ: Այսինքն՝ միացնել ու ինտեգրել աշխատանքային գործընթացները միմյանց մեջ։
DevOps-ի գալուստով մասնագետների կառուցվածքն ու դերերը մնացին նույնը (կան մշակողներ, կան ինժեներներ), բայց փոխազդեցության կանոնները փոխվեցին։ Գերատեսչությունների միջև սահմանները լղոզվել են:
DevOps-ի նպատակները կարելի է նկարագրել երեք կետով.
- Ծրագիրը պետք է պարբերաբար թարմացվի:
- Ծրագրային ապահովումը պետք է արագ կատարվի:
- Ծրագիրը պետք է տեղադրվի հարմար և կարճ ժամանակում:
DevOps-ի համար մեկ գործիք չկա: Մի քանի ապրանքների կազմաձևում, առաքում և ուսումնասիրություն չի նշանակում, որ DevOps-ը հայտնվել է ընկերությունում։ Կան բազմաթիվ գործիքներ, և դրանք բոլորն էլ օգտագործվում են տարբեր փուլերում, բայց ծառայում են մեկ ընդհանուր նպատակի:
Եվ սա DevOps գործիքների միայն մի մասն է
Ես արդեն 2 տարուց ավելի է, ինչ հարցազրույցներ եմ վարում DevOps-ի ինժեների պաշտոնի համար, և հասկացա, թե որքան կարևոր է հստակ հասկանալ տերմինի էությունը: Ես կուտակել եմ կոնկրետ փորձառություններ, դիտարկումներ և մտքեր, որոնք ուզում եմ կիսվել։
Հարցազրույցի փորձից ես տեսնում եմ հետևյալ պատկերը. մասնագետները, ովքեր DevOps-ը համարում են աշխատանքի կոչում, սովորաբար թյուրիմացություններ են ունենում գործընկերների հետ.
Մի վառ օրինակ կար. Մի երիտասարդ եկել էր հարցազրույցի իր ռեզյումեում շատ խելացի խոսքերով. Իր վերջին երեք աշխատատեղերում նա ուներ 5-6 ամսվա փորձ։ Ես լքեցի երկու ստարտափ, քանի որ նրանք «չգնացին»: Բայց երրորդ ընկերության մասին նա ասաց, որ այնտեղ իրեն ոչ ոք չի հասկանում. մշակողները Windows-ում կոդ են գրում, և տնօրենը ստիպում է այս կոդը «փաթաթել» սովորական Docker-ով և ներկառուցել CI/CD խողովակաշարի մեջ։ Տղան շատ բացասական բաներ ասաց իր ներկայիս աշխատանքի վայրի և իր գործընկերների մասին, ես պարզապես ուզում էի պատասխանել. «Ուրեմն փիղ չես վաճառի»:
Հետո ես նրան հարցրեցի, որը յուրաքանչյուր թեկնածուի համար իմ ցուցակում բարձր է:
— Ի՞նչ է նշանակում DevOps-ն անձամբ ձեզ համար:
- Ընդհանրապես, թե ինչպե՞ս եմ դա ընկալում։
Ինձ հետաքրքրեց նրա անձնական կարծիքը։ Նա գիտեր տերմինի տեսությունն ու ծագումը, բայց կտրականապես համաձայն չէր դրանց հետ։ Նա կարծում էր, որ DevOps-ը աշխատանքի կոչում է: Հենց այստեղ է նրա խնդիրների արմատը։ Ինչպես նաեւ նույն կարծիքի այլ մասնագետներ։
Գործատուները, շատ լսելով «DevOps-ի մոգության» մասին, ցանկանում են գտնել մի մարդու, ով կգա և կստեղծի այս «կախարդանքը»: Իսկ «DevOps-ը աշխատանք է» կատեգորիայի դիմորդները չեն հասկանում, որ այս մոտեցմամբ նրանք չեն կարողանա արդարացնել սպասելիքները։ Իսկ ընդհանրապես, ռեզյումեում գրել են DevOps, քանի որ դա թրենդ է, ու դրա համար շատ են վճարում։
DevOps մեթոդաբանություն և փիլիսոփայություն
Մեթոդաբանությունը կարող է լինել տեսական և գործնական: Մեր դեպքում դա երկրորդն է։ Ինչպես նշեցի վերևում, DevOps-ը պրակտիկաների և ռազմավարությունների մի շարք է, որն օգտագործվում է նշված նպատակներին հասնելու համար: Եվ յուրաքանչյուր դեպքում, կախված ընկերության բիզնես գործընթացներից, այն կարող է զգալիորեն տարբերվել: Ինչը չի դարձնում այն ավելի լավ կամ վատ:
DevOps մեթոդաբանությունը միայն նպատակներին հասնելու միջոց է:
Այժմ այն մասին, թե որն է DevOps-ի փիլիսոփայությունը: Եվ սա թերեւս ամենադժվար հարցն է։
Կարճ ու լակոնիկ պատասխանը բավականին դժվար է ձեւակերպել, քանի որ այն դեռ չի ձեւակերպվել։ Եվ քանի որ DevOps-ի փիլիսոփայության կողմնակիցներն ավելի շատ են զբաղվում գործնականում, պարզապես փիլիսոփայելու ժամանակ չկա: Այնուամենայնիվ, սա շատ կարևոր գործընթաց է։ Ավելին, դա ուղղակիորեն կապված է ինժեներական գործունեության հետ։ Կա նույնիսկ գիտելիքի մասնագիտացված տարածք. .
Իմ համալսարանում նման առարկա չկար, ես ստիպված էի ամեն ինչ ինքնուրույն ուսումնասիրել՝ օգտագործելով այն նյութերը, որոնք կարող էի գտնել 90-ականներին։ Թեման ընտրովի է ճարտարագիտական կրթության համար, հետևաբար՝ պատասխանի պաշտոնականացման բացակայությունը։ Բայց այն մարդիկ, ովքեր լրջորեն ընկղմված են DevOps-ի մեջ, սկսում են զգալ ընկերության բոլոր գործընթացների որոշակի «ոգի» կամ «անգիտակցական համապարփակություն»:
Օգտվելով իմ սեփական փորձից՝ ես փորձեցի պաշտոնականացնել այս փիլիսոփայության որոշ «պոստուլատներ»: Արդյունքը հետևյալն է.
- DevOps-ը անկախ բան չէ, որը կարելի է բաժանել գիտելիքի կամ գործունեության առանձին տարածքի:
- Ընկերության բոլոր աշխատակիցներն իրենց գործունեությունը պլանավորելիս պետք է առաջնորդվեն DevOps մեթոդաբանությամբ:
- DevOps-ն ազդում է ընկերության բոլոր գործընթացների վրա:
- DevOps-ը գոյություն ունի ընկերության ներսում ցանկացած գործընթացի ժամանակի ծախսերը նվազեցնելու համար՝ ապահովելու իր ծառայությունների զարգացումը և հաճախորդների առավելագույն հարմարավետությունը:
- DevOps-ը, ժամանակակից լեզվով ասած, ընկերության յուրաքանչյուր աշխատակցի ակտիվ դիրքորոշումն է, որն ուղղված է ժամանակի ծախսերի կրճատմանը և մեզ շրջապատող ՏՏ արտադրանքի որակի բարելավմանը:
Կարծում եմ, որ իմ «պոստուլատները» առանձին քննարկման թեմա են։ Բայց հիմա ինչ-որ բան կա կառուցելու:
Ինչ է անում DevOps-ը
Այստեղ հիմնական բառը հաղորդակցությունն է: Շատ հաղորդակցություններ կան, որոնց նախաձեռնողը պետք է լինի հենց նույն DevOps-ի ինժեները։ Ինչո՞ւ է այդպես։ Որովհետև սա փիլիսոփայություն և մեթոդիկա է, և միայն դրանից հետո ինժեներական գիտելիքներ:
Ես չեմ կարող 100% վստահությամբ խոսել արևմտյան աշխատաշուկայի մասին. Բայց ես բավականին շատ բան գիտեմ Ռուսաստանում DevOps շուկայի մասին: Բացի հարյուրավոր հարցազրույցներից, վերջին մեկուկես տարվա ընթացքում ես մասնակցել եմ ռուսական խոշոր ընկերությունների և բանկերի «DevOps» ծառայության իրականացման հարյուրավոր տեխնիկական նախավաճառքի:
Ռուսաստանում DevOps-ը դեռ շատ երիտասարդ, բայց արդեն թրենդային թեմա է: Որքան գիտեմ, միայն Մոսկվայում նման մասնագետների պակասը 2019 թվականին կազմել է ավելի քան 1000 մարդ։ Իսկ «Կուբերնետես» բառը գործատուների համար գրեթե նման է ցլի կարմիր լաթին: Այս գործիքի հետևորդները պատրաստ են օգտագործել այն նույնիսկ այնտեղ, որտեղ դա անհրաժեշտ չէ և տնտեսապես շահավետ: Գործատուն միշտ չէ, որ հասկանում է, թե ինչ դեպքերում է ավելի նպատակահարմար օգտագործել, և պատշաճ տեղակայման դեպքում Kubernetes կլաստերի պահպանումն արժե 2-3 անգամ ավելի, քան սովորական կլաստերի սխեմայի օգտագործմամբ հավելվածի տեղակայումը: Օգտագործեք այն այնտեղ, որտեղ դուք իսկապես դրա կարիքն ունեք:
DevOps-ի ներդրումը փողի առումով թանկ է: Եվ դա արդարացված է միայն այնտեղ, որտեղ տնտեսական օգուտ է բերում այլ ոլորտներում, այլ ոչ թե ինքնուրույն։
DevOps-ի ինժեներները, ըստ էության, ռահվիրաներ են. նրանք են, ովքեր առաջինը պետք է կիրառեն այս մեթոդաբանությունը ընկերությունում և կառուցեն գործընթացներ: Որպեսզի դա հաջող լինի, մասնագետը պետք է մշտապես շփվի բոլոր մակարդակների աշխատակիցների և գործընկերների հետ: Ինչպես սովորաբար ասում եմ, ընկերության բոլոր աշխատակիցները պետք է ներգրավված լինեն DevOps-ի իրականացման գործընթացում՝ հավաքարարից մինչև գործադիր տնօրեն: Եվ սա նախապայման է։ Եթե թիմի ամենակրտսեր անդամը չգիտի և չի հասկանում, թե ինչ է DevOps-ը և ինչու են իրականացվում որոշակի կազմակերպչական գործողություններ, ապա հաջող իրականացումը չի աշխատի:
Բացի այդ, DevOps-ի ինժեներին ժամանակ առ ժամանակ անհրաժեշտ է վարչական ռեսուրս օգտագործել: Օրինակ՝ հաղթահարել «բնապահպանական դիմադրությունը», երբ թիմը պատրաստ չէ ընդունել DevOps գործիքներն ու մեթոդաբանությունը:
Մշակողը պետք է գրի միայն կոդ և թեստեր: Դա անելու համար նրան պետք չէ գերհզոր նոութբուք, որի վրա նա կտեղակայի և տեղայնորեն կաջակցի նախագծի ողջ ենթակառուցվածքին: Օրինակ, front-end ծրագրավորողը պահում է հավելվածի բոլոր տարրերը իր նոութբուքում, ներառյալ տվյալների բազան, S3 էմուլյատորը (minio) և այլն: Այսինքն՝ նա շատ ժամանակ է ծախսում տեղական այս ենթակառուցվածքի պահպանման վրա և միայնակ պայքարում է նման լուծման բոլոր խնդիրների դեմ։ Առջևի համար կոդ մշակելու փոխարեն: Նման մարդիկ կարող են շատ դիմադրել ցանկացած փոփոխության։
Բայց կան թիմեր, որոնք, ընդհակառակը, ուրախ են նոր գործիքներ ու մեթոդներ ներմուծել և ակտիվորեն մասնակցել այս գործընթացին։ Չնայած նույնիսկ այս դեպքում DevOps-ի ինժեների և թիմի միջև կապը չեղարկվեց:
Երբ DevOps-ն անհրաժեշտ չէ
Կան իրավիճակներ, երբ DevOps-ն անհրաժեշտ չէ։ Սա փաստ է, այն պետք է հասկանալ և ընդունել:
Սա առաջին հերթին վերաբերում է ցանկացած ընկերության (հատկապես փոքր բիզնեսին), երբ նրանց շահույթը ուղղակիորեն կախված չէ հաճախորդներին տեղեկատվական ծառայություններ մատուցող ՏՏ արտադրանքի առկայությունից կամ բացակայությունից: Եվ այստեղ մենք չենք խոսում ընկերության կայքի մասին, լինի դա ստատիկ «այցեքարտ», թե դինամիկ նորությունների բլոկներով և այլն:
DevOps-ը պահանջվում է, երբ ձեր հաճախորդի գոհունակությունը և կրկին ձեզ մոտ վերադառնալու ցանկությունը կախված են հաճախորդի հետ փոխգործակցության համար այս տեղեկատվական ծառայությունների առկայությունից, դրանց որակից և թիրախավորումից:
Վառ օրինակ է հայտնի բանկերից մեկը։ Ընկերությունը չունի սովորական հաճախորդների գրասենյակներ, փաստաթղթերի հոսքն իրականացվում է փոստի կամ սուրհանդակների միջոցով, և շատ աշխատակիցներ աշխատում են տնից: Ընկերությունը դադարել է պարզապես բանկ լինել և, իմ կարծիքով, վերածվել է զարգացած DevOps տեխնոլոգիաներով ՏՏ ընկերության։
Շատ այլ օրինակներ և դասախոսություններ կարելի է գտնել թեմատիկ հանդիպումների և կոնֆերանսների ձայնագրություններում: Ես անձամբ այցելեցի նրանցից մի քանիսին. սա շատ օգտակար փորձ է նրանց համար, ովքեր ցանկանում են զարգանալ այս ուղղությամբ: Ահա YouTube ալիքների հղումներ՝ լավ դասախոսություններով և DevOps-ի վերաբերյալ նյութերով.
Այժմ նայեք ձեր բիզնեսին և մտածեք այս մասին. որքանո՞վ է ձեր ընկերությունը և նրա շահույթը կախված ՏՏ արտադրանքներից՝ հաճախորդների հետ փոխազդեցություն ապահովելու համար:
Եթե ձեր ընկերությունը ձուկ է վաճառում փոքր խանութում, և միակ ՏՏ արտադրանքը երկու 1C է՝ Enterprise կոնֆիգուրացիաներ (Հաշվապահություն և UNF), ապա դժվար թե իմաստ ունենա խոսել DevOps-ի մասին:
Եթե դուք աշխատում եք խոշոր առևտրային և արտադրական ձեռնարկությունում (օրինակ, որսորդական հրացաններ եք արտադրում), ապա պետք է մտածեք դրա մասին։ Դուք կարող եք նախաձեռնող լինել և ձեր ղեկավարությանը փոխանցել DevOps-ի ներդրման հեռանկարները։ Դե, և միևնույն ժամանակ, ղեկավարեք այս գործընթացը: Նախաձեռնող դիրքորոշումը DevOps-ի փիլիսոփայության կարևոր դրույթներից մեկն է:
Տարեկան ֆինանսական շրջանառության չափն ու ծավալը հիմնական չափանիշը չէ՝ որոշելու, թե արդյոք ձեր ընկերությանն անհրաժեշտ են DevOps:
Պատկերացնենք արդյունաբերական խոշոր ձեռնարկություն, որն անմիջականորեն չի շփվում հաճախորդների հետ։ Օրինակ՝ որոշ ավտոարտադրողներ և ավտոարտադրող ընկերություններ։ Հիմա վստահ չեմ, բայց իմ անցյալի փորձից ելնելով, երկար տարիներ հաճախորդների հետ փոխգործակցությունը կատարվում էր էլեկտրոնային փոստի և հեռախոսի միջոցով:
Նրանց հաճախորդները մեքենաների դիլերների սահմանափակ ցուցակ են: Եվ յուրաքանչյուրին նշանակվում է արտադրողի մասնագետ։ Ամբողջ ներքին փաստաթղթերի հոսքը տեղի է ունենում SAP ERP-ի միջոցով: Ներքին աշխատողները հիմնականում տեղեկատվական համակարգի հաճախորդներ են: Բայց այս IS-ը վերահսկվում է կլաստերային համակարգերի կառավարման դասական միջոցներով: Ինչը բացառում է DevOps պրակտիկաների օգտագործման հնարավորությունը:
Հետևաբար եզրակացությունը. նման ձեռնարկությունների համար DevOps-ի ներդրումը շատ կարևոր բան չէ, եթե հիշենք հոդվածի սկզբից մեթոդաբանության նպատակները: Բայց ես չեմ բացառում, որ նրանք այսօր օգտագործում են որոշ DevOps գործիքներ:
Մյուս կողմից, կան բազմաթիվ փոքր ընկերություններ, որոնք մշակում են ծրագրակազմ՝ օգտագործելով DevOps մեթոդաբանությունը, փիլիսոփայությունը, գործելակերպը և գործիքները: Եվ նրանք կարծում են, որ DevOps-ի ներդրման արժեքը այն արժեքն է, որը թույլ է տալիս արդյունավետ մրցակցել ծրագրային ապահովման շուկայում: Նման ընկերությունների օրինակներ կարելի է տեսնել .
Հիմնական չափանիշը հասկանալու համար, թե արդյոք DevOps-ն անհրաժեշտ է. ինչ արժեք ունեն ձեր ՏՏ արտադրանքները ընկերության և հաճախորդների համար:
Եթե ընկերության հիմնական արտադրանքը, որը շահույթ է առաջացնում, ծրագրաշարն է, ապա ձեզ DevOps-ն է պետք: Եվ դա այնքան էլ կարևոր չէ, եթե դուք իրական գումար եք վաստակում այլ ապրանքներից: Սա ներառում է նաև առցանց խանութներ կամ խաղերով բջջային հավելվածներ:
Ցանկացած խաղ գոյություն ունի ֆինանսավորման շնորհիվ՝ ուղղակի կամ անուղղակի խաղացողների կողմից: Playgendary-ում մենք մշակում ենք անվճար բջջային խաղեր, որոնց ստեղծման մեջ անմիջականորեն ներգրավված է ավելի քան 200 մարդ: Ինչպե՞ս ենք մենք օգտագործում DevOps-ը:
Այո, ճիշտ նույնը, ինչ վերը նկարագրված է: Ես անընդհատ շփվում եմ ծրագրավորողների և փորձարկողների հետ և աշխատակիցների համար ներքին ուսուցում եմ անցկացնում DevOps մեթոդաբանության և գործիքների վերաբերյալ:
Այժմ մենք ակտիվորեն օգտագործում ենք Jenkins-ը որպես CI/CD խողովակաշարերի գործիք՝ Unity-ով բոլոր հավաքման խողովակաշարերը գործարկելու և App Store-ում և Play Market-ում հետագա տեղակայման համար: Ավելին դասական գործիքակազմից.
- Ասանա - ծրագրի կառավարման համար: Ինտեգրումը Jenkins-ի հետ կազմաձևվել է:
- Google Meet - տեսահանդիպումների համար:
- Slack - հաղորդակցությունների և տարբեր ահազանգերի համար, ներառյալ Jenkins-ի ծանուցումները:
- Atlassian Confluence - փաստաթղթերի և խմբային աշխատանքի համար:
Մեր անմիջական ծրագրերը ներառում են SonarQube-ի միջոցով ստատիկ կոդի վերլուծության ներդրում և UI-ի ավտոմատացված թեստավորում՝ օգտագործելով Selenium-ը շարունակական ինտեգրման փուլում:
Փոխարենը մի եզրակացության
Կցանկանայի ավարտել հետևյալ մտքով. DevOps-ի բարձր որակավորում ունեցող ինժեներ դառնալու համար կենսական նշանակություն ունի սովորել, թե ինչպես շփվել մարդկանց հետ ուղիղ եթերում:
DevOps-ի ինժեները թիմային խաղացող է: Եվ ուրիշ ոչինչ։ Գործընկերների հետ շփվելու նախաձեռնությունը պետք է լինի հենց նրանից, այլ ոչ թե ինչ-որ հանգամանքների ազդեցության տակ։ DevOps-ի մասնագետը պետք է տեսնի և առաջարկի թիմի լավագույն լուծումը:
Եվ այո, ցանկացած լուծման իրագործումը կպահանջի մեծ քննարկումներ, իսկ վերջում այն կարող է ընդհանրապես փոխվել։ Ինքնուրույն զարգանալով, առաջարկելով և իրագործելով իր գաղափարները՝ նման մարդն ավելի մեծ արժեք ունի ինչպես թիմի, այնպես էլ գործատուի համար։ Ինչը, ի վերջո, արտացոլվում է նրա ամսական վարձատրության չափի կամ հավելյալ հավելավճարների տեսքով։
Source: www.habr.com