Այս հոդվածը գրելու պահին «Ցանցային ինժեներ» արտահայտության հայտնի աշխատատեղում որոնումը վերադարձրեց մոտ երեք հարյուր թափուր աշխատատեղ ամբողջ Ռուսաստանում: Համեմատության համար նշենք, որ «համակարգի ադմինիստրատոր» արտահայտության որոնումը վերադարձնում է գրեթե 2.5 հազար թափուր աշխատատեղ, իսկ «DevOps ինժեներ»՝ գրեթե 800:
Արդյո՞ք սա նշանակում է, որ ցանցային աշխատողներն այլևս կարիք չունեն հաղթական ամպերի, Docker-ի, Kubernetes-ի և ամենուր տարածված հանրային Wi-Fi-ի ժամանակ:
Եկեք պարզենք (գ)
Եկեք ծանոթանանք։ Իմ անունը Ալեքսեյ է, և ես ցանցային աշխատող եմ:
Ես ներգրավված եմ եղել ցանցերում ավելի քան 10 տարի և աշխատել եմ տարբեր *nix համակարգերի հետ ավելի քան 15 տարի (ես հնարավորություն ունեի աշխատելու ինչպես Linux-ի, այնպես էլ FreeBSD-ի հետ): Ես աշխատել եմ հեռահաղորդակցական օպերատորներում, խոշոր ընկերություններում, որոնք համարվում են «ձեռնարկություն», իսկ վերջերս աշխատում եմ «երիտասարդ և համարձակ» ֆինտեխում, որտեղ ամպեր, դևոպս, կուբերնետներ և այլ սարսափելի բառեր, որոնք հաստատ ինձ և իմ գործընկերներին ավելորդ կդարձնեն։ . Մի օր. Միգուցե.
«Մեր կյանքում ամեն ինչ չէ, որ միշտ և ամենուր է, բայց ինչ-որ բան, երբեմն տեղերում» (գ) Մաքսիմ Դորոֆեև:
Ստորև գրված ամեն ինչ կարելի է և պետք է համարել հեղինակի անձնական կարծիքը, որը չի հավակնում լինել վերջնական ճշմարտության կամ նույնիսկ լիարժեք ուսումնասիրության։ Բոլոր կերպարները մտացածին են, բոլոր զուգադիպությունները՝ պատահական։
Բարի գալուստ իմ աշխարհ.
Որտե՞ղ կարող եք նույնիսկ հանդիպել ցանցային աշխատողների:
1. Հեռահաղորդակցության օպերատորներ, սպասարկող ընկերություններ և այլ ինտեգրատորներ. Այստեղ ամեն ինչ պարզ է. ցանցը նրանց համար բիզնես է: Նրանք կամ ուղղակիորեն վաճառում են կապը (օպերատորներ) կամ ծառայություններ են մատուցում իրենց հաճախորդների ցանցերը գործարկելու/պահպանելու համար:
Այստեղ մեծ փորձ կա, բայց ոչ շատ գումար (եթե տնօրեն չեք կամ հաջողակ վաճառքի մենեջեր): Եվ այնուամենայնիվ, եթե ձեզ դուր են գալիս ցանցերը, և դուք դեռ ձեր ճանապարհորդության սկզբում եք, կարիերան, որն աջակցում է որոշ ոչ շատ խոշոր օպերատորի, նույնիսկ հիմա կլինի իդեալական մեկնարկային կետ (դաշնայիններում ամեն ինչ շատ գրված է, և այնտեղ քիչ տեղ է ստեղծագործելու համար): Դե, պատմություններն այն մասին, թե ինչպես կարող ես մի քանի տարում հերթապահ ինժեներից դառնալ C մակարդակի մենեջեր, նույնպես բավականին իրական են, թեև հազվադեպ են, ակնհայտ պատճառներով: Կադրերի կարիք միշտ կա, քանի որ շրջանառություն իսկապես լինում է։ Սա միևնույն ժամանակ և՛ լավ է, և՛ վատ. միշտ թափուր աշխատատեղեր կան, մյուս կողմից՝ հաճախ ամենաակտիվները/խելացիներն արագ հեռանում են կա՛մ առաջխաղացման, կա՛մ այլ, «ավելի տաք» վայրեր:
2. Պայմանական «ձեռնարկություն».. Կապ չունի՝ նրա հիմնական գործունեությունը կապված է ՏՏ ոլորտի հետ, թե ոչ։ Հիմնական բանն այն է, որ այն ունի իր սեփական ՏՏ բաժինը, որն ապահովում է ընկերության ներքին համակարգերի աշխատանքը, ներառյալ ցանցը գրասենյակներում, կապի ուղիները դեպի մասնաճյուղեր և այլն: Նման ընկերություններում ցանցային ինժեների գործառույթները կարող են «կես դրույքով» կատարել համակարգի ադմինիստրատորը (եթե ցանցային ենթակառուցվածքը փոքր է կամ կառավարվում է արտաքին կապալառուի կողմից), իսկ ցանցի մասնագետը, եթե այդպիսին կա, կարող է միևնույն ժամանակ հոգ տանել հեռախոսի և SAN-ի մասին (լավ չէ): Նրանք վճարում են տարբեր կերպ՝ դա մեծապես կախված է բիզնեսի շահութաբերությունից, ընկերության չափից և կառուցվածքից: Ես աշխատել եմ ընկերությունների հետ, որտեղ Cisco համակարգերը պարբերաբար «բեռնվում էին տակառներում», և ընկերությունների հետ, որտեղ ցանցը կառուցված էր կղանքից, ձողիկներից և կապույտ ժապավենից, և սերվերները երբեք չեն թարմացվել (կարիք չկա ասելու, որ պաշարներ նույնպես չեն տրամադրվել): Այստեղ շատ ավելի քիչ փորձ կա, և դա գրեթե անկասկած կլինի խիստ վաճառող-կողպման ոլորտում, կամ «ինչպես ոչնչից ինչ-որ բան պատրաստել»: Անձամբ ինձ դա շատ ձանձրալի թվաց, չնայած շատերին դա դուր է գալիս. Առնվազն տարին մեկ անգամ որոշ խոշոր վաճառողներ ասում են, որ իրենք եկել են մեկ այլ մեգա-սուպեր-դյուպեր համակարգով, որն այժմ ավտոմատացնելու է ամեն ինչ, և համակարգի բոլոր ադմինիստրատորներն ու ցանցային աշխատողները կարող են ցրվել՝ թողնելով զույգին սեղմել կոճակները գեղեցիկ ինտերֆեյսի մեջ: Իրականությունն այն է, որ նույնիսկ եթե մենք անտեսենք լուծման արժեքը, ցանցային աշխատողներն այնտեղից ոչ մի տեղ չեն գնա: Այո, միգուցե վահանակի փոխարեն նորից կլինի վեբ ինտերֆեյս (բայց ոչ թե կոնկրետ սարքաշար, այլ մեծ համակարգ, որը կառավարում է տասնյակ և հարյուրավոր այդպիսի սարքավորումներ), բայց «ինչպես է ամեն ինչ աշխատում ներսում» դեռևս գիտելիքը: անհրաժեշտ լինել:
3. Արտադրական ընկերություններ, որի շահույթը գալիս է ինչ-որ ծրագրաշարի կամ պլատֆորմի մշակումից (և հաճախ շահագործումից)՝ այդ նույն արտադրանքը։ Սովորաբար նրանք փոքր են ու ճարպիկ, դեռ հեռու են ձեռնարկությունների մասշտաբներից ու նրանց բյուրոկրատացումից։ Այստեղ է, որ զանգվածաբար հանդիպում են այդ նույն դևոպները, կուբերները, դոկերները և այլ սարսափելի բառեր, որոնք, անշուշտ, ցանցն ու ցանցային ինժեներները կդարձնեն ավելորդ տարր:
Ինչպե՞ս է ցանցագործը տարբերվում համակարգի ադմինիստրատորից:
Մարդկանց ըմբռնման մեջ ոչ ՏՏ-ից՝ ոչինչ: Երկուսն էլ նայում են սև էկրանին և ինչ-որ հմայություններ գրում, երբեմն էլ հանգիստ հայհոյում։
Ծրագրավորողների ըմբռնման մեջ՝ գուցե ըստ առարկայի: Համակարգի ադմինիստրատորները կառավարում են սերվերները, ցանցայինները՝ անջատիչներ և երթուղիչներ: Երբեմն վարչակազմը վատն է, և ամեն ինչ փլուզվում է բոլորի համար: Դե ինչ տարօրինակ բանի դեպքում մեղավոր են նաև ցանցառները։ Պարզապես այն պատճառով, որ քեզ ջղայնացնեմ, դրա համար:
Իրականում հիմնական տարբերությունը աշխատանքի նկատմամբ մոտեցումն է։ Հավանաբար, ցանցայինների շրջանում է, որ «Եթե այն աշխատում է, մի՛ դիպչեք» մոտեցման ամենաշատ կողմնակիցներն են: Որպես կանոն, ինչ-որ բան կարելի է անել (մեկ վաճառողի ներսում) միայն մեկ եղանակով. տուփի ամբողջ կոնֆիգուրացիան գտնվում է հենց ձեր ձեռքի ափի մեջ: Սխալի արժեքը բարձր է, և երբեմն շատ բարձր (օրինակ, երթուղիչը վերագործարկելու համար ստիպված կլինեք ճանապարհորդել մի քանի հարյուր կիլոմետր, և այս պահին մի քանի հազար մարդ կմնա առանց կապի. հեռահաղորդակցության օպերատորի համար բավականին տարածված իրավիճակ): .
Իմ կարծիքով, սա է պատճառը, որ ցանցային ինժեներները, մի կողմից, չափազանց մոտիվացված են ցանցի կայունության համար (իսկ փոփոխությունը կայունության գլխավոր թշնամին է), և երկրորդ՝ նրանց գիտելիքներն ավելի խորն են, քան լայնությունը (դուք չեք դուք պետք է կարողանաք կարգավորել տասնյակ տարբեր դևերներ, դուք պետք է իմանաք տեխնոլոգիաները և դրանց իրականացումը կոնկրետ սարքավորումների արտադրողի կողմից): Ահա թե ինչու համակարգի ադմինիստրատորը, ով google-ում փնտրել է, թե ինչպես գրանցել vlan Cisco համակարգում, դեռ ցանցային չէ: Եվ քիչ հավանական է, որ նա կարողանա արդյունավետորեն աջակցել (ինչպես նաև շտկել) քիչ թե շատ բարդ ցանցը:
Բայց ինչո՞ւ է ձեզ հարկավոր ցանցային աշխատող, եթե ունեք հոսթեր:
Լրացուցիչ գումարի համար (և եթե դուք շատ մեծ և սիրելի հաճախորդ եք, գուցե նույնիսկ անվճար, «որպես ընկեր»), տվյալների կենտրոնի ինժեներները կկազմաձևեն ձեր անջատիչները ձեր կարիքներին համապատասխան, և գուցե նույնիսկ կօգնեն ձեզ ստեղծել BGP ինտերֆեյս պրովայդերների հետ: (եթե դուք ունեք IP հասցեների ձեր սեփական ենթացանցը հայտարարության համար):
Հիմնական խնդիրն այն է, որ տվյալների կենտրոնը ձեր ՏՏ բաժինը չէ, այն առանձին ընկերություն է, որի նպատակը շահույթ ստանալն է։ Այդ թվում՝ ձեր՝ որպես հաճախորդի հաշվին։ Տվյալների կենտրոնը տրամադրում է դարակաշարեր, ապահովում է նրանց էլեկտրաէներգիա և ցուրտ, ինչպես նաև ապահովում է որոշակի «կանխադրված» կապ ինտերնետին: Այս ենթակառուցվածքի հիման վրա տվյալների կենտրոնը կարող է հյուրընկալել ձեր սարքավորումը (կոլոկացում), ձեզ վարձակալել սերվեր (նվիրված սերվեր) կամ տրամադրել կառավարվող ծառայություն (օրինակ՝ OpenStack կամ K8s): Բայց տվյալների կենտրոնի բիզնեսը (սովորաբար) հաճախորդի ենթակառուցվածքի կառավարումը չէ, քանի որ այս գործընթացը բավականին աշխատատար է, վատ ավտոմատացված (և նորմալ տվյալների կենտրոնում այն ամենը, ինչ հնարավոր է ավտոմատացված է), միավորված նույնիսկ ավելի վատ (յուրաքանչյուր հաճախորդ): անհատական է) և, ընդհանուր առմամբ, հղի է բողոքներով («դու ինձ ասում ես, որ սերվերը կարգավորվել է, բայց հիմա այն խափանվել է, ամեն ինչ քո մեղքն է!!!111»): Հետևաբար, եթե հյուրընկալողը ձեզ ինչ-որ բանում օգնի, նա կփորձի այն հնարավորինս պարզ և հարմարավետ դարձնել: Որովհետև դժվար անելն անշահավետ է, համենայն դեպս, այս նույն հոսթերի ինժեներների աշխատանքային ծախսերի տեսանկյունից (բայց իրավիճակները տարբեր են, տե՛ս հերքումը): Սա չի նշանակում, որ հյուրընկալողը անպայման ամեն ինչ վատ կանի։ Բայց ամենևին էլ փաստ չէ, որ նա կանի հենց այն, ինչ ձեզ իսկապես անհրաժեշտ էր:
Թվում է, թե բանը միանգամայն ակնհայտ է, բայց մի քանի անգամ իմ պրակտիկայում ես հանդիպել եմ այն փաստի, որ ընկերությունները սկսեցին ապավինել իրենց հոսթինգ մատակարարին մի փոքր ավելի, քան պետք է, և դա ոչ մի լավ բանի չհանգեցրեց: Ես ստիպված էի երկար և մանրամասն բացատրել, որ ոչ մի SLA չի ծածկի վնասները, որոնք առաջանում են պարապուրդից (կան բացառություններ, բայց սովորաբար դա շատ, ՇԱՏ թանկ է հաճախորդի համար), և որ հյուրընկալողը ընդհանրապես տեղյակ չէ, թե ինչ է կատարվում հաճախորդների ենթակառուցվածքը (բացառությամբ շատ ընդհանուր ցուցանիշների): Եվ հոսթերը նույնպես ձեզ համար կրկնօրինակներ չի ստեղծում: Իրավիճակն ավելի վատ է, եթե դուք ունեք մեկից ավելի հյուրընկալող: Նրանց միջև որևէ խնդրի դեպքում նրանք, անշուշտ, ձեզ համար չեն պարզի, թե ինչն է սխալ եղել։
Իրականում, այստեղ շարժառիթները ճիշտ նույնն են, ինչ «ներքին ադմինիստրատորի թիմն ընդդեմ աութսորսի» ընտրության ժամանակ: Եթե ռիսկերը հաշվարկված են, որակը գոհացուցիչ է, իսկ բիզնեսը դեմ չէ, ինչու չփորձել: Մյուս կողմից, ցանցը ենթակառուցվածքի ամենահիմնական շերտերից մեկն է, և դժվար թե արժե այն թողնել դրսի տղաներին, եթե դուք արդեն աջակցում եք մնացած ամեն ինչին:
Ո՞ր դեպքերում է անհրաժեշտ ցանցային աշխատող:
Հաջորդիվ կխոսենք հատկապես ժամանակակից սննդամթերք արտադրող ընկերությունների մասին։ Օպերատորների և ձեռնարկությունների հետ ամեն ինչ պարզ է, գումարած կամ մինուս. վերջին տարիներին այնտեղ քիչ բան է փոխվել, և ցանցային աշխատողներ նախկինում անհրաժեշտ էին այնտեղ, և նրանք այժմ անհրաժեշտ են: Բայց այդ նույն «երիտասարդ ու համարձակ» դեպքում ամեն ինչ այնքան էլ պարզ չէ։ Հաճախ նրանք իրենց ամբողջ ենթակառուցվածքը տեղադրում են ամպերի մեջ, այնպես որ նրանք իրականում ադմինների կարիք չունեն, իհարկե, բացի այդ նույն ամպերի ադմիններից: Ենթակառուցվածքը մի կողմից բավականին պարզ է իր դիզայնով, մյուս կողմից՝ լավ ավտոմատացված (ansible/puppet, terraform, ci/cd... դե գիտեք)։ Բայց նույնիսկ այստեղ կան իրավիճակներ, երբ դուք չեք կարող անել առանց ցանցային ինժեների:
Օրինակ 1, դասական
Ենթադրենք, ընկերությունը սկսում է մեկ սերվերով հանրային IP հասցեով, որը գտնվում է տվյալների կենտրոնում։ Այնուհետև կան երկու սերվեր: Հետո ավելին... Վաղ թե ուշ սերվերների միջև մասնավոր ցանցի կարիք կառաջանա։ Քանի որ «արտաքին» տրաֆիկը սահմանափակված է և՛ թողունակությամբ (օրինակ՝ 100 Մբիթ/վրկ-ից ոչ ավելի), և՛ ամսական ներբեռնվող/վերբեռնված ծավալով (տարբեր հոսթերները տարբեր սակագներ ունեն, բայց դեպի արտաքին աշխարհ թողունակությունը սովորաբար շատ ավելի թանկ է, քան մասնավոր ցանց):
Հոսթերը սերվերներին ավելացնում է լրացուցիչ ցանցային քարտեր և դրանք ներառում է իրենց անջատիչների մեջ առանձին vlan-ում: Սերվերների միջև հայտնվում է «հարթ» տեղական տարածք: Հարմարավետ!
Աճում է սերվերների թիվը, աճում է նաև մասնավոր ցանցի տրաֆիկը` կրկնօրինակումներ, կրկնօրինակումներ և այլն: Հոսթերն առաջարկում է ձեզ տեղափոխել առանձին անջատիչներ, որպեսզի դուք չխանգարեք այլ հաճախորդներին, և նրանք չխանգարեն ձեզ: Հոսթերը տեղադրում է որոշ անջատիչներ և ինչ-որ կերպ կարգավորում դրանք, ամենայն հավանականությամբ, թողնելով մեկ հարթ ցանց ձեր բոլոր սերվերների միջև: Ամեն ինչ լավ է աշխատում, բայց ինչ-որ պահի խնդիրներ են սկսվում. հոսթերների միջև ուշացումները պարբերաբար մեծանում են, տեղեկամատյանները բողոքում են վայրկյանում չափազանց շատ arp փաթեթների մասին, և աուդիտի ժամանակ pentester-ը ջարդել է ձեր ամբողջ տեղական ցանցը՝ կոտրելով միայն մեկ սերվեր:
Ինչ պետք է անեմ:
Ցանցը բաժանեք հատվածների՝ վլանների։ Կազմաձևեք ձեր սեփական հասցեները յուրաքանչյուր vlan-ում, ընտրեք դարպաս, որը կփոխանցի երթևեկությունը ցանցերի միջև: Կարգավորեք acl-ը դարպասի վրա՝ սահմանափակելու մուտքը հատվածների միջև կամ նույնիսկ մոտակայքում առանձին firewall տեղադրելու համար:
Օրինակ 1, շարունակություն
Սերվերները միացված են LAN-ին մեկ լարով։ Դարակաշարերի անջատիչները ինչ-որ կերպ կապված են միմյանց հետ, բայց եթե մեկ դարակում վթար է տեղի ունենում, ևս երեք հարակիցները ընկնում են: Սխեմաներ կան, բայց կասկածներ կան դրանց արդիականության վերաբերյալ: Յուրաքանչյուր սերվեր ունի իր հանրային հասցեն, որը թողարկվում է հոսթերի կողմից և կապված է դարակին: Նրանք. Սերվեր տեղափոխելիս հասցեն պետք է փոխվի:
Ինչ պետք է անեմ:
Միացրեք սերվերները՝ օգտագործելով LAG (Link Aggregation Group) երկու լարերով դարակի անջատիչներին (դրանք նույնպես պետք է ավելորդ լինեն): Պահպանեք դարակների միջև կապերը և դրանք դարձրեք «աստղի» (կամ այժմ նորաձև CLOS), որպեսզի մի դարակի կորուստը չազդի մյուսների վրա: Ընտրեք «կենտրոնական» դարակաշարեր, որոնցում կտեղակայվի ցանցի միջուկը և որտեղ միացված կլինեն այլ դարակաշարեր: Միևնույն ժամանակ, կարգի բերեք հանրային հասցեները, վերցրեք հոսթերից (կամ RIR-ից, եթե հնարավոր է) ենթացանց, որը դուք ինքներդ (կամ հոսթերի միջոցով) հայտարարում եք աշխարհին։
Կարո՞ղ է այս ամենը անել «սովորական» համակարգի ադմինիստրատորը, ով չունի ցանցերի խորը գիտելիքներ։ Վստահ չեմ. Արդյո՞ք հյուրընկալողը դա կանի: Միգուցե դա կլինի, բայց ձեզ անհրաժեշտ կլինի բավականին մանրամասն տեխնիկական բնութագրում, որը ինչ-որ մեկին նույնպես պետք է կազմի: և հետո ստուգեք, որ ամեն ինչ ճիշտ է արված:
Օրինակ 2. Ամպ
Ենթադրենք, դուք ունեք VPC որոշ հանրային ամպի մեջ: Գրասենյակից կամ ենթակառուցվածքի նախնական մասից VPC-ի ներսում տեղական ցանց մուտք ստանալու համար դուք պետք է կարգավորեք կապը IPSec-ի կամ հատուկ ալիքի միջոցով: Մի կողմից, IPSec-ն ավելի էժան է, քանի որ կարիք չկա լրացուցիչ սարքավորումներ գնել, դուք կարող եք թունել ստեղծել ձեր սերվերի միջև հանրային հասցեով և ամպի հետ: Բայց - ուշացումներ, սահմանափակ կատարում (քանի որ ալիքը պետք է գաղտնագրվի), գումարած չերաշխավորված կապ (քանի որ մուտքը սովորական ինտերնետի միջոցով է):
Ինչ պետք է անեմ:
Բարձրացրեք կապը հատուկ ալիքի միջոցով (օրինակ, AWS-ն այն անվանում է Direct Connect): Դա անելու համար գտեք գործընկեր օպերատոր, ով կկապի ձեզ, կորոշի ձեզ ամենամոտ միացման կետը (և՛ դուք օպերատորին, և՛ օպերատորին՝ ամպին), և վերջապես, ամեն ինչ կկարգավորի: Հնարավո՞ր է այս ամենը անել առանց ցանցային ինժեների։ Անշուշտ այո։ Բայց ինչպես լուծել խնդիրները առանց նրա խնդիրների դեպքում, այլևս այնքան էլ պարզ չէ:
Կարող են լինել նաև ամպերի միջև առկա հասանելիության հետ կապված խնդիրներ (եթե դուք ունեք բազմաամպ) կամ տարբեր շրջանների միջև ուշացումների հետ կապված խնդիրներ և այլն: Իհարկե, հիմա շատ գործիքներ են հայտնվել, որոնք մեծացնում են ամպում կատարվողի թափանցիկությունը (նույն Հազար աչքերը), բայց սրանք բոլորը ցանցային ինժեների գործիքներն են, այլ ոչ թե նրան փոխարինող։
Ես կարող էի ուրվագծել ևս մեկ տասնյակ նման օրինակներ իմ պրակտիկայից, բայց կարծում եմ, որ պարզ է, որ թիմը, սկսած ենթակառուցվածքի զարգացման որոշակի մակարդակից, պետք է ունենա մարդ (ցանկալի է մեկից ավելի), ով գիտի, թե ինչպես է աշխատում ցանցը և կարող է կարգավորել: ցանցային սարքավորումներ և լուծել խնդիրները, եթե դրանք առաջանան: Հավատացեք, նա անելիք կունենա
Ի՞նչ պետք է իմանա ցանցային աշխատողը:
Ցանցային ինժեների համար ամենևին էլ պարտադիր չէ (և նույնիսկ երբեմն վնասակար) միայն ցանցի հետ գործ ունենալը և ուրիշ ոչինչ։ Նույնիսկ եթե մենք չդիտարկենք այն ենթակառուցվածքի տարբերակը, որը գրեթե ամբողջությամբ ապրում է հանրային ամպի մեջ (և, ինչ էլ որ ասի, այն դառնում է ավելի ու ավելի տարածված), և վերցնենք, օրինակ, տարածքային կամ մասնավոր ամպերի վրա, որտեղ «CCNP- մակարդակի գիտելիք մենակ» մասին «Դուք չեք հեռանա.
Ի հավելումն, ըստ էության, ցանցերի, թեև ուսումնասիրության համար պարզապես անսահման դաշտ կա, նույնիսկ եթե դուք կենտրոնանաք միայն մեկ տարածքի վրա (մատակարար ցանցեր, ձեռնարկություններ, տվյալների կենտրոններ, Wi-Fi ...)
Իհարկե, ձեզնից շատերն այժմ կհիշեն Python-ը և այլ «ցանցային ավտոմատացում», բայց դա միայն անհրաժեշտ, բայց ոչ բավարար պայման է։ Որպեսզի ցանցային ինժեները «հաջողությամբ միանա թիմին», նա պետք է կարողանա խոսել նույն լեզվով ինչպես մշակողների, այնպես էլ գործընկեր ադմինիստրատորների/մշակողների հետ: Ինչ է դա նշանակում?
- կարողանալ ոչ միայն աշխատել Linux-ում որպես օգտատեր, այլ նաև կառավարել այն, գոնե sysadmin-jun մակարդակով. տեղադրել անհրաժեշտ ծրագրակազմը, վերագործարկել ձախողված ծառայությունը, գրել պարզ systemd-unit:
- Հասկացեք (գոնե ընդհանուր տերմիններով), թե ինչպես է աշխատում ցանցային ստեկը Linux-ում, ինչպես է ցանցն աշխատում հիպերվիզորներում և կոնտեյներներում (lxc / docker / kubernetes):
- Իհարկե, կարողանալ աշխատել ansible/chef/puppet կամ այլ SCM համակարգի հետ:
- Առանձին տող պետք է գրվի SDN-ի և մասնավոր ամպերի ցանցերի մասին (օրինակ՝ TungstenFabric կամ OpenvSwitch): Սա գիտելիքի ևս մեկ հսկայական շերտ է:
Մի խոսքով, ես նկարագրեցի T-ի տիպիկ մասնագետի (ինչպես հիմա մոդա է ասել): Թվում է, թե նորություն չէ, բայց հարցազրույցի փորձի հիման վրա ոչ բոլոր ցանցային ինժեներները կարող են պարծենալ վերը նշված ցանկից առնվազն երկու թեմաների իմացությամբ: Գործնականում «հարակից ոլորտներում» գիտելիքների պակասը շատ դժվար է դարձնում ոչ միայն գործընկերների հետ շփումը, այլև հասկանալ այն պահանջները, որոնք բիզնեսը դնում է ցանցում՝ որպես ծրագրի ամենացածր մակարդակի ենթակառուցվածք: Եվ առանց այս ըմբռնման, ավելի դժվար է դառնում պաշտպանել ձեր տեսակետը և այն «վաճառել» բիզնեսին։
Մյուս կողմից, «հասկանալու, թե ինչպես է համակարգը աշխատում» նույն սովորությունը ցանցային աշխատողներին շատ լավ առավելություն է տալիս տարբեր «գեներալիստների» նկատմամբ, ովքեր գիտեն տեխնոլոգիաների մասին Habré/medium-ի հոդվածներից և Telegram-ում զրույցներից, բայց բացարձակապես չեն պատկերացնում, թե ինչ անել: սկզբունքով է աշխատում այս կամ այն ծրագրաշարը: Իսկ որոշակի օրինաչափությունների իմացությունը, ինչպես հայտնի է, հաջողությամբ փոխարինում է բազմաթիվ փաստերի իմացությանը։
Եզրակացություններ, կամ պարզապես TL;DR
- Ցանցի ադմինիստրատորը (ինչպես DBA կամ VoIP ինժեները) բավականին նեղ պրոֆիլով մասնագետ է (ի տարբերություն համակարգի ադմինիստրատորների/devs/SRE-ի), որի անհրաժեշտությունը անմիջապես չի առաջանում (և իրականում երկար ժամանակ կարող է չառաջանալ): . Բայց եթե այն իսկապես առաջանա, դժվար թե այն փոխարինվի արտաքին փորձով (աութսորսինգ կամ սովորական ընդհանուր նշանակության ադմինիստրատորներ, «որոնք նաև հոգ են տանում ցանցի մասին»): Ավելի ցավալին այն է, որ նման մասնագետների կարիքը փոքր է, և, պայմանականորեն, 800 ծրագրավորող և 30 devop/ադմինիստրատոր ունեցող ընկերությունում կարող են լինել միայն երկու ցանցային աշխատող, ովքեր իրենց պարտականություններով գերազանց են կատարում: Նրանք. շուկան շատ ու շատ փոքր էր ու կա, իսկ լավ աշխատավարձով` էլ ավելի քիչ:
- Մյուս կողմից, ժամանակակից աշխարհում լավ ցանցագործը պետք է իմանա ոչ միայն ցանցերն իրենք (և ինչպես ավտոմատացնել դրանց կոնֆիգուրացիան), այլ նաև, թե ինչպես են այդ ցանցերի վերևում աշխատող օպերացիոն համակարգերը և ծրագրերը փոխազդում դրանց հետ: Առանց դրա չափազանց դժվար կլինի հասկանալ, թե ինչ են խնդրում ձեր գործընկերները ձեզանից և ձեր ցանկությունները/պահանջները (հիմնավոր կերպով) փոխանցել նրանց:
- Ամպ չկա, դա պարզապես ուրիշի համակարգիչն է: Դուք պետք է հասկանաք, որ հանրային/մասնավոր ամպերի կամ հոսթինգ մատակարարի ծառայությունների օգտագործումը, «որը ձեզ համար ամեն ինչ անում է բանտի հիմունքներով» չի փոխում այն փաստը, որ ձեր հավելվածը դեռ օգտագործում է ցանցը, և դրա հետ կապված խնդիրները կազդեն դրա աշխատանքի վրա։ ձեր դիմումը. Ձեր ընտրությունն այն է, թե որտեղ կտեղակայվի իրավասությունների կենտրոնը, որը պատասխանատու կլինի ձեր նախագծի ցանցի համար:
Source: www.habr.com