Վերջերս ես ներկա էի DevOpsForum 2019-ին, որը հյուրընկալվել էր Logrocon-ի կողմից: Այս համաժողովում մասնակիցները փորձեցին լուծումներ և նոր գործիքներ գտնել բիզնեսի և զարգացման և տեղեկատվական տեխնոլոգիաների ծառայությունների մասնագետների միջև արդյունավետ փոխգործակցության համար:
Համաժողովը հաջողված էր. իսկապես շատ օգտակար զեկույցներ եղան, ներկայացման հետաքրքիր ձևաչափեր և շատ շփում բանախոսների հետ: Եվ հատկապես կարևոր է, որ ոչ ոք չփորձեց ինձ ինչ-որ բան վաճառել, ինչի համար վերջին շրջանում մեղավոր են խոշոր համաժողովների խոսնակները:
Հատված Raiffeisenbank-ի, Alfastrakhovanie-ի, Mango Telecom-ի ավտոմատացման ներդրման փորձից և այլ մանրամասների ելույթներից:
Իմ անունը Յանա է, ես աշխատում եմ որպես փորձարկող, զբաղվում եմ ավտոմատացումով, ինչպես նաև DevOps-ով, և ես սիրում եմ գնալ կոնֆերանսների և հանդիպումների: Վերջին երկու տարվա ընթացքում ես եղել եմ Օլեգ Բունինի կոնֆերանսներին (HighLoad++, TeamLead Conf), Jug միջոցառումներին (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow:
Առաջին հերթին ուշադրություն եմ հրավիրում համաժողովի ծրագրի վրա. Ես ավելի քիչ եմ նայում, թե ինչի մասին է լինելու զեկույցը, ավելի շատ՝ բանախոսին։ Նույնիսկ եթե զեկույցը շատ տեխնոլոգիական և հետաքրքիր է ստացվում, փաստ չէ, որ դուք կկարողանաք կիրառել զեկույցի լավագույն փորձը ձեր ընկերությունում: Եվ հետո ձեզ պետք է բարձրախոս:
Լույս Ռայֆայզենբանկի խողովակաշարի վերջում
Սովորաբար, ես որսում եմ ինձ հետաքրքրող կողքից բարձրախոսներ: DevOpsForum 2019-ին Raiffeisenbank-ի խոսնակ Միխայիլ Բիժանը գրավեց իմ հետաքրքրությունը: Իր ելույթի ընթացքում նա խոսեց այն մասին, թե ինչպես են նրանք աստիճանաբար ներգրավում իրենց թիմերը DevOps-ին, ինչու է դա նրանց անհրաժեշտ և ինչպես վաճառել DevOps-ի վերափոխման գաղափարը բիզնեսին: Դե, ընդհանուր առմամբ, ես խոսեցի այն մասին, թե ինչպես կարելի է տեսնել լույսը խողովակաշարի վերջում:
Միխայիլ Բիժան, Raiffeisenbank-ի ավտոմատացման տնօրեն
Այժմ նրանք չունեն «DevOps» իրենց ընկերությունում: Այսինքն՝ աշխատում է, բայց ոչ բոլոր թիմերում։ DevOps-ն իրականացնելիս նրանք ապավինում են թիմերի պատրաստվածությանը, ինչպես կոնկրետ ինժեներների, այնպես էլ արտադրանքի կարիքների և հարթակի հասունության առումով, որի վրա կառուցված է այս արտադրանքը: Միշան պատմեց, թե ինչպես բացատրել բիզնեսին, թե ինչու է անհրաժեշտ DevOps-ը:
Բանկային սեգմենտը ունի աճի մի քանի շարժիչ ուժ՝ ծառայությունների արժեքը և հաճախորդների բազայի ընդլայնումը: Ծառայությունների արժեքի բարձրացումը այնքան էլ լավ շարժիչ ուժ չէ, սակայն հաճախորդների բազայի աճը հակառակն է: Եթե մրցակիցները թողարկեն օբյեկտիվորեն զով արտադրանք, բոլոր հաճախորդները գնում են այնտեղ, ապա ժամանակի ընթացքում շուկան դուրս է գալիս: Հետևաբար, նոր ապրանքատեսակների շուկա ներմուծումը և դրանց ներդրման արագությունը գլխավորն է, որի վրա բանկերը կենտրոնանում են։ Դա հենց այն է, ինչի համար է DevOps-ը, և բիզնեսները դա հասկանում են:
Հաջորդ կարևոր նշումը. DevOps-ը միշտ չէ, որ նվազեցնում է շուկա դուրս գալու ժամանակը: DevOps-ը չի կարող միայնակ աշխատել, դա պարզապես արտադրանքի ստեղծման և շուկա դուրս բերելու գործընթացի մի մասն է մշակումից մինչև արտադրություն (կոդից մինչև հաճախորդ): Բայց ամեն ինչ մինչ կոդը ուղղակիորեն կապված չէ DevOps-ի հետ։ Այսինքն՝ մարքեթոլոգները կարող են տարիներ շարունակ ուսումնասիրել շուկան և իրենց ողջ կյանքն անցկացնել՝ հասնելով մրցակիցներին: Պետք է արագ հասկանալ, թե ինչ է պետք հաճախորդին և պլանավորել այս կամ այն ֆունկցիայի իրականացումը. հաճախ դա այն է, ինչը բավարար չէ, որպեսզի DevOps-ն աշխատի, և ընկերությունը հասնի իր նպատակին: Ուստի, առաջին հերթին, Raiffeisenbank-ը համաձայնեց բիզնեսի հետ, որ անհրաժեշտ է սովորել, թե ինչպես օգտագործել DevOps-ը: Ավտոմատացումը հանուն ավտոմատացման այնքան էլ չի օգնի նոր հաճախորդների համար պայքարում։
Ընդհանուր առմամբ, Միշան կարծում է, որ DevOps-ը պետք է իրականացվի, բայց իմաստուն: Եվ մենք պետք է պատրաստ լինենք այն բանին, որ վերափոխման սկզբում թիմի արտադրողականությունը կնվազի, այն ավելի քիչ գումար կվաստակի, բայց հետո դա արդարացված կլինի։
Թեստավորման ավտոմատացում Mango Telecom-ում
Մեկ այլ հետաքրքիր զեկույց ինձ համար՝ որպես փորձարկողի, տվել է Եգոր Մասլովը Mango Telecom-ից։ Շնորհանդեսը կոչվում էր «Ամբողջ փորձարկման ցիկլի ավտոմատացում SCRUM թիմում»: Եգորը կարծում է, որ DevOps-ը ստեղծվել է հատուկ SCRUM-ի համար, բայց միևնույն ժամանակ, DevOps-ը SCRUM թիմ ներմուծելը բավականին խնդրահարույց է: Դա տեղի է ունենում այն պատճառով, որ SCRUM թիմը միշտ ինչ-որ տեղ է վազում, ժամանակ չկա նորամուծություններով շեղվելու և գործընթացը վերակառուցելու համար: Խնդիրը կայանում է նաև նրանում, որ SCRUM-ը չի ներառում ենթախմբի բաժանումը թիմում (թեստավորման թիմ, մշակող թիմ և այլն): Դե, բացի այդ, գոյություն ունեցող գործընթացն ավտոմատացնելու համար անհրաժեշտ է փաստաթղթավորում, և SCRUM-ում ամենից հաճախ ամբողջական փաստաթուղթ չկա. «ապրանքն ավելի կարևոր է, քան ինչ-որ գրություն»:
SCRUM-ին անցնելուց հետո փորձարկողները սկսեցին խորհրդակցել ծրագրավորողների հետ, թե ինչպես փորձարկել հնարավորությունները: Աստիճանաբար ֆունկցիոնալության ծավալը մեծացավ, փաստաթղթեր չկար, և սկսեցին շատ սխալներ որսալ ֆունկցիոնալության մեջ, որոնք չեն ծածկվել թեստերով և ընդհանրապես պարզ չէր, թե ով և երբ է այն փորձարկել: Մի խոսքով, շփոթություն և տատանումներ: Մենք որոշեցինք անցնել փորձարկման ավտոմատացման: Բայց նույնիսկ այն ժամանակ կատարյալ ձախողում եղավ։ Նրանք վարձեցին աութսորսինգ ավտոմատացման մասնագետներ, ովքեր գրում էին ներքին փորձարկողների համար անհայտ բուրգի վրա: Ավտոթեստերի շրջանակն, իհարկե, աշխատեց, բայց աութսորսորների հեռանալուց հետո այն տևեց երկու շաբաթ։ Հաջորդը փորձ էր ներդնել ինքնաթեստավորում թիվ երկու: Այն սկսվեց նրանից, որ ամեն ինչ պետք է կառուցվի ընկերության ներսում, ինքնուրույն (ճիշտ վեկտորը. ներքին փորձի կուտակում), SCRUM-ի շրջանակներում և այդ գործընթացում ստեղծել փաստաթղթեր: Ավտոմատացման համար նախատեսված կույտը պետք է հավասար լինի արտադրանքի կույտին (այստեղ ես ավելացնում եմ այն, մի փորձարկեք ձեր JavaScript նախագիծը որևէ այլ բանով): Սպրինտի վերջում նրանք ցուցադրեցին այն մասին, թե ինչպես է ավտոթեստն աշխատում ամբողջ թիմի հետ (օգտակար): Այսպիսով, ավելացավ թիմի բոլոր անդամների ներգրավվածությունը ավտոմատացման գործընթացում, ինչպես նաև վստահությունը ավտոթեստերի նկատմամբ և հնարավորությունը, որ այս ավտոթեստը անպայման կկիրառվի (և մեկ ամսից չի մեկնաբանվի մշտական ձախողումների պատճառով):
Ի դեպ, DevOpsForum 2019-ին բաց խոսափող կար՝ ելույթների վաղուց հայտնի և, իմ կարծիքով, օգտակար ձևաչափ։ Դուք շրջում եք այսպես, լսում զեկույցներ, ապա որոշում, որ համաժողովում արժե քննարկել որոշակի թեմա կամ խնդիր, կիսվել խնդրի լուծման համապատասխան փորձով։
Նկատեցի նաև, որ կազմակերպիչները կարճ զեկույցների հոսք են արել։ Յուրաքանչյուր զեկույց տևում է ոչ ավելի, քան 10 րոպե, որին հաջորդում են հարցեր: Այս կերպ Դուք կարող եք միանգամից լուսաբանել բազմաթիվ թեմաներ և հարցեր տալ ձեզ հետաքրքրող բանախոսներին:
Շնորհանդեսների միջև ընկած ժամանակահատվածում ես շրջեցի համաժողովի գործընկերների տաղավարներով և գողացա/շահեցի շատ բաներ: Օ, ես սիրում եմ թերթիկը:
Կլոր սեղան և DevOps հարցեր Alfastrakhovanie-ի զարգացման տնօրենի հետ
Ինձ համար DevOpsForum 2019 տորթի վրա դրոշմը DevOps փորձագետների հետ մեկ ժամ տևած լիագումար նիստն էր: Նիստի չորս մասնակիցներ հրավիրված էին դիտելու DevOps-ը տարբեր տեսանկյուններից՝ Անտոն Իսանինը (Alfastrakhovanie, զարգացման տնօրեն), Նաիլյա Զամաշկինան (Fintech Lab, օպերացիոն տնօրեն), Օլեգ Եգորկինը (Rostelecom, Agile մարզիչ) և Անտոն Մարտյանովը (անկախ փորձագետ, նայեց DevOps-ին։ բիզնեսի տեսանկյունից):
Փորձագետները ավելի մոտ նստեցին մարդկանց, և հետո ամեն ինչ սկսվեց տեղի ունենալ. մի ամբողջ ժամ լսարանի մասնակիցներն իրենց հարցերն էին տալիս, իսկ փորձագետները վերցրեցին ռեփը: Երբեմն իրական բանավեճեր էին լինում։ Հարցերը շատ տարբեր էին, օրինակ՝ ընդհանրապես պե՞տք են DevOps-ի ինժեներներ, ինչո՞ւ նրանք չեն կարող վերապատրաստվել որպես համակարգի ադմինիստրատորներ, պե՞տք է արդյոք DevOps-ն առաջարկվի բոլորին, ինչ արժեք ունի և այլն։
Հետո անձամբ զրուցեցի Անտոն Իսանինի հետ։ Մենք քննարկեցինք DevOps մշակույթը յուրաքանչյուր տուն բերելու անհրաժեշտությունը և բացահայտեցինք DevOps-ի վերափոխման մութ կողմը:
Եկեք պատկերացնենք, որ բոլորը հավաքվեցին և որոշեցին, որ DevOps-ն անհրաժեշտ է և՛ արտադրանքին, և՛ բիզնեսին և թիմին: Եկեք գնանք այն իրականացնել: Ամեն ինչ ստացվեց։ Մենք արտաշնչեցինք։ DevOps-ը մեզ մոտեցրել է հաճախորդին, այժմ մենք կարող ենք արագ կատարել նրա բոլոր ցանկությունները։ Արդյունքում, մենք ունենք օպերատիվ ծառայությունների մեծ բաժին՝ խիստ կանոնակարգերով և պահանջներով, և այն անընդհատ հայտնաբերում է արտադրանքի թերությունները և ստեղծում մի շարք հարցումներ: Ավելին, բոլոր թերություններին տրվում է «հրատապ» կարգավիճակ, նույնիսկ եթե հաճախորդը անսպասելիորեն ցանկացել է կոճակը կանաչի փոխարեն ներկել դեղին: Նախագիծն աճում է, թողարկումների քանակը աճում է և, համապատասխանաբար, հաճախորդների կողմից նոր ֆունկցիոնալության թերությունների և թյուրիմացությունների թիվը: Ops-ը ևս 10 հոգու է վարձում, որպեսզի հետ չմնան թերությունների մասին, իսկ մշակումը ևս 15 հոգու է վարձում, որպեսզի հետ չմնա դրանք փակելու համար: Եվ նոր հնարավորություններ ներդնելու փոխարեն թիմն աշխատում է անվերջ SD-ներով՝ բացատրելով օգտատիրոջ ֆունկցիոնալությունը և միաժամանակ աջակցությունը: Արդյունքում, և՛ Ops-ը, և՛ զարգացումը աշխատում են, բայց հաճախորդը և բիզնեսը դժգոհ են. նոր գործառույթները խրված են: Պարզվում է, որ DevOps-ը կարծես գոյություն ունի, բայց կարծես թե գոյություն չունի:
DevOps-ի ներդրման անհրաժեշտության վերաբերյալ Անտոնը հստակ հայտարարեց, որ դա ուղղակիորեն կախված է բիզնեսի մասշտաբից։ Եթե տարեկան մեկ հաճախորդի սպասարկումը ընկերությանը միլիարդ է բերում, DevOps-ն անհրաժեշտ չէ (պայմանով, որ ձեզ հարկավոր չէ կանոնավոր կերպով նոր փոփոխություններ մտցնել այս հաճախորդի համար): Ամեն ինչ պատված է շոկոլադով։ Բայց եթե բիզնեսն աճում է, և ավելի շատ հաճախորդներ են հայտնվում, ապա դուք պետք է համապատասխանեք: Որպես կանոն, ի սկզբանե ընկերությունում թույն Ops չկա: Սկզբում մենք կտրում ենք արտադրանքը, և միայն դրանից հետո ենք հասկանում, որ արտադրանքը աշխատելու համար պետք է հետևել սերվերներին և վերահսկել մատակարարումները: Հենց այդ ժամանակ էլ առաջանում է Ops-ը: Մնում է հասկանալ, որ Ops-ը, որպես առանձին ստորաբաժանում, կսկսի մի շարք խոչընդոտներ դնել զարգացման համար, և բոլոր մատակարարումները կսկսեն կանգ առնել: Այսինքն՝ այս դեպքում DevOps մշակույթն արդեն իսկ ակտուալ է, բայց չպետք է մոռանալ դրա մութ կողմի մասին։
Source: www.habr.com