Монолиттерден микросервистерге дейін: M.Video-Eldorado және MegaFon тәжірибесі

Монолиттерден микросервистерге дейін: M.Video-Eldorado және MegaFon тәжірибесі

25 сәуірде біз Mail.ru Group-та бұлттар және айнала туралы конференция өткіздік - mailto: Cloud. Бірнеше маңызды сәт:

  • Басты ресейлік провайдерлер — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center және Yandex.Cloud біздің бұлттық нарықтың ерекшеліктері мен олардың қызметтері туралы айтты;
  • Bitrix24 әріптестері бұл туралы айтып берді көп бұлтқа келді;
  • Лерой Мерлин, Откритие, Бургер Кинг және Schneider Electric қызықты болды бұлтты тұтынушылардан көру — олардың бизнесі IT үшін қандай міндеттер қояды және қандай технологияларды, соның ішінде бұлтты технологияларды ең перспективалы деп санайды.

Сіз барлық бейнелерді mailto:CLOUD конференциясынан көре аласыз байланыс, және осы жерден микросервистер туралы талқылау қалай өткенін оқи аласыз. MegaFon бизнес жүйелерін зерттеу және дамыту орталығының басшысы Александр Деулин мен M.Video-Eldorado тобының ақпараттық технологиялар жөніндегі директоры Сергей Сергеев монолиттерден құтылудың сәтті оқиғаларымен бөлісті. Біз сондай-ақ АТ-стратегиясының, процестердің және тіпті HR-нің байланысты мәселелерін талқыладық.

Панельге қатысушылар

  • Сергей Сергеев, CIO тобы «М.Видео-Эльдорадо»;
  • Александр Деулин, бизнес жүйелерін зерттеу және дамыту орталығының басшысы MegaFon;
  • Модератор — Дмитрий Лазаренко, PaaS бағытының жетекшісі Mail.ru бұлтты шешімдері.

Александр Деулиннің сөзінен кейін «MegaFon микросервис платформасы арқылы бизнесін қалай кеңейтуде» оны талқылауға M.Video-Eldorado-дан Сергей Сергеев және Mail.ru Cloud Solutions пікірталас модераторы Дмитрий Лазаренко қосылды.

Төменде біз сіз үшін талқылаудың стенограммасын дайындадық, бірақ сіз бейнені де көре аласыз:

Микросервистерге көшу нарық қажеттіліктеріне жауап болып табылады

Дмитрий:

Микросервистерге көшуде сәтті тәжірибеңіз болды ма? Жалпы: микросервистерді пайдаланудың немесе монолиттерден микросервистерге көшудің ең үлкен бизнес пайдасын қайдан көресіз?

Сергей:

Біз микросервистерге көшуде белгілі бір жолмен келдік және бұл тәсілді үш жылдан астам қолданып келеміз. Микросервистердің қажеттілігін негіздеген бірінші қажеттілік - бұл әр түрлі фронтальды өнімдердің бэк-офиспен шексіз интеграциясы. Әр жолы біз осы немесе басқа қызметтің жұмыс істеуі үшін өз ережелерімізді жүзеге асыра отырып, қосымша интеграция мен дамуды жасауға мәжбүр болдық.

Бір кездері біз жүйелеріміздің жұмысын және функционалдылықты шығаруды жылдамдату керек екенін түсіндік. Сол кезде микросервис және микросервис тәсілі сияқты тұжырымдамалар нарықта бұрыннан бар еді, біз оны қолданып көруді шештік. Бұл 2016 жылы басталды. Содан кейін платформа төселіп, алғашқы 10 қызметті жеке топ жүзеге асырды.

Алғашқы қызметтердің бірі, ең көп жүктелгені бағаны есептеу қызметі болды. Кез келген арнаға, M.Video-Eldorado компаниялар тобына, ол веб-сайт немесе бөлшек сауда дүкеніне кірген сайын, сол жерден өнімді таңдаңыз, веб-сайттан немесе «Кәрзеңке» бағасын қараңыз, құны автоматты түрде көрсетіледі. бір қызмет бойынша есептеледі. Бұл не үшін қажет: бұған дейін әр жүйеде акциялармен жұмыс істеудің өзіндік принциптері болды - жеңілдіктермен және т.б. Біздің бэк-офис баға белгілеумен айналысады, жеңілдік функциясы басқа жүйеде енгізілген. Бұл орталықтандырылған болуы керек және бизнес-процесс түрінде жасалатын бірегей, бөлінетін қызмет бізге мұны жүзеге асыруға мүмкіндік береді. Біз осылай бастадық.

Алғашқы нәтижелердің құндылығы өте үлкен болды. Біріншіден, біз бөлек және біріктірілген түрде жұмыс істеуге мүмкіндік беретін бөлінетін нысандарды жасай алдық. Екіншіден, біз көбірек жүйелермен біріктіру тұрғысынан меншік құнын төмендеттік.

Соңғы үш жылда біз үш алдыңғы қатарлы жүйені қостық. Оларды компания көтере алатындай ресурстармен қамтамасыз ету қиын болды. Сондықтан нарыққа жылдамдық, ішкі шығындар мен тиімділік тұрғысынан жауап беретін жаңа сауда нүктелерін іздеу міндеті туындады.

Микросервистерге көшудің сәттілігін қалай өлшеуге болады

Дмитрий:

Микросервистерге көшудегі сәттілік қалай анықталады? Әрбір компанияда «бұрын» қандай болды? Өтпелі кезеңнің сәттілігін анықтау үшін қандай көрсеткішті қолдандыңыз және оны нақты кім анықтады?

Сергей:

Біріншіден, ол IT-те жаңа мүмкіндіктерді «құлпын ашатын» белсендіруші ретінде дүниеге келді. Бізге нарықтық қиындықтарға жауап бере отырып, салыстырмалы түрде бірдей ақшаға бәрін тезірек жасау қажет болды. Қазір табыс әртүрлі жүйелер қайта пайдаланатын қызметтердің санында, процестерді бір-бірімен біріктіруде көрінеді. Қазір бұл, бірақ сол сәтте платформа құру және біз мұны істей алатын гипотезаны растау мүмкіндігі болды, бұл нәтиже береді және бизнес жағдайын есептейді.

Александр:

Сәттілік - бұл ішкі сезім. Бизнес әрқашан көп нәрсені қалайды және біздің артта қалуымыздың тереңдігі табыстың дәлелі болып табылады. Маған солай көрінеді.

Сергей:

Иә мен келісемін. Үш жылдың ішінде бізде екі жүзден астам қызмет пен артта қалулар бар. Командадағы ресурстарға деген қажеттілік тек қана өсуде - жыл сайын 30%. Бұл адамдар сезінгендіктен болып жатыр: бұл жылдамырақ, бұл басқаша, әртүрлі технологиялар бар, мұның бәрі дамып келеді.

Микросервистер келеді, бірақ өзегі қалады

Дмитрий:

Бұл дамуға инвестиция салатын бітпейтін процесс сияқты. Бизнеске арналған микросервистерге көшу қазірдің өзінде аяқталды ма, жоқ па?

Сергей:

Жауап беру өте оңай. Сіз қалай ойлайсыз: телефондарды ауыстыру шексіз процесс пе? Біз жыл сайын телефон сатып аламыз. Міне, жылдамдық қажет болғанша, нарыққа бейімделу үшін кейбір өзгерістер қажет болады. Бұл стандартты нәрселерден бас тартамыз дегенді білдірмейді.

Бірақ біз бәрін бірден жауып, қайта жасай алмаймыз. Бізде бұрын қол жетімді болған, стандартты біріктіру қызметтері бар: кәсіпорын автобустары және т.б. Бірақ артта қалушылық бар, қажеттілік те бар. Мобильді қосымшалардың саны және олардың функционалдығы артып келеді. Бұл ретте 30 пайызға артық ақша беріледі деп ешкім айтпайды. Яғни, әрқашан бір жағынан қажеттілік болса, екінші жағынан тиімділікті іздеу.

Дмитрий:

Өмір жақсы жағдайда. (Күлді)

Александр:

Жалпы, иә. Бізде ландшафттан негізгі бөлікті алып тастаудың революциялық тәсілдері жоқ. Жүйелерді микросервис архитектурасына сәйкес келетіндей етіп декомпозициялау, жүйелердің бір-біріне әсерін азайту бойынша жүйелі жұмыстар жүргізілуде.

Бірақ біз негізгі бөлікті сақтауды жоспарлап отырмыз, өйткені оператордың ландшафтында әрқашан біз сатып алатын платформалар болады. Тағы да, бізге салауатты тепе-теңдік қажет: біз өзегін кесуге асықпауымыз керек. Біз жүйелерді қатар қоямыз, енді біз көптеген негізгі бөліктердің үстінде екеніміз белгілі болды. Әрі қарай, функционалдылықты дамыта отырып, біз байланыс қызметтерімен жұмыс істейтін барлық арналар үшін қажетті өкілдіктерді жасаймыз.

Кәсіпорындарға микросервистерді қалай сатуға болады

Дмитрий:

Мені де қызықтырады - ауыспаған, бірақ жоспарлап отырғандар үшін: бұл идеяны бизнеске сату қаншалықты оңай болды және бұл шытырман оқиға, инвестициялық жоба ма? Немесе бұл саналы стратегия ма: енді біз микросервистерге барамыз, міне, бізді ештеңе тоқтатпайды. Сізге қалай болды?

Сергей:

Біз тәсілді емес, бизнес пайдасын саттық. Бизнесте мәселе болды, оны шешуге тырыстық. Ол сол кезде әр түрлі арналардың бағаны есептеудің әртүрлі қағидаттарын - акциялар үшін, акциялар үшін және т.б. Күту қиын болды, қателер орын алды және біз тұтынушылардың шағымдарын тыңдадық. Яғни, біз мәселенің шешімін сататынбыз, бірақ платформа жасау үшін ақша қажет екендігімен келдік. Және олар инвестицияның бірінші кезеңі мысалында іскерлік жағдайды көрсетті: біз оны қалай өтейміз және бұл бізге не істеуге мүмкіндік береді.

Дмитрий:

Бірінші кезеңнің уақытын қандай да бір түрде жазып алдыңыз ба?

Сергей:

Иә, әрине. Біз ядроны платформа ретінде жасап, ұшқышты сынауға 6 ай уақыт бөлдік. Осы уақыт ішінде біз ұшқыш конькимен сырғанау алаңын жасауға тырыстық. Содан кейін гипотеза расталды және ол жұмыс істейтіндіктен, бұл біз жалғастыра алатынымызды білдіреді. Олар команданы қайталай бастады және нығайтты - олар оны дәл осылай жасайтын жеке бөлімге ауыстырды.

Келесі кезекте бизнес қажеттіліктеріне, мүмкіндіктеріне, ресурстардың қолжетімділігіне және қазіргі уақытта жұмыс істеп жатқан барлық нәрселерге негізделген жүйелі жұмыс келеді.

Дмитрий:

ЖАРАЙДЫ МА. Александр, не айтасыз?

Александр:

Біздің микросервистер «теңіз көбігінен» пайда болды - ресурстарды үнемдеу, сервер сыйымдылығы түріндегі кейбір қалдықтар және команда ішіндегі күштерді қайта бөлу есебінен. Бастапқыда бұл жобаны бизнеске сатпадық. Бұл біз зерттеп, соған сәйкес әзірлеген жоба еді. Біз 2018 жылдың басында бастадық және бұл бағытты ынтамен дамыттық. Сатылымдар енді ғана басталды және біз осы процесте жатырмыз.

Дмитрий:

Бизнес сізге Google сияқты әрекеттерді аптасына бір бос күнде жасауға мүмкіндік береді ме? Сізде осындай бағыт бар ма?

Александр:

Зерттеумен қатар біз бизнес мәселелерімен де айналыстық, сондықтан біздің барлық микросервистеріміз бизнес мәселелерін шешу болып табылады. Тек басында ғана біз абоненттік базаның шағын бөлігін қамтитын микросервистерді құрдық, ал қазір біз барлық дерлік флагмандық өнімдерде бармыз.

Ал материалдық әсер қазірдің өзінде анық - біз қазірдің өзінде санауға болады, егер біз ескі жолмен жүрсек, өнімді шығару жылдамдығы мен жоғалған кірісті бағалауға болады. Біз істі осыған негіздеп жатырмыз.

Микросервис: айқайлау ма әлде қажеттілік пе?

Дмитрий:

Сандар - сандар. Ал табыс немесе үнемделген ақша өте маңызды. Екінші жағына қарасаңыз ше? Микросервистер - бұл тренд, хайп және көптеген компаниялар оны теріс пайдаланып жатқан сияқты ма? Микросервистерге не істеп жатқаныңызды және аудармайтыныңызды қаншалықты анық ажыратасыз? Егер қазір мұра болса, 5 жылдан кейін сізде мұра қалады ма? 5 жылдан кейін M.Video-Eldorado және MegaFon компанияларында жұмыс істейтін ақпараттық жүйелердің жасы қанша болады? Он жылдық, он бес жылдық ақпараттық жүйелер бола ма, әлде жаңа буын бола ма? Бұған қалай қарайсыз?

Сергей:

Маған өте алысты ойлау қиын сияқты. Өткенге көз жүгіртсек, технология нарығы осылайша дамиды, соның ішінде машиналық оқыту және пайдаланушыны бет-жүзімен сәйкестендіру деп кім ойлаған? Бірақ алдағы жылдарға қарасаңыз, менің ойымша, негізгі жүйелер, компаниялардағы ERP класындағы кәсіпорын жүйелері - олар ұзақ уақыт бойы жұмыс істейді.

Біздің компаниялар 25 жаста, классикалық ERP жүйесі жүйе ландшафтында өте терең. Біз ол жерден кейбір бөліктерді алып, оларды микросервистерге біріктіруге тырысатынымыз анық, бірақ өзегі қалады. Мен үшін қазір барлық негізгі жүйелерді ауыстырып, жаңа жүйелердің басқа, жарқын жағына тез көшетінімізді елестету қиын.

Мен клиент пен тұтынушыға жақынырақ нәрсенің бәрі бизнестің ең үлкен пайдасы мен құндылығы, бейімделушілік пен жылдамдыққа, өзгертуге, «көріп көру, бас тарту, қайта пайдалану, басқаша істеу» сияқты маңыздылығын жақтаймын. қажет «— пейзаж өзгеретін жерде. Ал қораптағы өнімдер оған өте жақсы сәйкес келмейді. Кем дегенде, біз оны көрмейміз. Онда ең оңай, қарапайым шешімдер қажет.

Біз бұл дамуды көреміз:

  • негізгі ақпараттық жүйелер (негізінен бэк-офис);
  • микросервис түріндегі ортаңғы қабаттар ядроны қосады, біріктіреді, кэшті жасайды және т.б.;
  • алдыңғы қатарлы жүйелер тұтынушыға бағытталған;
  • жалпы нарықтарға, басқа жүйелерге және экожүйелерге біріктірілген интеграциялық деңгей. Бұл қабат мүмкіндігінше жеңіл, қарапайым және ең аз іскерлік логиканы қамтиды.

Бірақ, сонымен бірге, мен ескі қағидаларды дұрыс пайдаланса, оны әрі қарай қолдануды жақтаймын.

Сізде классикалық кәсіпорын жүйесі бар делік. Ол бір сатушының ландшафтында орналасқан және бір-бірімен жұмыс істейтін екі модульден тұрады. Сондай-ақ стандартты интеграциялық интерфейс бар. Неліктен оны қайта жасап, микросервисті сонда әкеліңіз?

Бірақ бэк-офисте 5 модуль болған кезде, олардан бизнес-процеске ақпарат жиналады, содан кейін оны 8-10 алдыңғы қатарлы жүйе пайдаланады, пайдасы бірден байқалады. Сіз бес бэк-офис жүйесінен алып, бизнес процесіне бағытталған оқшауланған қызметті жасайсыз. Қызметті технологиялық тұрғыдан жетілдіріңіз - ол ақпаратты кэштей алады және ақауларға төзімді, сонымен қатар құжаттармен немесе бизнес құрылымдарымен жұмыс істейді. Сіз оны барлық алдыңғы қатарлы өнімдермен бір принцип бойынша біріктіресіз. Олар алдыңғы қатардағы өнімнен бас тартты - олар жай ғана интеграцияны өшірді. Ертең сізге мобильді қосымша жазу немесе шағын веб-сайт жасау және функционалдылыққа тек бір бөлігін қосу керек - бәрі қарапайым: сіз оны конструктор сияқты жинадыңыз. Мен бұл бағыттағы дамуды байқаймын – кем дегенде біздің елде.

Александр:

Сергей біздің көзқарасымызды толығымен сипаттады, рахмет. Мен қайда бармайтынымызды айтайын - негізгі бөлікке, онлайн есепшот тақырыбына. Яғни, рейтинг пен зарядтау, шын мәнінде, ақшаны сенімді түрде есептен шығаратын «үлкен» қырман болып қалады. Және бұл жүйені біздің бақылаушы органдар сертификаттауды жалғастырады. Клиенттерге қарайтын барлық нәрсе, әрине, микросервистер.

Дмитрий:

Бұл жерде сертификаттау бір әңгіме. Көбірек қолдау көрсету керек шығар. Егер сіз қолдауға аз жұмсасаңыз немесе жүйе қолдау мен өзгертуді қажет етпесе, оған қол тигізбеу жақсы. Ақылға қонымды ымыраға келу.

Сенімді микросервистерді қалай дамытуға болады

Дмитрий:

Жақсы. Бірақ мені әлі де қызықтырады. Енді сіз сәттілік тарихын айтып жатырсыз: бәрі жақсы болды, біз микросервистерге көштік, идеяны бизнеске қорғадық және бәрі ойдағыдай болды. Бірақ мен басқа әңгімелерді естідім.

Екі жыл бұрын банктерге арналған жаңа микросервис платформасын әзірлеуге екі жыл инвестиция салған швейцариялық компания ақыры жобаны жауып тастады. Толығымен құлаған. Көптеген миллиондаған швейцариялық франк жұмсалды, бірақ соңында команда тарап кетті - нәтиже болмады.

Сізде осындай оқиғалар болды ма? Қандай да бір қиындықтар болды ма, жоқ па? Мысалы, микросервистерді қолдау және бақылау да компанияның операциялық қызметіндегі бас ауруы болып табылады. Өйткені, құрамдас бөліктердің саны ондаған есе артады. Сіз оны қалай көресіз, мұнда инвестиция салудың сәтсіз мысалдары болды ма? Ал сіз адамдарға мұндай мәселелерге тап болмас үшін не бере аласыз?

Александр:

Сәтсіз мысалдарға бизнестің басымдықтарды өзгертуі және жобалардан бас тартуы жатады. Дайындықтың жақсы сатысында (шын мәнінде MVP дайын), бизнес: «Бізде жаңа басымдықтар бар, біз басқа жобаға көшеміз және біз оны жабамыз» деді.

Бізде микросервистермен жаһандық ақаулар болған жоқ. Біз тыныш ұйықтаймыз, бізде бүкіл BSS [бизнесті қолдау жүйесі] қызмет көрсететін тәулік бойы жұмыс ауысымы бар.

Тағы бір нәрсе - біз қораптағы өнімдерге қолданылатын ережелерге сәйкес микросервистерді жалға береміз. Табыстың кілті мынада, біріншіден, микросервисті өндіріске толығымен дайындайтын топты жинау керек. Дамудың өзі шартты түрде 40% құрайды. Қалғаны - аналитика, DevSecOps әдістемесі, дұрыс интеграция және дұрыс архитектура. Біз қауіпсіз қолданбаларды құру принциптеріне ерекше назар аударамыз. Ақпараттық қауіпсіздік өкілдері әр жобаға сәулетті жоспарлау кезеңінде де, іске асыру процесінде де қатысады. Олар сондай-ақ осалдықтар үшін кодты талдау жүйелерін басқарады.

Біз азаматтығы жоқ қызметтерімізді орналастырдық делік - бізде олар Кубернетесте бар. Бұл қызметтерді автоматты түрде масштабтау және автоматты көтеру арқасында барлығына тыныш ұйықтауға мүмкіндік береді, ал кезекші ауысым оқиғаларды көтереді.

Біздің микросервистердің бүкіл өмірінде біздің желіге жеткен бір-екі оқиға ғана болды. Қазір операцияда қиындықтар жоқ. Бізде, әрине, 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):

Сергей, сіздің компанияңызда IT-менеджмент қалай өзгерді? Мен бірнеше жүйенің үлкен стекі болған кезде оны қалай басқаратындығы өте түсінікті және логикалық процесс екенін түсінемін. Қысқа уақыт ішінде өте көп микросервистерді біріктіргеннен кейін АТ құрамдас бөлігін басқаруды қалай қалпына келтірдіңіз?

Сергей:

Әріптесімнің архитектураның өзгерістер драйвері ретінде өте маңызды екендігімен келісемін. Біз сәулет бөлімінен бастадық. Сәулетшілер бір уақытта функционалдылықты бөлу мен оның ландшафтта қалай көрінетініне қойылатын талаптардың иелері болып табылады. Сондықтан олар осы өзгерістердің үйлестірушісі ретінде де әрекет етеді. Нәтижесінде CI/CD платформасын жасаған кезде нақты жеткізу процесінде нақты өзгерістер болды.

Бірақ стандартты, негізгі даму принциптері, бизнесті талдау, тестілеу және дамыту жойылған жоқ. Біз жай ғана жылдамдықты қостық. Бұрын цикл өте көп уақытты алды, сынақ орталарына орнату әлдеқайда көп уақытты алды. Енді бизнес пайдасын көріп: «Неге басқа жерлерде мұны істеуге болмайды?»

Бұл жақсы мағынада вакцина түріндегі инъекцияға ұқсайды: сіз мұны осылай жасай аласыз, бірақ оны басқа жолмен жасай аласыз. Әрине, кадрда, құзыретте, білімде, қарсылықта мәселе бар.

Аудиториядан сұрақ (2):

Микросервис архитектурасын сынаушылар тестілеу мен әзірлеу қиын екенін айтады. Бұл жағдай қиындайтын жерде логикалық. Сіздің командаңыз қандай қиындықтарға тап болды және сіз оларды қалай жеңдіңіз? Барлығына сұрақ.

Александр:

Микросервистерден платформаға көшу кезінде қиындықтар бар, бірақ оларды шешуге болады.

Мысалы, біз 5-7 микросервистен тұратын өнім жасап жатырмыз. Негізгі бөлімге көшу үшін жасыл шамды беру үшін біз бүкіл микросервис стегінде интеграциялық сынақтарды қамтамасыз етуіміз керек. Бұл тапсырма біз үшін жаңалық емес еді: біз мұны BSS-те ұзақ уақыт бойы істедік, бұл кезде сатушы бізге жеткізілген шешімдерді берді.

Ал біздің мәселе тек шағын ұжымда. Бір шартты өнім үшін бір QA инженері қажет. Осылайша, біз 5-7 микросервис өнімін жеткіземіз, оның 2-3-ін үшінші тарап әзірлеуі мүмкін. Мысалы, бізде өнім бар, оны әзірлеуге біздің төлем жүйесінің жеткізушісі, Mail.ru Group және MegaFon R&D қатысады. Біз оны өндіріске жібермес бұрын оны сынақтармен қамтуымыз керек. QA инженері бұл өніммен бір жарым ай жұмыс істеді, ал қалған команда оның қолдауынсыз қалды.

Бұл күрделілік тек масштабтаудан туындайды. Біз микросервистердің вакуумда болуы мүмкін емес екенін түсінеміз; абсолютті оқшаулау жоқ. Бір қызметті өзгерткен кезде біз әрқашан API келісімшартын сақтауға тырысамыз. Сорғыштың астында бірдеңе өзгерсе, алдыңғы қызмет қалады. Өзгерістер өлімге әкелетін болса, архитектуралық түрлендірудің қандай да бір түрі орын алады және біз мүлдем үйлеспейтін мүлде басқа деректер метамодельіне көшеміз - сонда ғана біз v2 қызметінің API сипаттамасының пайда болуы туралы айтамыз. Біз бірінші және екінші нұсқаларды бір уақытта қолдаймыз және барлық тұтынушылар екінші нұсқаға ауысқаннан кейін біріншісін жабамыз.

Сергей:

Мен қосқым келеді. Мен асқынулар туралы толықтай келісемін - олар болады. Ландшафт күрделене түсуде және үстеме шығындар, әсіресе сынақтар үшін артып келеді. Мұнымен қалай күресуге болады: автоматтандырылған тестілеуге ауысу. Иә, сізге автотесттер мен бірлік сынақтарын жазуға қосымша қаражат салуға тура келеді. Әзірлеушілер сынақтан өтпей әрекет ете алмайтыны үшін олар кодты өзгерте алмады. Тіпті басу түймесі автотестсіз, бірлік сынағысыз жұмыс істемеуі үшін.

Бұрынғы функционалдылықты сақтау маңызды, бұл қосымша шығындар. Технологияны басқа протоколға қайта жазсаңыз, барлығын толығымен жапқанша оны қайта жазасыз.

Біз кейде мақсатты түрде тестілеуді жасамаймыз, өйткені біз дамуды тоқтатқымыз келмейді, бірақ бізде бірінен соң бірі бар. Ландшафт өте үлкен, күрделі, көптеген жүйелер бар. Кейде бұл жай ғана тұнбалар - иә, сіз қауіпсіздік маржасын төмендетесіз, көбірек тәуекелдер пайда болады. Бірақ сонымен бірге сіз жеткізуді босатасыз.

Александр:

Иә, автотесттер мен бірлік сынақтары жоғары сапалы қызметті жасауға мүмкіндік береді. Біз бірлік пен интеграциялық сынақтарсыз өтпейтін құбырды жақтаймыз. Бізге жиі эмуляторлар мен коммерциялық жүйелерді сынақ аймақтары мен әзірлеу орталарына апаруға тура келеді, өйткені барлық жүйелерді сынақ аймақтарына орналастыру мүмкін емес. Сонымен қатар, олар жай ғана ылғалданбайды - біз жүйеден толыққанды жауап жасаймыз. Бұл микросервистермен жұмыс істеудің маңызды бөлігі және біз оған инвестиция салып жатырмыз. Онсыз хаос пайда болады.

Аудиториядан сұрақ (3):

Менің түсінуімше, микросервистер бастапқыда жеке топтан өсті және қазір осы үлгіде бар. Оның артықшылықтары мен кемшіліктері қандай?

Бізде ұқсас оқиға бар: микросервистердің бір түрі пайда болды. Енді біз концептуалды түрде осы тәсілді өндіріске ағындар мен жүйелер бойынша кеңейтетін жағдайға жеттік. Басқаша айтқанда, біз микросервистердің, микросервис үлгілерінің орталықтандырылған дамуынан алшақтап, жүйелерге жақындай түсудеміз.

Тиісінше, біздің жұмысымыз да жүйелерге барады, яғни біз бұл тақырыпты орталықсыздандырудамыз. Сіздің көзқарасыңыз қандай және сіздің мақсатыңыз қандай?

Александр:

Сіз «микросервис фабрикасы» деген атауды аузыңыздан алып тастадыңыз - біз де масштабтағымыз келеді. Біріншіден, қазір бізде бір команда бар. Біз MegaFon-ның барлық әзірлеушілер тобына ортақ экожүйеде жұмыс істеу мүмкіндігін ұсынғымыз келеді. Біз қазір бар әзірлеу функцияларын толығымен қабылдағымыз келмейді. Жергілікті міндет - масштабтау, жаһандық міндет - микросервис деңгейіндегі барлық командаларды дамыту.

Сергей:

Мен саған біз жүріп өткен жолды айтамын. Біз шынымен бір команда болып жұмыс істей бастадық, бірақ қазір жалғыз емеспіз. Мен мыналарды жақтаймын: процестің иесі болуы керек. Біреу микросервистерді әзірлеу процесін түсінуі, басқаруы, бақылауы және құруы керек. Ол ресурстарды иеленуі және ресурстарды басқарумен айналысуы керек.

Технологияларды, ерекшеліктерді білетін және микросервистерді құру жолын түсінетін бұл ресурстарды өнім топтарында орналастыруға болады. Бізде микросервис платформасының адамдары мобильді қосымшаны жасайтын өнім тобында болатын қоспасы бар. Олар бар, бірақ олар әзірлеу менеджерімен микросервис платформасын басқару бөлімінің процесіне сәйкес жұмыс істейді. Бұл бөлімшеде технологиямен айналысатын жеке топ бар. Яғни, біз ресурстардың ортақ пулын өз ара араластырамыз және оларды командаларға бере отырып, бөлеміз.

Сонымен қатар, процесс жалпы, бақыланатын болып қалады, ол жалпы технологиялық принциптерге сәйкес, қондырғыларды сынаумен және т.б. - үстіне салынғанның бәрі жүреді. Өнім тәсілінің әртүрлі бөлімдерінен жиналған ресурстар түріндегі бағандар болуы мүмкін.

Александр:

Сергей, сіз шынымен процестің иесісіз, солай ма? Тапсырмалар тізімі ортақ па? Оның таралуына кім жауапты?

Сергей:

Қараңыз: міне, тағы да араластырыңыз. Технологиялық жетілдірулер негізінде қалыптасатын артта қалу бар - бұл бір әңгіме. Жобалардан тұжырымдалған артта қалу бар және өнімдерден артта қалу бар. Бірақ қызмет көрсету өнімдерінің әрқайсысына енгізу реттілігін немесе осы қызметті жасауды өнім маманы әзірлейді. Ол IT дирекциясында жоқ, оны арнайы алып тастаған. Бірақ менің адамдарым сол үрдіс бойынша жұмыс істейтіні сөзсіз.

Әртүрлі бағыттағы артта қалудың иесі - өзгерістердің артта қалуы - әртүрлі адамдар болады. Технологиялық қызметтердің байланысы, оларды ұйымдастыру принципі – мұның бәрі АТ-да болады. Мен платформа мен ресурстарды да иеленемін. Жоғарғы жағында артта қалуға және функционалдық өзгерістерге және осы мағынадағы архитектураға қатысты.

Бизнес: «Біз бұл функцияны қалаймыз, біз жаңа өнімді жасағымыз келеді - несиені қайта жасағымыз келеді» делік. Біз: «Иә, қайта жасаймыз» деп жауап береміз. Сәулетшілер: «Ойланайық: микросервистерді несиенің қай жеріне жазамыз және оны қалай жасаймыз?» Содан кейін біз оны жобаларға, өнімдерге немесе технологиялық стекке бөлеміз, оны топтарға бөлеміз және оны жүзеге асырамыз. Сіз өнімді іштей жасап, осы өнімде микросервистерді пайдалануды шештіңіз бе? Біз: «Енді бізде болған бұрынғы жүйелер немесе алдыңғы қатарлы жүйелер осы микросервистерге ауысуы керек» дейміз. Сәулетшілер: «Сонымен: алдыңғы қатардағы өнімдердің ішіндегі технологиялық артта қалуда - микросервистерге көшу. Барыңыз». Ал өнім мамандары немесе бизнес иелері қуаттылықтың қанша бөлінгенін, қашан және не үшін жасалатынын түсінеді.

Талқылаудың соңы, бірақ бәрі емес

mailto:CLOUD конференциясы ұйымдастырылды Mail.ru бұлтты шешімдері.

Біз сондай-ақ басқа іс-шараларды өткіземіз - мысалы. @Kubernetes кездесуі, мұнда біз әрқашан керемет спикерлерді іздейміз:

  • Telegram арнамызда @Kubernetes және басқа @Meetup жаңалықтарын бақылаңыз t.me/k8s_mail
  • @Meetups бірінде сөйлегіңіз келе ме? Өтінім қалдырыңыз mcs.mail.ru/speak

Ақпарат көзі: www.habr.com

пікір қалдыру