Ինչպես է OpenShift-ը փոխում ՏՏ կազմակերպությունների կառավարման կառուցվածքը: Տնտեսական մոդելների զարգացումներ PaaS բջջերի տեղափոխման գործընթացում

Չնայած PaaS (ծառայություն որպես հարթակ) լուծումների ինքնին չի կարող փոխել անհատի և թիմի համագործակցության ձևերը, նրանք հաճախ ծառայում են որպես կազմակերպական փոփոխությունների katalizator, պատասխանելով IT տեխնոլոգիաների աճող ճկնության վրա:

Իրականում PaaS-ում ներդրումներից առավելագույն օգուտ ստանալ հնարավոր է միայն այն դեպքում, երբ կազմակերպական դերերը, պատասխանատվությունների ոլորտները (պատասխանատվությունները) և հարաբերությունների սխեմաները փոփոխվում են: Բախտի վրա, PaaS լուծումները, ինչպիսիք են OpenShift Container Platform, բավականաչափ ճկունություն են ունենում, որպեսզի յուրաքանչյուր IT կազմակերպություն կարողանա ինքնուրույն որոշել փոփոխությունների արագությունը և չափսերը՝ կապված ներգրավված մարդկանց և ընթացող գործընթացների հետ:

Ընկերության առաջին մակարդակի կոնտեյներիզացման ընթացքում առաջնային կարևորությունը կոնտեյների հարթակի ներդրումն է որպես նոր դիմումների տեղադրման համակարգ: Այս պահին կազմակերպությունները սովորական աշխատանքները կապում են սովորական դերերին, որպեսզի արձագանքեն զարգացման թիմերի ստանդարտ պահանջներին՝ նման հարցերում, ինչպիսիք են պահեստավորման համակարգերը, տեղադրման միջավայրերը և այլն: Կոնտեյներիզացման հետագա մակարդակներում խոսքը արդեն ավտոմատացման կամ զարգացման թիմերին ինքնակառավարման հնարավորություններ տրամադրելու մասին է, որպեսզի նվազեցնել համակարգիչների ադմինիստրատորների վրա դրված բեռը և բարձրացնել մշակողների ինքնավարությունն ու արագությունը: Գրեթե այդպես ընկերությունը սկսում է շարժվել DevOps-ի ուղղությամբ: Կոնտեյներիզացման եզրափակիչ փուլում ընկերությունն գալիս է ավելի մաքուր, կանոնական DevOps մոդելին, որտեղ նախկին առաջադրանքներից ու աշխատանքներից շատերը անցնում են խաչաձև ֆունկցիոնալ թիմերի վերահսկողության տակ, որոնք դասակարգվում են ոչ թե հարթակների կամ տեխնոլոգիաների, այլ կիրառական ծառայությունների աշխատանքի ապահովման տեսանկյունից:

Այս գրառման մեջ մենք կներկայացնենք անհրաժեշտ կազմակերպական փոփոխությունների իրականացման ուղեցույց և կպատմենք, թե ինչպես են փոխվում ավանդական IT դերերը, երբ ընկերությունում ներդրվում են կոնտեյներային տեխնումները:

Նոր աշխատանքների կապումը հին դերերի հետ

PaaS-ի իր հիմունքային, նախնական ձևով կազմակերպական մոդելն կազմավորվում է՝ իբրև среды выполнения IT ռեսուրսների առավել բազմազան ու արագ տրամադրման համար, որը ծրագրերի համար է: Եվ չնայած դա որոշակի առավելություններ է տալիս համակարգավարներին, ծրագրավորողները սովորաբար այստեղ որևէ էական օգուտ և նոր հնարավորություններ չեն ստանում, քանի որ այս փուլում կազմակերպությունը կարող է հեշտությամբ обходиться առանց ավտոմատացման, ինքնակառավարման կամ տեղաբաշխման աշխատանքների արմատական բարելավումների: Նախագծման գործընթացներին նվազագույն ազդեցություն ունենալով այս իրադարձության պահին, PaaS, այնուամենայնիվ, բարձրացնում է IT համակարգի դինամիկությունը, ինչը հնարավորություն է տալիս համակարգավարներին ավելի լավ սպասարկել ծրագրավորողների պահանջները: Օրինակ, եթե նախկինում ծրագրակազմի միջավայր ստեղծելը կարող էր տևել օրեր կամ նույնիսկ շաբաթներ, և պահանջում էր մի քանի տարբեր համակարգավարների ներգրավում, ապա PaaS-ում ամեն ինչ իրականացվում է շատ ավելի արագ և միայն մեկ համակարգավարի ուժերով: օգտագործման համար կիրառվում է KubeVirt տեխնոլոգիան, որը թույլ է տալիս աշխատեցնել դասական վիրտուալ մեքենաներ ուղղակի Kubernetes կոնտեյներում և արդեն ունի բոլոր անհրաժեշտ ինտեգրացիաները Cluster API-ի հետ՝ կառավարվող Kubernetes կլաստերներ սկսելու համար «երևակայական» Kubernetes կլաստերում: Նաեւ, ծրագրավորողների թիմերը հիմա դիմում են, ինչպես նախկինում, սակայն այդ դիմումներին արձագանքելու աշխատանքներն արդեն կատարվում են նոր սխեմայի համաձայն:

DevOps կազմակերպությանը առճանաջ կլինի

Պայմանները PaaS-ի գործարկման և IT համակարգերի սպասարկման մասնագետների, սկսել DevOps մեթոդաբանության կիրառումը, որը, ներառյալ այլ բաների, պահպանում է հետևյալ հիմնական սկզբունքները:

• Աշխատանքը մանր մանրամասների բաժանել, որպեսզի վաղ փուլերում արձագանք ստանալ, ռիսկերը նվազեցնել և խուսափել «վերլուծական պառկման» դեպքում;
• Արդյունավետորեն ավտոմատացնել գործողությունները, որպեսզի խոչընդոտներ կամ նեղ բռնապատկերներ չստեղծվեն ծրագիրը տեղաբաշխելու գործընթացում;
• Նորությունների փոխանակումը դուք վստահության ձևավորման մեկնակետն է;
• Տեխնիկական պարտքերը կարգավորելու, աշխատանային յուրաքանչյուր ցիկլում որոշակի ժամանակ հատկացնել համակարգային բարելավումների համար։

Երկրորդ փուլում կոնտեյների տեխնոլոգիաների ներդրման ընթացքում զարգացման թիմերը, բնականաբար, սկսում են տեսնել բարելավման հնարավորություններ, և կազմակերպությունը ձգտում է ավելի կանոնական DevOps մոդելի։ Gelen механիզմը ՝ ծառայությունների հայտերը ներկայացնելն ու կատարելն, այժմ ընկալվում է որպես նեղ տեղ, ուստի կազմակերպությունը ձգտում է ավտոմատացնել կրկնվող գործողությունները և ընձեռել ծրագրավորողներին ինքնուրույն սպասարկման հնարավորություններ։ Այսինքն ՝ ծրագրավորողների այդ հնարավորությունները տարբեր հայտերում սահմանվում են ՀՏ մասնագետների և այն անձանց համատեղ ջանքերով, ովքեր պատասխանատու են ծրագրերի առաքման համար։ Այլ կերպ ասած, համակարգերի ադմինիստրատորների, որոնք կատարում էին ծրագրավորողների հայտերի գործողությունները, փոխարինվում են վերոհիշյալ երկու երկրից գործակիցները, որոնք պատասխանատու են քաղաքականությունների նկարագրության և կիրառման համար, որոնք կարգավորում են, թե ինչու ծրագրավորողներին թույլատրվում է ինքնուրույն գործել։ Ավտոմատացված ընթացակարգերը օգնում են ապահովել նշված պահանջների պահպանման և համաձայնեցված գործողությունների ապահովում, երբ իրավիճակը դուրս է զգալիորեն գործող քաղաքականություններից։

ԻՏ միջավայրի և օպերացիոն մոդելի բարելավումը ժամանակի ընթացքում հաջորդող համակարգերի կամ օպերացիոն մոդելների փոփոխությունների անցում, критիկական կարևոր նշանակություն ունի կազմակերպությունում DevOps հասուն համակարգ ձևավորելու համար։ DevOps մեթոդաբանության ընդունման աստիճանը կախված է յուրաքանչյուր կազմակերպության փոփոխություններին հանդուրժողականությունից և այն փոփոխություններից, որոնք առավելագույն օգուտ են տալիս։ Օրինակ, եթե նոր միջավայրեր կամ կիրառումներ ստեղծելու ցանկությունը չի էլ առաջանում հաճախ, ապա համապատասխան գործողության օպտիմիզացումը կլինի ավելի քիչ կարևոր, քան ծրագրավորողների վերահսկողության ուժեղացումը ծրագրերի կյանքի ընթացքում։

Նոր խնդիրները, որոնք առաջանում են ԻՏ կազմակերպություններում OpenShift-ը անցնելու ընթացքում

Այս բաժնում մենք կանդրադառնանք այն դերերին և խնդիրներին, որոնք OpenShift-ի անցած կազմակերպությունները սովորաբար կիրառում են ավտոմատացմանը և ինքնլիցքավորմանը արագացնելու համար՝ օգտագործելով տեխնոլոգիաներ և PaaS։

Սեղաններում ներկայացված են բարձր մակարդակի հիմնական առաջադրանքները, որոնք առկա են յուրաքանչյուր կազմակերպությունում, որը ներդրել է OpenShift, համապատասխան աշխատանքների և հմտությունների օրինակներով: Այս առաջադրանքների ցանկը չի կարելի շփոթել աշխատանքի բաժանման esquema-ի կամ թիմերի կազմակերպական կառուցվածքի հետ, սա միայն այն առաջադրանքների հավաքածու է, որն արժանապատիվ մարդիկ պետք է լուծեն ՏՏ միջավայրի աջակցման համար, որպեսզի հաջողությամբ ներդրվի կոնտեյներային հարթակ: Իրականում, հետագայում ցույց կտանք, թե ինչպես կոնտեյներային տեխնոլոգիաների ներդրումը ստեղծում է հիմքեր ավելի բարեփոխված DevOps ռազմավարության ձևավորման համար, ինչը, իր հերթին, բարձրացնում է թիմերի միջֆունկցիոնալության աստիճանը և նվազեցնում է ինչպես անհատների, այնպես էլ թիմերի մակարդակում նեղ մասնագիտացման ռիսկերը.

Սեղան 1. OpenShift առաջադրանքների սահմանումները

Բեռնավորություններ
Պետք նշանակությունները

ՏՏ ենթակառուցվածքների ավտոմատացում և նախապատրաստում (provisioning)

Աշխատանքներ:

• Հոսքագծային լուծումների նախագծում և կառուցում
• Ավտոմատացման սկզբնական կարգավորման կազմակերպում և աջակցում
• Վիրահայեցվածքների և հոստինգների նախապատրաստման նախագծում և ավտոմատացում

• Տվյալների կենտրոնների նախագծում և իրականացում
• Linux համակարգի վարչարարություն
• Ավտոմատացման սցենարներ
• Պահեստային համակարգերի գիտելիքներ
• Յաոզատվություն և ցանցերի նախագծման ու իրականացման գիտելիքներ
• Ապահովություն

OpenShift հարթակի ինստալացում և կառավարում

Աշխատանքներ:

• Կլաստերի ինստալացման իրականացում
• Արդյունավետ ծառայությունների կառավարում
• Հարթակի մասշտաբի կառավարման ղեկավարում
• Ապահովվածության և հեղինակում օգտագործողների վերահսկում հարթակի մակարդակում

• Linux համակարգի վարչարարություն
• Յաոզատվություն ցանցային տեխնոլոգիաների հետ
• Ավտոմատացման սցենարներ (Ansible)
• Պահեստային համակարգերի գիտելիքներ
• Կոնտեյներային տեխնոլոգիաների և ճարտարապետությունների գիտելիքներ
• Kubernetes և OpenShift ճարտարապետությունների գիտելիքներ
• Հարթակների անվտանգություն
• Հետազոտման ինտեգրում

Հաճախորդային միջավայրերի նախապատրաստման կառավարում (tenant provisioning), ՏՏ ռեսուրսների մեկուսացում

Աշխատանքներ:

• Օգտագործողների և թիմերի ստեղծում հարթակի շրջանակներում
• Քվոտաների նախագծում և կառավարում
• RBAC նախագծում և իրականացում

• Kubernetes և OpenShift ճարտարապետությունների գիտելիքներ
• Կոնտեյներային տեխնոլոգիաների և ճարտարապետությունների գիտելիքներ
• Ավտոմատացման սցենարներ
• Լավ գիտելիքներ նախագծերի, քվոտաների, դերի կապերի և պլանավորողների հետ աշխատանքներում

Արտադրություն և հիմնական պատկերների կառավարում

Աշխատանքներ:

• Նկարների փոփոխության աշխատանքային գործընթացի մշակումը
• Պահնակների հիման վրա նկարների մշակումը

• Linux համակարգի վարչարարություն
• Ավտոմատացման սցենարներ
• Դիմումների և միջին ծրագրերի runtime բաղադրիչների կոնֆիգուրացում
• Կոնտեյներային ճարտարապետությունների գիտելիքներ
• Դիմումների կառուցման ֆրեյմվորքեր (application build frameworks)
• Լավ գիտելիքներ պատկերների, imagestream և ձևերի մասին

Կարգավիճակների նախագծում և կառավարում

Աշխատանքներ:

• Կարգավիճակային ստանդարտների նախագծում և փաստաթղթավորում
• Կարճ հրահանգների և ձևերի մշակումը
• Ավելի հիմնավորների պատրաստում

• Առարկայի կոդի կառավարում
• Դիմումների նախագծում և իրականացում
• Ավտոմատացման սցենարներ
• Ավտոմատացված փորձարկում
• Կոդի որակի փորձարկում
• Կոնտեյներային ճարտարապետությունների գիտելիքներ
• Միօրինակ ենթակառուցվածքների գիտելիքներ
• Անվտանգություն – հասանելիության վարչակարգերը աշխատանքային վերին մակարդակում, աշխատանքային ընթացակարգերի հաստատում և այլն:
• OpenShift պատկերավոր մոդելների, buildconfigs, deploymentconfigs, ծառայությունների, routes, configmaps-ի լավ գիտելիք

Կիրառումների և թեստերի մշակույթ

Աշխատանքներ:

• Կոդավորման կիրարկումներ
• Ավտոմատացված թեստերի մշակույթ
• Թեստերի չօգտագործման արձագանքում ծրագրման համակարգում
• Կիրառությունների ձախողումների արձագանքում
• Օգտագործող ընդունման թեստավորում

• Դիմումների նախագծում և իրականացում
• Ավտոմատացված փորձարկում
• Առարկայի կոդի կառավարում
• Կիրառությունների հսկողություն
• Անհրաժեշտ բաշխված կլինիք Cloud Native ծրագրային միջավայրերի նկատմամբ գիտելիք

Օպերացիոն հսկողություն և կառավարում կիրարկելու համար

Աշխատանքներ:

• Կիրառումների նախագծում արդյունավետության համատեքստում
• Կիրառությունների կատարողականի ընթացքում հսկողություն
• Կիրառությունների մասշտաբավորում (կամ ավտոմատ մասշտաբավորում)
• Կիրառությունների հասանելիության կառավարում
• Հետազոտությունների քվոտաներ և ռեսուրսների կառավարուկ սահմաններ
• Արդյունավետության և IT հնարավորությունների թեստավորում

• Կիրառությունների կատարողականի նախագծում և իրականացում
• Կիրառությունների կատարողականի հսկողություն
• Արդյունավետության թեստավորում և բեռի թեստավորում

Օգտագործող ընդունման թեստավորում

Աշխատանքներ:

• UI թեստավորում (դիզայն և օգտագործողի հետազորություն)
• Ավտոմատացված թեստերի մշակույթ

• Օգտագործողի ինտերֆեյսների նախագծում և ստուգում
• Ավտոմատացված թեստավորման մոդելներ
• Թեստավորմամբ ձև frameworks
• Կիրառությունների նախագծման մոդելներ

OpenShift-ին անցնելու ժամանակ ի հայտ եկող նոր դերեր IT կազմակերպությունում

DevOps- հիմնված կազմակերպական մոդելին անցնելու ընթացքում, դերերի մասնագիտացումը, սովորաբար, նվազում է, իսկ կիսակող ցուցակներում և դերերում ավելանում մինչև համագործակցության պայմանների առավելագույն արդյունավետություն: Այսպիսին է մեր կարծիքով OpenShift-ի վրա հիմնված IT կազմակերպության հիմնական դիրքերի ցուցակը.

• Կիրառական գործողությունների ինժեներ (Application Operations Engineer) կամ Ապահովության կայքի ինժեներ (Site Reliability Engineer). Նախկինում այս դիրքը կարող էր կոչվել «Ծառայությունների ղեկավարի ադմինիստրատոր»:
• Կիրառությունների մշակող / ծրագրային մշակողի / ծրագրավորող- ինժեներ:
• Կլաստերի/կիրառման պլատֆորմի ադմինիստրատոր: Նախկինում այս դեր կարող էր կոչվել «Համակարգային ադմինիստրատոր» կամ «Linux-ի պլատֆորմի ադմինիստրատոր»:
• Ծրագրային արտադրանքի կառավարիչ (Release Manager) / Բազմաթիվ ինժեներ (Build Engineer).

RACI դերերի և պարտականությունների մատրից

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

Բեռնավորություններ
Դերեր

Կիրառական գործողությունների ինժեներ / Ապահովության կայքի ինժեներ
Կիրառությունների մշակող / ծրագրային մշակող / ծրագրավորող- ինժեներ
Կլաստերի/կիրառման պլատֆորմի ադմինիստրատոր
Ծրագրային ապահովման թողարկման մենեջեր / Հավաքման ինժեներ

ՏՏ ենթակառուցվածքների ավտոմատացում և նախապատրաստում (provisioning)
I
I
R/A
C

OpenShift հարթակի ինստալացում և կառավարում
C
I
R/A
C

Կարգավիճակների նախագծում և կառավարում
C
C
I
R/A

Հաճախորդի միջավայրերի կառավարման գործընթացը (tenant provisioning), մեկուսացումը և IT հնարավորություները
C
I
R/A
I

Արտադրություն և հիմնական պատկերների կառավարում
R
C
R/A
C

Կիրառումների և թեստերի մշակույթ
C
R/A
I
I

Օպերացիոն հսկողություն և կառավարում կիրարկելու համար
R/A
C
C
I

Օգտագործող ընդունման թեստավորում
C
R
I
I

RACI մատենագրության նշանաբանները
Ընտանիք: Wikipedia

• Պատասխանատու – Իսկ կատարողը՝ այն, ով անհրաժեշտ միջոցները ձեռնարկում է առաջադրանքի իրականացման համար։
• Հաշվետու – Հաշվետու – այն աշխատակից, ով վերջնական հաշվով պատասխանատու է առաջադրանքի ճիշտ և պատշաճ կատարման կամ արդյունքի հասնելու համար; ինչպես նաև միակը, ով կարող է հետույն աշխատանք delegated կատարել կատարողներին։
• Խորհրդատու – Խորհրդատուները՝ որպես կանոն, մասնագետներ են, ում խորհուրդն ի մի է բերվում; սրանց հետ պահպանվում է երկկողմային հաղորդակցություն։
• Տեղեկացված – Տեղեկացվողները՝ մարդիկ, որոնց պահում են իրազեկի կարգավիճակում (պատահում է, որ միայն առաջադրանքի ավարտից կամ արդյունքի հասնելուց հետո); նրանք ստանում են տեղեկություններ միակողմանի կարգով։

Ինչպե՞ս կազմակերպվում է թիմերի համագործակցությունը DevOps կազմակերպություններում

tradicional ռեսուրսների ձեռքբերման սխեման, սովորաբար, ներկայացնում է ռեսուրսների تخصման թողարկման հարցերի ցիկլ, որոնք հետո շահագործվում են մի քանի թիմերի կողմից: Վերջնական արդյունքում բոլոր անհրաժեշտ ռեսուրսները տրամադրվում են և հաստատվում դիմող կողմից: Շատ դեպքերում այս գործընթացները մասնակի կամ ամբողջությամբ ձեռքով են իրականացվում և պահանջում են հաճախակի և բազմազան փոխհամագործակցություն թիմերի մեջ յուրաքանչյուր հարցի հաջող հ 처리ման համար:

Ռիսուն 1. ավանդական IT-կազմակերպություն

Առկա սքեմայում ցուցադրված է ավանդական IT-կազմակերպության միջև վարկածային հարաբերությունները: Այս սքեմայի շրջանակներում, որոշ թիմեր դիմում են ուրիշ թիմերի, որպեսզի կատարեն անհրաժեշտ աշխատանքները, ավելի ձևավորված հաղորդակցության միջոցներով, նման վարկանիշային համակարգերի կամ էլեկտրոնային փոստի միջոցով: Այնուհետև այդ դիմումները ընկնում են հերթափոխի և սպասում իրենց հերթին, իսկ երկար սպասումը հաճախ հանգեցնում է վատացման կամ նույնիսկ թեժացման հարաբերությունների միջև: Կ напряжением ավելի ոչ պատշաճ է այն, որ տարբեր թիմերի անդամները հազվադեպ հանդիպում են անձնական ակնարկով և, ինչպես այսպես, սովորաբար կիսում են միայն համապատասխան մանրամասները.

Ռիսուն 2. IT-տխնում DevOps

Այս գծապատկերի վրա ցույց է տրված, թե ինչպես է կազմակերպությունում աշխատում DevOps տեխնոլոգիան: Այստեղ նախկին գծապատկերի նույն թիմերը հրաժարվել են անարդյունավետ հաղորդակցություններից, որոնք ուժեղացնում էին բաժանվածությունը, և փոխարինել դրանք անձնական շփումներով, հետեւաբար, ստեղծելով մշտապես գործող շփման ալիքներ թիմերի միջև: Այս ալիքները նպաստում են հիբրիդային հմտությունների մասնագիտական խմբի ստեղծմանը, որը օգնում է աշխատակիցներին ավելի լավ հասկանալու և ներկայացնելու այն թիմերի պահանջները, խնդիրները և հնարավորությունները, որոնք իրենք ներկայացնում են. Թիմերը միմյանց հնարավորություն են տալիս կատարել անհրաժեշտ աշխատանքները ավտոմատացված ինքնասպասարկման պորտալների միջոցով, փոխարենը նախորդի նման ձեռքով տնօրինելու ուրիշների փոփոխություններ, ինչպես դա եղել է նախկինում: Եվ շփման ալիքների առկայության շնորհիվ այս ինքնասպասարկման համակարգերը կարող են արագ ադապտացվել նրանց թիմերի պահանջներին, որոնց համար դրանք ստեղծվել են: Միաժամանակ ավելի շատ փոխհասկացողություն և գիտելիքների փոխանակում ձեռք բերելու համար մտավոր աշխատանքի անդամները ժամանակ առ ժամանակ փոխում են իրենց դերերը, որպեսզի փորձ ստանան տարբեր թիմերի հետ և ավելի լավ հասկանան այն IT համակարգերի ընդհանուր պատկերը, որոնք նրանք սպասարկում են, շեշտելով իրենց հետազոտման մակարդակը և արդյունավետությունը:

Վերջաբանիև

Այս գրառումնում մենք պատմել ենք, թե ինչպես PaaS լուծումների ներդրումը կարող է խթանել կազմակերպությունը դեպի DevOps մեթոդաբանության կիրառում, причём в рамках этого процесса изменению подвергаются традиционные роли и задачи. Поэтому мы перечислили основные ИТ-задачи, которые возникают в организации с переходом на OpenShift, а также навыки, необходимые для их выполнения. Мы также привели основной набор организационных ролей, возникающий при построении кросс-фունկցիոնальных команд DevOps, и матрицу RACI, увязывающую новые роли с новыми задачами. И наконец, мы рассказали, как платформа OpenShift и связанная с ней методология DevOps могут изменить оргструктуру организации при переходе от традиционной иерархии и систем обработки заявок к кросс-функциональным командам с более высоким уровнем персональных коммуникаций.

Ընտանիք: habr.com