Ովքե՞ր են DevOps-ը:

Այս պահին սա գրեթե ամենաթանկ դիրքն է շուկայում։ «DevOps» ինժեներների շուրջ աղմուկը գերազանցում է բոլոր երևակայելի սահմանները, և նույնիսկ ավելի վատ է DevOps-ի ավագ ինժեներների մոտ:
Ես աշխատում եմ որպես ինտեգրման և ավտոմատացման բաժնի ղեկավար, գուշակեք անգլերենի վերծանումը - DevOps Manager: Դժվար թե անգլերեն սղագրությունը արտացոլի մեր ամենօրյա գործունեությունը, սակայն ռուսերեն տարբերակն այս դեպքում ավելի ճշգրիտ է։ Իմ գործունեության բնույթից ելնելով բնական է, որ ես պետք է հարցազրույց անցկացնեմ թիմիս ապագա անդամների հետ, և անցած մեկ տարվա ընթացքում մոտ 50 հոգի անցել է իմ միջով, և նույնքան էլ նախաքրված են իմ աշխատակիցների հետ։

Մենք դեռ փնտրում ենք գործընկերներ, քանի որ DevOps պիտակի հետևում թաքնված է տարբեր տեսակի ինժեներների մի շատ մեծ շերտ:

Ստորև գրված ամեն ինչ իմ անձնական կարծիքն է, պարտադիր չէ, որ դրա հետ համաձայնվեք, բայց ընդունում եմ, որ դա որոշակի գույն կհաղորդի ձեր վերաբերմունքին թեմային։ Չնայած անբարենպաստությունից ընկնելու ռիսկին, ես հրապարակում եմ իմ կարծիքը, քանի որ կարծում եմ, որ այն իր տեղն ունի։

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

Այսպիսով, ովքեր են DevOps-ի ինժեներները:

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

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

Հայտնվել է «հրաշալի» բան՝ դոկեր։ Ինչու՞ հրաշալի: Այո, միայն այն պատճառով, որ chroot-ում կամ բանտում մեկուսացում ստեղծելը, ինչպես նաև OpenVZ-ը պահանջում էր ՕՀ-ի ոչ տրիվիալ գիտելիքներ, ընդհակառակը, կոմունալը թույլ է տալիս պարզապես ստեղծել մեկուսացված հավելվածի միջավայր որոշակի հոսթի վրա՝ ներսում և ձեռքով անհրաժեշտ ամեն ինչով: կրկին զարգացման ղեկի վրա, և համակարգի ադմինիստրատորը կարող է կառավարել միայն մեկ հոսթով՝ ապահովելով դրա անվտանգությունն ու բարձր հասանելիությունը՝ տրամաբանական պարզեցում: Բայց առաջընթացը կանգ չի առնում, և համակարգերը կրկին դառնում են ավելի ու ավելի բարդ, ավելի ու ավելի շատ բաղադրիչներ կան, մեկ հոսթն այլևս չի բավարարում համակարգի կարիքները, և անհրաժեշտ է կառուցել կլաստերներ, մենք կրկին վերադառնում ենք համակարգի ադմինիստրատորներին, որոնք կարող է կառուցել այս համակարգերը:

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

Նմանատիպ «ճոճանակները» որոշակի ռեսուրսի փորձագիտական ​​գիտելիքների մակարդակում շարունակվում են մինչ օրս: Բայց մենք մի փոքր շեղվում ենք, կան շատ կետեր, որոնք արժե ընդգծել:

Build Engineer/Release Engineer

Շատ բարձր մասնագիտացված ինժեներներ, որոնք ի հայտ եկան որպես ծրագրային ապահովման ստանդարտացման միջոց, ստեղծեցին գործընթացները և թողարկումները: Համատարած Agile-ի ներդրման գործընթացում թվում էր, թե դրանք դադարել են պահանջված լինել, բայց դա հեռու է դեպքից։ Այս մասնագիտացումը հայտնվեց որպես արդյունաբերական մասշտաբով ծրագրային ապահովման հավաքման և առաքման ստանդարտացման միջոց, այսինքն. օգտագործելով ստանդարտ տեխնիկա բոլոր ընկերության արտադրանքի համար: DevOps-ի գալուստով ծրագրավորողները մասամբ կորցրեցին իրենց գործառույթները, քանի որ հենց մշակողները սկսեցին պատրաստել արտադրանքը առաքման համար, և հաշվի առնելով փոփոխվող ենթակառուցվածքը և հնարավորինս արագ առաքման մոտեցումը՝ առանց որակի հաշվի առնելու, ժամանակի ընթացքում դրանք վերածվեցին. փոփոխությունների խափանիչ, քանի որ որակի չափանիշներին հավատարմությունն անխուսափելիորեն դանդաղեցնում է առաքումները: Այսպիսով, աստիճանաբար, Build/Release ինժեներների ֆունկցիոնալության մի մասը տեղափոխվեց համակարգի ադմինիստրատորների ուսերին:

Գործողությունները այնքան տարբեր են

Մենք առաջ ենք շարժվում և նորից պատասխանատվության մեծ շրջանակի առկայությունը և որակյալ կադրերի բացակայությունը մղում են մեզ դեպի խիստ մասնագիտացում, ինչպես սնկերը անձրևից հետո, հայտնվում են տարբեր Գործողություններ.

• TechOps - enikey համակարգի ադմինիստրատորներ՝ HelpDesk Engineer
• LiveOps - համակարգի ադմինիստրատորներ, որոնք հիմնականում պատասխանատու են արտադրական միջավայրերի համար
• CloudOps - համակարգի ադմինիստրատորներ, որոնք մասնագիտացած են հանրային ամպերի Azure, AWS, GCP և այլն:
• PlatOps/InfraOps/SysOps - ենթակառուցվածքային համակարգի ադմինիստրատորներ:
• NetOps - ցանցային ադմինիստրատորներ
• SecOps - համակարգի ադմինիստրատորներ, որոնք մասնագիտացած են տեղեկատվական անվտանգության ոլորտում՝ PCI համապատասխանություն, ԱՊՀ համապատասխանություն, կարկատում և այլն:

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

Այս տեսակի աշխատանքն ու պարտականությունները կատարելու համար այս անձը պետք է միջոցներ ունենա կառավարելու ոչ միայն մշակման և փորձարկման գործընթացները, այլև արտադրանքի ենթակառուցվածքի կառավարումը, ինչպես նաև ռեսուրսների պլանավորումը: DevOps-ն այս ըմբռնմամբ չի կարող տեղակայվել ոչ ՏՏ-ում, ոչ R&D-ում կամ նույնիսկ PMO-ում, այն պետք է ազդեցություն ունենա այս բոլոր ոլորտներում՝ ընկերության տեխնիկական տնօրեն, գլխավոր տեխնիկական տնօրեն:

Սա ճի՞շտ է ձեր ընկերությունում: - Ես կասկածում եմ. Շատ դեպքերում սա կա՛մ ՏՏ է, կա՛մ R&D:

Ֆոնդերի բացակայությունը և գործունեության այս երեք ոլորտներից առնվազն մեկի վրա ազդելու կարողությունը կփոխանցի խնդիրների կշիռը դեպի այնտեղ, որտեղ այս փոփոխություններն ավելի հեշտ են կիրառել, օրինակ՝ «կեղտոտ» կոդի հետ կապված թողարկումների տեխնիկական սահմանափակումների կիրառումը ըստ ստատիկի: անալիզատոր համակարգեր. Այսինքն, երբ PMO-ն սահմանում է ֆունկցիոնալության թողարկման խիստ վերջնաժամկետ, R&D-ը չի կարող բարձրորակ արդյունք տալ այս ժամկետներում և արտադրում է այն հնարավորինս լավ՝ թողնելով վերամշակումը ավելի ուշ, ՏՏ-ի հետ կապված DevOps-ը արգելափակում է թողարկումը՝ օգտագործելով տեխնիկական միջոցներ: . Իրավիճակը փոխելու իրավասության բացակայությունը, պատասխանատու աշխատողների դեպքում, հանգեցնում է գերպատասխանատվության դրսևորմանը, ինչի վրա նրանք չեն կարող ազդել, հատկապես, եթե այդ աշխատակիցները հասկանում և տեսնում են սխալները և ինչպես ուղղել դրանք. «Երանությունը տգիտությունն է». և որպես հետևանք այդ աշխատակիցների այրման և կորստի:

DevOps ռեսուրսների շուկա

Դիտարկենք մի քանի թափուր աշխատատեղեր DevOps-ի պաշտոնների համար տարբեր ընկերություններից:

Մենք պատրաստ ենք հանդիպել ձեզ հետ, եթե դուք.

1. Դուք պատկանում եք Zabbix-ին և գիտեք, թե ինչ է Պրոմեթևսը.
2. Iptables;
3. BASH PhD ուսանող;
4. Պրոֆեսոր Անսիբլ;
5. Linux գուրու;
6. Իմանալ, թե ինչպես օգտագործել վրիպազերծումը և գտնել հավելվածների խնդիրները մշակողների հետ միասին (php/java/python);
7. Երթուղիները ձեզ հիստերիկ չեն դարձնում.
8. Զգալի ուշադրություն դարձնել համակարգի անվտանգությանը.
9. Կրկնօրինակեք «ամեն ինչ և ամեն ինչ», ինչպես նաև հաջողությամբ վերականգնեք այս «ամեն ինչ և ամեն ինչ»;
10. Դուք գիտեք, թե ինչպես կարելի է կարգավորել համակարգը այնպես, որ առավելագույնը ստանաք նվազագույնից;
11. Կարգավորեք կրկնօրինակումը քնելուց առաջ Postgres-ում և MySQL-ում;
12. CI/CD-ի կարգավորումն ու կարգավորումը ձեզ համար նույնքան անհրաժեշտ է, որքան նախաճաշ/ճաշ/ընթրիք:
13. Ունեն փորձ AWS-ի հետ;
14. Պատրաստ է զարգանալ ընկերության հետ;

So.

• 1-ից 6-ը `համակարգի ադմինիստրատոր
• 7 - մի փոքր ցանցային կառավարում, որը նույնպես տեղավորվում է համակարգի ադմինիստրատորի մեջ, միջին մակարդակ
• 8 - մի փոքր անվտանգություն, որը պարտադիր է միջին մակարդակի համակարգի ադմինիստրատորի համար
• 9-11 – Միջին համակարգի ադմինիստրատոր
• 12 — Կախված հանձնարարված առաջադրանքներից, կա՛մ միջին համակարգի ադմինիստրատոր, կա՛մ շինարարական ինժեներ
• 13 - Վիրտուալացում - Միջին համակարգի ադմինիստրատոր կամ, այսպես կոչված, CloudOps, կոնկրետ հոսթինգ կայքի ծառայությունների առաջադեմ գիտելիքներ, միջոցների արդյունավետ օգտագործման և սպասարկման բեռը նվազեցնելու համար

Ամփոփելով այս թափուր պաշտոնը, կարելի է ասել, որ միջին/ավագ համակարգի ադմինիստրատորը բավական է տղաներին։

Ի դեպ, Linux/Windows-ում ադմիններին խիստ բաժանելու կարիք չկա։ Իհարկե, ես հասկանում եմ, որ այս երկու աշխարհների ծառայություններն ու համակարգերը տարբեր են, բայց բոլորի հիմքերը նույնն են, և ցանկացած իրեն հարգող ադմին ծանոթ է և՛ մեկին, և՛ մյուսին, և եթե նույնիսկ ծանոթ չէ, դա կլինի կոմպետենտ ադմինի համար դժվար չէ ծանոթանալ դրան:

Դիտարկենք մեկ այլ թափուր աշխատատեղ.

1. Բարձր բեռնվածության համակարգերի կառուցման փորձ;
2. Linux OS-ի, ընդհանուր համակարգի ծրագրային ապահովման և վեբ ստեկի գերազանց իմացություն (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Վիրտուալացման համակարգերի հետ աշխատելու փորձ (KVM, VMWare, LXC/Docker);
4. սկրիպտային լեզուների իմացություն;
5. Ցանցային պրոտոկոլային ցանցերի գործառնական սկզբունքների իմացություն;
6. Սխալ հանդուրժող համակարգերի կառուցման սկզբունքների իմացություն;
7. Անկախություն և նախաձեռնություն;

Եկեք նայենք.

• 1 – Համակարգի ավագ ադմինիստրատոր
• 2 - Կախված այս բուրգի մեջ դրված նշանակությունից՝ միջին/ավագ համակարգի ադմինիստրատոր
• 3 - Աշխատանքային փորձը, ներառյալ, կարող է նշանակել. «Կլաստերը չի բարձրացրել, այլ ստեղծել և կառավարել է վիրտուալ մեքենաներ, կար մեկ Docker հոսթ, մուտքը դեպի կոնտեյներներ հասանելի չի եղել» - Middle System Administrator
• 4 - Junior System Administrator - այո, ադմին, ով չգիտի, թե ինչպես գրել հիմնական ավտոմատացման սցենարներ, անկախ լեզվից, ոչ թե admin - enikey:
• 5 - միջին համակարգի ադմինիստրատոր
• 6 – Համակարգի ավագ ադմինիստրատոր

Ամփոփելու համար՝ միջին/ավագ համակարգի ադմինիստրատոր

Ուրիշ մեկը:

1. Devops փորձ;
2. CI/CD գործընթացներ ստեղծելու համար մեկ կամ մի քանի արտադրանք օգտագործելու փորձ: Gitlab CI-ն առավելություն կլինի.
3. Կոնտեյներների հետ աշխատանք և վիրտուալացում; Եթե ​​դուք օգտագործել եք docker, լավ է, բայց եթե օգտագործել եք k8s, հիանալի:
4. Արագաշարժ թիմում աշխատելու փորձ;
5. Ծրագրավորման ցանկացած լեզվի իմացություն;

Եկեք տեսնենք.

• 1 - Հմմ... Ի՞նչ նկատի ունեն տղերքը: =) Ամենայն հավանականությամբ նրանք իրենք էլ չգիտեն, թե ինչ է թաքնված դրա հետևում
• 2 - շինարարության ինժեներ
• 3 - միջին համակարգի ադմինիստրատոր
• 4 - Փափուկ հմտություն, մենք դա առայժմ չենք հաշվի առնի, չնայած Agile-ը ևս մեկ բան է, որը մեկնաբանվում է հարմար ձևով:
• 5 - Չափազանց ծավալուն - դա կարող է լինել սցենարային լեզու կամ կազմված: Հետաքրքիր է, դպրոցում Pascal-ով և Basic-ով գրելը կհամապատասխանի՞ նրանց: =)

Կցանկանայի նաև նշում կատարել 3-րդ կետի վերաբերյալ՝ ամրապնդելու համար, թե ինչու է այս կետը ծածկված համակարգի ադմինիստրատորի կողմից: Kubernetes-ը պարզապես նվագախմբություն է, գործիք, որը մի քանի հրամաններով փաթաթում է ուղիղ հրամանները ցանցի վարորդներին և վիրտուալացման/մեկուսացման հոսթներին և թույլ է տալիս նրանց հետ հաղորդակցությունը դարձնել վերացական, այսքանը: Օրինակ՝ վերցնենք «build frame» Make, որը, ի դեպ, ես շրջանակ չեմ համարում։ Այո, ես գիտեմ Make-ը ցանկացած տեղ հրելու մոդայի մասին, որտեղ դա անհրաժեշտ է և անհրաժեշտ չէ. Maven-ին, օրինակ, Maven-ով փաթաթելը լրջորեն:
Ըստ էության, Make-ը պարզապես փաթաթում է կեղևի վրա, որը պարզեցնում է կոմպիլյացիայի, կապելու և կոմպիլյացիայի միջավայրի հրամանները, ինչպես k8s-ը:

Մի անգամ ես հարցազրույց վերցրեցի մի տղայի հետ, ով OpenStack-ի վերևում իր աշխատանքում օգտագործում էր k8, և նա խոսեց այն մասին, թե ինչպես է ծառայությունները տեղադրում դրա վրա, սակայն, երբ ես հարցրի OpenStack-ի մասին, պարզվեց, որ այն կառավարվում էր, ինչպես նաև բարձրացվում էր համակարգի կողմից: ադմինիստրատորներ. Իսկապե՞ս կարծում եք, որ այն մարդը, ով տեղադրել է OpenStack-ը, անկախ նրանից, թե ինչ հարթակ է օգտագործում իր հետևում, չի՞ կարողանում օգտագործել k8s: =)
Այս դիմորդը իրականում DevOps չէ, այլ համակարգի ադմինիստրատոր և, ավելի ճիշտ, Kubernetes ադմինիստրատոր:

Եվս մեկ անգամ ամփոփենք. միջին/ավագ համակարգի ադմինիստրատորը նրանց բավական կլինի:

Որքա՞ն է կշռել գրամով

Նշված թափուր աշխատատեղերի համար առաջարկվող աշխատավարձերի միջակայքը 90-200 հազար է
Այժմ ես կցանկանայի զուգահեռ անցկացնել համակարգի ադմինիստրատորների և DevOps Engineers-ի դրամական պարգևների միջև:

Սկզբունքորեն, գործերը պարզեցնելու համար կարող եք ցրել գնահատականները՝ հիմնվելով աշխատանքային փորձի վրա, թեև դա ճշգրիտ չի լինի, բայց հոդվածի նպատակների համար դա բավարար կլինի։

Փորձ.

1. մինչև 3 տարի՝ կրտսեր
2. մինչև 6 տարեկան – Միջին
3. ավելի քան 6 – Ավագ

Աշխատակիցների որոնման կայքը առաջարկում է.
Համակարգի ադմինիստրատորներ.

1. Կրտսեր - 2 տարեկան - 50 հազար ռուբ.
2. Միջին - 5 տարի - 70 հազար ռուբ.
3. Ավագ - 11 տարեկան - 100 հազար ռուբ.

DevOps Engineers:

1. Կրտսեր - 2 տարեկան - 100 հազար ռուբ.
2. Միջին - 3 տարի - 160 հազար ռուբ.
3. Ավագ - 6 տարեկան - 220 հազար ռուբ.

«DevOps»-ի փորձի համաձայն՝ օգտագործվել է փորձ, որը գոնե ինչ-որ կերպ ազդել է SDLC-ի վրա:

Վերոնշյալից հետևում է, որ իրականում ընկերությունները DevOps-ի կարիք չունեն, ինչպես նաև, որ նրանք կարող են խնայել սկզբնական պլանավորված ծախսերի առնվազն 50 տոկոսը՝ վարձելով ադմինիստրատոր, ավելին, նրանք կարող են ավելի հստակ սահմանել իրենց փնտրած անձի պարտականությունները։ և ավելի արագ լրացրեք կարիքը: Չպետք է մոռանալ նաև, որ պարտականությունների հստակ բաշխումը թույլ է տալիս կրճատել կադրերի պահանջները, ինչպես նաև թիմում ստեղծել ավելի բարենպաստ մթնոլորտ՝ համընկնումների բացակայության պատճառով։ Թափուր աշխատատեղերի ճնշող մեծամասնությունը լի է կոմունալ ծառայություններով և DevOps պիտակներով, բայց դրանք հիմնված չեն DevOps Engineer-ի իրական պահանջների վրա, այլ միայն գործիքի ադմինիստրատորի հարցումների:

DevOps-ի ինժեներների վերապատրաստման գործընթացը նույնպես սահմանափակվում է միայն կոնկրետ աշխատանքների, կոմունալ ծառայությունների մի շարքով և չի ապահովում գործընթացների և դրանց կախվածության ընդհանուր պատկերացում: Անշուշտ լավ է, երբ մարդը կարող է տեղակայել AWS EKS-ը Terraform-ի միջոցով՝ այս կլաստերի Fluentd կողային սայլի և գրանցման համակարգի համար AWS ELK ստեկի հետ 10 րոպեում, օգտագործելով միայն մեկ հրաման վահանակում, բայց եթե նա չի հասկանում Ինքն տեղեկամատյանները մշակելու սկզբունքը և ինչի համար են դրանք անհրաժեշտ, եթե չգիտեք, թե ինչպես հավաքել չափումներ դրանց վրա և հետևել ծառայության դեգրադացմանը, ապա դա դեռ նույն enikey-ն կլինի, ով գիտի, թե ինչպես օգտագործել որոշ կոմունալ ծառայություններ:

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

Այսպիսով, ովքեր են նրանք: DevOps, թե՞ ագահ համակարգի ադմինիստրատորներ: =)

Ինչպե՞ս շարունակել ապրել:

Գործատուները պետք է ավելի ճշգրիտ ձևակերպեն պահանջները և փնտրեն հենց նրանց, ովքեր պետք են, այլ ոչ թե պիտակներ նետեն: Դուք չգիտեք, թե ինչ են անում DevOps-ը, այդ դեպքում դրանք ձեզ պետք չեն:

Աշխատողներ - Սովորեք: Անընդհատ կատարելագործեք ձեր գիտելիքները, նայեք գործընթացների ընդհանուր պատկերին և հետևեք ձեր նպատակին հասնելու ճանապարհին: Դու կարող ես դառնալ ով ուզում ես, պարզապես պետք է փորձել։

Source: www.habr.com