Ի՞նչ է անհրաժեշտ ՏՏ ընկերությանը 2019 թվականին հաջողակ լինելու համար: Կոնֆերանսների և հանդիպումների դասախոսները շատ ամպագոռգոռ խոսքեր են ասում, որոնք միշտ չէ, որ հասկանալի են նորմալ մարդկանց: Պայքար տեղակայման ժամանակի, միկրոծառայությունների, մոնոլիտից հրաժարվելու, DevOps-ի վերափոխման և շատ ու շատ ավելին: Եթե մենք հրաժարվենք խոսքային գեղեցկությունից և խոսենք ուղղակիորեն և ռուսերենով, ապա ամեն ինչ հանգում է մի պարզ թեզի. պատրաստել բարձրորակ արտադրանք և դա անել թիմի համար հարմարավետությամբ:
Վերջինս դարձել է կրիտիկական կարևորություն։ Բիզնեսը վերջապես եկել է այն եզրակացության, որ հարմարավետ զարգացման գործընթացը մեծացնում է արտադրողականությունը, և եթե ամեն ինչ կարգաբերվում է և աշխատում է ժամացույցի պես, դա նաև որոշակի մանևրելու տեղ է տալիս կրիտիկական իրավիճակներում: Ժամանակին, հանուն այս մանևրի, ինչ-որ խելացի մարդ հանդես եկավ կրկնօրինակներով, բայց ոլորտը զարգանում է, և մենք հասանք DevOps-ի ինժեներներին. կապ չունի շամանիզմի հետ։
Այս ամբողջ «մոդուլային» պատմությունը հիասքանչ է, բայց... Պատահեց, որ ադմիններից ոմանց կտրուկ անվանեցին DevOps, և DevOps-ի ինժեներներից իրենք սկսեցին պահանջել գոնե հեռատեսության և պայծառատեսության հմտություններ ունենալ:
Նախքան ենթակառուցվածքների ապահովման ժամանակակից խնդիրների մասին խոսելը, եկեք պարզենք, թե ինչ ենք հասկանում այս տերմինով։ Ներկա պահին իրավիճակն այնպես է զարգացել, որ մենք հասել ենք այս հայեցակարգի երկակիությանը՝ ենթակառուցվածքները կարող են լինել պայմանականորեն արտաքին և պայմանականորեն ներքին։
Արտաքին ենթակառուցվածք ասելով մենք հասկանում ենք այն ամենը, ինչ ապահովում է ծառայության կամ արտադրանքի ֆունկցիոնալությունը, որը մշակում է թիմը: Դրանք հավելվածների կամ կայքերի սերվերներ են, հոսթինգ և այլ ծառայություններ, որոնք ապահովում են արտադրանքի ֆունկցիոնալությունը:
Ներքին ենթակառուցվածքը ներառում է ծառայություններ և սարքավորումներ, որոնք օգտագործվում են հենց զարգացման թիմի և այլ աշխատակիցների կողմից, որոնցից սովորաբար շատ են: Սրանք կոդերի պահպանման համակարգերի ներքին սերվերներ են, տեղակայված առաջադրանքների կառավարիչ և ամեն ինչ, ամեն ինչ, այն ամենը, ինչ գոյություն ունի կորպորատիվ ինտրանետում:
Ի՞նչ է անում համակարգային ադմինիստրատորը ընկերությունում: Ի հավելումն այս կորպորատիվ ներքին ցանցի կառավարման աշխատանքին, այն հաճախ կրում է տնտեսական մտահոգությունների բեռը՝ ապահովելու գրասենյակային սարքավորումների գործունակությունը: Ադմինը նույն տղան է, ով արագորեն հետի սենյակից կքաշի նոր համակարգային միավորը կամ օգտագործման համար պատրաստ պահեստային նոութբուքը, կտա թարմ ստեղնաշար և չորս ոտքերով սողում է գրասենյակներում՝ ձգելով Ethernet մալուխը: Ադմինիստրատորը ոչ միայն ներքին և արտաքին սերվերների տեղական սեփականատերն ու տիրակալն է, այլև բիզնեսի ղեկավարը: Այո, որոշ ադմինիստրատորներ կարող են աշխատել միայն համակարգի հարթությունում, առանց սարքաշարի: Նրանք պետք է բաժանվեն «ենթակառուցվածքային համակարգի ադմինիստրատորների» առանձին ենթադասում։ Իսկ ոմանք մասնագիտանում են բացառապես գրասենյակային սարքավորումների սպասարկման մեջ, բարեբախտաբար, եթե ընկերությունն ունի հարյուրից ավելի մարդ, ապա աշխատանքը երբեք չի ավարտվում։ Բայց նրանցից ոչ մեկը դեվոպ չի:
Ովքե՞ր են DevOps-ը: Devops-ը տղաներ են, ովքեր խոսում են արտաքին ենթակառուցվածքի հետ ծրագրային ապահովման մշակման փոխազդեցության մասին: Ավելի ճիշտ, ժամանակակից devop-ները ներգրավված են զարգացման և տեղակայման գործընթացներում շատ ավելի խորը, քան երբևէ ներգրավված են եղել ադմինները, ովքեր պարզապես թարմացումներ են բեռնել ftp-ում: Այժմ DevOps-ի ինժեների հիմնական խնդիրներից մեկը մշակող թիմերի և արտադրանքի ենթակառուցվածքի միջև փոխգործակցության հարմարավետ և արդյունավետ կառուցվածքային գործընթաց ապահովելն է: Հենց այս մարդիկ են պատասխանատու հետադարձ և տեղակայման համակարգերի տեղակայման համար, հենց այս մարդիկ են վերցնում ծրագրավորողների բեռի մի մասը և հնարավորինս կենտրոնանում իրենց չափազանց կարևոր առաջադրանքի վրա: Միևնույն ժամանակ, devops-ը երբեք չի գործարկի նոր մալուխ կամ նոր նոութբուք թողարկի հետևի սենյակից (c) KO
Որն է բռնել:
«Ո՞վ է DevOps» հարցին: Ոլորտի աշխատողների կեսը սկսում է պատասխանել «Դե, մի խոսքով, սա այն ադմինն է, ով ...» և տեքստում ավելի ուշ: Այո, ժամանակին, երբ DevOps-ի ինժեների մասնագիտությունը նոր էր առաջանում սպասարկման սպասարկման առումով ամենատաղանդավոր ադմինիստրատորներից, նրանց միջև եղած տարբերություններն ակնհայտ չէին բոլորի համար։ Բայց հիմա, երբ թիմում devops-ի և admin-ի գործառույթներն արմատապես տարբերվել են, անընդունելի է նրանց շփոթել միմյանց հետ կամ նույնիսկ նույնացնել։
Բայց ի՞նչ է սա նշանակում բիզնեսի համար:
Աշխատանքի ընդունում, ամեն ինչ դրա մասին է:
Դուք բացում եք «Համակարգի ադմինիստրատորի» թափուր աշխատատեղ, և այնտեղ թվարկված պահանջներն են՝ «փոխգործակցություն զարգացման և հաճախորդների հետ», «CI/CD առաքման համակարգ», «ընկերության սերվերների և սարքավորումների սպասարկում», «ներքին համակարգերի կառավարում» և այլն։ վրա; հասկանում ես, որ գործատուն անհեթեթություն է խոսում. Բռնությունն այն է, որ «System Administrator»-ի փոխարեն թափուր աշխատատեղի անվանումը պետք է լինի «DevOps Engineer», իսկ եթե այս վերնագիրը փոխվի, ապա ամեն ինչ իր տեղը կընկնի։
Այնուամենայնիվ, ի՞նչ տպավորություն է ստեղծվում նման թափուր աշխատատեղ կարդալիս։ Որ ընկերությունը փնտրում է մի քանի մեքենաների օպերատոր, ով կտեղակայի և՛ տարբերակի վերահսկման, և՛ մոնիտորինգի համակարգ և ատամներով կսեղմի պտույտը...
Բայց աշխատաշուկայում թմրամոլության աստիճանը չբարձրացնելու համար բավական է թափուր աշխատատեղերն անվանել իրենց համապատասխան անուններով և հստակ հասկանալ, որ DevOps-ի ինժեները և համակարգի ադմինիստրատորը երկու տարբեր սուբյեկտներ են: Բայց որոշ գործատուների անզուսպ ցանկությունը՝ թեկնածուին ներկայացնելու պահանջների հնարավորինս լայն ցանկը, հանգեցնում է նրան, որ «դասական» համակարգի ադմինիստրատորները դադարում են հասկանալ, թե ինչ է կատարվում իրենց շուրջը: Ի՞նչ է, մասնագիտությունը մուտացիայի է ենթարկվում, և նրանք ժամանակից հետ են մնում։
Ոչ ոչ և ևս մեկ անգամ ոչ: Ենթակառուցվածքի ադմինիստրատորները, ովքեր կկառավարեն ընկերության ներքին սերվերները կամ կզբաղեցնեն L2/L3 աջակցության դիրքերը և կօգնեն այլ աշխատակիցներին, չեն հեռացել և չեն պատրաստվում հեռանալ:
Կարո՞ղ են այս մասնագետները դառնալ DevOps-ի ինժեներներ: Իհարկե կարող են։ Իրականում, սա հարակից միջավայր է, որը պահանջում է համակարգի կառավարման հմտություններ, բայց դրան գումարվում է մոնիտորինգի, առաքման համակարգերի հետ աշխատանքը և, ընդհանուր առմամբ, սերտ փոխգործակցությունը զարգացման և թեստավորման թիմի հետ:
DevOps-ի ևս մեկ խնդիր
Փաստորեն, ամեն ինչ չի սահմանափակվում միայն աշխատանքի ընդունելով և ադմինների և devops-ի միջև մշտական խառնաշփոթով: Ինչ-որ պահի բիզնեսը բախվեց թարմացումների մատուցման և զարգացման թիմի վերջնական ենթակառուցվածքի հետ փոխգործակցության խնդրի հետ:
Հավանաբար դա այն ժամանակ էր, երբ շողշողացող աչքերով հորեղբայրը կանգնեց ինչ-որ համաժողովի բեմի վրա և ասաց. «Մենք դա անում ենք և այն անվանում ենք DevOps: Այս տղաները կլուծեն ձեր բոլոր խնդիրները», - և սկսեց պատմել, թե որքան լավ է կյանքը ընկերությունում DevOps-ի պրակտիկա իրականացնելուց հետո:
Այնուամենայնիվ, բավարար չէ DevOps-ի ինժեներ վարձելը, որպեսզի ամեն ինչ աշխատի այնպես, ինչպես պետք է: Ընկերությունը պետք է կատարի DevOps-ի ամբողջական վերափոխում, այսինքն՝ մեր DevOps-ի դերն ու հնարավորությունները պետք է հստակորեն հասկանալի լինեն նաև արտադրանքի մշակման և փորձարկման թիմի կողմից: Այս թեմայով մենք ունենք մի «հրաշալի» պատմություն, որը լիովին ցույց է տալիս այն ողջ դաժանությունը, որը տեղի է ունենում որոշ վայրերում:
Իրավիճակը. DevOps-ից պահանջվում է տարբերակի վերադարձման համակարգ տեղակայելու համար՝ առանց խորամուխ լինելու, թե ինչպես է այն աշխատելու: Ենթադրենք, որ Users համակարգում կան անուն, ազգանուն և գաղտնաբառի առանձին դաշտեր։ Արտադրանքի նոր տարբերակը դուրս է գալիս, բայց մշակողների համար «վերադարձը» պարզապես կախարդական փայտիկ է, որը կշտկի ամեն ինչ, և նրանք նույնիսկ չգիտեն, թե ինչպես է այն աշխատում: Այսպիսով, օրինակ, հաջորդ կարկատում ծրագրավորողները միավորեցին անուն և ազգանվան դաշտերը, այն դուրս բերեցին արտադրության մեջ, բայց տարբերակը ինչ-ինչ պատճառներով դանդաղ է: Ինչ է կատարվում? Ղեկավարությունը գալիս է devops և ասում «Քաշիր անջատիչը», այսինքն՝ խնդրում է նրան վերադառնալ նախորդ տարբերակին: Ի՞նչ է անում devops-ը: Այն վերադառնում է նախորդ տարբերակին, բայց քանի որ մշակողները չէին ցանկանում պարզել, թե ինչպես է կատարվել այս վերադարձը, ոչ ոք չասաց devops թիմին, որ տվյալների բազան նույնպես պետք է հետ վերադարձվի: Արդյունքում մեզ մոտ ամեն ինչ խափանում է, և դանդաղ կայքի փոխարեն օգտատերերը տեսնում են «500» սխալ, քանի որ հին տարբերակը չի աշխատում նոր տվյալների բազայի դաշտերի հետ։ Devops-ը չգիտի այս մասին: Մշակողները լռում են. Ղեկավարությունը սկսում է կորցնել նյարդերն ու փողը և հիշում է կրկնօրինակները՝ առաջարկելով հետ գցել դրանցից, որպեսզի «գոնե ինչ-որ բան ստացվի»։ Արդյունքում, օգտվողները կորցնում են իրենց բոլոր տվյալները որոշակի ժամանակահատվածում:
Ընկույզները, իհարկե, գնում են devops-ին, որը «չստեղծեց պատշաճ հետադարձ համակարգ», և ոչ ոքի չի հետաքրքրում, որ այս պատմության մոզերը մշակողներ են:
Եզրակացությունը պարզ է. առանց DevOps-ին որպես այդպիսին նորմալ մոտեցման, այն քիչ օգուտ ունի:
Հիմնական բանը, որ պետք է հիշել. DevOps-ի ինժեները հրաշագործ չէ, և առանց որակյալ հաղորդակցության և զարգացման հետ երկկողմանի փոխազդեցության, նա չի հաղթահարի իր առաջադրանքները: Dev-ներին չի կարելի մենակ թողնել իրենց «խնդիրների» հետ կամ հրաման տալ «մի խառնվեք մշակողների հետ, նրանց գործը կոդավորումն է», և հետո հուսալ, որ կրիտիկական պահին ամեն ինչ կաշխատի այնպես, ինչպես պետք է: Այդպես չի աշխատում:
Ըստ էության, DevOps-ը իրավասություն է կառավարման և տեխնոլոգիայի միջև սահմանին: Ավելին, ակնհայտ չէ, որ այս կոկտեյլում պետք է լինի ավելի շատ տեխնոլոգիա, քան կառավարում: Եթե դուք իսկապես ցանկանում եք կառուցել ավելի արագ և արդյունավետ զարգացման գործընթացներ, դուք պետք է վստահեք ձեր devops թիմին: Նա գիտի ճիշտ գործիքները, նա նմանատիպ նախագծեր է իրականացրել, գիտի, թե ինչպես դա անել։ Օգնեք նրան, լսեք նրա խորհուրդները, մի փորձեք մեկուսացնել նրան ինչ-որ ինքնավար միավորում: Եթե ադմինները կարող են ինքնուրույն աշխատել, ապա devops-ն այս դեպքում անօգուտ է, նրանք չեն կարողանա օգնել ձեզ դառնալ ավելի լավը, եթե դուք ինքներդ չեք ցանկանում ընդունել այս օգնությունը:
Եվ վերջին բանը՝ դադարեցրեք ենթակառուցվածքի ադմինիստրատորներին վիրավորելը: Նրանք ունեն իրենց սեփական, չափազանց կարևոր աշխատանքային ճակատը։ Այո, ադմինիստրատորը կարող է դառնալ DevOps-ի ինժեներ, բայց դա պետք է տեղի ունենա հենց անձի խնդրանքով, այլ ոչ թե ճնշման տակ։ Եվ ոչ մի վատ բան չկա, որ համակարգային ադմինիստրատորը ցանկանում է մնալ համակարգային ադմինիստրատոր՝ սա նրա առանձին մասնագիտությունն է և իրավունքը։ Եթե ցանկանում եք մասնագիտական վերափոխման ենթարկվել, ապա երբեք չպետք է մոռանաք, որ դուք պետք է զարգացնեք ոչ միայն տեխնոլոգիական, այլև կառավարման հմտություններ: Ամենայն հավանականությամբ, ձեզնից կախված կլինի՝ որպես առաջնորդի, հավաքել այս բոլոր մարդկանց և սովորեցնել նրանց շփվել նույն լեզվով:
Source: www.habr.com