Որտեղ գնալ այս գիտելիքներով, ինչ անել նախագծում և որքան վաստակել, ինչ ասել և հարցնել հարցազրույցի ժամանակ, - ասում է Ալեքսանդր Տիտովը, Express 42-ի կառավարիչ գործընկեր և հեղինակ: .
Բարեւ Ձեզ! Չնայած DevOps տերմինը գոյություն ունի 2009 թվականից, ռուսական համայնքում դեռևս չկա կոնսենսուս: Դուք հավանաբար նկատել եք, որ ոմանք DevOps-ը համարում են մասնագիտություն, մյուսները՝ փիլիսոփայություն, իսկ մյուսները՝ տերմինը համարում են տեխնոլոգիաների մի շարք: Ես արդեն բազմիցս ելույթ եմ ունեցել նրա հետ այս ուղղության զարգացման մասին, ուստի ես չեմ մանրամասնի այս հոդվածում: Միայն ասեմ, որ Էքսպրես 42-ում մենք ներառում ենք հետևյալը.
DevOps-ը կոնկրետ մեթոդաբանություն է, թվային արտադրանք ստեղծելու մշակույթ, երբ արտադրությանը մասնակցում են թիմի բոլոր մասնագետները։
Դասական կորպորատիվ զարգացման մեջ ամեն ինչ հաջորդաբար է ընթանում՝ ծրագրավորում, թեստավորում և հետո միայն շահագործում, իսկ գաղափարից մինչև արտադրություն այս գործընթացի արագությունը 3 ամիս է։ Սա գլոբալ խնդիր է թվային արտադրանքի համար, քանի որ անհնար է արագ արձագանք ստանալ հաճախորդներից։
DevOps-ում գործիքներն ու մոտեցումները նախագծված են՝ ապահովելու, որ մշակման, փորձարկման և գործառնությունների գործընթացները միաժամանակ գործարկվեն:
Ի՞նչ է հետևում այս մոտեցումից:
- Չես կարող վարձել ինչ-որ «ինժեների», որը կգա և կլուծի արտադրության հետ կապված բոլոր խնդիրները։ Ամբողջ թիմը պետք է կիրառի տեխնիկան։
- DevOps-ը Sysadmin-ի հաջորդ ձևը ՉԷ, որին պետք է թարմացնեք: «DevOps engineer»-ը մոտավորապես նույնն է, ինչ «Agile developer»-ը:
- Եթե թիմն օգտագործում է Kubernetes, Ansible, Prometheus, Mesosphere և Docker, դա չի նշանակում, որ այնտեղ ներդրվել են DevOps-ի պրակտիկա։
DevOps-ից հետո կյանքը երբեք նույնը չի լինի
DevOps-ի մոտեցումը, առաջին հերթին, այլ մտածելակերպ է, զարգացման ընկալում որպես ամբողջություն և իր տեղը գործընթացում: Մենք մեր առցանց դասընթացը բաժանեցինք 2 բլոկի.
1. Ինքնորոշում
Նախ, մենք մանրամասնորեն ուսումնասիրում ենք DevOps մոտեցման էությունը, և ուսանողները հայտնաբերում են նոր դերեր թիմում, տեսնում են, թե որն է ավելի շատ արձագանքում և իրենք են որոշում, թե որ ուղղությունը զարգացնել:
2. Գործիքներ և պրակտիկա
Ուսանողները տիրապետում են կոնկրետ տեխնոլոգիաների՝ DevOps մեթոդի տեսանկյունից։
DevOps գործիքները կարող են օգտագործվել ինչպես DevOps-ի մոտեցման, այնպես էլ դասական զարգացման մեջ: Ամենաակնառու օրինակը կլինի Ansible կոնֆիգուրացիայի կառավարման գործիքի օգտագործումը: Այն ստեղծվել և ստեղծվել է DevOps-ի «Ենթակառուցվածքը որպես կոդ» պրակտիկայի իրականացման համար, ինչը նշանակում է, որ նկարագրված են համակարգի տարբեր վիճակներ՝ օպերացիոն համակարգի կարգավորումներից մինչև կիրառական ծրագրեր: Նկարագրությունը բաժանված է շերտերի և թույլ է տալիս կառավարել բարդ, անընդհատ փոփոխվող կոնֆիգուրացիան: Սակայն ինժեներները հաճախ օգտագործում են Ansible-ը որպես մի քանի մեքենաների վրա bash սկրիպտներ գործարկելու միջոց: Սա ոչ վատ է, ոչ լավ, բայց դուք պետք է հասկանաք, որ Ansible-ի առկայությունը չի երաշխավորում DevOps-ի առկայությունը ընկերությունում:
Մենք ընթացքի մեջ ենք Դուք կներգրավվեք հանրահայտ Reddit-ի նման հավելվածի մշակման գործընթացում՝ սկսած նրա մոնոլիտ տարբերակից՝ քայլ առ քայլ անցնելով դեպի միկրոսերվիսներ։ Քայլ առ քայլ մենք կյուրացնենք նոր գործիքներ՝ Git, Ansible, Gitlab և կավարտենք Kubernetes-ով և Prometheus-ով:
Պրակտիկայի առումով, մենք կհետևենք DevOps ձեռնարկում նկարագրված երեք ուղիների մարտավարությանը.
Ի՞նչ է տալիս այս գիտելիքը մասնագետներից յուրաքանչյուրին։
Համակարգի ադմինիստրատորների համար
Պրակտիկան թույլ կտա ձեզ հեռանալ վարչարարությունից՝ ստեղծելով շարունակական առաքման խողովակաշար և ծրագրային ապահովման մատակարարման ենթակառուցվածքային հարթակ: Բանն այն է, որ նա ստեղծում է ապրանք՝ ենթակառուցվածքային հարթակ ծրագրավորողների համար, որն օգնում է նրանց արագորեն առաջ մղել իրենց փոփոխությունները դեպի արտադրություն:
Նախկինում համակարգի ադմինիստրատորները վերջին բաստիոնն էին, որից հետո ամեն ինչ գնում է արտադրության: Եվ հիմնականում նրանք զբաղվում էին շարունակական հրդեհաշիջմամբ, որի լույսի ներքո բավականին դժվար է խորանալ բիզնեսի կարիքների մեջ, մտածել ապրանքի և օգտագործողի համար օգուտների մասին:
DevOps մեթոդի շնորհիվ մտածողությունը փոխվում է։ Համակարգի ադմինիստրատորը հասկանում է, թե ինչպես թարգմանել կոնֆիգուրացիան կոդի, ինչ պրակտիկա կա դրա համար:
Սա կարևոր է, քանի որ ընկերություններն ավելի ու ավելի են գիտակցում, որ իրենց պարզապես պետք չէ ամեն ինչ ավտոմատացնել, այսինքն. ինչով, ըստ էության, սովոր էին անել հին դպրոցի համակարգի ադմինիստրատորները, որոնք գումարած դրան քիչ էին շփվում և թիմին չէին տեղեկացնում կատարված բոլոր փոփոխությունների մասին: Այժմ թիմերը փնտրում են նրանց, ովքեր կդառնան ներքին ենթակառուցվածքի արտադրանքի արտադրողը և կօգնեն համատեղել տարանջատված գործընթացները մեկում։
Կառուցապատողներ
Մշակողը դադարում է մտածել միայն ալգորիթմներով։ Նա ձեռք է բերում ենթակառուցվածքների հետ աշխատելու հմտություն, լանդշաֆտի ճարտարապետական իրազեկման հմտություն։ Նման մշակողը հասկանում է, թե ինչպես է աշխատում հավելվածը, ինչպես է այն անցնում շարունակական առաքման խողովակաշարով, ինչպես վերահսկել այն, ինչպես գրանցել այն, որպեսզի այն շահի հաճախորդին: Արդյունքում այս ամբողջ գիտելիքները թույլ են տալիս գրել համապատասխան կոդ։
Փորձարկողների համար
Թեստավորումը վաղուց անցել է ավտոմատ ռեժիմի, մենք բոլորս ասում ենք, որ շատ թեստեր պետք չէ անել, այլ գրել :) Թեստավորումը դառնում է ձեր արտադրանքի առաքման ողջ խողովակաշարի մի մասը: Փորձարկողին պետք է ոչ միայն սովորել, թե ինչպես գրել կոդը, այլև հասկանալ, թե ինչպես այն ինտեգրել շարունակական առաքման համակարգերին, ինչպես ստանալ արձագանք կոդից առաքման բոլոր փուլերում և ինչպես անընդհատ կատարելագործել թեստավորումը՝ սխալները հայտնաբերելու համար: որքան հնարավոր է շուտ:
Այսպիսով, ստացվում է, որ բոլոր երեք փուլերը տեղի են ունենում միաժամանակ. Օրինակ, այն կարող է այսպիսի տեսք ունենալ.
Մշակողը գրում է կոդը, անմիջապես գրում է դրա համար թեստեր և նկարագրում է կոդերի կոնտեյներ այն կոդի համար, որը պետք է գործարկվի: Այն նաև անմիջապես նկարագրում է մոնիտորինգը, որը վերահսկելու է այս ծառայության աշխատանքը արտադրության մեջ, և պարտավորվում է այս ամենը։
Երբ շարունակական ինտեգրումը սկսվում է, գործընթացները միաժամանակ են ընթանում: Ծառայությունը սկսվում և կազմաձևվում է: Միևնույն ժամանակ գործարկվում է դոկերի կոնտեյները և ստուգվում է, որ այն աշխատում է: Միևնույն ժամանակ, ամբողջ տեղեկատվությունը գնում է անտառահատումների համակարգ: Եվ այսպես շարունակ զարգացման յուրաքանչյուր փուլում. պարզվում է, որ դա համակարգային ադմինիստրատորների, մշակողների և փորձարկողների իրական թիմային աշխատանք է:
Ես ուսումնասիրեցի DevOps-ը, ի՞նչ հետո:
Ինչպես գիտեք, դաշտում գտնվողը ռազմիկ չէ: Եթե ձեր ընկերությունը չօգտագործի այս մեթոդը, ձեռք բերված հմտությունները պարապ կմնան: Եվ DevOps-ի մոտեցումներին ծանոթանալուց հետո, ամենայն հավանականությամբ, չեք ցանկանա լինել կորպորատիվ զարգացման մեջ: Կարող է լինել մեկ բացառություն՝ դուք թիմում համակարգի ադմինիստրատոր եք և կարող եք բոլոր գործընթացները նորովի կառուցել: Այստեղ արժե ավելացնել, որ կան բազմաթիվ ընկերություններ, որոնք օգտագործում են այս մոտեցումը, և նրանց վրա չի ազդում արգելափակումը և փնտրում են մասնագետներ։ Քանի որ DevOps-ը առցանց արտադրանք ստեղծելու մասին է:
Եվ հիմա լավ բաների մասին. DevOps-ի պրակտիկաների և գործիքների տիրապետումը մոտավորապես +30% է ձեր արժեքից աշխատաշուկայում: Աշխատավարձերը սկսվում են 140 հազար ռուբլուց, բայց որոշվում են, բնականաբար, ձեր հիմնական մասնագիտությամբ և ֆունկցիոնալությամբ:
Դուք կարող եք դիտել «ենթակառուցվածքին ուղղված» նշված թափուր աշխատատեղերը, որտեղ կա թեստային ավտոմատացում, ամպային տեխնոլոգիաների օգտագործմամբ միկրոսերվիսային հավելվածների մշակում, ենթակառուցվածքի ինժեներների թափուր աշխատատեղեր և DevOps-ի բոլոր տեսակի հղումներ: Պարզապես հիշեք, որ յուրաքանչյուր ընկերություն այս սահմանմամբ տարբեր բան է նշանակում. ուշադիր կարդացեք նկարագրությունը:
Մեր դասընթացի մեկնարկի ժամանակ ինձ մոտ հայտնվեց մի պատկերացում՝ դասընթացից հետո շատ մարդիկ ընկնում են DevOps-ի ինժեների թակարդը: Նրանք վերը նշված վերնագրով թափուր աշխատատեղ են գտնում, լավ առաջարկ են ստանում, հետո աշխատանքի են անցնում ու հասկանում, որ Ջենկինսում ստիպված են լինելու երեք էջանոց բաշ սցենար պահպանել։ Որտե՞ղ են Kubernetes-ը, ChatOps-ը, դեղձանիկների թողարկումները և այդ ամենը: Բայց ոչինչ չկա, քանի որ ընկերությանը ոչ թե DevOps-ը պետք է որպես մեթոդաբանություն, այլ օգտագործում է անհատական նորամուծություններ։
Սա պատճառ է ընկերությունից ինտենսիվորեն պարզելու, թե ինչպես է աշխատում ծրագրային ապահովման առաքման գործընթացը, տեխնոլոգիական փաթեթը և ինչ պարտականություններ եք կատարելու:
Եթե գործատուն պատասխանում է ձեր հարցերին վերացական, կարծես գրքից, առանց մանրամասների, ապա, ամենայն հավանականությամբ, ընկերությունում DevOps գործընթաց դեռ չկա, բայց դա պատճառ չէ հրաժարվելու, ուսումնասիրեք ընկերությունը և նրա արտադրանքը, արդյոք կան առցանց: ծառայություններ, որոնք ընկերությունն ինքն է մշակում, բջջային հավելվածներ, արտադրանքի գաղափարներ:
Եթե այո, ապա պարզաբանեք, թե արդյոք դուք ստիպված կլինեք ուղղակիորեն աշխատել այս համակարգերի հետ, թե արդյոք կա հորիզոնական շարժման հնարավորություն դեպի այս ծառայությունների թիմերը՝ միաժամանակ լավ արդյունքներ ցույց տալով DevOps-ի պրակտիկայում: Եթե այո, ապա արժե գնալ և լինել ակտիվ և օգտակար, իսկ եթե ավարտեք մեր դասընթացը, ապա վերջինս երաշխավորված է։
Կարևոր է նշել, որ Devops-ի պրակտիկանտները իրական արժեք են ձեռք բերում միայն մշակման/կառավարման/փորձարկման փորձով: Միայն այդ դեպքում գիտելիքը կլինի ոչ թե վերացական, այլ կհարստացնի մասնագետին (ամեն իմաստով): Հետևաբար, «DevOps-ը զրոյից սովորելու» գաղափարը մոտավորապես նույնն է, ինչ «զրոյից ոսպնյակներ օգտագործել» սովորելը, եթե երբեք տեսախցիկ չեք պահել ձեր ձեռքերում կամ նկարահանում չեք արել: Որպեսզի օգնենք ձեզ որոշել, թե արդյոք դասընթացը ճիշտ է ձեզ համար, մենք ընդունելության թեստ ենք պատրաստել, որը կստուգի ձեր գիտելիքների բավարար մակարդակը:
Կարծում եմ հնարքներից մեկը — որ վերապատրաստման ընթացքում յուրաքանչյուր ուսանող ինքն է որոշում, թե որ ուղղությամբ է ցանկանում զարգանալ։ Մենք հաճախ տեսնում ենք անցումներ, երբ ծրագրավորողը դառնում է ենթակառուցվածքի ինժեներ, և ադմինիստրատորը հասկանում է, որ հետաքրքրված է կոդ գրելով, այնուհետև նա լրացուցիչ ուսումնասիրում է լեզուն և լրացնում այն ձեռք բերված DevOps հմտություններով: Ուստի մենք հատկապես ողջունում ենք նրանց, ովքեր զգում են, որ իրենց կարիերան խրված է խաչմերուկում։ Դասընթացը սկսվում է մայիսի 28-ից, բայց կարող եք միանալ դասերի մեկնարկից 2 շաբաթ անց։ Դուք կարող եք դիտել ծրագիրը և անցնել թեստը . Կհանդիպենք OTUS-ում:
Source: www.habr.com