25 красавіка мы ў Mail.ru Group правялі канферэнцыю пра аблокі і вакол. . Некалькі хайлайтаў:
- На адной сцэне сабраліся асноўныя - Пра спецыфіку нашага хмарнага рынку і сваіх сэрвісаў казалі Mail.ru Cloud Solutions, # CloudMTS, SberCloud, Selectel, "Ростелеком – ЦАД" і "Яндэкс. Воблака";
- Калегі з "Бітрыкс24" распавялі, як яны ;
- "Леруа Мерлен", "Адкрыццё", Burger King і Schneider Electric падалі цікавы - якія задачы іх бізнэс ставіць перад IT і якія тэхналогіі, у тым ліку хмарныя, бачацца ім найбольш перспектыўнымі.
Усе відэа з канферэнцыі mailto:CLOUD можна паглядзець , а тут можна пачытаць, як прайшла дыскусія пра мікрасэрвісы. Сваімі - паспяховымі - кейсамі збавення ад маналітаў падзяліліся Аляксандр Деулин, кіраўнік цэнтра даследавання і распрацоўкі бізнес-сістэм "Мегафона", і Сяргей Сяргееў, дырэктар па інфармацыйных тэхналогіях групы "М. Відэа-Эльдарада". Таксама абмеркавалі блізкія пытанні IT-стратэгіі, працэсаў і нават HR.
Удзельнікі дыскусіі
- Сяргей Сяргееў, дырэктар па інфармацыйных тэхналогіях групы «М.Відэа-Эльдарада»;
- Аляксандр Деулін, кіраўнік цэнтра даследавання і распрацоўкі бізнес-сістэм "Мегафона";
- Мадэратар - Дзмітрый Лазарэнка, кіраўнік PaaS-кірункі Mail.ru Cloud Solutions.
Пасля выступлення Аляксандра Дэвуліна да яго далучаюцца для дыскусіі Сяргей Сяргееў з "М. Відэа-Эльдарада" і мадэратар дыскусіі Дзмітрый Лазарэнка, Mail.ru Cloud Solutions.
Ніжэй мы падрыхтавалі для вас расшыфроўку дыскусіі, але таксама можна паглядзець відэа:
Пераход на мікрасэрвісы – рэакцыя на патрэбы рынку
Зміцер:
Ці быў у вас паспяховы досвед пераходу на мікрасэрвісы? І наогул: дзе вы бачыце найбольшую карысць у бізнэсе ад ужывання мікрасэрвісаў ці пераходу ад маналітаў да мікрасэрвісаў?
Сяргей:
Мы прайшлі ўжо некаторы шлях па пераходзе на мікрасэрвісы і выкарыстоўваем такі падыход больш за тры гады. Першай патрэбай, якая абгрунтавала неабходнасць мікрасэрвісаў, была бясконцая інтэграцыя розных франтавых прадуктаў з бэк-офісам. І кожны раз мы змушана рабілі дадатковую інтэграцыю, распрацоўку, рэалізоўваючы свае правілы па працы таго ці іншага сэрвісу.
У нейкі момант мы зразумелі, што нам трэба паскарэнне працы нашых сістэм і вываду функцыянальнасці. У той момант на рынку ўжо існавалі такія паняцці як мікрасэрвісы, мікрасэрвісны падыход, і мы вырашылі паспрабаваць. Пачалося гэта ў 2016 годзе. Тады была закладзена платформа і рэалізаваны першыя 10 сэрвісаў, сіламі асобнай каманды.
Адным з першых сэрвісаў, самых высоканагружаных, стаў сэрвіс разліку кошту. Кожны раз, калі вы прыходзіце ў любы канал, у групу кампаній "М. Відэа-Эльдарада", няхай гэта будзе сайт або рознічны магазін, падбіраеце там тавар, бачыце цану на сайце або ў "Кошыку", кошт аўтаматычна разлічвае адзін сэрвіс. Навошта гэта трэба: да гэтага ў кожнай сістэмы былі свае прынцыпы працы з прома - са зніжкамі і гэтак далей. Цэнаўтварэннем у нас займаецца бэк-офіс, функцыянал скідак рэалізаваны ў іншай сістэме. Гэта трэба было цэнтралізаваць і стварыць такі ўнікальны, які адлучаецца сэрвіс у выглядзе бізнэс-працэсу, які дазваляў бы нам гэта рэалізаваць. Прыкладна так мы стартавалі.
Каштоўнасць першых вынікаў была вельмі вялікая. Па-першае, мы змаглі рабіць якія адлучаюцца сутнасці, якія дазваляюць асобна, агрэгавана працаваць. Па-другое, мы знізілі кошт валодання з пункту гледжання інтэграцыі з вялікай колькасцю сістэм.
За апошнія тры гады ў нас дадаліся тры франтавыя сістэмы. Іх было складана падтрымліваць у тым жа аб'ёме рэсурсаў, якія магла дазволіць сабе кампанія. Таму ўзнікла задача шукаць новыя выхады, адказваючы на рынак з пункту гледжання хуткасці, з пункту гледжання ўнутраных затрат і эфектыўнасці.
Як ацаніць паспяховасць пераходу на мікрасэрвісы
Зміцер:
Як вызначаецца паспяховасць у пераходзе на мікрасэрвісы? Што было "да" ў кожнай кампаніі? Якую метрыку вы выкарыстоўвалі для вызначэння паспяховасці пераходу, хто яе вызначаў насамрэч?
Сяргей:
У першую чаргу гэта нарадзілася ўнутры IT як enabler – "разлочивание" новых магчымасцяў. У нас была патрэба рабіць усё хутчэй за ўмоўна тыя ж грошы, адказваючы на выклікі рынку. Цяпер паспяховасць выяўляецца ў колькасці сэрвісаў, перавыкарыстаных рознымі сістэмамі, уніфікацыя працэсаў паміж сабой. Цяпер так, а ў той момант гэта была магчымасць стварэння платформы і пацвярджэнне гіпотэзы, што мы можам гэта зрабіць, гэта дасць эфект і разлік бізнэс-кейса.
Аляксандр:
Паспяховасць - гэта, хутчэй, унутранае адчуванне. Бізнес заўсёды хоча больш, і глыбіня нашага backlog'а - гэта і ёсць пацвярджэнне паспяховасці. Мне так здаецца.
Сяргей:
Так, згодзен. За тры гады ў нас ужо больш за дзвесце сэрвісаў і backlog. Патрэба ў рэсурсах ўнутры каманды толькі расце - штогод на 30%. Так здараецца таму, што людзі адчулі: гэта хутчэй, па-іншаму, іншыя тэхналогіі, усё гэта развіваецца.
Мікрасэрвісы прыйдуць, але core застанецца
Зміцер:
Гэта падобна на бясконцы працэс, дзе вы інвестуеце ў распрацоўку. Сам пераход на мікрасэрвісы для бізнэсу ўжо скончыўся ці не?
Сяргей:
Вельмі проста адказаць. Вы як лічыце: замена тэлефонаў - гэта бясконцы працэс? Мы ж самі купляем тэлефоны кожны год. І тут так: пакуль існуе запатрабаванне ў хуткасці, у адаптацыі да рынка, будуць патрабавацца нейкія змены. Гэта ня значыць, што мы адмаўляемся ад стандартных рэчаў.
Але мы не можам адразу ўсё ахапіць і перарабіць. Мы маем legacy, стандартныя інтэграцыйныя сэрвісы, якія былі да гэтага: шыны enterprise і гэтак далей. Але ёсць backlog, і запатрабаванне таксама ёсць. Колькасць мабільных прыкладанняў і іх функцыянал прырастаюць. Пры гэтым ніхто не гаворыць аб тым, што вам выдадуць на 30% больш грошай. Гэта значыць пастаянна з аднаго боку ёсць патрэбы, а з другога - пошук эфектыўнасці.
Зміцер:
Жыццё ў тонусе. (Смяецца)
Аляксандр:
Увогуле, так. У нас няма рэвалюцыйных падыходаў да выдалення з ландшафту core-часткі. Ідзе планамерная праца па дэкампазіцыі сістэм, каб тыя больш адпавядалі мікрасэрвіснай архітэктуры, па памяншэнні ўплыву сістэм сябар на сябра.
Але мы плануем захаваць core-частку, бо ў ландшафце аператара заўсёды будуць нейкія платформы, якія мы купляем. Ізноў жа, патрэбен здаровы баланс: мы не павінны кідацца ў выпілоўванне core. Мы ставім сістэмы побач, а зараз, аказваецца, што ўжо і над многімі core-часткамі. Далей, развіваючы функцыянал, які робіцца патрэбныя паданні для ўсіх каналаў, якія працуюць з нашымі паслугамі сувязі.
Як прадаць мікрасэрвісы бізнесу
Зміцер:
Мне яшчэ цікава - для тых, хто не перайшоў, але збіраецца: наколькі лёгка было прадаць гэтую ідэю бізнэсу і ці была гэта авантура, інвестпраект? Ці ж гэта было ўсвядомленай стратэгіяй: зараз мы ідзем у мікрасэрвісы і ўсё, нас нічога не спыніць. Як гэта было ў вас?
Сяргей:
Мы прадавалі не падыход, а бізнэс-выгаду. Была праблематыка ў бізнэсе, і мы яе спрабавалі зняць. У той момант яна выяўлялася ў тым, што ў розных каналах выкарыстоўваліся розныя прынцыпы разліку кошту - асобна для прома, для акцый і гэтак далей. Гэта было складана падтрымліваць, узнікалі памылкі, мы выслухоўвалі нараканні кліентаў. Гэта значыць, мы прадавалі ўхіленне праблемы, але прыходзілі з тым, што нам патрэбныя грошы на стварэнне платформы. І паказвалі бізнес-кейс на прыкладзе першага этапа інвесціравання: як мы далей будзем яго акупляць і што гэта дазволіць нам рабіць.
Зміцер:
А вы неяк фіксавалі час першага этапа?
Сяргей:
Так, вядома. Мы адводзілі 6 месяцаў на стварэнне core як платформы і праверку пілота. За гэты час мы спрабавалі стварыць плятформу, на якой адкаталі пілот. Далей пацвердзілі гіпотэзу, а раз яна працуе - значыць, можна працягваць. Пачалі тыражаваць і ўзмацнілі каманду - вывелі яе ў асобнае падраздзяленне, якое толькі гэтым і займаецца.
Далей ідзе планамерная работа, якая зыходзіць з патрэбнасцей бізнесу, магчымасцей, даступнасці рэсурсаў і ўсяго таго, што ёсць цяпер у рабоце.
Зміцер:
Окей. Аляксандр, што скажаце?
Аляксандр:
У нас мікрасэрвісы нарадзіліся з «пены марскі» – за кошт эканоміі рэсурсаў, за кошт нейкіх рэшткаў у выглядзе серверных магутнасцяў і пераразмеркавання сіл усярэдзіне каманд. Першапачаткова мы не прадавалі гэты праект бізнэсу. Гэта быў праект, дзе мы і даследавалі, і распрацоўвалі адпаведна. Мы стартавалі ў пачатку 2018 года і проста на энтузіязме развівалі гэты напрамак. Продажы толькі што пачаліся, і мы ў працэсе.
Зміцер:
А бывае, што бізнэс дазваляе займацца такім справамі па прынцыпе Google - у адзін вольны дзень у тыдзень? У вас ёсць такі напрамак?
Аляксандр:
Адначасова з даследаваннямі мы займаліся і бізнес задачамі, таму ўсе нашы мікрасэрвісы – гэта рашэнне бізнес-задач. Толькі спачатку мы будавалі мікрасэрвісы, якія ахопліваюць невялікую частку абаненцкай базы, а зараз мы ёсць практычна ва ўсіх флагманскіх прадуктах.
І ўжо зразумела матэрыяльны ўплыў - нас ужо можна палічыць, ацаніць хуткасць вываду прадуктаў і недаатрыманую выручку, калі б мы ішлі старым шляхам. Вось на гэтым мы і які будуецца кейс.
Мікрасэрвісы: хайп ці неабходнасць?
Зміцер:
Лічбы ёсць лічбы. І выручка або зэканомленыя грошы - гэта вельмі важна. А калі паглядзець на іншы бок? Здаецца, што мікрасэрвісы – гэта трэнд, хайп і многія кампаніі злоўжываюць гэтым? Наколькі выразна вы размяжоўваеце, што вы перакладаеце і не перакладаеце на мікрасэрвісы? Калі legacy зараз, то ці застанецца ў вас legacy праз 5 гадоў? Якім будзе ўзрост інфармацыйных сістэм, якія працуюць у "М. Відэа-Эльдарада" і ў "Мегафоне" праз 5 гадоў? Ці будуць там дзесяцігадовыя, пятнаццацігадовыя інфармацыйныя сістэмы, ці гэта будзе новае пакаленне? Як вы гэта бачыце?
Сяргей:
Мне падаецца, што зусім далёка складана загадваць. Калі абярнуцца назад, то хто меркаваў, што так будзе развівацца рынак тэхналогій і таго ж машыннага навучання, ідэнтыфікацыі карыстачоў па твары? Але калі паглядзець у бліжэйшыя гады, мне здаецца, што core-сістэмы, enterprise-сістэмы класа ERP у кампаніях – яны працуюць дастаткова даўно.
Нашым кампаніям сукупна 25 гадоў, у іх класічны ERP знаходзіцца вельмі глыбока ў ландшафце сістэм. Зразумела, што мы выносім адтуль нейкія кавалкі і спрабуем іх агрэгаваць у мікрасэрвісы, але core застанецца. Мне складана цяпер уявіць, што мы там заменім усе core-сістэмы і хутка перабяжым на іншы, светлы бок новых сістэм.
Я прыхільнік таго, што ўсё, што знаходзіцца бліжэй да кліента і спажыўца, там, дзе самая вялікая бізнэс-выгада і каштоўнасць, дзе патрэбна адаптыўнасць і арыентацыя на хуткасць, на змены, на «паспрабаваць, адмяніць, перавыкарыстоўваць, зрабіць нешта іншае » - вось там ландшафт зменіцца. І туды не вельмі добра ўбудоўваюцца скрынкавыя прадукты. Прынамсі, мы гэтага не бачым. Тамака патрабуюцца максімальна лёгкія, простыя рашэнні.
Мы бачым такое развіццё:
- core інфармацыйных сістэм (у большай ступені бэк-офіс);
- middle-пласты ў выглядзе мікрасэрвісаў злучаюць core, агрэгуюць, ствараюць кэш і гэтак далей;
- франтавыя сістэмы накіраваны на спажыўца;
- інтэграцыйны пласт, які наогул інтэграваны ў маркетплэйсы, іншыя сістэмы і экасістэмы. Гэты пласт максімальна лёгкі, просты, у ім мінімум бізнэс-логікі.
Але пры гэтым я прыхільнік таго, каб працягваць выкарыстоўваць старыя прынцыпы, калі яны выкарыстоўваюцца да месца.
Дапусцім, у вас ёсць класічная enterprise-сістэма. Яна знаходзіцца ў ландшафце аднаго вендара, складаецца з двух модуляў, якія адзін з адным працуюць. Таксама ёсць стандартны інтэграцыйны інтэрфейс. Навошта гэта перарабляць і прыносіць туды мікрасэрвіс?
А вось калі ёсць 5 модуляў у бэк-офісе, з якіх збіраюцца кавалкі інфармацыі ў бізнес-працэс, якім потым карыстаюцца 8-10 франтавых сістэм - тут адразу прыкметная выгада. Вы забіраеце з пяці бэк-офісных сістэм, ствараеце сэрвіс, прычым ізаляваны, які арыентаваны на бізнэс-працэс. Сэрвіс робіце тэхналагічным - каб ён кэшаваў інфармацыю і быў адмоваўстойлівым, а таксама працаваў з дакументамі або бізнес-сутнасцям. І інтэгруеце яго па адзіным прынцыпе са ўсімі франтавымі прадуктамі. Адмянілі франтавы прадукт - проста выключылі інтэграцыю. Заўтра вам трэба напісаць мабільнае прыкладанне або зрабіць маленькі сайт і толькі адну частку прызямліць у функцыянал - усё проста: вы сабралі гэта, як канструктар. Я больш у такі бок бачу развіццё - прынамсі, у нас.
Аляксандр:
Сяргей поўнасцю апісаў наш падыход, дзякуй. Я толькі скажу, куды мы дакладна не пойдзем — у core-частку, у тэму анлайн-тарыфікацыі. Гэта значыць рэйтынг і чарджынг застанецца, уласна, «сішной» малатарні, якая будзе надзейна спісваць грошы. І гэтая сістэма будзе па-ранейшаму сертыфікавацца нашымі кантралюючымі органамі. Усё астатняе, што глядзіць у бок кліентаў, вядома - гэта мікрасэрвісы.
Зміцер:
Тут якраз сертыфікацыя - гэта адна гісторыя. Мусіць, яшчэ падтрымка. Калі вы марнуеце на падтрымку крыху або сістэма не патрабуе падтрымкі і дапрацоўкі, лепш яе не чапаць. Разумны кампраміс.
Як распрацоўваць надзейныя мікрасэрвісы
Зміцер:
Добра. А вось мне яшчэ цікава. Цяпер вы расказваеце success story: усё было добра, мы перайшлі на мікрасэрвісы, абаранілі ідэю перад бізнэсам, і ўсё атрымалася. Але я чуў іншыя гісторыі.
Пару гадоў таму адна швейцарская кампанія, якая інвесціравала два гады ў распрацоўку новай мікрасэрвіснай платформы для банкаў, у выніку закрыла гэты праект. Цалкам згарнула. Было выдаткавана шмат мільёнаў швейцарскіх франкаў, а ў выніку разагналі каманду - не пайшло.
У вас былі падобныя гісторыі? Былі ці ёсць нейкія складанасці? Напрыклад, абслугоўванне мікрасэрвісаў, той жа маніторынг – таксама галаўны боль у аперацыйнай дзейнасці кампаніі. Бо колькасць кампанентаў павялічваецца ў дзясяткі разоў. Як вы гэта бачыце, ці былі няўдалыя прыклады інвестыцый тут? І што можна параіць людзям, каб яны не сутыкаліся з такімі праблемамі?
Аляксандр:
Няўдалыя прыклады былі ў тым, што бізнэс мяняў прыярытэты і адмяняў праекты. Калі на добрым этапе гатоўнасці (фактычна гатовы MVP) бізнэс казаў: "У нас новыя прыярытэты, ідзем у іншы праект, а гэты закрываем".
Глабальных фэйлаў з мікрасэрвісамі ў нас не было. Мы спакойна спім, у нас ёсць дзяжурная змена 24/7, якая абслугоўвае ўвесь BSS [business support system].
І яшчэ - мы здаем мікрасэрвісы па правілах, па якіх здаюцца скрынкавыя прадукты. Заклад поспеху ў тым, што трэба, па-першае, сабраць каманду, якая будзе поўнасцю рыхтаваць мікрасэрвіс да прадакшэна. Сама распрацоўка - гэта, умоўна, 40%. Астатняе - аналітыка, метадалогія DevSecOps, правільныя інтэграцыі і правільная архітэктура. Адмысловая ўвага надаем прынцыпам пабудовы бяспечных прыкладанняў. У кожным праекце ўдзельнічаюць прадстаўнікі ИБ як на этапе планавання архітэктуры, так і ў працэсе рэалізацыі. Яшчэ яны кіруюць сістэмамі аналізу кода на ўразлівасці.
Дапусцім, мы дэплоім свае сэрвісы stateless - у нас яны ў Kubernetes. Гэта і дазваляе ўсім спаць спакойна за кошт аўтамаштабавання і аўтаўзняцця сэрвісаў, а дзяжурная змена падхапляе інцыдэнты.
За ўвесь час існавання нашых мікрасэрвісаў быў усяго адзін ці два інцыдэнты, якія дайшлі да нашай лініі. Цяпер праблем з эксплуатацыяй няма. У нас, вядома, не 200, а каля 50 мікрасэрвісаў, але яны выкарыстоўваюцца ў флагманскіх прадуктах. Калі б яны збілі, мы б даведаліся пра гэта першымі.
Мікрасэрвісы і HR
Сяргей:
Згодны з калегам пра перадачу ў падтрымку - што трэба правільна арганізоўваць працу. Але скажу аб праблемах, якія, вядома ж, ёсць.
Па-першае, тэхналогія новая. Гэта ў добрым сэнсе хайп, і знайсці спецыяліста, які будзе разбірацца і зможа ствараць гэта - вялікая складанасць. Канкурэнцыя за рэсурсы вар'ятка, адпаведна, эксперты на вагу золата.
Па-другое, пры стварэнні вызначаных ландшафтаў і якая расце колькасці сэрвісаў павінна стала вырашацца задача з перавыкарыстаннем. Як любяць рабіць распрацоўшчыкі: "Давайце зараз панапішам тут шмат усяго цікавага…" З-за гэтага сістэма разрастаецца і губляе сваю эфектыўнасць з пункту гледжання грошай, кошту валодання і гэтак далей. Гэта значыць, трэба закладваць перавыкарыстанне ў архітэктуру сістэм, уключаць у road map укараненні сэрвісаў і перакладу legacy на новую архітэктуру.
Яшчэ адна праблема - хоць гэта па-свойму і добра - гэта ўнутраная канкурэнцыя. "О, новыя модныя хлопцы з'явіліся ў нас, размаўляюць на новай мове". Людзі, вядома, розныя. Ёсць тыя, хто абвык пісаць на Java, і тыя, хто піша і выкарыстае Docker і Kubernetes. Гэта абсалютна іншыя людзі, яны па-рознаму размаўляюць, выкарыстоўваюць іншыя тэрміны і часам адно аднаго не разумеюць. Уменне ці няўменне дзяліцца практыкай, knowledge sharing, у гэтым сэнсе таксама праблема.
Ну і маштабаванне рэсурсаў. «Здароў, паехалі! А зараз жадаем хутчэй, больш. А што, не можаце? Няўжо ў два разы больш паставіць за год нельга? А чаму?" Такія праблемы росту - стандартныя, напэўна, для многіх рэчаў, многіх падыходаў, і яны адчуваюцца.
Наконт маніторынгу. Мне здаецца, што сэрвісы ці прамысловыя прылады маніторынгу ўжо вучацца ці ўмеюць працаваць і з Docker, і Kubernetes у іншым, нестандартным рэжыме. Каб у вас, напрыклад, не з'явілася 500 Java-машын, пад якімі ўсё гэта запушчана, а менавіта агрэгуе. Але гэтым прадуктам яшчэ не хапае сталасці, ім трэба будзе гэта прайсці. Тэма сапраўды новая, яна яшчэ будзе разьвівацца.
Зміцер:
Так, вельмі цікава. І гэта датычыцца HR. Магчыма, ваш НR-працэс і HR-брэнд крыху памяняліся за гэтыя 3 гады. Вы сталі набіраць іншых людзей, з іншай кампетэнцыяй. І тут ёсць, мусіць, і плюсы, і мінусы. Раней хайпавымі былі blockchain і data science, і спецыялісты па іх каштавалі проста мільёны. Цяпер кошт спадае, рынак насычаецца, і ў мікрасэрвісах падобны трэнд.
Сяргей:
Так, абсалютна.
Аляксандр:
HR задае пытанне: "Дзе ж ваш ружовы аднарог паміж backend'ам і frontend'ам?" HR не разумеюць, што такое мікрасэрвіс. Мы адкрылі ім сакрэт і сказалі, што гэта backend усё зрабіў, і там няма аднарога. Але HR змяняюцца, хутка вучацца і падбіраюць у рэкрутынгу людзей, якія валодаюць базавымі IT-ведамі.
Эвалюцыя мікрасэрвісаў
Зміцер:
Калі паглядзець на мэтавую архітэктуру, то мікрасэрвісы выглядаюць такім сабе монстрам. Ваш шлях заняў некалькі год. У іншых год, у трэціх - тры гады. Вы прадбачылі ўсе праблемы, мэтавую архітэктуру, ці мянялася нешта? Напрыклад, у выпадку мікрасэрвісаў зараз з'яўляюцца зноў gateways, service mesh'ы. Вы выкарыстоўвалі іх у пачатку ці мянялі саму архітэктуру? Ці ёсць такія выклікі ў вас?
Сяргей:
Мы перапісалі ўжо некалькі пратаколаў узаемадзеяння. Спачатку адзін пратакол, зараз перайшлі на іншы. Падвышаем бяспеку і надзейнасць. Пачыналі з enterprise-тэхналогій – Oracle, Web Logic. Цяпер сыходзім ад тэхналагічных enterprise-прадуктаў у мікрасэрвісах і пераходзім на open source або на зусім адчыненыя тэхналогіі. Адмаўляемся ад баз даных, пераходзім на тое, што больш эфектыўна працуе для нас у гэтай мадэлі. Тэхналогіі Oracle нам сталі не патрэбныя.
Мы пачыналі проста як сэрвіс, не задумваючыся аб тым, наколькі нам патрэбен кэш, што мы будзем рабіць, калі няма сувязі з мікрасэрвісам, а дадзеныя патрэбныя, і т. д. Цяпер развіваем платформу, каб архітэктуру можна было апісаць не на мове сэрвісаў, а на бізнэс-мове, перавесці бізнэс-логіку на наступны ўзровень, калі мы пачнем размаўляць словамі. Цяпер мы навучыліся размаўляць літарамі, а наступны ўзровень - гэта калі сэрвісы будуць збірацца ў нейкі агрэгат, калі гэта ўжо слова - напрыклад, картка тавару цалкам. Яна збіраецца з мікрасэрвісаў, але гэта такі надбудаваны над гэтым API.
Бяспека вельмі важная. Як толькі вы пачынаеце быць даступнымі і ў вас ёсць сэрвіс, па якім можна шмат чаго цікавага атрымаць, і вельмі хутка, за дзелі секунд, тое ўзнікае жаданне атрымаць гэта не самай бяспечнай выявай. Каб ад гэтага адысці, прыйшлося мяняць падыходы да тэсціравання і маніторынгу. Прыйшлося мяняць каманду, структуру кіравання пастаўкай, CI/CD.
Гэта эвалюцыя - як з тэлефонамі, толькі значна хутчэй: спачатку былі кнопкавыя тэлефоны, потым з'явіліся смартфоны. Перапісалі, перарабілі прадукт таму, што ў рынка з'явілася іншае запатрабаванне. Так і мы эвалюцыянуем: першы клас, дзесяты клас, праца.
Ітэратыўна ў год закладваецца нешта з пункту гледжання тэхналогій, яшчэ нешта – з пункту гледжання backlog'а і патрэбаў. Мы злучаем адно з іншым. Каманда марнуе 20% на тэхдоўг і тэхнічнае забеспячэнне каманды, 80% - на бізнес-сутнасць. І рухаем, з разуменнем, навошта які робіцца, чаму які робіцца гэтыя тэхналагічныя паляпшэнні, да чаго яны прывядуць. Прыкладна так.
Зміцер:
Стромка. А што ў "Мегафоне"?
Аляксандр:
Асноўны выклік падчас нашага прыходу ў мікрасэрвісы - не зваліцца ў хаос. Да нас адразу падключыўся, нават стаў ініцыятарам і драйверам архітэктурны офіс «Мегафона» - зараз у нас вельмі моцная архітэктура. Яго задачай было зразумець, у якую мэтавую мадэль мы ідзем і якія тэхналогіі трэба пілатаваць. З архітэктурай мы самі праводзілі гэтыя пілатаванні.
Наступнае пытанне было: "А як потым гэта ўсё эксплуатаваць?". І яшчэ адзін: "Як забяспечыць празрыстае ўзаемадзеянне паміж мікрасэрвісамі?". На апошняе пытаньне нам дапамог адказаць service mesh. Мы прапілатавалі Istio, і вынікі нам спадабаліся. Цяпер мы знаходзімся на этапе раскочвання ў прадуктыўныя зоны. Да ўсіх выклікаў мы ставімся пазітыўна - да таго, што трэба пастаянна мяняць стэк, вывучаць нешта новае. Нам цікава развівацца, а не эксплуатаваць старыя рашэнні.
Зміцер:
Залатыя словы! Такія выклікі трымаюць у тонусе каманду і бізнэс і ствараюць будучыню. GDPR стварыў chief data protection officers, а цяперашнія выклікі ствараюць галоўных па мікрасэрвісах і архітэктуры. І гэта радуе.
Мы шмат абмеркавалі. Галоўнае - добрая прапрацоўка мікрасэрвісаў і самой архітэктуры дазваляе пазбегнуць шматлікіх памылак. Вядома, працэс гэта ітэратыўны і эвалюцыйны, але за ім будучыня.
Дзякуй усім удзельнікам, дзякуй Сяргею і Аляксандру!
Пытанні з залы
Пытанне з залы (1):
Сяргей, як змяніўся IT-мэнэджмент у вашай кампаніі? Я разумею, калі ёсць вялікі стэк з некалькіх сістэм, тут як ён кіруецца - гэта досыць зразумелы і лагічны працэс. Як вы перабудоўвалі менеджмент у IT-складніку пасля таго, як вельмі вялікая колькасць мікрасэрвісаў была інтэгравана ў такі кароткі тэрмін?
Сяргей:
Я далучаюся да калегі, што вельмі важная архітэктура як драйвер змен. Мы пачалі з таго, што ў нас зьявілася архітэктурнае падразьдзяленьне. Архітэктары адначасова з'яўляюцца ўладальнікамі размеркавання функцыянальнасці і патрабаванняў да таго, як гэта будзе выглядаць у ландшафце. Так што яны ж выступаюць і каардынатарамі гэтых змен. У выніку адбыліся канкрэтныя змены ў канкрэтным працэсе пастаўкі, калі мы стварылі платформу CI/CD.
Але стандартныя, базавыя прынцыпы распрацоўкі, бізнес-аналіз, тэсціраванне і распрацоўку — ніхто не адмяняў. Мы проста дадалі хуткасць. Раней цыкл займаў столькі, устаноўка на тэставыя асяроддзя - яшчэ столькі. Цяпер бізнэс бачыць выгаду і кажа: "А чаму ў іншых месцах нельга гэтак жа зрабіць?".
Гэта як, у добрым сэнсе, ін'екцыя ў выглядзе вакцыны, якая паказала: можна вось так, а можна і інакш. Вядома, ёсць праблема ў персанале, у кампетэнцыях, у ведах, у супраціве.
Пытанне з залы (2):
Крытыкі мікрасэрвіснай архітэктуры гавораць, што ўзнікаюць складанасці з тэсціраваннем і распрацоўкай. Гэта лагічна там, дзе нешта ўскладняецца. З якімі цяжкасцямі сутыкнулася ваша каманда і як вы іх перамаглі? Пытанне да ўсіх.
Аляксандр:
Складанасці ёсць пры пераходзе ад мікрасэрвісаў да платформы, але яны развязальныя.
Напрыклад, мы робім прадукт, які складаецца з 5-7 мікрасэрвісаў. Нам трэба забяспечыць інтэграцыйныя тэсты па ўсім скупцы мікрасэрвісаў, каб даць зялёнае святло да пераходу ў майстар-галінку. Гэтая задача была для нас не новая: мы доўга займаліся гэтым у BSS, калі вендар пастаўляў нам ужо адгружаныя рашэнні.
І наша праблема толькі ў малалікай камандзе. На адзін умоўны прадукт патрэбен адзін QA-інжынер. І вось, мы адгружаем прадукт з 5-7 мікрасэрвісаў, з якіх 2-3 могуць быць распрацаваны іншымі людзьмі. Напрыклад, у нас ёсць прадукт, у распрацоўцы якога ўдзельнічае наш вендар білінгавай сістэмы, Mail.ru Group і R&D "Мегафона". Нам трэба пакрыць гэта тэстамі перад тым, як адгрузіць у прад. Паўтара месяца QA-інжынер займаецца гэтым прадуктам, і астатняя каманда застаецца без яго падтрымкі.
Гэтая складанасць выклікана толькі маштабаваннем. Мы разумеем, што мікрасэрвісы не могуць існаваць у вакууме, абсалютнай ізаляцыі не існуе. Змяняючы адзін сэрвіс, мы абавязкова імкнемся захаваць API-кантракт. Калі нешта мяняецца пад капотам, front сэрвісу застаецца. Калі змены фатальныя, ідзе якая-небудзь архітэктурная трансфармацыя і мы пераходзім наогул на іншую метамадэль дадзеных, якая цалкам несумяшчальная - толькі тады мы кажам аб тым, што з'яўляецца API-спецыфікацыя сэрвісу v2. Мы падтрымліваем адначасова першую і другую версіі, а пасля пераходу ўсіх спажыўцоў на другую версію першую проста закрываем.
Сяргей:
Я хачу дапоўніць. Абсалютна згодны пра ўскладненні - яны адбываюцца. Ландшафт ускладняецца, вырастаюць накладныя выдаткі, асабліва на тэсціраванне. Як з гэтым змагацца: пераходзіць на аўтатэставанне. Так, давядзецца дадаткова інвеставаць у напісанне аўтатэстаў і unit-тэстаў. Каб распрацоўшчыкі не маглі камiціць без праходжання тэста, не маглі мяняць код. Каб нават кнопка push не працавала без аўтатэста, unit-тэсту.
Важна падтрымліваць папярэдні функцыянал, а гэта дадатковыя накладныя выдаткі. Калі перапісваць тэхналогію на іншы пратакол, то перапісваеш датуль, пакуль не зачыніш усё цалкам.
Мы часам спецыяльна не які робіцца end-to-end тэставанне, бо не жадаем спыняць распрацоўку, хоць у нас адно за іншае таксама чапляецца. Ландшафт вельмі вялікі, складаны, сістэм шмат. Часам проста заглушкі - так, вы зніжаеце мяжу бяспекі, з'яўляецца больш рызык. Але пры гэтым пастаўку выпускаеце.
Аляксандр:
Так, аўтатэсты і unit-тэсты дазваляюць зрабіць якасны сэрвіс. Мы за пайплайн, які нельга прайсці без unit- і інтэграцыйных тэстаў. Даводзіцца часта цягнуць у тэставыя зоны і ў асяроддзі распрацоўкі эмулятары, сістэмы з прода, таму што не ўсе сістэмы можна размясціць у тэставых зонах. Прычым яны не проста макаюцца - мы генеруем паўнавартасны адказ ад сістэмы. Гэта сур'ёзная частка працы з мікрасэрвісамі, і мы ў яе таксама ўкладваемся. Без гэтага наступіць хаос.
Пытанне з залы (3):
Наколькі я разумею, першапачаткова мікрасэрвісы раслі з асобнай каманды і зараз існуюць у гэтай мадэлі. Якія ў яе плюсы і мінусы?
Проста ў нас падобная гісторыя: узнікла нейкая фабрыка мікрасэрвісаў. Цяпер мы канцэптуальна падышлі да таго, што гэты падыход мы распаўсюджваем на вытворчасць па стрымах і па сістэмах. Іншымі словамі, мы сыходзім ад цэнтралізаванай распрацоўкі менавіта мікрасэрвісаў, мадэляў мікрасэрвісаў, і становімся бліжэй да сістэм.
Адпаведна, эксплуатацыя ў нас таксама сыходзіць да сістэм, гэта значыць мы дэцэнтралізуем гэтую тэму. Які ў вас падыход і якая мэтавая гісторыя для вас?
Аляксандр:
Назву «фабрыка мікрасэрвісаў» вы як з мовы знялі – мы таксама хочам адмаштабавацца. Па-першае, у нас сапраўды зараз адна каманда. Усім камандам распрацоўкі, якія ёсць у "Мегафоне", мы хочам даць магчымасць працаваць у агульнай экасістэме. Мы не жадаем цалкам забіраць на сябе ўвесь функцыянал распрацоўкі, які ёсць зараз. Задача лакальная - адмаштабавацца, задача глабальная - весці распрацоўку ўсім камандам у мікрасэрвісным пласце.
Сяргей:
Раскажу, які шлях мы прайшлі. Мы сапраўды пачыналі працаваць адной камандай, але зараз яна не адна. Я прыхільнік наступнага: павінен быць уладальнік працэсу. Хтосьці павінен разумець, кіраваць, кантраляваць і будаваць працэс распрацоўкі па мікрасэрвісах. Ён павінен валодаць рэсурсамі і займацца рэсурс-мэнэджментам.
Гэтыя рэсурсы, якія ведаюць тэхналогіі, спецыфіку і разумеюць, як будаваць мікрасэрвісы, могуць знаходзіцца ў прадуктовых камандах. У нас мікс, дзе людзі з мікрасэрвіснай платформы знаходзяцца ў прадуктовай камандзе, якая робіць мабільнае прыкладанне. Яны там знаходзяцца, але працуюць па працэсе аддзела па кіраванні мікрасэрвіснай платформы са сваім кіраўніком распрацоўкі. Унутры гэтага падраздзялення ёсць асобная каманда, якая займаецца тэхналогіямі. Гэта значыць, мы міксуем паміж сабой агульны пул рэсурсаў і падзяляем іх, аддаючы іх унутр каманд.
Пры гэтым працэс застаецца агульным, кантраляваным, ён працякае па агульных тэхналагічных прынцыпах, з unit-тэставаннем і гэтак далей - усім, што надбудавана зверху. Тут могуць быць калоны ў выглядзе рэсурсаў, сабраных з розных падраздзяленняў прадуктовага падыходу.
Аляксандр:
Сяргей, вы фактычна з'яўляецеся уладальнікам працэсу, так? Backlog задач агульны? Хто займаецца яго размеркаваннем?
Сяргей:
Глядзіце: тут зноў мікс. Ёсць backlog, які фармуецца, зыходзячы з тэхналагічных паляпшэнняў – гэта адна гісторыя. Ёсць backlog, які фармулюецца з праектаў, і есць backlog з прадуктаў. Але паслядоўнасць вывядзення ўнутр кожнага з прадуктаў сэрвісу або стварэнне гэтага сэрвісу распрацоўвае прадуктолаг. Яго няма ў IT-дырэкцыі, ён спецыяльна з яе выведзены. Але мае людзі сапраўды працуюць па адным працэсе.
Уладальнікам backlog'а ў розных кірунках - backlog'а змен - будуць розныя людзі. Звязанасць тэхналагічных сэрвісаў, іх прынцыпу арганізацыі – усё гэта будзе знаходзіцца ў IT. Платформай валодаю я, рэсурсамі - таксама. Зверху знаходзіцца тое, што дакранаецца backlog'а і функцыянальных змен, і архітэктура ў гэтым сэнсе.
Дапусцім, бізнэс кажа: «Хочам вось такую функцыю, хочам стварыць новы прадукт - перарабіць крэдыт». Мы адказваем: "Так, пераробім". Архітэктары кажуць: "Давайце падумаем: дзе ў крэдыце ўпішам мікрасэрвісы і як гэта зробім?". Далей раскладваем гэта на праекты, прадукты ці на тэхналагічны стэк, апускаем у каманды і рэалізуемы. Стварылі ўнутры прадукт і вырашылі ў гэтым прадукце выкарыстоўваць мікрасэрвісы? Які гаворыцца: «Цяпер legacy-сістэмы, якія ў нас былі, або франтавыя, павінны пераходзіць на гэтыя мікрасэрвісы». Архітэктары кажуць: «Так: у тэхналагічны backlog унутр франтавых прадуктаў – пераход на мікрасэрвісы. Паехалі». І прадуктолагі ці ўладальнікі ад бізнэсу разумеюць, колькі адведзена capacity, калі гэта будзе зроблена і чаму.
Канец дыскусіі, але яшчэ не ўсё
Канферэнцыя mailto:CLOUD была арганізавана .
Мы таксама робім іншыя мерапрыемствы - напрыклад, @Kubernetes Meetup, куды заўсёды шукаем класных спікераў:
- Сачыце за навінамі @Kubernetes і іншых @Meetup у нашым Telegram-канале
- Жадаеце выступіць на адным з @Meetup? Пакіньце заяўку на
Крыніца: habr.com