Մոնոլիտներից մինչև միկրոծառայություններ. M.Video-Eldorado-ի և MegaFon-ի փորձը

Ապրիլի 25-ին մենք Mail.ru Group-ում անցկացրեցինք կոնֆերանս ամպերի և շուրջը - mailto:CLOUD. Մի քանի կարևոր դրույթներ.

• Գլխավոր հիմնական Ռուսական պրովայդերներ — Mail.ru Cloud Solutions-ը, #CloudMTS-ը, SberCloud-ը, Selectel-ը, Rostelecom Data Center-ը և Yandex.Cloud-ը խոսեցին մեր ամպային շուկայի առանձնահատկությունների և իրենց ծառայությունների մասին.
• Bitrix24-ի գործընկերները պատմել են, թե ինչպես են իրենք եկավ բազմամպի վրա;
• Հետաքրքիր են տրամադրել Leroy Merlin-ը, Otkritie-ն, Burger King-ը և Schneider Electric-ը տեսարան ամպի սպառողների կողմից — ինչ խնդիրներ են դնում իրենց բիզնեսը ՏՏ-ի համար և ինչ տեխնոլոգիաներ, այդ թվում՝ ամպային, նրանք համարում են ամենահեռանկարայինը:

Դուք կարող եք դիտել բոլոր տեսանյութերը mailto:CLOUD կոնֆերանսից по ссылке, իսկ այստեղ կարող եք կարդալ, թե ինչպես է անցել միկրոծառայությունների մասին քննարկումը։ MegaFon բիզնես համակարգերի հետազոտության և զարգացման կենտրոնի ղեկավար Ալեքսանդր Դեուլինը և M.Video-Eldorado խմբի տեղեկատվական տեխնոլոգիաների տնօրեն Սերգեյ Սերգեևը կիսվել են մոնոլիտներից ազատվելու իրենց հաջող դեպքերով։ Քննարկեցինք նաև ՏՏ ռազմավարության, գործընթացների և նույնիսկ կադրերի հետ կապված հարցեր։

Պանելիստներ

• Սերգեյ Սերգեև, Group CIO «M.Video-Eldorado»;
• Ալեքսանդր Դեուլին, բիզնես համակարգերի հետազոտության և զարգացման կենտրոնի ղեկավար Մեգաֆոն;
• Մոդերատոր - Դմիտրի Լազարենկո, PaaS ուղղության ղեկավար Mail.ru Cloud Solutions.

Ալեքսանդր Դեուլինի ելույթից հետո «Ինչպես է MegaFon-ն ընդլայնում իր բիզնեսը միկրոսերվիսային հարթակի միջոցով» Քննարկման համար նրան միանում են Սերգեյ Սերգեևը M.Video-Eldorado-ից և քննարկման մոդերատոր Դմիտրի Լազարենկոն, Mail.ru Cloud Solutions-ը:

Ստորև մենք ձեզ համար պատրաստել ենք քննարկման սղագրությունը, բայց կարող եք դիտել նաև տեսանյութը.

Միկրոծառայությունների անցումը շուկայի կարիքների արձագանքն է

Դմիտրի.

Ունեցե՞լ եք միկրոսերվիսներ տեղափոխելու հաջող փորձ: Եվ ընդհանրապես. որտեղ եք տեսնում բիզնեսի ամենամեծ օգուտը միկրոսերվիսներից օգտվելուց կամ մոնոլիտներից միկրոծառայությունների անցնելուց:

Սերգեյ.

Մենք արդեն որոշակի ճանապարհ ենք անցել միկրոծառայությունների անցնելու հարցում և այս մոտեցումն օգտագործում ենք ավելի քան երեք տարի: Առաջին անհրաժեշտությունը, որն արդարացնում էր միկրոծառայությունների կարիքը, տարբեր առաջնային ապրանքների անվերջ ինտեգրումն էր հետին գրասենյակի հետ: Եվ ամեն անգամ մեզ ստիպում էին լրացուցիչ ինտեգրում և զարգացում կատարել՝ կյանքի կոչելով այս կամ այն ​​ծառայության գործունեության մեր կանոնները։

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

Առաջին ծառայություններից մեկը՝ ամենածանրաբեռնվածը, գների հաշվարկման ծառայությունն էր։ Ամեն անգամ, երբ դուք գալիս եք ցանկացած ալիք, M.Video-Eldorado ընկերությունների խումբ, լինի դա կայք, թե մանրածախ խանութ, ընտրեք այնտեղ որևէ ապրանք, տեսեք գինը կայքում կամ «Զամբյուղում», ինքնարժեքը ինքնաշխատ է: հաշվարկված մեկ ծառայության կողմից: Ինչու է դա անհրաժեշտ. մինչ այս, յուրաքանչյուր համակարգ ուներ իր սկզբունքները գովազդների հետ աշխատելու համար՝ զեղչերով և այլն: Մեր հետին գրասենյակը կարգավորում է գնագոյացումը, զեղչի գործառույթն իրականացվում է մեկ այլ համակարգում: Սա պետք է կենտրոնացվեր և ստեղծվեր եզակի, բաժանելի ծառայություն՝ բիզնես գործընթացի տեսքով, որը մեզ թույլ կտար դա իրականացնել: Մենք մոտավորապես այդպես սկսեցինք:

Առաջին արդյունքների արժեքը շատ մեծ էր։ Նախ, մենք կարողացանք ստեղծել տարանջատելի միավորներ, որոնք թույլ են տալիս աշխատել առանձին և ագրեգացված: Երկրորդ՝ մենք նվազեցրել ենք սեփականության արժեքը՝ ավելի շատ համակարգերի հետ ինտեգրվելու առումով:

Վերջին երեք տարիների ընթացքում մենք ավելացրել ենք երեք առաջնագծի համակարգ: Դժվար էր դրանք պահպանել նույն քանակությամբ ռեսուրսներով, որոնք ընկերությունը կարող էր իրեն թույլ տալ: Ուստի խնդիր առաջացավ փնտրել նոր ելքեր՝ արձագանքելով շուկային արագությամբ, ներքին ծախսերով ու արդյունավետությամբ։

Ինչպես չափել միկրոծառայությունների միգրացիայի հաջողությունը

Դմիտրի.

Ինչպե՞ս է որոշվում միկրոծառայությունների միգրացիայի հաջողությունը: Ո՞րն էր «նախկին» յուրաքանչյուր ընկերությունում: Ի՞նչ չափանիշ եք օգտագործել՝ որոշելու անցման հաջողությունը, և ո՞վ է իրականում որոշել այն:

Սերգեյ.

Առաջին հերթին, այն ծնվել է ՏՏ շրջանակներում՝ որպես հնարավորություն՝ «բացելով» նոր հնարավորություններ: Մենք կարիք ունեինք ամեն ինչ ավելի արագ անել համեմատաբար նույն գումարի դիմաց՝ արձագանքելով շուկայի մարտահրավերներին: Այժմ հաջողությունն արտահայտվում է տարբեր համակարգերի կողմից վերօգտագործվող ծառայությունների քանակով, գործընթացների միմյանց միջև միավորմամբ։ Հիմա կա, բայց այդ պահին հնարավորություն էր ստեղծել հարթակ և հաստատել այն վարկածը, որ մենք կարող ենք դա անել, դա էֆեկտ կտա և կհաշվարկի բիզնես գործը։

Ալեքսանդր:

Հաջողությունը ավելի շուտ ներքին զգացողություն է։ Բիզնեսը միշտ ավելին է ուզում, և մեր կուտակումների խորությունը հաջողության ապացույց է: Ինձ այդպես է թվում։

Սերգեյ.

Այո, ես համաձայն եմ. Երեք տարվա ընթացքում մենք արդեն ունենք ավելի քան երկու հարյուր ծառայություններ և հետաձգումներ։ Թիմի ներսում ռեսուրսների կարիքը միայն աճում է՝ տարեկան 30%-ով: Սա տեղի է ունենում այն ​​պատճառով, որ մարդիկ զգացել են՝ ավելի արագ է, տարբեր է, տարբեր տեխնոլոգիաներ կան, այս ամենը զարգանում է։

Միկրոծառայությունները կգան, բայց միջուկը կմնա

Դմիտրի.

Դա նման է անվերջ գործընթացի, որտեղ դուք ներդրումներ եք կատարում զարգացման մեջ: Բիզնեսի համար միկրոծառայությունների անցումը արդեն ավարտվե՞լ է, թե՞ ոչ։

Սերգեյ.

Շատ հեշտ է պատասխանել. Ի՞նչ եք կարծում. հեռախոսների փոխարինումն անվերջ գործընթաց է: Մենք ինքներս ամեն տարի հեռախոսներ ենք գնում։ Եվ ահա, քանի դեռ արագության, շուկային հարմարվելու անհրաժեշտություն կա, որոշակի փոփոխություններ են պահանջվելու։ Սա չի նշանակում, որ մենք հրաժարվում ենք ստանդարտ բաներից։

Բայց մենք չենք կարող միանգամից ծածկել և վերագործարկել ամեն ինչ: Մենք ունենք ժառանգական, ստանդարտ ինտեգրացիոն ծառայություններ, որոնք նախկինում կային. ձեռնարկությունների ավտոբուսներ և այլն: Բայց կա հետընթաց, և կա նաև անհրաժեշտություն։ Բջջային հավելվածների թիվը և դրանց ֆունկցիոնալությունը գնալով աճում է։ Ընդ որում, ոչ ոք չի ասում, որ ձեզ 30 տոկոսով ավելի գումար են տալու։ Այսինքն՝ մի կողմից միշտ կարիքներ կան, մյուս կողմից՝ արդյունավետության որոնում։

Դմիտրի.

Կյանքը լավ վիճակում է։ (Ծիծաղում է)

Ալեքսանդր:

Ընդհանուր առմամբ՝ այո։ Մենք հեղափոխական մոտեցումներ չունենք առանցքային մասը լանդշաֆտից հեռացնելու հարցում։ Համակարգային աշխատանքներ են տարվում համակարգերը քայքայելու համար, որպեսզի դրանք ավելի համապատասխան լինեն միկրոսերվիսային ճարտարապետությանը, նվազեցնել համակարգերի ազդեցությունը միմյանց վրա:

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

Ինչպես վաճառել միկրոծառայություններ բիզնեսին

Դմիտրի.

Ինձ նաև հետաքրքրում է. նրանց համար, ովքեր չեն անցել, բայց պլանավորում են. որքանո՞վ էր հեշտ այս գաղափարը վաճառել բիզնեսին և արդյոք դա արկածախնդրություն էր, ներդրումային նախագիծ: Թե՞ դա գիտակցված ռազմավարություն էր. հիմա մենք գնում ենք միկրոծառայությունների և վերջ, մեզ ոչինչ չի խանգարի։ Ինչպե՞ս էր ձեզ համար:

Սերգեյ.

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

Դմիտրի.

Ինչ-որ կերպ գրանցե՞լ եք առաջին փուլի ժամը։

Սերգեյ.

Այո իհարկե. Մենք 6 ամիս հատկացրեցինք միջուկը որպես հարթակ ստեղծելու և փորձնական փորձարկման համար։ Այս ընթացքում մենք փորձեցինք ստեղծել հարթակ, որի վրա կարող ենք սահել օդաչուին: Հետո վարկածը հաստատվեց, և քանի որ այն աշխատում է, նշանակում է՝ կարող ենք շարունակել։ Նրանք սկսեցին կրկնօրինակել և ուժեղացրին թիմը. նրանք տեղափոխեցին այն առանձին բաժին, որն անում է հենց դա:

Հաջորդը գալիս է համակարգված աշխատանքը՝ հիմնված բիզնեսի կարիքների, հնարավորությունների, ռեսուրսների առկայության և այն ամենի վրա, ինչ ներկայումս մշակվում է:

Դմիտրի.

ԼԱՎ. Ալեքսանդր, ի՞նչ կասես։

Ալեքսանդր:

Մեր միկրոծառայությունները ծնվել են «ծովի փրփուրից»՝ ռեսուրսների խնայողության, սերվերի հզորության տեսքով որոշ մնացորդների և թիմի ներսում ուժերի վերաբաշխման շնորհիվ: Սկզբում մենք այս նախագիծը չենք վաճառել բիզնեսին: Սա նախագիծ էր, որտեղ մենք և՛ ուսումնասիրեցինք, և՛ համապատասխանաբար զարգացրեցինք: Մենք սկսել ենք 2018 թվականի սկզբից և ուղղակի ոգևորությամբ զարգացրել այս ուղղությունը։ Վաճառքը նոր է սկսվել, և մենք ընթացքի մեջ ենք:

Դմիտրի.

Պատահու՞մ է, որ բիզնեսը թույլ է տալիս անել այնպիսի բաներ, ինչպիսին Google-ն է՝ շաբաթական մեկ անվճար օր: Դուք ունե՞ք նման ուղղություն։

Ալեքսանդր:

Հետազոտության հետ միաժամանակ մենք զբաղվել ենք նաև բիզնեսի խնդիրներով, ուստի մեր բոլոր միկրոծառայությունները բիզնեսի խնդիրների լուծում են: Միայն սկզբում մենք կառուցեցինք միկրոսերվիսներ, որոնք ծածկում էին բաժանորդային բազայի մի փոքր մասը, և այժմ մենք առկա ենք գրեթե բոլոր առաջատար ապրանքներում։

Իսկ նյութական ազդեցությունն արդեն պարզ է. մեզ արդեն կարելի է հաշվել, արտադրանքի թողարկման արագությունը և կորցրած եկամուտը կարելի է գնահատել, եթե մենք գնայինք հին ճանապարհով: Ահա թե ինչի վրա ենք կառուցում գործը։

Միկրոծառայություններ. հիպ, թե՞ անհրաժեշտություն:

Դմիտրի.

Թվերը թվեր են: Իսկ եկամուտը կամ խնայված գումարը շատ կարևոր է: Իսկ եթե նայեք մյուս կողմին: Թվում է, թե միկրոսերվիսները թրենդ են, հիպ և շատ ընկերություններ չարաշահո՞ւմ են դա։ Որքանո՞վ եք հստակ տարբերակում այն, ինչ անում եք և չեք թարգմանում միկրոծառայություններ: Եթե ​​ժառանգություն հիմա, 5 տարի հետո դեռ ժառանգություն կունենա՞ք: Որքա՞ն են լինելու M.Video-Eldorado-ում և MegaFon-ում աշխատող տեղեկատվական համակարգերը 5 տարի հետո: Կլինե՞ն տասնամյա, տասնհինգ տարվա տեղեկատվական համակարգեր, թե՞ դա կլինի նոր սերունդ։ Ինչպե՞ս եք սա տեսնում:

Սերգեյ.

Ինձ թվում է՝ դժվար է շատ հեռու մտածել։ Եթե ​​հետ նայենք, ո՞վ էր պատկերացնում, որ տեխնոլոգիաների շուկան կզարգանա այսպես՝ ներառյալ մեքենայական ուսուցումը և օգտատերերի նույնականացումը դեմքով: Բայց եթե նայեք գալիք տարիներին, ինձ թվում է, որ հիմնական համակարգերը, ձեռնարկությունների ERP դասի համակարգերը ընկերություններում, դրանք բավականին երկար ժամանակ են աշխատում:

Մեր ընկերությունները միասին 25 տարեկան են, դասական ERP-ով շատ խորը համակարգերի լանդշաֆտում: Հասկանալի է, որ մենք այնտեղից որոշ կտորներ ենք հանում և փորձում դրանք ագրեգացնել միկրոծառայությունների մեջ, բայց միջուկը կմնա։ Ինձ համար հիմա դժվար է պատկերացնել, որ մենք այնտեղ կփոխարինենք բոլոր հիմնական համակարգերը և արագ անցնենք նոր համակարգերի մյուս՝ լուսավոր կողմին:

Ես կողմնակից եմ այն ​​փաստին, որ այն ամենն, ինչ ավելի մոտ է հաճախորդին և սպառողին, այնտեղ է ամենամեծ բիզնեսի օգուտն ու արժեքը, որտեղ հարմարվողականությունն ու կենտրոնացումը արագության, փոփոխության, «փորձել, չեղարկել, վերօգտագործել, այլ բան անել» վրա են: անհրաժեշտ է «- ահա, որտեղ կփոխվի լանդշաֆտը: Եվ տուփով պատրաստված արտադրանքները այնքան էլ լավ չեն տեղավորվում այնտեղ: Համենայն դեպս մենք դա չենք տեսնում։ Այնտեղ պահանջվում են ամենահեշտ, ամենապարզ լուծումները։

Մենք տեսնում ենք այս զարգացումը.

• հիմնական տեղեկատվական համակարգեր (հիմնականում back office);
• միջին շերտերը միկրոծառայությունների տեսքով միացնում են միջուկը, ագրեգատը, ստեղծում քեշ և այլն;
• առաջին գծի համակարգերն ուղղված են սպառողին.
• ինտեգրացիոն շերտ, որն ընդհանուր առմամբ ինտեգրված է շուկաներին, այլ համակարգերին և էկոհամակարգերին: Այս շերտը հնարավորինս թեթև է, պարզ և պարունակում է նվազագույն բիզնես տրամաբանություն:

Բայց միևնույն ժամանակ ես կողմնակից եմ, որ շարունակենք օգտագործել հին սկզբունքները, եթե դրանք պատշաճ կերպով կիրառվեն։

Ենթադրենք, դուք ունեք դասական ձեռնարկության համակարգ: Այն գտնվում է մեկ վաճառողի լանդշաֆտում և բաղկացած է երկու մոդուլներից, որոնք աշխատում են միմյանց հետ: Կա նաև ստանդարտ ինտեգրման ինտերֆեյս: Ինչու՞ նորից դա անել և այնտեղ միկրոսերվիս բերել:

Բայց երբ հետին գրասենյակում կան 5 մոդուլներ, որոնցից տեղեկատվությունը հավաքվում է բիզնես գործընթացի մեջ, որն այնուհետև օգտագործվում է առաջին գծի 8-10 համակարգերի կողմից, օգուտը անմիջապես նկատելի է: Դուք վերցնում եք հինգ back-office համակարգերից և ստեղծում ծառայություն, մեկուսացված, որը կենտրոնացած է բիզնես գործընթացի վրա: Դարձրեք ծառայությունը տեխնոլոգիապես առաջադեմ, այնպես որ այն պահում է տեղեկատվությունը և հանդուրժում է սխալները, ինչպես նաև աշխատի փաստաթղթերի կամ բիզնես սուբյեկտների հետ: Եվ դուք այն ինտեգրում եք առաջին գծի բոլոր ապրանքների հետ մեկ սկզբունքով: Նրանք չեղարկեցին առաջին գծի արտադրանքը. նրանք պարզապես անջատեցին ինտեգրումը: Վաղը դուք պետք է գրեք բջջային հավելված կամ ստեղծեք փոքր կայք և գործառության մեջ տեղադրեք միայն մի մասը. ամեն ինչ պարզ է՝ դուք այն հավաքել եք որպես կոնստրուկտոր: Ես ավելի շատ զարգացում եմ տեսնում այս ուղղությամբ՝ գոնե մեր երկրում։

Ալեքսանդր:

Սերգեյն ամբողջությամբ նկարագրեց մեր մոտեցումը, շնորհակալություն։ Ես պարզապես կասեմ, թե ուր մենք հաստատ չենք գնա՝ հիմնական մասի, առցանց վճարումների թեմայի: Այսինքն՝ վարկանիշն ու գանձումը, ըստ էության, կմնան «մեծ» կալսիչ, որը հուսալիորեն դուրս կգրի գումարը։ Եվ այս համակարգը կշարունակի հավաստագրվել մեր կարգավորող մարմինների կողմից: Մնացած ամեն ինչ, որ նայում է հաճախորդներին, իհարկե, միկրոծառայություններ են:

Դմիտրի.

Այստեղ հավաստագրումը մեկ պատմություն է: Հավանաբար ավելի շատ աջակցություն: Եթե ​​դուք քիչ եք ծախսում աջակցության վրա, կամ համակարգը չի պահանջում աջակցություն և փոփոխություն, ավելի լավ է չդիպչել դրան: Խելամիտ փոխզիջում.

Ինչպես զարգացնել հուսալի միկրոծառայություններ

Դմիտրի.

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

Մի քանի տարի առաջ շվեյցարական մի ընկերություն, որը երկու տարի ներդրել էր բանկերի համար նոր միկրոսպասարկման հարթակի մշակման համար, ի վերջո փակեց նախագիծը: Ամբողջովին փլուզված. Շատ միլիոնավոր շվեյցարական ֆրանկներ են ծախսվել, և ի վերջո թիմը ցրվել է՝ չստացվեց։

Դուք նման պատմություններ ունեցե՞լ եք: Դժվարություններ եղե՞լ են, թե՞ կան։ Օրինակ, միկրոծառայությունների և մոնիտորինգի պահպանումը նույնպես գլխացավանք է ընկերության գործառնական գործունեության մեջ: Ի վերջո, բաղադրիչների թիվը տասնյակ անգամ ավելանում է: Ինչպե՞ս եք դա տեսնում, այստեղ եղե՞լ են ներդրումների անհաջող օրինակներ։ Իսկ ի՞նչ խորհուրդ կտաք մարդկանց, որ նման խնդիրների չհանդիպեն։

Ալեքսանդր:

Անհաջող օրինակները ներառում էին բիզնեսի առաջնահերթությունները փոխելը և ծրագրերի չեղարկումը: Երբ պատրաստության լավ փուլում (իրականում MVP-ն պատրաստ է), բիզնեսն ասաց. «Մենք ունենք նոր առաջնահերթություններ, մենք անցնում ենք մեկ այլ նախագծի, և մենք փակում ենք այս մեկը»:

Մենք միկրոծառայությունների հետ կապված որևէ գլոբալ խափանում չենք ունեցել: Մենք հանգիստ քնում ենք, ունենք 24/7 հերթափոխ, որը սպասարկում է ամբողջ BSS-ը [բիզնեսի աջակցության համակարգը]:

Եվ ևս մեկ բան. մենք միկրոսերվիսները վարձակալում ենք տուփով ապրանքների համար կիրառվող կանոնների համաձայն։ Հաջողության գրավականն այն է, որ ձեզ անհրաժեշտ է, առաջին հերթին, թիմ հավաքել, որը լիովին կպատրաստի միկրոսերվիսը արտադրության համար: Ինքնին զարգացումը, պայմանականորեն, 40% է։ Մնացածը վերլուծություն է, DevSecOps մեթոդաբանություն, ճիշտ ինտեգրումներ և ճիշտ ճարտարապետություն: Մենք հատուկ ուշադրություն ենք դարձնում անվտանգ հավելվածների ստեղծման սկզբունքներին: Տեղեկատվական անվտանգության ներկայացուցիչները յուրաքանչյուր նախագծին մասնակցում են ինչպես ճարտարապետության պլանավորման փուլում, այնպես էլ իրականացման գործընթացում: Նրանք նաև կառավարում են խոցելիության կոդի վերլուծության համակարգերը:

Ենթադրենք, մենք տեղակայում ենք քաղաքացիություն չունեցող մեր ծառայությունները. մենք դրանք ունենք Kubernetes-ում: Սա թույլ է տալիս բոլորին հանգիստ քնել՝ ծառայությունների ավտոմատ մասշտաբի և ավտոմատ բարձրացման շնորհիվ, իսկ հերթափոխը նշում է միջադեպերը:

Մեր միկրոծառայությունների ողջ գոյության ընթացքում միայն մեկ-երկու միջադեպ է եղել, որ հասել է մեր գիծ։ Այժմ շահագործման հետ կապված խնդիրներ չկան։ Մենք, իհարկե, ունենք ոչ թե 200, այլ մոտ 50 միկրոսերվիս, բայց դրանք օգտագործվում են առաջատար արտադրանքներում։ Եթե ​​ձախողվեին, մենք առաջինը կիմանայինք այդ մասին։

Միկրոծառայություններ և HR

Սերգեյ.

Ես համաձայն եմ իմ գործընկերոջ հետ աջակցության տեղափոխման հարցում, որ աշխատանքը պետք է ճիշտ կազմակերպել։ Բայց ես ձեզ կասեմ այն ​​խնդիրների մասին, որոնք, իհարկե, կան։

Նախ, տեխնոլոգիան նոր է. Սա լավ իմաստով հիպ է, և մասնագետ գտնելը, ով կհասկանա և կարող է դա ստեղծել, մեծ մարտահրավեր է: Ռեսուրսների համար մրցակցությունը խելահեղ է, ուստի փորձագետները արժեն իրենց քաշը ոսկով:

Երկրորդ՝ որոշակի լանդշաֆտների ստեղծմամբ և ծառայությունների աճող թվով պետք է անընդհատ լուծվի վերաօգտագործման խնդիրը։ Ինչպես ծրագրավորողներն են սիրում անել. «Եկեք հիմա այստեղ շատ հետաքրքիր բաներ գրենք…»: Դրա պատճառով համակարգը աճում է և կորցնում է իր արդյունավետությունը փողի, սեփականության արժեքի և այլնի առումով: Այսինքն՝ անհրաժեշտ է վերաօգտագործումը ներառել համակարգի ճարտարապետության մեջ, ներառել այն ծառայությունների ներդրման և ժառանգությունը նոր ճարտարապետություն փոխանցելու ճանապարհային քարտեզում։

Մեկ այլ խնդիր, թեև սա յուրովի լավ է, ներքին մրցակցությունն է։ «Օ՜, նոր նորաձև տղաներ են հայտնվել այստեղ, նրանք խոսում են նոր լեզվով»: Մարդիկ, իհարկե, տարբեր են։ Կան նրանք, ովքեր սովոր են գրել Java-ով, և նրանք, ովքեր գրում և օգտագործում են Docker-ը և Kubernetes-ը: Սրանք բոլորովին տարբեր մարդիկ են, տարբեր կերպ են խոսում, տարբեր տերմիններ են օգտագործում և երբեմն իրար չեն հասկանում։ Պրակտիկան կիսելու կարողությունը կամ անկարողությունը, գիտելիքների փոխանակումը, այս առումով նույնպես խնդիր է:

Դե, ռեսուրսների ընդլայնում: «Հիանալի է, գնանք։ Եվ հիմա մենք ուզում ենք ավելի արագ, ավելին: Ի՞նչ, չես կարող: Հնարավո՞ր չէ տարեկան երկու անգամ ավելի շատ առաքել: Իսկ ինչո՞ւ»։ Նման աճող ցավերը, հավանաբար, շատ բաների, շատ մոտեցումների ստանդարտ են, և դուք կարող եք դրանք զգալ:

Մոնիտորինգի վերաբերյալ. Ինձ թվում է, որ ծառայությունները կամ արդյունաբերական մոնիտորինգի գործիքներն արդեն սովորում են կամ կարողանում են աշխատել ինչպես Docker-ի, այնպես էլ Kubernetes-ի հետ այլ, ոչ ստանդարտ ռեժիմով: Որպեսզի, օրինակ, չվերջացնեք 500 Java մեքենաների հետ, որոնց տակ այս ամենը աշխատում է, մասնավորապես, այն համախմբվում է: Բայց այս ապրանքները դեռ հասունության պակաս ունեն, նրանք պետք է անցնեն դրա միջով: Թեման իսկապես նոր է, այն կշարունակի զարգանալ։

Դմիտրի.

Այո, շատ հետաքրքիր է: Եվ սա վերաբերում է HR-ին: Միգուցե ձեր HR գործընթացը և HR ապրանքանիշը մի փոքր փոխվել են այս 3 տարիների ընթացքում: Դուք սկսեցիք հավաքագրել այլ մարդկանց տարբեր իրավասություններով: Եվ հավանաբար կան և՛ դրական, և՛ դեմ կողմեր: Նախկինում բլոկչեյնը և տվյալների գիտությունը մեծ աղմուկ էին բարձրացնում, և դրանց մասնագետները միլիոններ էին արժենում: Հիմա ինքնարժեքը նվազում է, շուկան հագեցվում է, նման միտում կա նաև միկրոծառայությունների ոլորտում։

Սերգեյ.

Այո, բացարձակապես։

Ալեքսանդր:

HR-ը հարց է տալիս. «Որտե՞ղ է ձեր վարդագույն միաեղջյուրը հետնամասի և ճակատի միջև»: HR-ը չի հասկանում, թե ինչ է միկրոսերվիսը: Մենք նրանց ասացինք գաղտնիքը և ասացինք, որ բեքենդն ամեն ինչ արել է, և միաեղջյուր չկա: Սակայն HR-ը փոխվում է, արագ սովորում և հավաքագրում մարդկանց, ովքեր ունեն հիմնական ՏՏ գիտելիքներ:

Միկրոծառայությունների էվոլյուցիան

Դմիտրի.

Եթե ​​նայեք թիրախային ճարտարապետությանը, միկրոսերվիսները նման հրեշի տեսք ունեն: Ձեր ճանապարհորդությունը տևեց մի քանի տարի: Մյուսները մեկ տարի ունեն, մյուսները երեք տարի: Դուք կանխատեսե՞լ եք բոլոր խնդիրները, թիրախային ճարտարապետությունը, ինչ-որ բան փոխվե՞լ է։ Օրինակ, միկրոսերվիսների դեպքում այժմ նորից հայտնվում են դարպասներ և սպասարկման ցանցեր։ Դուք սկզբում օգտագործե՞լ եք դրանք, թե՞ փոխել եք հենց ճարտարապետությունը: Դուք նման մարտահրավերներ ունե՞ք։

Սերգեյ.

Մենք արդեն վերաշարադրել ենք կապի մի քանի արձանագրություններ։ Սկզբում կար մի արձանագրություն, հիմա անցանք մյուսի։ Մենք բարձրացնում ենք անվտանգությունն ու հուսալիությունը։ Մենք սկսեցինք ձեռնարկությունների տեխնոլոգիաներից՝ Oracle, Web Logic: Այժմ մենք հեռանում ենք միկրոծառայությունների ոլորտում տեխնոլոգիական ձեռնարկությունների արտադրանքներից և անցնում բաց կոդով կամ ամբողջովին բաց տեխնոլոգիաների: Մենք հրաժարվում ենք տվյալների շտեմարաններից և շարժվում դեպի այն, ինչը մեզ համար ավելի արդյունավետ է աշխատում այս մոդելում: Մեզ այլևս պետք չեն Oracle տեխնոլոգիաները։

Մենք սկսել ենք պարզապես որպես ծառայություն՝ չմտածելով, թե մեզ ինչքան քեշ է պետք, ինչ կանեինք, երբ կապ չկար միկրոսերվիսի հետ, այլ անհրաժեշտ էին տվյալներ և այլն։ Այժմ մենք մշակում ենք հարթակ, որպեսզի կարողանանք նկարագրել ճարտարապետությունը։ ոչ թե ծառայությունների լեզվով, իսկ բիզնեսի լեզվով ասած՝ բիզնես տրամաբանությունը տեղափոխեք հաջորդ մակարդակ, երբ սկսենք բառերով խոսել։ Հիմա մենք սովորել ենք տառերով խոսել, և հաջորդ մակարդակն այն է, երբ ծառայությունները կհավաքվեն ինչ-որ ագրեգատի մեջ, երբ սա արդեն բառ է, օրինակ՝ մի ամբողջ ապրանքի քարտ: Այն հավաքվում է միկրոսերվիսներից, բայց դա API է, որը կառուցված է դրա վրա:

Անվտանգությունը շատ կարևոր է։ Հենց սկսում ես հասանելի լինել և ունես ծառայություն, որի միջոցով կարող ես շատ հետաքրքիր բաներ ստանալ, և շատ արագ՝ վայրկյանների ընթացքում, ապա ցանկություն է առաջանում ստանալ այն ոչ ամենաապահով ձևով։ Դրանից խուսափելու համար մենք պետք է փոխեինք փորձարկման և մոնիտորինգի մոտեցումները: Մենք պետք է փոխեինք թիմը, առաքման կառավարման կառուցվածքը, CI/CD:

Սա էվոլյուցիա է, ինչպես հեռախոսների դեպքում, միայն շատ ավելի արագ. սկզբում կային կոճակով հեռախոսներ, հետո հայտնվեցին սմարթֆոններ: Նրանք վերագրեցին և վերափոխեցին ապրանքը, քանի որ շուկան այլ կարիք ուներ: Ահա թե ինչպես ենք մենք զարգանում՝ առաջին դասարան, տասներորդ դասարան, աշխատանք։

Կրկնվող, տարեկան ինչ-որ բան է դրվում տեխնոլոգիայի տեսանկյունից, մեկ այլ բան՝ կուտակումների և կարիքների տեսանկյունից: Մենք մի բան ենք կապում մյուսի հետ: Թիմը 20%-ը ծախսում է թիմի տեխնիկական պարտքի և տեխնիկական աջակցության վրա, 80%-ը՝ տնտեսվարող սուբյեկտի վրա։ Եվ մենք շարժվում ենք՝ հասկանալով, թե ինչու ենք դա անում, ինչու ենք անում այս տեխնոլոգիական բարելավումները, ինչի կհանգեցնեն դրանք: Դրա նման.

Դմիտրի.

Թույն. Ի՞նչ կա MegaFon-ում:

Ալեքսանդր:

Հիմնական մարտահրավերը, երբ մենք հասանք միկրոսերվիսներին, քաոսի մեջ չընկնելն էր: MegaFon-ի ճարտարապետական ​​գրասենյակը անմիջապես միացավ մեզ, նույնիսկ դարձավ նախաձեռնող և վարորդ. այժմ մենք ունենք շատ ուժեղ ճարտարապետություն: Նրա խնդիրն էր հասկանալ, թե ինչ թիրախային մոդելի ենք գնում և ինչ տեխնոլոգիաներ պետք է փորձարկվեն։ Ճարտարապետությամբ մենք ինքներս վարեցինք այս օդաչուները:

Հաջորդ հարցը հետևյալն էր. «Այդ դեպքում ինչպե՞ս շահագործել այս ամենը»: Եվ ևս մեկը. «Ինչպե՞ս ապահովել միկրոծառայությունների միջև թափանցիկ փոխգործակցությունը»: Ծառայության ցանցը մեզ օգնեց պատասխանել վերջին հարցին: Մենք օդաչուեցինք Istio-ին և հավանեցինք արդյունքները: Այժմ մենք գտնվում ենք արտադրողական գոտիներ դուրս գալու փուլում։ Մենք դրական ենք վերաբերվում բոլոր մարտահրավերներին, այն է, որ մենք պետք է անընդհատ փոխենք փաթեթը, սովորենք նոր բան: Մենք շահագրգռված ենք զարգացնել, ոչ թե շահագործել հին լուծումները։

Դմիտրի.

Ոսկե խոսքեր! Նման մարտահրավերները թիմին և բիզնեսին պահում են իրենց ոտքի վրա և ստեղծում ապագա: GDPR-ը ստեղծել է տվյալների պաշտպանության գլխավոր սպաներ, իսկ ընթացիկ մարտահրավերները ստեղծում են միկրոծառայությունների և ճարտարապետության գլխավոր սպաներ: Եվ դա հաճելի է:

Մենք շատ ենք քննարկել։ Հիմնական բանն այն է, որ միկրոսերվիսների լավ դիզայնը և ճարտարապետությունն ինքնին թույլ են տալիս խուսափել բազմաթիվ սխալներից: Իհարկե, գործընթացը կրկնվող և էվոլյուցիոն է, բայց դա ապագան է:

Շնորհակալություն բոլոր մասնակիցներին, շնորհակալություն Սերգեյին և Ալեքսանդրին:

Հարցեր հանդիսատեսից

Հարց հանդիսատեսից (1).

Սերգեյ, ինչպե՞ս է փոխվել ՏՏ մենեջմենթը Ձեր ընկերությունում։ Ես հասկանում եմ, որ երբ կա մի քանի համակարգերի մեծ փաթեթ, այն ինչպես է կառավարվում, բավականին պարզ և տրամաբանական գործընթաց է: Ինչպե՞ս վերակառուցեցիք ՏՏ բաղադրիչի կառավարումը այն բանից հետո, երբ այդքան կարճ ժամանակում ինտեգրվեցին շատ մեծ թվով միկրոծառայություններ:

Սերգեյ.

Համաձայն եմ իմ գործընկերոջ հետ, որ ճարտարապետությունը շատ կարևոր է որպես փոփոխությունների շարժիչ ուժ: Սկսեցինք ճարտարապետական ​​բաժին ունենալով։ Ճարտարապետները միաժամանակ հանդիսանում են ֆունկցիոնալության բաշխման և լանդշաֆտում այն ​​հայտնվելու պահանջների սեփականատերերը: Այսպիսով, նրանք նաև հանդես են գալիս որպես այս փոփոխությունների համակարգող։ Որպես արդյունք, եղան հատուկ փոփոխություններ առաքման կոնկրետ գործընթացում, երբ մենք ստեղծեցինք CI/CD հարթակ:

Սակայն ստանդարտը, զարգացման, բիզնեսի վերլուծության, փորձարկման և զարգացման հիմնական սկզբունքները չեն չեղարկվել։ Մենք պարզապես արագություն ավելացրինք: Նախկինում ցիկլը շատ էր տևում, փորձարկման միջավայրում տեղադրումը շատ ավելին էր պահանջում: Հիմա բիզնեսը տեսնում է օգուտը և ասում. «Ինչո՞ւ մենք չենք կարող նույնն անել այլ վայրերում»:

Դա լավ իմաստով նման է պատվաստանյութի տեսքով ներարկման, որը ցույց տվեց. դուք կարող եք դա անել այս կերպ, բայց կարող եք դա անել այլ կերպ: Իհարկե, խնդիր կա կադրերի, իրավասությունների, գիտելիքի, դիմադրության մեջ։

Հարց հանդիսատեսից (2).

Միկրոծառայությունների ճարտարապետության քննադատներն ասում են, որ փորձարկումն ու զարգացումը դժվար է: Սա տրամաբանական է, որտեղ ամեն ինչ բարդանում է: Ի՞նչ դժվարությունների հանդիպեց ձեր թիմը և ինչպե՞ս հաղթահարեցիք դրանք: Հարց բոլորին.

Ալեքսանդր:

Դժվարություններ կան միկրոսերվիսներից հարթակ տեղափոխվելիս, բայց դրանք լուծելի են։

Օրինակ, մենք պատրաստում ենք արտադրանք, որը բաղկացած է 5-7 միկրոսերվիսներից։ Մենք պետք է տրամադրենք ինտեգրման թեստեր ամբողջ միկրոծառայությունների փաթեթում, որպեսզի կանաչ լույս տանք գլխավոր մասնաճյուղ տեղափոխվելու համար: Այս խնդիրը մեզ համար նորություն չէր. մենք դա անում էինք երկար ժամանակ BSS-ում, երբ վաճառողը մեզ մատակարարեց արդեն առաքված լուծումները:

Իսկ մեր խնդիրը միայն փոքր թիմում է։ Մեկ պայմանական արտադրանքի համար անհրաժեշտ է մեկ ՈԱ ինժեներ։ Եվ այսպես, մենք առաքում ենք 5-7 միկրոծառայությունների արտադրանք, որոնցից 2-3-ը կարող են մշակվել երրորդ անձանց կողմից: Օրինակ, մենք ունենք արտադրանք, որի մշակմանը մասնակցում են մեր բիլինգային համակարգի վաճառողը, Mail.ru Group-ը և MegaFon R&D-ը: Մենք պետք է սա ծածկենք թեստերով, նախքան այն արտադրություն ուղարկելը: QA-ի ինժեներն այս ապրանքի վրա աշխատել է մեկուկես ամիս, իսկ թիմի մնացած անդամները մնացել են առանց նրա աջակցության:

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

Սերգեյ.

Ես ուզում եմ ավելացնել. Ես բացարձակապես համաձայն եմ բարդությունների հետ, դրանք լինում են: Լանդշաֆտը դառնում է ավելի բարդ, և ավելանում են վերադիր ծախսերը, հատկապես փորձարկման համար: Ինչպես վարվել սրա հետ. անցնել ավտոմատացված թեստավորման: Այո, դուք ստիպված կլինեք լրացուցիչ ներդրումներ կատարել ավտոթեստերի և միավորի թեստեր գրելու համար: Որպեսզի մշակողները չկարողանան պարտավորվել առանց թեստը անցնելու, նրանք չէին կարող փոխել կոդը: Որպեսզի նույնիսկ սեղմման կոճակը չաշխատի առանց ավտոմատ փորձարկման, միավորի փորձարկման:

Կարևոր է պահպանել նախկին ֆունկցիոնալությունը, և դա լրացուցիչ ծախս է: Եթե ​​դուք վերաշարադրում եք տեխնոլոգիան մեկ այլ արձանագրության մեջ, ապա այն վերագրում եք այնքան ժամանակ, մինչև ամեն ինչ ամբողջությամբ փակեք:

Մենք երբեմն միտումնավոր չենք անում վերջնական թեստավորում, քանի որ չենք ցանկանում դադարեցնել զարգացումը, թեև մենք նույնպես ունենք մեկը մյուսի հետևից: Լանդշաֆտը շատ մեծ է, բարդ, կան բազմաթիվ համակարգեր։ Երբեմն դա պարզապես կոճղեր է. այո, դուք նվազեցնում եք անվտանգության սահմանը, ավելի շատ ռիսկեր են հայտնվում: Բայց միևնույն ժամանակ դուք թողարկում եք մատակարարումը:

Ալեքսանդր:

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

Հարց հանդիսատեսից (3).

Որքան հասկանում եմ, միկրոսերվիսները սկզբում աճում էին առանձին թիմից և այժմ գոյություն ունեն այս մոդելում: Որո՞նք են դրա դրական և բացասական կողմերը:

Մենք պարզապես նման պատմություն ունենք՝ առաջացել է միկրոսերվիսների մի գործարան։ Այժմ մենք կոնցեպտուալ առումով հասել ենք այն կետին, որ մենք այս մոտեցումը ընդլայնում ենք արտադրության վրա՝ ըստ հոսքերի և համակարգերի: Այսինքն՝ մենք հեռանում ենք միկրոծառայությունների կենտրոնացված զարգացումից, միկրոսերվիսային մոդելներից, ավելի ենք մոտենում համակարգերին։

Համապատասխանաբար, մեր գործունեությունը գնում է նաև համակարգեր, այսինքն՝ մենք ապակենտրոնացնում ենք այս թեման։ Ո՞րն է ձեր մոտեցումը և ո՞րն է ձեր թիրախային պատմությունը:

Ալեքսանդր:

Դուք անմիջապես ձեր բերանից հանեցիք «միկրոծառայությունների գործարան» անվանումը. մենք նույնպես ուզում ենք մասշտաբավորել: Նախ, մենք հիմա իսկապես մեկ թիմ ունենք։ Մենք ցանկանում ենք բոլոր զարգացման թիմերին, որոնք ունի MegaFon-ը, հնարավորություն տալ աշխատել ընդհանուր էկոհամակարգում: Մենք չենք ցանկանում ամբողջությամբ ստանձնել զարգացման բոլոր գործառույթները, որոնք այժմ ունենք: Տեղական խնդիրն է մասշտաբը, գլոբալ խնդիրն է զարգացումը տանել միկրոսպասարկման շերտի բոլոր թիմերին:

Սերգեյ.

Ես ձեզ կասեմ մեր անցած ճանապարհը: Մենք իսկապես սկսեցինք աշխատել որպես մեկ թիմ, բայց հիմա միայնակ չենք։ Ես հետեւյալի կողմնակիցն եմ՝ գործընթացի տերը պետք է լինի։ Ինչ-որ մեկը պետք է հասկանա, կառավարի, վերահսկի և կառուցի միկրոծառայությունների զարգացման գործընթացը: Նա պետք է ունենա ռեսուրսներ և զբաղվի ռեսուրսների կառավարմամբ:

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

Միևնույն ժամանակ, գործընթացը մնում է ընդհանուր, վերահսկվող, այն ընթանում է ընդհանուր տեխնոլոգիական սկզբունքներով, միավորի փորձարկումներով և այլն՝ այն ամենը, ինչ կառուցված է վերևում։ Կարող են լինել սյունակներ՝ արտադրանքի մոտեցման տարբեր բաժիններից հավաքագրված ռեսուրսների տեսքով:

Ալեքսանդր:

Սերգեյ, դու իրականում գործընթացի տերն ես, չէ՞։ Արդյո՞ք առաջադրանքների մնացորդները համօգտագործվում են: Ո՞վ է պատասխանատու դրա բաշխման համար:

Սերգեյ.

Տեսեք. ահա նորից խառնուրդը: Կա մի կուտակում, որը ձևավորվում է տեխնոլոգիական բարելավումների հիման վրա. սա մեկ պատմություն է: Կա հետածք, որը ձևակերպված է նախագծերից, և կա ապրանքների կուտակում։ Սակայն սպասարկման ապրանքներից յուրաքանչյուրի մեջ ներմուծման կամ այս ծառայության ստեղծման հաջորդականությունը մշակվում է արտադրանքի մասնագետի կողմից: Նա ՏՏ տնօրինությունում չէ, նրան հատուկ հեռացրին։ Բայց իմ ժողովուրդը հաստատ աշխատում է նույն գործընթացով։

Տարբեր ուղղություններով կուտակված կուտակումների տերը՝ փոփոխությունների կուտակումները, կլինեն տարբեր մարդիկ։ Տեխնոլոգիական ծառայությունների կապը, դրանց կազմակերպման սկզբունքը՝ այս ամենը կլինի ՏՏ-ում։ Ես նույնպես ունեմ հարթակի և ռեսուրսների սեփականատերը: Վերևում այն ​​է, ինչ վերաբերում է հետաձգված և ֆունկցիոնալ փոփոխություններին և այս առումով ճարտարապետությանը:

Ենթադրենք, բիզնեսն ասում է. «Մենք ցանկանում ենք այս գործառույթը, մենք ցանկանում ենք ստեղծել նոր արտադրանք՝ վերափոխել վարկը»: Մենք պատասխանում ենք. «Այո, մենք նորից կանենք դա»: Ճարտարապետներն ասում են. «Եկեք մտածենք՝ վարկի մեջ որտե՞ղ ենք գրելու միկրոսերվիսներ և ինչպե՞ս ենք դա անելու»։ Այնուհետև մենք այն բաժանում ենք նախագծերի, ապրանքների կամ տեխնոլոգիական փաթեթի, դնում ենք թիմերի մեջ և իրականացնում: Դուք ներքին արտադրանք եք ստեղծել և որոշել եք այս ապրանքի մեջ օգտագործել միկրոսերվիսներ: Մենք ասում ենք. «Այժմ մեր ունեցած ժառանգական համակարգերը կամ առաջին գծի համակարգերը պետք է անցնեն այս միկրոծառայությունների»: Ըստ ճարտարապետների. Գնա»: Իսկ արտադրանքի մասնագետները կամ բիզնեսի սեփականատերերը հասկանում են, թե որքան հզորություն է հատկացվում, երբ է արվելու և ինչու։

Քննարկման ավարտը, բայց ոչ բոլորը

Կազմակերպվել է mailto:CLOUD կոնֆերանսը Mail.ru Cloud Solutions.

Մենք նաև այլ միջոցառումներ ենք անում, օրինակ. @Kubernetes Meetup, որտեղ մենք միշտ փնտրում ենք հիանալի խոսնակներ.

• Հետևեք @Kubernetes-ին և @Meetup-ի այլ նորություններին մեր Telegram ալիքում t.me/k8s_mail
• Հետաքրքրվա՞ծ եք խոսել @Meetups-ից մեկում: Թողեք հարցումը mcs.mail.ru/speak

Source: www.habr.com