От монолити до микроуслуги: опитът на M.Video-Eldorado и MegaFon

На 25 април ние от Mail.ru Group проведохме конференция за облаците и около тях - mailto:CLOUD. Няколко акцента:

• Основното Руски доставчици — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center и Yandex.Cloud говориха за спецификата на нашия облачен пазар и техните услуги;
• Колегите от Bitrix24 разказаха как те стигна до multicloud;
• Leroy Merlin, Otkritie, Burger King и Schneider Electric предоставиха интересни изглед от облачни потребители — какви задачи си поставя техният бизнес пред ИТ и какви технологии, включително облачните, виждат като най-обещаващи.

Можете да гледате всички видеоклипове от конференцията mailto:CLOUD по ссылке, а тук можете да прочетете как протече дискусията за микроуслугите. Александър Деулин, ръководител на Центъра за изследване и развитие на бизнес системи MegaFon, и Сергей Сергеев, директор по информационни технологии на групата M.Video-Eldorado, споделиха своите успешни случаи на премахване на монолитите. Обсъдихме и свързани въпроси на ИТ стратегията, процесите и дори човешките ресурси.

Панелисти

• Сергей Сергеев, CIO на групата "М.Видео-Елдорадо";
• Александър Деулин, ръководител на центъра за изследване и развитие на бизнес системи Мегафон;
• Модератор — Дмитрий Лазаренко, ръководител направление PaaS Облачни решения на Mail.ru.

След словото на Александър Деулин „Как MegaFon разширява бизнеса си чрез платформа за микросервизи“ към него за дискусия се присъединяват Сергей Сергеев от M.Video-Eldorado и модераторът на дискусията Дмитрий Лазаренко, Mail.ru Cloud Solutions.

По-долу сме подготвили за вас стенограма от дискусията, но можете да гледате и видеото:

Преходът към микроуслуги е отговор на нуждите на пазара

Дмитрий:

Имали ли сте успешен опит с мигриране към микроуслуги? И като цяло: къде виждате най-голямата бизнес полза от използването на микроуслуги или преминаването от монолити към микроуслуги?

Сергей:

Вече сме изминали известен път в прехода към микроуслуги и използваме този подход повече от три години. Първата необходимост, която оправда нуждата от микроуслуги, беше безкрайната интеграция на различни front-end продукти с back office. И всеки път бяхме принудени да правим допълнителна интеграция и развитие, прилагайки собствени правила за работа на тази или онази услуга.

В един момент осъзнахме, че трябва да ускорим работата на нашите системи и извеждането на функционалност. В този момент такива концепции като микроуслуги и подход към микроуслугите вече съществуваха на пазара и ние решихме да опитаме. Това започна през 2016 г. Тогава беше положена платформата и първите 10 услуги бяха внедрени от отделен екип.

Една от първите услуги, най-натоварени, беше услугата за изчисляване на цените. Всеки път, когато влезете в който и да е канал, в групата от компании M.Video-Eldorado, независимо дали е уебсайт или магазин, изберете продукт там, вижте цената на уебсайта или в „Кошницата“, цената е автоматично изчислено от една услуга. Защо е необходимо това: ​​преди това всяка система имаше свои собствени принципи за работа с промоции - с отстъпки и така нататък. Нашият бек офис се занимава с ценообразуването; функционалността за отстъпки е внедрена в друга система. Това трябваше да бъде централизирано и да се създаде уникална, отделима услуга под формата на бизнес процес, който да ни позволи да приложим това. Горе-долу така започнахме.

Стойността на първите резултати беше много голяма. Първо, успяхме да създадем отделими обекти, които ни позволяват да работим отделно и по обобщен начин. Второ, намалихме разходите за притежание по отношение на интеграцията с повече системи.

През последните три години добавихме три системи на първа линия. Беше трудно да се поддържат със същото количество ресурси, които компанията можеше да си позволи. Затова възникна задачата да се търсят нови изходи, отговарящи на пазара по бързина, по вътрешни разходи и ефективност.

Как да измерим успеха на мигрирането към микроуслуги

Дмитрий:

Как се определя успехът при мигрирането към микроуслуги? Какво беше „преди“ във всяка компания? Какъв показател използвахте, за да определите успеха на прехода и кой всъщност го определи?

Сергей:

На първо място, той е роден в рамките на ИТ като средство за активиране - „отключване“ на нови възможности. Имахме нужда да правим всичко по-бързо за относително същите пари, отговаряйки на предизвикателствата на пазара. Сега успехът се изразява в броя на услугите, използвани повторно от различни системи, обединяването на процесите помежду им. Сега е, но в този момент беше възможност да създадем платформа и да потвърдим хипотезата, че можем да направим това, това ще даде ефект и ще изчисли бизнес казуса.

Александър:

Успехът е по-скоро вътрешно чувство. Бизнесът винаги иска повече и дълбочината на нашето изоставане е доказателство за успех. Така ми се струва.

Сергей:

Аз съм съгласен да. За три години вече имаме повече от двеста услуги и неизпълнени задължения. Нуждата от ресурси в екипа само нараства - с 30% годишно. Това се случва, защото хората усетиха: по-бързо е, различно е, има различни технологии, всичко това се развива.

Микроуслугите ще дойдат, но ядрото ще остане

Дмитрий:

Това е като безкраен процес, при който инвестирате в развитие. Преходът към микроуслуги за бизнеса вече приключи или не?

Сергей:

Много е лесно да се отговори. Какво мислите: смяната на телефони е безкраен процес? Ние самите купуваме телефони всяка година. И ето го: докато има нужда от скорост, от адаптиране към пазара, ще са необходими някои промени. Това не означава, че се отказваме от стандартните неща.

Но не можем да покрием и преработим всичко наведнъж. Имаме наследени, стандартни интеграционни услуги, които съществуваха преди: корпоративни автобуси и така нататък. Но има изоставане, а също така има нужда. Броят на мобилните приложения и тяхната функционалност нараства. В същото време никой не казва, че ще ви дадат 30% повече пари. Тоест винаги има нужди от една страна и търсене на ефективност от друга.

Дмитрий:

Животът е в добра форма. (Смее се)

Александър:

Като цяло, да. Ние нямаме революционни подходи за премахване на сърцевината от пейзажа. В ход е системна работа за декомпозиране на системите, така че да са по-съгласувани с архитектурата на микросервизите, за да се намали влиянието на системите една върху друга.

Но планираме да запазим основната част, тъй като в пейзажа на оператора винаги ще има някои платформи, които купуваме. Отново се нуждаем от здравословен баланс: не трябва да бързаме да изрязваме сърцевината. Поставяме системите една до друга и сега се оказва, че вече сме на върха на много основни части. Освен това, развивайки функционалността, ние създаваме необходимите представяния за всички канали, които работят с нашите комуникационни услуги.

Как да продаваме микроуслуги на бизнеса

Дмитрий:

Интересува ме също - за тези, които не са преминали, но планират: колко лесно беше да продам тази идея на бизнеса и беше ли това приключение, инвестиционен проект? Или беше съзнателна стратегия: сега отиваме към микроуслуги и това е, нищо няма да ни спре. Как беше при вас?

Сергей:

Ние не продавахме подход, а бизнес полза. Имаше проблем в бизнеса и ние се опитахме да го разрешим. В този момент това се изразяваше във факта, че различните канали използваха различни принципи за изчисляване на цените - отделно за промоции, за промоции и т.н. Беше трудно за поддръжка, възникваха грешки и се вслушвахме в оплакванията на клиентите. Тоест ние продавахме решение на проблем, но дойдохме с факта, че имаме нужда от пари, за да създадем платформа. И те показаха бизнес казус, използвайки примера на първия етап от инвестицията: как ще продължим да я възстановяваме и какво ще ни позволи това да направим.

Дмитрий:

Записахте ли по някакъв начин времето на първия етап?

Сергей:

Да, разбира се. Отделихме 6 месеца за създаване на ядрото като платформа и тестване на пилота. През това време се опитахме да създадем платформа, на която да се пързаля пилотът. Тогава хипотезата беше потвърдена и тъй като работи, това означава, че можем да продължим. Започнаха да копират и подсилиха екипа - преместиха го в отделна дивизия, която прави точно това.

Следва систематична работа, базирана на нуждите на бизнеса, възможностите, наличието на ресурси и всичко, което се работи в момента.

Дмитрий:

ДОБРЕ. Александър, какво ще кажеш?

Александър:

Нашите микроуслуги се родиха от „морската пяна“ - поради спестяване на ресурси, поради някои остатъци под формата на сървърен капацитет и преразпределение на силите в екипа. Първоначално не продадохме този проект на бизнеса. Това беше проект, в който ние изследвахме и развивахме съответно. Започнахме в началото на 2018 г. и просто развихме тази посока с ентусиазъм. Продажбите току-що започнаха и ние сме в процес.

Дмитрий:

Случва ли се бизнес да ви позволи да правите такива неща като Google - в един свободен ден в седмицата? Имате ли такава посока?

Александър:

Едновременно с изследванията се занимавахме и с бизнес проблеми, така че всички наши микроуслуги са решения на бизнес проблеми. Само в началото изградихме микроуслуги, които покриваха малка част от абонатната база, а сега присъстваме в почти всички водещи продукти.

И материалното въздействие вече е ясно - вече можем да се преброим, скоростта на пускане на продукти и загубените приходи могат да бъдат оценени, ако бяхме следвали стария път. На това градим делото.

Микроуслуги: шум или необходимост?

Дмитрий:

Числата са си числа. А спестените приходи или пари са много важни. Ами ако погледнете от другата страна? Изглежда, че микроуслугите са тенденция, хайп и много компании злоупотребяват с това? Колко ясно правите разлика между това, което правите и това, което не превеждате на микроуслуги? Ако наследство сега, ще продължите ли да имате наследство след 5 години? Каква ще бъде възрастта на информационните системи, които работят в M.Video-Eldorado и MegaFon след 5 години? Ще има ли десетгодишни, петнадесетгодишни информационни системи или ще е ново поколение? Как го виждаш това?

Сергей:

Струва ми се, че е трудно да се мисли много далеч. Ако погледнем назад, кой си е представял, че технологичният пазар ще се развие по този начин, включително машинно обучение и идентификация на потребителите по лице? Но ако погледнете следващите години, струва ми се, че основните системи, корпоративните ERP-клас системи в компаниите - те работят от доста дълго време.

Нашите компании са колективно на 25 години, с класически ERP много дълбоко в системния пейзаж. Ясно е, че изваждаме някои части от там и се опитваме да ги обединим в микроуслуги, но ядрото ще остане. Сега ми е трудно да си представя, че ще заменим всички основни системи там и бързо ще преминем към другата, светла страна на новите системи.

Аз съм привърженик на факта, че всичко, което е по-близо до клиента и потребителя, е мястото, където има най-голямата бизнес полза и стойност, където са адаптивността и фокусът върху скоростта, върху промяната, върху „опитайте, отменете, използвайте повторно, направете нещо различно“ необходимо “-това е мястото, където пейзажът ще се промени. И опакованите продукти не се вписват много добре там. Поне ние не го виждаме. Там се изискват най-лесните, най-простите решения.

Виждаме това развитие:

• основни информационни системи (предимно бек офис);
• средните слоеве под формата на микроуслуги свързват ядрото, агрегират, създават кеш и т.н.;
• системите от първа линия са насочени към потребителя;
• интеграционен слой, който обикновено е интегриран в пазари, други системи и екосистеми. Този слой е възможно най-лек, прост и съдържа минимум бизнес логика.

Но в същото време аз съм привърженик на продължаването на използването на старите принципи, ако се използват по подходящ начин.

Да приемем, че имате класическа корпоративна система. Той се намира в пейзажа на един доставчик и се състои от два модула, които работят един с друг. Има и стандартен интерфейс за интеграция. Защо да го преработвате и да въвеждате микроуслуга там?

Но когато в бек офиса има 5 модула, от които информацията се събира в бизнес процес, който след това се използва от 8-10 системи на първа линия, ползата се забелязва веднага. Вземате от пет бек-офис системи и създавате услуга, изолирана, която е фокусирана върху бизнес процеса. Направете услугата технологично напреднала - така че да кешира информация и да е устойчива на грешки, както и да работи с документи или бизнес обекти. И вие го интегрирате според един принцип с всички продукти от първа линия. Те отмениха продукта от първа линия - просто изключиха интеграцията. Утре трябва да напишете мобилно приложение или да направите малък уебсайт и да включите само една част във функционалност - всичко е просто: сглобихте го като конструктор. Виждам повече развитие в тази посока – поне у нас.

Александър:

Сергей описа напълно нашия подход, благодаря. Просто ще кажа къде определено няма да стигнем - до основната част, до темата за онлайн таксуването. Тоест рейтингът и таксуването ще останат всъщност „голяма“ вършачка, която надеждно ще отпише пари. И тази система ще продължи да бъде сертифицирана от нашите регулаторни органи. Всичко останало, което е насочено към клиентите, разбира се, са микроуслуги.

Дмитрий:

Тук сертифицирането е една история. Вероятно повече подкрепа. Ако харчите малко за поддръжка или системата не изисква поддръжка и модификация, по-добре е да не я докосвате. Разумен компромис.

Как да разработим надеждни микроуслуги

Дмитрий:

Глоба. Но все пак ми е интересно. Сега вие разказвате история на успеха: всичко беше наред, преминахме към микроуслуги, защитихме идеята пред бизнеса и всичко се получи. Но съм чувал и други истории.

Преди няколко години швейцарска компания, която инвестира две години в разработването на нова платформа за микросервизи за банки, в крайна сметка затвори проекта. Напълно сринат. Бяха похарчени много милиони швейцарски франкове и в крайна сметка отборът беше разпръснат - не се получи.

Имали ли сте подобни истории? Има ли или има някакви трудности? Например поддържането на микроуслуги и мониторинг също е главоболие в оперативната дейност на компанията. В крайна сметка броят на компонентите се увеличава десетки пъти. Как го виждате, имало ли е неуспешни примери за инвестиции тук? И какво можете да посъветвате хората, за да не се сблъскват с подобни проблеми?

Александър:

Неуспешните примери включват бизнеси, които променят приоритетите си и отменят проекти. Когато беше на добър етап на готовност (всъщност MVP е готов), бизнесът каза: „Имаме нови приоритети, преминаваме към друг проект и затваряме този.“

Нямахме глобални повреди с микроуслуги. Спим спокойно, имаме 24/7 дежурна смяна, която обслужва цялата BSS [система за поддръжка на бизнеса].

И още нещо - ние отдаваме микроуслуги под наем според правилата, които важат за продуктите в кутия. Ключът към успеха е, че първо трябва да съберете екип, който напълно да подготви микроуслугата за производство. Самото развитие е условно 40%. Останалото е анализи, методология на DevSecOps, правилните интеграции и правилната архитектура. Обръщаме специално внимание на принципите за изграждане на сигурни приложения. Представителите на информационната сигурност участват във всеки проект както на етапа на планиране на архитектурата, така и в процеса на изпълнение. Те също така управляват системи за анализиране на код за уязвимости.

Да речем, че внедрим нашите услуги без състояние – имаме ги в Kubernetes. Това позволява на всички да спят спокойно поради автоматично мащабиране и автоматично повишаване на услугите, а дежурната смяна прибира инциденти.

През цялото съществуване на нашите микроуслуги е имало само един или два инцидента, които са достигнали до нашата линия. Сега няма проблеми с работата. Ние, разбира се, имаме не 200, а около 50 микроуслуги, но те се използват във водещи продукти. Ако се провалят, ние ще сме първите, които ще научат за това.

Микроуслуги и HR

Сергей:

Съгласен съм с колегата за прехвърлянето към съпорт - че работата трябва да се организира правилно. Но ще ви разкажа за проблемите, които, разбира се, съществуват.

Първо, технологията е нова. Това е хайп в добрия смисъл и намирането на специалист, който ще разбере и може да създаде това, е голямо предизвикателство. Конкуренцията за ресурси е луда, така че експертите си струват златото.

Второ, със създаването на определени пейзажи и нарастващ брой услуги, проблемът с повторното използване трябва постоянно да се решава. Както обичат да правят разработчиците: „Нека напишем много интересни неща тук сега...“ Поради това системата расте и губи своята ефективност по отношение на пари, цена на притежание и т.н. Това означава, че е необходимо да се включи повторно използване в системната архитектура, да се включи в пътната карта за въвеждане на услуги и прехвърляне на наследство към нова архитектура.

Друг проблем – въпреки че това е добре по свой начин – е вътрешната конкуренция. „О, тук се появиха нови модерни момчета, те говорят нов език.“ Хората, разбира се, са различни. Има такива, които са свикнали да пишат на Java, и такива, които пишат и използват Docker и Kubernetes. Това са напълно различни хора, говорят различно, използват различни термини и понякога не се разбират. Възможността или неспособността за споделяне на практика, споделяне на знания в този смисъл също е проблем.

Е, мащабиране на ресурси. „Страхотно, да тръгваме! А сега искаме по-бързо, повече. Какво, не можеш? Не е ли възможно да доставяме два пъти повече за една година? И защо?" Такива нарастващи болки вероятно са стандартни за много неща, много подходи и можете да ги почувствате.

Относно мониторинга. Струва ми се, че услугите или индустриалните инструменти за мониторинг вече се учат или могат да работят както с Docker, така и с Kubernetes в различен, нестандартен режим. Така че, например, да не се окажете с 500 Java машини, под които всичко това работи, а именно агрегира. Но тези продукти все още нямат зрялост; те трябва да преминат през това. Темата наистина е нова, ще продължи да се развива.

Дмитрий:

Да, много интересно. И това се отнася за HR. Може би вашият HR процес и HR марка са се променили малко през тези 3 години. Започнахте да наемате други хора с различни компетенции. И вероятно има както плюсове, така и минуси. Преди това блокчейн и науката за данни бяха реклама, а специалистите по тях струваха милиони. Сега разходите падат, пазарът се насища и има подобна тенденция при микроуслугите.

Сергей:

Да, абсолютно.

Александър:

HR задава въпроса: „Къде е вашият розов еднорог между бекенда и фронтенда?“ HR не разбира какво е микроуслуга. Казахме им тайната и им казахме, че бекендът прави всичко и че няма еднорог. Но човешките ресурси се променят, учат се бързо и набират хора, които имат основни ИТ познания.

Еволюцията на микроуслугите

Дмитрий:

Ако погледнете целевата архитектура, микроуслугите изглеждат като такова чудовище. Вашето пътуване отне няколко години. Други имат година, трети три години. Предвидихте ли всички проблеми, целевата архитектура, промени ли се нещо? Например, в случай на микроуслуги, шлюзовете и мрежите за услуги сега се появяват отново. Използвахте ли ги в началото или променихте самата архитектура? Имате ли такива предизвикателства?

Сергей:

Вече сме пренаписали няколко комуникационни протокола. Отначало имаше един протокол, сега минахме на друг. Ние повишаваме безопасността и надеждността. Започнахме с корпоративни технологии - Oracle, Web Logic. Сега се отдалечаваме от технологичните корпоративни продукти в микроуслугите и преминаваме към отворен код или напълно отворени технологии. Изоставяме базите данни и преминаваме към това, което работи по-ефективно за нас в този модел. Вече не се нуждаем от технологии на Oracle.

Започнахме просто като услуга, без да мислим колко ни трябва кеш, какво ще правим, когато няма връзка с микроуслуга, но са необходими данни и т.н. Сега разработваме платформа, за да може да се опише архитектурата не на езика на услугите, а на бизнес езика, пренесете бизнес логиката на следващото ниво, когато започнем да говорим с думи. Сега се научихме да говорим с букви и следващото ниво е, когато услугите ще бъдат събрани в някакъв агрегат, когато това вече е дума - например цяла продуктова карта. Той е сглобен от микроуслуги, но е API, изграден върху това.

Безопасността е много важна. Веднага след като започнете да сте достъпни и имате услуга, чрез която можете да получите много интересни неща, и то много бързо, за част от секундата, тогава има желание да го получите по не най-сигурния начин. За да избегнем това, трябваше да променим подходите към тестването и мониторинга. Трябваше да променим екипа, структурата за управление на доставките, CI/CD.

Това е еволюция - както при телефоните, само че много по-бързо: първо имаше телефони с бутони, после се появиха смартфоните. Те пренаписаха и преработиха продукта, защото пазарът имаше различна нужда. Така се развиваме: първи клас, десети клас, работа.

Итеративно, нещо се излага на година от гледна точка на технологията, нещо друго от гледна точка на изоставането и нуждите. Ние свързваме едно нещо с друго. Екипът харчи 20% за технически дълг и техническа поддръжка за екипа, 80% за бизнес субекта. И се движим с разбиране защо го правим, защо правим тези технологични подобрения, до какво ще доведат. така.

Дмитрий:

Готино. Какво има в MegaFon?

Александър:

Основното предизвикателство, когато стигнахме до микроуслугите, беше да не изпаднем в хаос. Архитектурното бюро на MegaFon веднага се присъедини към нас, дори стана инициатор и двигател - сега имаме много силна архитектура. Неговата задача беше да разбере към какъв целеви модел вървим и какви технологии трябва да бъдат пилотирани. С архитектурата ние сами проведохме тези пилотни проекти.

Следващият въпрос беше: „Тогава как да използвам всичко това?“ И още нещо: „Как да осигурим прозрачно взаимодействие между микроуслугите?“ Service mesh ни помогна да отговорим на последния въпрос. Пилотирахме Istio и харесахме резултатите. Сега сме на етап разгръщане в продуктивни зони. Имаме положително отношение към всички предизвикателства - фактът, че трябва постоянно да променяме стека, да учим нещо ново. Интересуваме се от развитие, а не от експлоатиране на стари решения.

Дмитрий:

Златни думи! Подобни предизвикателства държат екипа и бизнеса на нокти и създават бъдещето. GDPR създаде главни служители по защита на данните, а настоящите предизвикателства създават главни служители по микроуслуги и архитектура. И това радва.

Обсъждахме много. Основното е, че добрият дизайн на микроуслугите и самата архитектура ви позволява да избегнете много грешки. Разбира се, процесът е итеративен и еволюционен, но това е бъдещето.

Благодаря на всички участници, благодаря на Сергей и Александър!

Въпроси от публиката

Въпрос от публиката (1):

Сергей, как се промени ИТ управлението във вашата компания? Разбирам, че когато има голям стек от няколко системи, как се управлява е доста ясен и логичен процес. Как възстановихте управлението на ИТ компонента, след като много голям брой микроуслуги бяха интегрирани за толкова кратко време?

Сергей:

Съгласен съм с моя колега, че архитектурата е много важна като двигател на промяната. Започнахме с архитектурно подразделение. Архитектите са едновременно собственици на разпределението на функционалността и изискванията за това как тя ще изглежда в ландшафта. Така че те действат и като координатори на тези промени. В резултат на това имаше специфични промени в конкретен процес на доставка, когато създадохме CI/CD платформа.

Но стандартът, основните принципи на развитие, бизнес анализ, тестване и развитие не са отменени. Просто добавихме скорост. Преди цикълът отнемаше толкова много, инсталацията в тестови среди отнемаше много повече. Сега бизнесът вижда ползата и казва: „Защо не можем да направим същото на други места?“

Това е като, в добрия смисъл, инжекция под формата на ваксина, която показва: можете да го направите по този начин, но можете да го направите по друг начин. Разбира се, че има проблем в кадрите, в компетенциите, в знанията, в съпротивата.

Въпрос от публиката (2):

Критиците на архитектурата на микросервизите казват, че тестването и разработката са трудни. Това е логично там, където нещата се усложняват. Пред какви предизвикателства се изправи вашият екип и как ги преодоляхте? Въпрос към всички.

Александър:

Има трудности при преминаване от микроуслуги към платформа, но те могат да бъдат решени.

Например, ние правим продукт, който се състои от 5-7 микроуслуги. Трябва да предоставим интеграционни тестове в целия стек на микроуслугите, за да дадем зелена светлина за преминаване към главния клон. Тази задача не беше нова за нас: правехме това от дълго време в BSS, когато доставчикът ни достави вече доставени решения.

А нашият проблем е само в малкия екип. Необходим е един QA инженер за един условен продукт. И така, изпращаме продукт от 5-7 микроуслуги, от които 2-3 могат да бъдат разработени от трети страни. Например, имаме продукт, в разработването на който участва нашият доставчик на система за таксуване, Mail.ru Group и MegaFon R&D. Трябва да покрием това с тестове, преди да го изпратим до производството. QA инженерът работи по този продукт от месец и половина, а останалата част от екипа остава без неговата подкрепа.

Тази сложност се причинява само от мащабиране. Разбираме, че микроуслугите не могат да съществуват във вакуум; абсолютна изолация не съществува. Когато променяме една услуга, ние винаги се опитваме да запазим API договора. Ако нещо се промени под капака, предният сервиз остава. Ако промените са фатални, се извършва някаква архитектурна трансформация и преминаваме към напълно различен метамодел на данните, който е напълно несъвместим – едва тогава говорим за появата на v2 service API спецификация. Ние поддържаме първата и втората версия едновременно и след като всички потребители преминат към втората версия, ние просто затваряме първата.

Сергей:

Искам да добавя. Абсолютно съм съгласна за усложненията - случват се. Пейзажът става все по-сложен и режийните разходи се увеличават, особено за тестване. Как да се справите с това: преминете към автоматизирано тестване. Да, ще трябва да инвестирате допълнително в писане на автотестове и модулни тестове. За да не могат разработчиците да се ангажират, без да преминат теста, те не могат да променят кода. Така че дори бутонът да не работи без автотест, unit test.

Важно е да се поддържа предишната функционалност, а това е допълнително натоварване. Ако пренапишете технология към друг протокол, тогава я пренаписвате, докато затворите всичко напълно.

Понякога не правим крайно тестване нарочно, защото не искаме да спрем разработката, въпреки че също имаме едно след друго. Пейзажът е много голям, сложен, има много системи. Понякога това са само мъничета - да, намалявате границата на безопасност, появяват се повече рискове. Но в същото време освобождавате доставките.

Александър:

Да, автотестовете и модулните тестове ви позволяват да създадете висококачествена услуга. Ние сме за конвейер, който не може да бъде преминат без модулни и интеграционни тестове. Често трябва да влачим емулатори и търговски системи в тестови зони и среди за разработка, защото не всички системи могат да бъдат поставени в тестови зони. Освен това те не просто се намокрят - ние генерираме пълноценен отговор от системата. Това е сериозна част от работата с микроуслуги и ние също инвестираме в нея. Без това ще настъпи хаос.

Въпрос от публиката (3):

Доколкото разбирам, микроуслугите първоначално са израснали от отделен екип и сега съществуват в този модел. Какви са неговите плюсове и минуси?

Просто имаме подобна история: възникна един вид фабрика за микроуслуги. Сега концептуално стигнахме до точката, че разширяваме този подход към производство по потоци и по системи. С други думи, ние се отдалечаваме от централизираното развитие на микроуслуги, модели на микроуслуги и се доближаваме до системите.

Съответно нашата работа отива и към системите, тоест децентрализираме тази тема. Какъв е вашият подход и каква е вашата целева история?

Александър:

Изпуснахте името „фабрика за микроуслуги“ направо от устата си - ние също искаме да мащабираме. Първо, сега наистина имаме един отбор. Искаме да предоставим на всички екипи за разработка, които има MegaFon, възможността да работят в обща екосистема. Не искаме да поемем напълно цялата функционалност за разработка, която имаме сега. Локалната задача е да се мащабира, глобалната задача е да се ръководи развитието на всички екипи в слоя на микросервизите.

Сергей:

Ще ви кажа пътя, който сме поели. Наистина започнахме да работим като един екип, но сега не сме сами. Аз съм привърженик на следното: трябва да има собственик на процеса. Някой трябва да разбира, управлява, контролира и изгражда процеса на разработка на микроуслуги. Той трябва да притежава ресурси и да участва в управлението на ресурсите.

Тези ресурси, които познават технологии, специфики и разбират как да изграждат микроуслуги, могат да бъдат разположени в продуктови екипи. Имаме комбинация, в която хора от платформата за микросервизи са в продуктовия екип, който прави мобилното приложение. Те са там, но работят според процеса на отдела за управление на платформата за микросервизи с техния мениджър по развитие. В рамките на това подразделение има отделен екип, който се занимава с технологии. Тоест, смесваме общ пул от ресурси помежду си и ги разделяме, давайки ги на екипи.

В същото време процесът остава общ, контролиран, протича по общи технологични принципи, с тестване на единици и така нататък - всичко, което е надградено. Може да има колони под формата на ресурси, събрани от различни отдели на продуктовия подход.

Александър:

Сергей, ти всъщност си собственикът на процеса, нали? Споделят ли се натрупаните задачи? Кой е отговорен за разпространението му?

Сергей:

Вижте: ето отново сместа. Има изоставане, което се формира на базата на технологични подобрения - това е една история. Има изоставане, което е формулирано от проекти, и има изоставане от продукти. Но последователността на въвеждане във всеки от сервизните продукти или създаването на тази услуга се разработва от продуктов специалист. Той не е в ИТ дирекция, специално е изваден от нея. Но моите хора определено работят по същия процес.

Собственикът на изоставането в различни посоки - изоставането на промените - ще бъдат различни хора. Свързаността на технологичните услуги, принципът им на организация - всичко това ще бъде в ИТ. Аз притежавам платформата и ресурсите също. Най-отгоре е това, което се отнася до изоставането и функционалните промени и архитектурата в този смисъл.

Да кажем, че един бизнес казва: „Искаме тази функция, искаме да създадем нов продукт – преработете заем.“ Отговаряме: „Да, ще го преработим.“ Архитектите казват: „Нека помислим: къде в заема ще напишем микроуслуги и как ще го направим?“ След това го разделяме на проекти, продукти или технологичен стек, поставяме го в екипи и го прилагаме. Създали ли сте продукт вътрешно и сте решили да използвате микроуслуги в този продукт? Казваме: „Сега наследените системи, които имахме, или системите на първа линия, трябва да преминат към тези микроуслуги.“ Архитектите казват: „И така: в технологичното изоставане в продуктите от първа линия - преходът към микроуслуги. Отивам". И продуктовите специалисти или собствениците на бизнес разбират колко капацитет е разпределен, кога ще бъде направено и защо.

Край на дискусията, но не всички

Организирана е конференцията mailto:CLOUD Облачни решения на Mail.ru.

Правим и други събития - напр. @Kubernetes среща, където винаги търсим страхотни лектори:

• Следвайте @Kubernetes и други новини от @Meetup в нашия канал в Telegram t.me/k8s_mail
• Интересувате ли се да говорите на една от @Meetups? Оставете заявка за mcs.mail.ru/speak

Източник: www.habr.com