Ողջույններ բոլորիդ, իմ սիրելի ընթերցողներ:
Այսօր ես ուզում եմ կիսվել իմ մտքերով վաղուց արդիական թեմայի շուրջ և, հնարավոր է, քննարկել այն մեկնաբանություններում:
Բավականին հաճախ հանդիպում եմ ծրագրավորողի պաշտոնի համար հարցազրույցների վատ պրակտիկայի մասին հոդվածների, որոնք, իմ կարծիքով, բավականին տեղին են և, հուսով եմ, կարդում են խոշոր և ոչ այնքան խոշոր ընկերությունների կադրային բաժինները:
Մեր տարածքում, որքան ես կարող եմ դատել, կա այնպիսի հետաքրքիր սուբյեկտների պահանջարկ, ինչպիսին են DevOps-ի ինժեներները: Ես այն մարդկանցից եմ, ով իրականում չի ընդունում այս արտահայտությունը (այո, DevOps մեթոդաբանությունը և այլն), ուստի որոշ տարբերություններ եմ տեսնում այս խմբի մասնագետների զարգացման ուղիներում։
Նախ, ես հաստատապես հավատում եմ, որ յուրաքանչյուր մարդ ունի իր հետաքրքրությունների շրջանակը, նույնիսկ աշխատանքային տարածքում, այսինքն՝ ինչ-որ մեկին դուր են գալիս ամպերը, ինչ-որ մեկը սիրում է խորանալ Application սերվերները, կարգավորել խորը Java-ն, իսկ ինչ-որ մեկը սիրում է գրել կոդ Python-ով կամ, Աստված մի արասցե, yaml կոդով: Այսինքն, այստեղ հայտնվում են այսպես կոչված Ենթակառուցվածքի ինժեներ, Build Engineer, Senior Yaml Developer :)
Այս ամենը թույլ է տալիս ձեզ մի կողմից գտնել այնպիսի մարդու, ով առավել հարմար է ձեր առաջադրանքների համար, բայց մյուս կողմից՝ թյուրիմացություններ է առաջացնում հարցազրույցների ժամանակ։
Ելնելով անձնական փորձից, մի քանի տասնյակ հարցազրույցներ կատարելով, ինչպես նաև որպես մեղադրյալ մասնակցելով տարբեր հարցազրույցների, ուզում եմ կիսվել իմ տեսակետով այն ամենի վերաբերյալ, ինչ կատարվում է։
Առաջին և, հավանաբար, իմ ամենասիրած հակաօրինաչափությունը որևէ մեկի ցանկությունն է ամեն ինչ անելու, կամ պարզ չէ, թե ում է պետք, մի խումբ թեկնածուների կնայենք, այնտեղ կպարզենք։ Սա, հավանաբար, վերաբերում է ցանկացած ոլորտի, բայց այստեղ կան որոշակի առանձնահատկություններ:
Ինչպես նկատել եմ, մարդկանց ավելի շատ գրավում են DevOps բառերով թափուր աշխատատեղերը, քան System Administrator, չնայած, իմ կարծիքով, ավագ մակարդակում առաջադրանքների շրջանակը ամենաշատը տարբերվում է այս երկու ոլորտներում:
Ցանկացած գործատու, ով իսկապես համակարգային ադմինիստրատորի կարիք ունի, աշխատանքի վերնագրում գրում է DevOps՝ անընդմեջ թվարկելով հարցման մեջ բացարձակապես ամեն ինչ, K8S/Java/gradle/oracleDB և այլն, չնայած ներսից անձը պետք է աջակցի K8S կլաստերին և աջակցի OracleDB ստեկին թիմից առանձին:
Դե, ինչպիսի՞ փոխազդեցություն կա Developers/Operations ձևաչափի միջև:
Այնուհետև պարզ է դառնում, որ թիմի հետ փոխգործակցության նման գործընթաց չկա, և, ընդհանրապես, գործառնությունների բաժին չկա, և դուք պետք է կարգավորեք ծրագրավորողների համակարգիչները:
Այս տարբերակը իրականում հարմար է որոշ դիմորդների համար, բայց եկեք անկեղծ լինենք, սա ավագ համակարգի ադմինիստրատոր է, բա ինչո՞ւ չեն ուզում այդպես գրել և ի՞նչն է ամոթալի: Ո՞րն է աշխատավարձի տարբերությունը տարբեր աշխատանքի կոչումների միջև: Բայց ընկերությունն ունի միայն մեկ բյուջե, և անկախ նրանից, թե նավը ինչպես եք անվանում, նա նավարկելու է իր բյուջեով:
Դե, ես նույնիսկ լսել եմ այս մասին, հիմա թեկնածուն արագ կավտոմատացնի ամեն ինչ և կմիանա Python-ում պրոդուկտի մշակմանը, ինչ տարբերություն, Python-ը ամենուր նույնն է։ Աշխարհայացքների ու մոտեցումների տարբերությունները հաշվի չեն առնվում։
Հաջորդը ես սովորաբար տարբերում եմ մասնագետների մակարդակը, ովքեր գալիս են ու տեսնում իրենց խնդիրները յուրաքանչյուրի համար առանձին։
Junior - անձամբ ինձ համար Junior DevOps-ն այն մարդն է, ով տիրապետում է համակարգի կառավարման/զարգացմանը միջանկյալ մակարդակով: Այստեղ հաճելի է տարբերակել Linux-ի ուժեղ օգտատերերին, ովքեր ցանկանում են աճել նոր տարածքում, կամ ծրագրավորողներին, ովքեր ցանկություն ունեն լավություն անել այլ մշակողների համար: Ուժեղ, որոշ վրիպազերծման հմտություններով, գրանցամատյանների որոնման կամ կոդավորված նախագծերի որոշ պաշարներով:
Ես հանդիպեցի և՛ համակարգի ադմինիստրատորների, ովքեր փորձել են ինչ-որ բան և ցանկանում են դիպչել ամպերին, և՛ նրանց, ովքեր փորձել են առջևի, հետևի և ինչ-ինչ պատճառներով հետաքրքրություն են գտել DevOps գործընթացների նկատմամբ:
Այս մակարդակում ես միշտ շփոթված եմ, երբ նրանք սկսում են շտապել տեխնոլոգիաների հսկայական փաթեթի միջով, Puppet, Ansible. ինչու՞ ես ամեն ինչ չեմ փորձել: K8S, K3S - ո՞րն է տարբերությունը: Քանի՞ տեսակի տվյալների բազա գիտեք: ինչու այդքան քիչ Ինչպե՞ս է կոդավորումն աշխատում Java-ում: Հատկապես նրանք, ովքեր եկել են զարգացումից, թեև շատ օգտակար կադրեր են, բայց այս ոլորտում նրանց համար միշտ աշխատանք կա։
Ինձ միշտ ապշեցնում է, երբ նման բան է պատահում, առաջին բանը, որ ուզում եմ հարցնել՝ ինչու՞??? Երկրորդ բանը, որ գալիս է մտքում, հետևյալն է. արդյո՞ք հարցազրույց տվողն ինքը պատրա՞ստ է պատասխանել հարցերին նման բազմազան փաթեթի վրա: Իսկապե՞ս ուզում են կրտսեր մեկին տանել ու ամեն ինչ բարդել նրա վրա։
Սա հաճախ տեղի է ունենում բոլոր տեսակի բոդիների խանութներում, երբ դուք պետք է վաճառեք մարդուն ինչ-որ նախագծի համար, և ձեր ռեզյումեի համար ավելի լավ խոսքեր են անհրաժեշտ, կամ ընկերությունը չի ցանկանում որևէ մեկին աշխատանքի ընդունել, այլ պարզապես նայում է, թե ինչպիսի կրտսերներ կան:
Միջին մակարդակ
Այստեղ մի քանի ծայրահեղություններ կան, իմ կարծիքով, նախ երևի դժվար է հստակ որոշել, որ մարդն ընդունակ է միջին լինել, կամ փորձում են նրան իջեցնել կրտսեր, կամ սկսում են նրան հրել ավագի պես՝ փորձելով միջինի գնով բռնել ավագին (այո, շուկան է որոշում, անձնական ոչինչ)
Ամենազարմանալին, որ ես տեսել եմ, խորանալն է կոդավորման մեջ, ձեռք բերել Python-ը, տանջել Java GC-ին, այսինքն՝ ավելի խորը կոնկրետ թեմաներով, կամ, ընդհակառակը, բացահայտել երկար ժամանակ չօգտագործված գիտելիքների բացերը, վազել ցանցերի շուրջ, ՕՀ-ի դրայվերների տեսակները, քմծիծաղն ու գոռգոռալը, ինչպե՞ս կարող է մարդը մոռանալ դա: Եվ ահա ամենահետաքրքիրը տեղի է ունենում.
Միջին մակարդակով, ըստ իս, մասնագետը զարգացնում է հետաքրքրությունների շրջանակ և անձնական տեսակետ այն մասին, թե ինչի հետ է նա ցանկանում աշխատել՝ բարձրաձայնել վերջին կույտը, ենթամարդուն մղել խորանարդի մեջ կամ բարձրանալ սարսափելի ձեռնարկության համար՝ խորանալով կոդի կատարման մեջ:
Իմ կարծիքով, արժե հարցնել այն գործընթացների մասին, որոնց վրա աշխատել է մարդը, հարցնել, թե որն է ամենահետաքրքիրը, ինչը ոչ, և հետո, այս գիտելիքի հիման վրա, ստեղծել հարցերի կլաստեր, անպայմանորեն հարցերը քարտեզագրել ձեր կույտին: Հակառակ դեպքում, մեկ-երկու ժամ հետաքրքրաշարժ զրույց վարելուց հետո OpenShift կլաստերի կազմաձևման մասին, վարձեք մեկին և աշխատեք շենքի մոնիտորինգի վրա: Հավանաբար դա դուր կգա երկու կողմերին էլ։
Ավագ մակարդակ
Օ, իմ սիրելի մակարդակը:
Քեզնից առաջ ուժեղ մասնագետ է, ով մեծացել է տարբեր տեսակի նախագծերի վրա, մարդ, ով արդեն գիտի, թե ինչ է ուզում և ինչն այնքան էլ չի սիրում:
Եվ ահա շոուն սկսվում է.
- խորը հարցեր համակարգի կառավարման վերաբերյալ (տես առաջին հակաօրինաչափությունը)
— ընդհանրապես Linux-ի մասին խորը հարցեր տեսական դաշտից, հեռու գործնական գիտելիքներից (OSI մակարդակների վերին հարց)
- կոդավորման վերաբերյալ ակադեմիական հարցեր (քանի որ հարցազրուցավարն ինքն իրականում չգիտի այդ ոլորտը, նրան ուղղակի խնդրեցին հարցազրույց վերցնել տարօրինակ DevOps-ից)
Այստեղ մի փոքրիկ դիտողություն անեմ. Մի անգամ, հարցազրույցի ժամանակ, ինձ խնդրեցին գրել կոդ: Թղթի մի կտորի վրա։ Դե, ինչպես բոլորն են սիրում, մենք ամեն օր գրում ենք, մի թուղթը մեր ամեն ինչն է։
Առաջադրանքը կատարելուց հետո իմ թուղթն ու լուծումը վերանայելուց հետո դատավճիռը կայացավ, որ ալգորիթմը կլինի ոչ օպտիմալ: Ես առաջարկեցի, որ հարցազրուցավարը գրի առնի իր ալգորիթմը, որին նա պատասխանեց. «Դա հարցազրույցի շրջանակում չէ»: Ես մի րոպե խնդրեցի, մի փոքր փոխեցի կոդը և ցույց տվեցի, հարցնելով՝ ավելի արագ կլինի, թե դանդաղ: Ինչի պատասխանը ստացա, անցնենք հաջորդ հարցին. Տարբերությունը կոդի ցիկլով և առանց օղակի գործողության մեջ էր, և ես պատրաստի պատասխան ունեի, թե ինչու է ավելի լավ դա անել այս ձևով և ոչ այնպես: Դե, դրանից հետո ես այլևս չէի ուզում պատասխանել հարցերին և աշխատել այս մարդու հետ։
Կարևոր է հիշել, որ մենք բոլորս տարբեր ենք, և թեկնածուն կարող է հետաձգվել ցանկացած բանով, որը ձեզ համար կարևոր չէ:
— սովորաբար ավագ մակարդակի մասնագետներն ունեն հստակ նկարագրված աշխատանքային ստեկ, բայց ոչ, դուք պետք է սկսեք վազել մոտ ինչ-որ բանի վրա, օրինակ, դուք ունեք Ansible գրված, հիանալի, և մենք ունենք Puppet, մենք պարզապես զանգահարեցինք ձեզ, լավ, պատմեք մեզ Puppet-ի մասին: Կատարյալ! Դուք աշխատե՞լ եք OpenShift-ի հետ: Մենք ունենք K8, մենք չգիտենք տարբերությունները, բայց ձեր փորձը կապ չունի: Զարմանալի!
Կա ևս մեկ ենթադաս՝ ես անձամբ պրակտիկանտներ եմ ընդունում՝ կրտսեր դառնալու համար:
Կուզենայի, որ բոլորը հասկանան, որ ինտերն այն էակ է, որը դեռևս չի ձևավորվել։ Ինձ իսկապես վախեցնում է, երբ պրակտիկանտներին հասցնում են ամուր կրտսեր մակարդակի, իսկ հետո գոհունակ հայացքով առաջարկում են պրակտիկա (երբեմն չվարձատրվող, մղձավանջ:)
Մի արեք դա այսպես.
Ստաժորն, իմ կարծիքով, կա՛մ ավագ ուսանող է, կա՛մ մեկը, ով իսկապես ցանկանում է «մտնել ՏՏ ոլորտում»:
Ուսանողների հետ դա պարզ է. հիանալի է պարզել, թե ինչով են նրանք զբաղվում համալսարանում, ինչով են զբաղվել իրենք, տեսնել, թե ինչ հարցերով են նրանց աչքերը լուսավորվում. Զգացեք մարդուն և հասկացեք՝ հաճելի կլինի՞ շարունակել նրա հետ աշխատել, արդյոք ցանկանում եք որևէ բան սովորեցնել տվյալ անձին։
Նրանց հետ, ովքեր ցանկանում են «մտնել ՏՏ» մեջ, ամեն ինչ մի փոքր ավելի խիստ է. տեսեք, թե որքանով է մարդը ինքնուսույց, ինչ է նա արել ձեր հարցազրույցին գալուց առաջ, այստեղ լավ տարբերակ կլինի նայել GitHub-ին, եթե կա, իհարկե, պարտավորությունների խտությունը և ինչ վարժություններ են արվել: Նաև հարցրե՛ք՝ ինչու՞ DevOps, քանի որ frontend-ը ավելի զվարճալի և բարդ է:
Դե, և վերջապես, ես կցանկանայի ձեզ մեկ այլ խորհուրդ տալ՝ որոշեք, թե ով է ձեզ իրականում անհրաժեշտ և անմիջապես կգտնեք ճիշտ մարդուն։ Բացահայտեք կարիքները, նայեք մասնագետին որպես մասնագետ, գտեք նրա ուժեղ կողմերը և հաջողությամբ օգտագործեք դրանք ձեր աշխատանքում: Զգույշ եղեք զրուցակցի նկատմամբ, նա եկել է ձեզ մոտ զրույցի, այլ ոչ թե մրցակցության, թե ով ում կարող է ձախողել կամ չտապալել։
Source: www.habr.com
