ProHoster > Blogs > Administrācija > No monolītiem līdz mikropakalpojumiem: M.Video-Eldorado un MegaFon pieredze

No monolītiem līdz mikropakalpojumiem: M.Video-Eldorado un MegaFon pieredze

No monolītiem līdz mikropakalpojumiem: M.Video-Eldorado un MegaFon pieredze

25. aprīlī mēs Mail.ru grupā rīkojām konferenci par mākoņiem un apkārtni - mailto:CLOUD. Daži akcenti:

  • Galvenais Krievijas pakalpojumu sniedzēji ā€” Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center un Yandex.Cloud stāstÄ«ja par mÅ«su mākoņu tirgus specifiku un saviem pakalpojumiem;
  • Kolēģi no Bitrix24 pastāstÄ«ja, kā viņi nonāca multicloud;
  • Interesanti sniedza Leroy Merlin, Otkritie, Burger King un Schneider Electric skats no mākoņa patērētājiem ā€” kādus uzdevumus viņu bizness izvirza IT jomā un kādas tehnoloÄ£ijas, tostarp mākoņpakalpojumus, uzskata par daudzsoloŔākajām.

Varat skatÄ«ties visus mailto:CLOUD konferences video ŠæŠ¾ ссыŠ»ŠŗŠµ, un Å”eit var palasÄ«t, kā noritēja diskusija par mikropakalpojumiem. MegaFon biznesa sistēmu pētniecÄ«bas un attÄ«stÄ«bas centra vadÄ«tājs Aleksandrs Deuļins un M.Video-Eldorado grupas informācijas tehnoloÄ£iju direktors Sergejs Sergejevs dalÄ«jās savos veiksmÄ«gajos gadÄ«jumos, kā atbrÄ«voties no monolÄ«tiem. Mēs pārrunājām arÄ« saistÄ«tos jautājumus par IT stratēģiju, procesiem un pat HR.

Paneļu dalībnieki

  • Sergejs Sergejevs, Grupas CIO "M.Video-Eldorado";
  • Aleksandrs Deulins, biznesa sistēmu pētniecÄ«bas un attÄ«stÄ«bas centra vadÄ«tājs MegaFon;
  • Moderators - Dmitrijs Lazarenko, PaaS virziena vadÄ«tājs Mail.ru mākoņa risinājumi.

Pēc Aleksandra Deulina runas ā€œKā MegaFon paplaÅ”ina savu biznesu, izmantojot mikropakalpojumu platformuā€ viņam pievienojas diskusijai Sergejs Sergejevs no M.Video-Eldorado un diskusijas moderators Dmitrijs Lazarenko, Mail.ru Cloud Solutions.

Zemāk esam sagatavojuŔi jums diskusijas stenogrammu, bet varat arī noskatīties video:

Pāreja uz mikropakalpojumiem ir atbilde uz tirgus vajadzībām

Dmitrijs:

Vai jums ir bijusi veiksmīga pieredze, pārejot uz mikropakalpojumiem? Un vispār: kur jūs redzat vislielāko biznesa ieguvumu no mikropakalpojumu izmantoŔanas vai pārejas no monolītiem uz mikropakalpojumiem?

Sergejs:

Mēs jau esam sasnieguÅ”i zināmu ceļu pārejā uz mikropakalpojumiem un izmantojam Å”o pieeju vairāk nekā trÄ«s gadus. Pirmā nepiecieÅ”amÄ«ba, kas attaisnoja mikropakalpojumu nepiecieÅ”amÄ«bu, bija dažādu priekÅ”gala produktu bezgalÄ«ga integrācija ar back office. Un katru reizi bijām spiesti veikt papildu integrāciju un attÄ«stÄ«bu, ievieÅ”ot savus noteikumus tā vai cita pakalpojuma darbÄ«bai.

Kādā brÄ«dÄ« mēs sapratām, ka mums ir jāpaātrina mÅ«su sistēmu darbÄ«ba un funkcionalitātes izvade. Tajā brÄ«dÄ« tirgÅ« jau pastāvēja tādi jēdzieni kā mikropakalpojumi un mikropakalpojumu pieeja, un mēs nolēmām to izmēģināt. Tas sākās 2016. gadā. Pēc tam platforma tika uzlikta un pirmos 10 pakalpojumus Ä«stenoja atseviŔķa komanda.

Viens no pirmajiem pakalpojumiem, visvairāk noslogotais, bija cenu aprēķināŔanas pakalpojums. Katru reizi, kad nonākat jebkurā kanālā, M.Video-Eldorado uzņēmumu grupā, neatkarÄ«gi no tā, vai tā ir vietne vai mazumtirdzniecÄ«bas veikals, tur atlasāt preci, skatiet cenu vietnē vai ā€œGrozāā€, maksa tiek automātiski aprēķināta. aprēķināts pēc viena pakalpojuma. Kāpēc tas ir nepiecieÅ”ams: pirms tam katrai sistēmai bija savi principi darbam ar akcijām - ar atlaidēm un tā tālāk. MÅ«su back office nodarbojas ar cenu noteikÅ”anu, atlaižu funkcionalitāte ir ieviesta citā sistēmā. To vajadzēja centralizēt un izveidot unikālu, atdalāmu pakalpojumu biznesa procesa veidā, kas ļautu mums to Ä«stenot. GandrÄ«z tā mēs sākām.

Pirmo rezultātu vērtÄ«ba bija ļoti liela. Pirmkārt, mēs varējām izveidot atdalāmas entÄ«tijas, kas ļauj mums strādāt atseviŔķi un apkopotā veidā. Otrkārt, esam samazinājuÅ”i Ä«paÅ”umtiesÄ«bu izmaksas saistÄ«bā ar integrāciju ar vairākām sistēmām.

Pēdējo trÄ«s gadu laikā esam pievienojuÅ”i trÄ«s frontālās sistēmas. Bija grÅ«ti tos uzturēt ar tādu paÅ”u resursu apjomu, kādu uzņēmums varēja atļauties. Tāpēc radās uzdevums meklēt jaunus noieta tirgus, reaģējot uz tirgu ātruma, iekŔējo izmaksu un efektivitātes ziņā.

Kā izmērÄ«t panākumus migrÄ“Å”anā uz mikropakalpojumiem

Dmitrijs:

Kā tiek noteikti panākumi migrÄ“Å”anā uz mikropakalpojumiem? Kas bija ā€œpirmsā€ katrā uzņēmumā? Kādu metriku izmantojāt, lai noteiktu pārejas panākumus, un kurÅ” to faktiski noteica?

Sergejs:

Pirmkārt, tas ir dzimis IT ietvaros kā veicinātājs ā€“ ā€œatbloķējotā€ jaunas iespējas. Mums bija nepiecieÅ”amÄ«ba visu darÄ«t ātrāk par salÄ«dzinoÅ”i to paÅ”u naudu, reaģējot uz tirgus izaicinājumiem. Tagad panākumi izpaužas dažādu sistēmu atkārtoti izmantoto pakalpojumu skaitā, procesu apvienoÅ”anā savā starpā. Tagad tā ir, bet tajā brÄ«dÄ« bija iespēja izveidot platformu un apstiprināt hipotēzi, ka mēs to varam izdarÄ«t, tas dos efektu un aprēķinās biznesa gadÄ«jumu.

Aleksandrs:

Panākumi drÄ«zāk ir iekŔēja sajÅ«ta. UzņēmējdarbÄ«ba vienmēr vēlas vairāk, un mÅ«su nepabeigtā apjoma dziļums ir veiksmes pierādÄ«jums. Man tā Ŕķiet.

Sergejs:

Jā, es piekrÄ«tu. TrÄ«s gadu laikā mums jau ir vairāk nekā divi simti pakalpojumu un neizpildÄ«tie pakalpojumi. VajadzÄ«ba pēc resursiem komandā tikai pieaug ā€“ par 30% gadā. Tas notiek tāpēc, ka cilvēki juta: tas ir ātrāk, tas ir savādāk, ir dažādas tehnoloÄ£ijas, tas viss attÄ«stās.

Mikropakalpojumi nāks, bet kodols paliks

Dmitrijs:

Tas ir kā nebeidzams process, kurā tu ieguldi attīstībā. Vai pāreja uz mikropakalpojumiem biznesam jau ir beigusies vai nav?

Sergejs:

Uz to ir ļoti viegli atbildēt. Ko jÅ«s domājat: tālruņu nomaiņa ir bezgalÄ«gs process? Mēs paÅ”i pērkam telefonus katru gadu. Un Å”eit tas ir: kamēr bÅ«s vajadzÄ«gs ātrums, pielāgoÅ”anās tirgum, bÅ«s nepiecieÅ”amas dažas izmaiņas. Tas nenozÄ«mē, ka mēs atsakāmies no standarta lietām.

Taču mēs nevaram visu uzreiz aptvert un pārtaisÄ«t. Mums ir mantoti standarta integrācijas pakalpojumi, kas pastāvēja iepriekÅ”: uzņēmumu autobusi un tā tālāk. Bet ir atpalicÄ«ba, un ir arÄ« nepiecieÅ”amÄ«ba. Pieaug mobilo aplikāciju skaits un to funkcionalitāte. Tajā paŔā laikā neviens nesaka, ka jums iedos par 30% vairāk naudas. Tas ir, no vienas puses vienmēr ir vajadzÄ«bas, no otras ā€“ efektivitātes meklējumi.

Dmitrijs:

Dzīve ir labā formā. (Smejas)

Aleksandrs:

Vispār jā. Mums nav revolucionāras pieejas galvenās daļas noņemÅ”anai no ainavas. Notiek sistemātisks darbs pie sistēmu sadalÄ«Å”anas, lai tās vairāk atbilstu mikropakalpojumu arhitektÅ«rai, lai samazinātu sistēmu ietekmi viena uz otru.

Bet mēs plānojam saglabāt galveno daļu, jo operatora vidē vienmēr bÅ«s dažas platformas, kuras mēs pērkam. Atkal mums ir vajadzÄ«gs veselÄ«gs lÄ«dzsvars: mums nevajadzētu steigties ar kodola izgrieÅ”anu. Mēs novietojam sistēmas blakus, un tagad izrādās, ka mēs jau esam virs daudzām galvenajām daļām. Tālāk, attÄ«stot funkcionalitāti, mēs veidojam nepiecieÅ”amos attēlojumus visiem kanāliem, kas strādā ar mÅ«su sakaru pakalpojumiem.

Kā pārdot mikropakalpojumus uzņēmumiem

Dmitrijs:

Mani arÄ« interesē - tiem, kas nav pārgājuÅ”i, bet plāno: cik viegli bija Å”o ideju pārdot biznesam un vai tas bija piedzÄ«vojums, investÄ«ciju projekts? Vai arÄ« tā bija apzināta stratēģija: tagad mēs ejam uz mikropakalpojumiem, un viss, nekas mÅ«s neapturēs. Kā tev gāja?

Sergejs:

Mēs nepārdevām pieeju, bet gan biznesa ieguvumu. Biznesā radās problēma, un mēs centāmies to atrisināt. Tajā brÄ«dÄ« tas izpaudās tajā, ka dažādi kanāli izmantoja dažādus cenu aprēķināŔanas principus - atseviŔķi akcijām, akcijām utt. Bija grÅ«ti uzturēt, radās kļūdas, mēs uzklausÄ«jām klientu sÅ«dzÄ«bas. Tas ir, mēs pārdevām problēmas risinājumu, bet mēs nonācām ar faktu, ka mums vajadzēja naudu, lai izveidotu platformu. Un viņi parādÄ«ja biznesa piemēru, izmantojot pirmā investÄ«ciju posma piemēru: kā mēs turpināsim to atpelnÄ«t un ko tas mums ļaus darÄ«t.

Dmitrijs:

Vai jūs kaut kā piefiksējāt pirmā posma laiku?

Sergejs:

Jā, protams. Mēs pieŔķīrām 6 mēneÅ”us, lai izveidotu kodolu kā platformu un pārbaudÄ«tu pilotu. Å ajā laikā mēģinājām izveidot platformu, uz kuras varētu slidot pilotu. Tad hipotēze tika apstiprināta, un, tā kā tā darbojas, tas nozÄ«mē, ka mēs varam turpināt. Viņi sāka atkārtot un nostiprināja komandu - viņi to pārcēla uz atseviŔķu divÄ«ziju, kas tieÅ”i to dara.

Tālāk seko sistemātisks darbs, kas balstās uz biznesa vajadzÄ«bām, iespējām, resursu pieejamÄ«bu un visu, kas Å”obrÄ«d ir darbos.

Dmitrijs:

LABI. Aleksandr, ko tu saki?

Aleksandrs:

MÅ«su mikropakalpojumi radās no ā€œjÅ«ras putāmā€ ā€“ resursu taupÄ«Å”anas, dažu pārpalikumu servera kapacitātes un spēku pārdales dēļ komandas iekÅ”ienē. Sākotnēji mēs nepārdevām Å”o projektu biznesam. Å is bija projekts, kurā mēs gan pētÄ«jām, gan attiecÄ«gi attÄ«stÄ«jāmies. Mēs sākām 2018. gada sākumā un vienkārÅ”i ar entuziasmu attÄ«stÄ«jām Å”o virzienu. PārdoÅ”ana ir tikko sākusies, un mēs esam procesā.

Dmitrijs:

Vai gadās, ka bizness ļauj darÄ«t tādas lietas kā Google ā€“ vienā brÄ«vā dienā nedēļā? Vai jums ir Ŕāds virziens?

Aleksandrs:

Vienlaikus ar pētniecÄ«bu mēs nodarbojāmies arÄ« ar biznesa problēmām, tāpēc visi mÅ«su mikropakalpojumi ir biznesa problēmu risinājumi. Tikai sākumā veidojām mikropakalpojumus, kas aptvēra nelielu daļu no abonentu bāzes, un tagad esam klāt gandrÄ«z visos vadoÅ”ajos produktos.

Un materiālā ietekme jau ir skaidra ā€“ mÅ«s jau var saskaitÄ«t, var novērtēt produktu palaiÅ”anas ātrumu un zaudētos ieņēmumus, ja bÅ«tu gājuÅ”i pa veco ceļu. Uz Ŕī pamata mēs veidojam lietu.

Mikropakalpojumi: ažiotāža vai nepiecieŔamība?

Dmitrijs:

Skaitļi ir skaitļi. Un ieņēmumi vai ietaupÄ«tā nauda ir ļoti svarÄ«gi. Ko darÄ«t, ja paskatās uz otru pusi? Å Ä·iet, ka mikropakalpojumi ir tendence, ažiotāža un daudzi uzņēmumi to ļaunprātÄ«gi izmanto? Cik skaidri jÅ«s atŔķirat to, ko darāt un ko netulkojat mikropakalpojumos? Ja mantojums bÅ«s tagad, vai jums joprojām bÅ«s mantojums pēc 5 gadiem? Kāds bÅ«s informācijas sistēmu vecums, kas strādās M.Video-Eldorado un MegaFon pēc 5 gadiem? Vai bÅ«s desmit, piecpadsmit gadus vecas informācijas sistēmas vai tā bÅ«s jauna paaudze? Kā jÅ«s to redzat?

Sergejs:

Man Ŕķiet, ka ir grÅ«ti domāt ļoti tālu. Ja mēs atskatāmies atpakaļ, kurÅ” iedomājās, ka tehnoloÄ£iju tirgus attÄ«stÄ«sies Ŕādā veidā, ieskaitot maŔīnmācÄ«Å”anos un lietotāja identifikāciju pēc sejas? Bet, ja paskatās uz nākamajiem gadiem, man Ŕķiet, ka pamatsistēmas, uzņēmumu ERP klases sistēmas uzņēmumos - tās darbojas jau diezgan ilgu laiku.

MÅ«su uzņēmumiem kopumā ir 25 gadi, un klasiskā ERP sistēma ir ļoti dziļa sistēmu vidē. Skaidrs, ka mēs izņemam no turienes dažus gabalus un mēģinām tos apkopot mikropakalpojumos, bet kodols paliks. Man tagad ir grÅ«ti iedomāties, ka mēs nomainÄ«sim visas tur esoŔās pamatsistēmas un ātri pāriesim uz citu, gaiÅ”o jauno sistēmu pusi.

Esmu piekritējs tam, ka viss, kas ir tuvāk klientam un patērētājam, ir tur, kur ir vislielākais biznesa ieguvums un vērtÄ«ba, kur ir pielāgoÅ”anās spēja un koncentrÄ“Å”anās uz ātrumu, pārmaiņām, uz ā€œmēģini, atcel, izmanto atkārtoti, dari kaut ko savādākā€ vajadzÄ«gs ā€œā€” tur ainava mainÄ«sies. Un kastē iepakotie produkti tur Ä«sti neiederas. Vismaz mēs to neredzam. Tur ir nepiecieÅ”ami vienkārŔākie, vienkārŔākie risinājumi.

Mēs redzam Ŕādu attÄ«stÄ«bu:

  • pamata informācijas sistēmas (galvenokārt back office);
  • vidējie slāņi mikropakalpojumu veidā savieno kodolu, apkopo, izveido keÅ”atmiņu utt.;
  • priekŔējās lÄ«nijas sistēmas ir vērstas uz patērētāju;
  • integrācijas slānis, kas parasti ir integrēts tirgos, citās sistēmās un ekosistēmās. Å is slānis ir pēc iespējas vieglāks, vienkārÅ”s un satur minimālu biznesa loÄ£iku.

Bet tajā paŔā laikā es atbalstu veco principu turpmāku izmantoŔanu, ja tie tiek atbilstoŔi izmantoti.

Pieņemsim, ka jums ir klasiska uzņēmuma sistēma. Tas atrodas viena pārdevēja ainavā un sastāv no diviem moduļiem, kas darbojas viens ar otru. Ir arī standarta integrācijas saskarne. Kāpēc to pārtaisīt un nest tur mikropakalpojumu?

Bet, kad aizmugurējā birojā ir 5 moduļi, no kuriem informācija tiek savākta biznesa procesā, ko pēc tam izmanto 8-10 frontālās sistēmas, ieguvums ir pamanāms uzreiz. JÅ«s ņemat no piecām back-office sistēmām un izveidojat pakalpojumu, izolētu, kas ir vērsts uz biznesa procesu. Padariet pakalpojumu tehnoloÄ£iski modernu ā€“ lai tas saglabātu informāciju keÅ”atmiņā un bÅ«tu izturÄ«gs pret kļūmēm, kā arÄ« darbotos ar dokumentiem vai biznesa vienÄ«bām. Un jÅ«s to integrējat saskaņā ar vienu principu ar visiem priekŔējās lÄ«nijas produktiem. Viņi atcēla priekŔējās lÄ«nijas produktu - viņi vienkārÅ”i izslēdza integrāciju. RÄ«t jums jāraksta mobilā aplikācija vai jāizveido neliela vietne un jāievieto funkcionalitātē tikai viena daļa - viss ir vienkārÅ”i: jÅ«s to samontējāt kā konstruktoru. Es redzu lielāku attÄ«stÄ«bu Å”ajā virzienā ā€“ vismaz mÅ«su valstÄ«.

Aleksandrs:

Sergejs pilnÄ«bā aprakstÄ«ja mÅ«su pieeju, paldies. Es tikai pateikÅ”u, kur mēs noteikti neiesim - uz galveno daļu, uz tieÅ”saistes norēķinu tēmu. Tas ir, reitings un iekasÄ“Å”ana faktiski paliks ā€œlielsā€ kuļnieks, kas droÅ”i norakstÄ«s naudu. Un Å”o sistēmu arÄ« turpmāk sertificēs mÅ«su regulējoŔās iestādes. Viss pārējais, kas skatās uz klientiem, protams, ir mikropakalpojumi.

Dmitrijs:

Å eit sertifikācija ir viens stāsts. DroÅ”i vien vairāk atbalsta. Ja atbalstam tērējat maz vai sistēmai nav nepiecieÅ”ams atbalsts un modifikācijas, labāk tai nepieskarties. SaprātÄ«gs kompromiss.

Kā izveidot uzticamus mikropakalpojumus

Dmitrijs:

Labi. Bet mani joprojām interesē. Tagad jūs stāstāt veiksmes stāstu: viss bija kārtībā, pārgājām uz mikropakalpojumiem, aizstāvējām ideju biznesam, un viss izdevās. Bet esmu dzirdējis citus stāstus.

Pirms pāris gadiem Šveices uzņēmums, kas divus gadus bija ieguldījis jaunas mikropakalpojumu platformas izstrādē bankām, galu galā projektu slēdza. Pilnīgi sabruka. Tika iztērēti daudzi miljoni Šveices franku, un galu galā komanda tika izklīdināta - tas neizdevās.

Vai jums ir bijuÅ”i lÄ«dzÄ«gi stāsti? Vai bija vai ir kādas grÅ«tÄ«bas? Piemēram, mikropakalpojumu uzturÄ“Å”ana un uzraudzÄ«ba ir arÄ« galvassāpes uzņēmuma operatÄ«vajā darbÄ«bā. Galu galā komponentu skaits palielinās desmitiem reižu. Kā jÅ«s to redzat, vai Å”eit ir bijuÅ”i neveiksmÄ«gi investÄ«ciju piemēri? Un ko jÅ«s varat ieteikt cilvēkiem, lai viņi nesaskartos ar Ŕādām problēmām?

Aleksandrs:

NeveiksmÄ«gi piemēri ietvēra uzņēmumus, kas mainÄ«ja prioritātes un atcēla projektus. Kad bija labā gatavÄ«bas stadijā (patiesÄ«bā MVP ir gatavs), uzņēmums teica: "Mums ir jaunas prioritātes, mēs pārejam pie cita projekta, un mēs slēdzam Å”o."

Mums nebija nekādu globālu kļūmju ar mikropakalpojumiem. Mēs guļam mierīgi, mums ir diennakts dežūras, kas apkalpo visu BSS [biznesa atbalsta sistēmu].

Un vēl viena lieta - iznomājam mikropakalpojumus pēc noteikumiem, kas attiecas uz kastÄ«tiem produktiem. Panākumu atslēga ir, pirmkārt, jāsaliek komanda, kas pilnÄ«bā sagatavos mikroservisu ražoÅ”anai. Pati attÄ«stÄ«ba nosacÄ«ti ir 40%. Pārējais ir analÄ«tika, DevSecOps metodoloÄ£ija, pareizās integrācijas un pareizā arhitektÅ«ra. Mēs pievērÅ”am Ä«paÅ”u uzmanÄ«bu droÅ”u lietojumprogrammu veidoÅ”anas principiem. Informācijas droŔības pārstāvji piedalās katrā projektā gan arhitektÅ«ras plānoÅ”anas stadijā, gan realizācijas procesā. Viņi arÄ« pārvalda sistēmas, lai analizētu ievainojamÄ«bu kodu.

Pieņemsim, ka mēs izvietojam savus bezvalstnieku pakalpojumus ā€” mums tie ir Kubernetes. Tas ļauj ikvienam mierÄ«gi gulēt, pateicoties pakalpojumu automātiskai mērogoÅ”anai un automātiskai paaugstināŔanai, un dežūras maiņa uzņem negadÄ«jumus.

Visā mÅ«su mikropakalpojumu pastāvÄ“Å”anas laikā ir bijis tikai viens vai divi incidenti, kas ir sasnieguÅ”i mÅ«su lÄ«niju. Tagad ar darbÄ«bu nav problēmu. Mums, protams, ir nevis 200, bet ap 50 mikropakalpojumu, bet tie tiek izmantoti vadoÅ”ajos produktos. Ja viņiem neizdosies, mēs par to uzzinātu pirmie.

Mikropakalpojumi un HR

Sergejs:

Par pārcelÅ”anu uz atbalstu piekrÄ«tu kolēģei - ka darbs ir pareizi jāorganizē. Bet es jums pastāstÄ«Å”u par problēmām, kas, protams, pastāv.

Pirmkārt, tehnoloÄ£ija ir jauna. Tas ir ažiotāža labā nozÄ«mē, un atrast speciālistu, kurÅ” to sapratÄ«s un spēs izveidot, ir liels izaicinājums. Konkurence par resursiem ir traka, tāpēc eksperti ir zelta vērti.

Otrkārt, veidojot noteiktas ainavas un pieaugot pakalpojumu skaitam, pastāvÄ«gi jārisina atkārtotas izmantoÅ”anas problēma. Izstrādātājiem patÄ«k darÄ«t: ā€œÅ eit tagad uzrakstÄ«sim daudz interesantu lietu...ā€ Å Ä« iemesla dēļ sistēma aug un zaudē savu efektivitāti naudas, Ä«paÅ”umtiesÄ«bu izmaksu un tā tālāk ziņā. Tas nozÄ«mē, ka atkārtota izmantoÅ”ana ir jāiekļauj sistēmas arhitektÅ«rā, jāiekļauj ceļvedÄ« pakalpojumu ievieÅ”anai un mantojuma nodoÅ”anai jaunai arhitektÅ«rai.

Vēl viena problēma ā€“ lai gan tas ir labi savā veidā ā€“ ir iekŔējā konkurence. "Ak, Å”eit ir parādÄ«juÅ”ies jauni moderni puiÅ”i, viņi runā jaunā valodā." Cilvēki, protams, ir dažādi. Ir tie, kas pieraduÅ”i rakstÄ«t Java valodā, un tie, kas raksta un izmanto Docker un Kubernetes. Tie ir pilnÄ«gi atŔķirÄ«gi cilvēki, viņi runā atŔķirÄ«gi, lieto dažādus terminus un dažreiz nesaprot viens otru. Spēja vai nespēja dalÄ«ties praksē, zināŔanu apmaiņa, Å”ajā ziņā arÄ« ir problēma.

Nu, resursu mērogoÅ”ana. ā€œLieliski, iesim! Un tagad mēs vēlamies ātrāk, vairāk. Ko, tu nevari? Vai nav iespējams gada laikā piegādāt divreiz vairāk? Un kāpēc?" Šādas augÅ”anas sāpes, iespējams, ir standarta daudzām lietām, daudzām pieejām, un jÅ«s varat tās sajust.

AttiecÄ«bā uz uzraudzÄ«bu. Man Ŕķiet, ka pakalpojumi vai rÅ«pnieciskās uzraudzÄ«bas rÄ«ki jau mācās vai spēj strādāt gan ar Docker, gan ar Kubernetes citā, nestandarta režīmā. Tā, piemēram, lai jÅ«s nesanāktu ar 500 Java maŔīnām, kurās tas viss darbojas, proti, tas tiek apkopots. Bet Å”iem produktiem joprojām trÅ«kst brieduma; tiem tas ir jāiziet. Tēma tieŔām jauna, tā turpinās attÄ«stÄ«ties.

Dmitrijs:

Jā, ļoti interesanti. Un tas attiecas uz HR. Iespējams, ka jÅ«su personāla vadÄ«bas process un personāla zÄ«mols Å”o 3 gadu laikā ir nedaudz mainÄ«juÅ”ies. JÅ«s sākāt pieņemt darbā citus cilvēkus ar dažādām kompetencēm. Un droÅ”i vien ir gan plusi, gan mÄ«nusi. IepriekÅ” blokķēdes un datu zinātne bija ažiotāža, un to speciālisti bija miljonu vērti. Tagad izmaksas krÄ«tas, tirgus kļūst piesātināts, un lÄ«dzÄ«ga tendence ir arÄ« mikropakalpojumos.

Sergejs:

Jā, absolūti.

Aleksandrs:

HR uzdod jautājumu: "Kur atrodas jÅ«su rozā vienradzis starp aizmuguri un priekŔējo daļu?" HR nesaprot, kas ir mikropakalpojums. Mēs viņiem izstāstÄ«jām noslēpumu un teicām, ka aizmugure darÄ«ja visu, un vienradža nav. Taču HR mainās, ātri mācās un pieņem darbā cilvēkus, kuriem ir IT pamatzināŔanas.

Mikropakalpojumu evolūcija

Dmitrijs:

Ja paskatās uz mērÄ·a arhitektÅ«ru, mikropakalpojumi izskatās pēc Ŕāda monstra. JÅ«su ceļojums ilga vairākus gadus. Citiem ir gads, citiem trÄ«s gadi. Vai jÅ«s paredzējāt visas problēmas, mērÄ·a arhitektÅ«ru, vai kaut kas mainÄ«jās? Piemēram, mikropakalpojumu gadÄ«jumā tagad atkal parādās vārtejas un pakalpojumu tÄ«kli. Vai jÅ«s tos izmantojāt sākumā vai mainÄ«jāt paÅ”u arhitektÅ«ru? Vai jums ir Ŕādi izaicinājumi?

Sergejs:

Mēs jau esam pārrakstÄ«juÅ”i vairākus sakaru protokolus. Sākumā bija viens protokols, tagad pārgājām uz citu. Mēs paaugstinām droŔību un uzticamÄ«bu. Mēs sākām ar uzņēmuma tehnoloÄ£ijām - Oracle, Web Logic. Tagad mēs attālināmies no tehnoloÄ£iskiem uzņēmumu produktiem mikropakalpojumos un pārejam uz atvērtā koda vai pilnÄ«gi atvērtām tehnoloÄ£ijām. Mēs atsakāmies no datubāzēm un pārejam uz to, kas Å”ajā modelÄ« mums darbojas efektÄ«vāk. Mums vairs nav vajadzÄ«gas Oracle tehnoloÄ£ijas.

Sākām vienkārÅ”i kā serviss, nedomājot par to, cik ļoti vajag keÅ”atmiņu, ko darÄ«sim, kad nebÅ«s savienojuma ar mikropakalpojumu, bet bija vajadzÄ«gi dati utt. Tagad izstrādājam platformu, lai arhitektÅ«ru varētu aprakstÄ«t ne pakalpojumu valodā, un biznesa valodā, paceliet biznesa loÄ£iku uz nākamo lÄ«meni, kad mēs sākam runāt vārdos. Tagad esam iemācÄ«juÅ”ies runāt ar burtiem, un nākamais lÄ«menis ir tad, kad pakalpojumi tiks apkopoti kaut kādā agregātā, kad tas jau ir vārds - piemēram, visa produkta karte. Tas ir samontēts no mikropakalpojumiem, taču tā ir API, kas ir veidota uz Ŕī pamata.

DroŔība ir ļoti svarÄ«ga. TiklÄ«dz tu sāc bÅ«t pieejams un tev ir serviss, caur kuru vari iegÅ«t daudz interesanta, turklāt ļoti ātri, sekundes daļā, tad rodas vēlme to iegÅ«t ne tajā droŔākajā veidā. Lai no tā izvairÄ«tos, mums bija jāmaina pieejas testÄ“Å”anai un uzraudzÄ«bai. Mums bija jāmaina komanda, piegādes vadÄ«bas struktÅ«ra, CI/CD.

Tā ir evolÅ«cija ā€“ kā ar telefoniem, tikai daudz ātrāk: vispirms bija spiedpogu telefoni, tad parādÄ«jās viedtālruņi. Viņi pārrakstÄ«ja un pārveidoja produktu, jo tirgum bija atŔķirÄ«gas vajadzÄ«bas. Tā mēs attÄ«stāmies: pirmā klase, desmitā klase, darbs.

IteratÄ«vi gadā kaut kas tiek izlikts no tehnoloÄ£iju viedokļa, kaut kas cits no atpalicÄ«bas un vajadzÄ«bu viedokļa. Mēs savienojam vienu lietu ar otru. Komanda tērē 20% tehniskajam parādam un komandas tehniskajam atbalstam, 80% uzņēmumam. Un mēs virzāmies ar izpratni par to, kāpēc mēs to darām, kāpēc mēs veicam Å”os tehnoloÄ£iskos uzlabojumus, pie kā tie novedÄ«s. Tādi.

Dmitrijs:

ForŔi. Kas ir MegaFon?

Aleksandrs:

Galvenais izaicinājums, kad nonācām pie mikropakalpojumiem, bija neiekrist haosā. MegaFon arhitektu birojs mums uzreiz pievienojās, pat kļuva par iniciatoru un virzÄ«tāju ā€“ tagad mums ir ļoti spēcÄ«ga arhitektÅ«ra. Viņa uzdevums bija saprast, uz kādu mērÄ·a modeli mēs ejam un kādas tehnoloÄ£ijas ir jākontrolē. Ar arhitektÅ«ru mēs paÅ”i vadÄ«jām Å”os izmēģinājumus.

Nākamais jautājums bija: "Kā tad to visu izmantot?" Un vēl: "Kā nodroÅ”ināt caurspÄ«dÄ«gu mijiedarbÄ«bu starp mikropakalpojumiem?" Servisa tÄ«kls mums palÄ«dzēja atbildēt uz pēdējo jautājumu. Mēs pilotējām Istio, un rezultāti patika. Tagad mēs esam ražoÅ”anas zonu izvērÅ”anas stadijā. Mums ir pozitÄ«va attieksme pret visiem izaicinājumiem ā€“ to, ka nemitÄ«gi jāmaina kaudze, jāapgÅ«st kaut kas jauns. Mēs esam ieinteresēti attÄ«stÄ«t, nevis izmantot vecos risinājumus.

Dmitrijs:

Zelta vārdi! Šādi izaicinājumi notur komandu un biznesu uz kājām un veido nākotni. GDPR izveidoja galvenos datu aizsardzÄ«bas speciālistus, un paÅ”reizējās problēmas rada galvenos mikropakalpojumu un arhitektÅ«ras speciālistus. Un tas priecē.

Mēs daudz apspriedām. Galvenais ir tas, ka labs mikropakalpojumu dizains un pati arhitektūra ļauj izvairīties no daudzām kļūdām. Protams, process ir iteratīvs un evolucionārs, bet tā ir nākotne.

Paldies visiem dalībniekiem, paldies Sergejam un Aleksandram!

Klausītāju jautājumi

Klausītāju jautājums (1):

Sergej, kā IT vadība ir mainījusies tavā uzņēmumā? Es saprotu, ka, ja ir liela vairāku sistēmu kaudze, tas, kā tas tiek pārvaldīts, ir diezgan skaidrs un loģisks process. Kā jūs atjaunojāt IT komponentes pārvaldību pēc tam, kad tik īsā laikā tika integrēts ļoti liels skaits mikropakalpojumu?

Sergejs:

Es piekrÄ«tu kolēģim, ka arhitektÅ«ra ir ļoti svarÄ«ga kā pārmaiņu virzÄ«tājspēks. Mēs sākām ar arhitektÅ«ras nodaļas izveidi. Arhitekti vienlaikus ir funkcionalitātes sadalÄ«juma Ä«paÅ”nieki un prasÄ«bas, kā tā parādÄ«sies ainavā. Tātad viņi darbojas arÄ« kā Å”o izmaiņu koordinatori. Tā rezultātā, veidojot CI/CD platformu, tika veiktas Ä«paÅ”as izmaiņas konkrētā piegādes procesā.

Taču standarts, izstrādes pamatprincipi, biznesa analÄ«ze, testÄ“Å”ana un izstrāde nav atcelta. Mēs vienkārÅ”i pievienojām ātrumu. IepriekÅ” cikls prasÄ«ja tik daudz, instalÄ“Å”ana testa vidēs prasÄ«ja daudz vairāk. Tagad bizness redz ieguvumu un saka: "Kāpēc mēs nevarētu darÄ«t to paÅ”u citās vietās?"

Labā nozÄ«mē tas ir kā injekcija vakcÄ«nas veidā, kas parādÄ«ja: jÅ«s varat darÄ«t tā, bet jÅ«s varat darÄ«t citādi. Protams, problēma ir personālā, kompetencēs, zināŔanās, pretestÄ«bā.

Klausītāju jautājums (2):

Mikropakalpojumu arhitektÅ«ras kritiÄ·i saka, ka testÄ“Å”ana un izstrāde ir sarežģīta. Tas ir loÄ£iski, ja lietas kļūst sarežģītas. Ar kādiem izaicinājumiem saskārās jÅ«su komanda un kā jÅ«s tos pārvarējāt? Jautājums visiem.

Aleksandrs:

Pārejot no mikropakalpojumiem uz platformu, rodas grūtības, taču tās var atrisināt.

Piemēram, mēs izgatavojam produktu, kas sastāv no 5-7 mikropakalpojumiem. Mums ir jānodroÅ”ina integrācijas testi visā mikropakalpojumu kaudzē, lai dotu zaļo gaismu pārejai uz galveno filiāli. Å is uzdevums mums nebija jauns: mēs to darÄ«jām jau ilgu laiku BSS, kad pārdevējs mums piegādāja jau piegādātus risinājumus.

Un mÅ«su problēma ir tikai mazajā komandā. Vienam nosacÄ«tajam produktam ir nepiecieÅ”ams viens kvalitātes nodroÅ”ināŔanas inženieris. Tātad, mēs piegādājam produktu ar 5-7 mikropakalpojumiem, no kuriem 2-3 var izstrādāt treŔās puses. Piemēram, mums ir produkts, kura izstrādē piedalās mÅ«su norēķinu sistēmas pārdevējs, Mail.ru Group un MegaFon R&D. Pirms nosÅ«tÄ«Å”anas uz ražoÅ”anu mums tas ir jāpārbauda ar testiem. Kvalitātes nodroÅ”ināŔanas inženieris pie Ŕī produkta strādā pusotru mēnesi, un pārējā komanda paliek bez viņa atbalsta.

Å o sarežģītÄ«bu izraisa tikai mērogoÅ”ana. Mēs saprotam, ka mikropakalpojumi nevar pastāvēt vakuumā; absolÅ«ta izolācija nepastāv. Mainot vienu pakalpojumu, mēs vienmēr cenÅ”amies saglabāt API lÄ«gumu. Ja kaut kas mainās zem pārsega, priekŔējais serviss paliek. Ja izmaiņas ir liktenÄ«gas, notiek kaut kāda arhitektÅ«ras transformācija un mēs pārietam uz pavisam citu datu metamodeļu, kas ir pilnÄ«gi nesaderÄ«gs - tikai tad runājam par v2 servisa API specifikācijas parādÄ«Å”anos. Mēs atbalstām pirmo un otro versiju vienlaicÄ«gi, un pēc tam, kad visi patērētāji pārslēdzas uz otro versiju, mēs vienkārÅ”i aizveram pirmo.

Sergejs:

Es gribu piebilst. PilnÄ«gi piekrÄ«tu par komplikācijām ā€“ tās gadās. Ainava kļūst sarežģītāka, un pieaug pieskaitāmās izmaksas, jo Ä«paÅ”i par testÄ“Å”anu. Kā ar to rÄ«koties: pārejiet uz automātisko testÄ“Å”anu. Jā, jums bÅ«s papildus jāiegulda autotestu un vienÄ«bu testu rakstÄ«Å”anā. Lai izstrādātāji nevarētu uzņemties saistÄ«bas, neizturot testu, viņi nevarēja mainÄ«t kodu. Lai pat spiedpoga nedarbojas bez automātiskās pārbaudes, vienÄ«bas pārbaudes.

Ir svarÄ«gi saglabāt iepriekŔējo funkcionalitāti, un tas ir papildu pieskaitāmās izmaksas. Ja jÅ«s pārrakstāt tehnoloÄ£iju uz citu protokolu, tad pārrakstiet to, lÄ«dz pilnÄ«bā aizverat visu.

Mēs dažkārt tīŔām neveicam pilnÄ«gu testÄ“Å”anu, jo nevēlamies apturēt attÄ«stÄ«bu, lai gan mums ir arÄ« viena lieta pēc otras. Ainava ir ļoti liela, sarežģīta, ir daudz sistēmu. Dažreiz tas ir tikai nepilnÄ«bas ā€” jā, jÅ«s samazināt droŔības rezervi, parādās vairāk risku. Bet tajā paŔā laikā jÅ«s atbrÄ«vojat piegādi.

Aleksandrs:

Jā, automātiskās pārbaudes un vienÄ«bu testi ļauj izveidot augstas kvalitātes pakalpojumu. Mēs esam par cauruļvadu, kuru nevar izturēt bez vienÄ«bas un integrācijas testiem. Mums bieži ir jāievelk emulatori un komerciālās sistēmas testa zonās un izstrādes vidēs, jo ne visas sistēmas var ievietot testa zonās. Turklāt tie ne tikai kļūst slapji ā€“ mēs Ä£enerējam pilnvērtÄ«gu sistēmas atbildi. Å Ä« ir nopietna daļa darbā ar mikropakalpojumiem, un mēs tajā arÄ« investējam. Bez tā iestāsies haoss.

Klausītāju jautājums (3):

Cik es saprotu, sākotnēji mikropakalpojumi izauga no atseviŔķas komandas un tagad pastāv Å”ajā modelÄ«. Kādi ir tā plusi un mÄ«nusi?

Mums nupat ir lÄ«dzÄ«gs stāsts: radās sava veida mikropakalpojumu rÅ«pnÄ«ca. Tagad mēs konceptuāli esam nonākuÅ”i pie tā, ka Å”o pieeju paplaÅ”inām uz ražoÅ”anu pa plÅ«smām un sistēmām. Citiem vārdiem sakot, mēs attālināmies no centralizētas mikropakalpojumu, mikropakalpojumu modeļu attÄ«stÄ«bas un kļūstam tuvāk sistēmām.

AttiecÄ«gi arÄ« mÅ«su darbÄ«ba aiziet uz sistēmām, proti, decentralizējam Å”o tēmu. Kāda ir jÅ«su pieeja un kāds ir jÅ«su mērÄ·a stāsts?

Aleksandrs:

JÅ«s izmetāt nosaukumu ā€œmikropakalpojumu rÅ«pnÄ«caā€ ā€” mēs arÄ« vēlamies palielināt mērogu. Pirmkārt, mums tagad tieŔām ir viena komanda. Mēs vēlamies nodroÅ”ināt visām MegaFon izstrādes komandām iespēju strādāt kopÄ«gā ekosistēmā. Mēs nevēlamies pilnÄ«bā pārņemt visu attÄ«stÄ«bas funkcionalitāti, kas mums ir tagad. Vietējais uzdevums ir mērogot, globālais uzdevums ir vadÄ«t attÄ«stÄ«bu visām komandām mikropakalpojumu slānÄ«.

Sergejs:

Es jums pastāstÄ«Å”u ceļu, kuru esam gājuÅ”i. Mēs tieŔām sākām strādāt kā viena komanda, bet tagad mēs neesam vieni. Es esmu Ŕāda: procesa Ä«paÅ”niekam ir jābÅ«t. Kādam ir jāsaprot, jāpārvalda, jākontrolē un jāveido mikropakalpojumu izstrādes process. Viņam ir jāpieder resursi un jāiesaistās resursu pārvaldÄ«bā.

Å ie resursi, kuri pārzina tehnoloÄ£ijas, specifiku un saprot, kā veidot mikropakalpojumus, var atrasties produktu komandās. Mums ir kombinācija, kurā cilvēki no mikropakalpojumu platformas ir produktu komandā, kas veido mobilo lietojumprogrammu. Viņi tur ir, bet strādā saskaņā ar mikropakalpojumu platformas pārvaldÄ«bas nodaļas procesu ar savu attÄ«stÄ«bas vadÄ«tāju. Å ajā nodaļā ir atseviŔķa komanda, kas nodarbojas ar tehnoloÄ£ijām. Tas ir, mēs savā starpā sajaucam kopÄ«gu resursu kopumu un sadalām tos, pieŔķirot komandām.

Tajā paŔā laikā process paliek vispārÄ«gs, kontrolēts, tas notiek pēc vispārējiem tehnoloÄ£iskiem principiem, ar vienÄ«bu testÄ“Å”anu un tā tālāk - viss, kas tiek bÅ«vēts virsÅ«. Var bÅ«t kolonnas resursu veidā, kas savākti no dažādiem produkta pieejas departamentiem.

Aleksandrs:

Sergej, jūs patiesībā esat procesa īpaŔnieks, vai ne? Vai tiek koplietots uzdevumu uzkrājums? KurŔ ir atbildīgs par tā izplatīŔanu?

Sergejs:

Paskaties: Å”eit atkal ir sajaukums. Ir atpalicÄ«ba, kas veidojas, balstoties uz tehnoloÄ£iskiem uzlabojumiem ā€“ tas ir viens stāsts. Ir uzkrājums, kas tiek formulēts no projektiem, un ir atlikums no produktiem. Bet katra pakalpojuma produkta ievieÅ”anas vai Ŕī pakalpojuma izveides secÄ«bu izstrādā produktu speciālists. ViņŔ neatrodas IT direkcijā, viņŔ tika speciāli no tā izņemts. Bet mani cilvēki noteikti strādā pēc tāda paÅ”a procesa.

Dažādos virzienos - izmaiņu uzkrājumu - Ä«paÅ”nieks bÅ«s dažādi cilvēki. TehnoloÄ£isko pakalpojumu sasaiste, to organizÄ“Å”anas princips ā€“ tas viss bÅ«s IT. Man pieder arÄ« platforma un resursi. AugÅ”pusē ir tas, kas attiecas uz atpalicÄ«bu un funkcionālajām izmaiņām, un arhitektÅ«ru Å”ajā ziņā.

Pieņemsim, ka uzņēmums saka: ā€œMēs vēlamies Å”o funkciju, mēs vēlamies izveidot jaunu produktu ā€” pārtaisÄ«t aizdevumu.ā€ Mēs atbildam: "Jā, mēs to atkārtosim." Arhitekti saka: "Padomāsim: kur aizdevumā rakstÄ«sim mikropakalpojumus un kā to darÄ«sim?" Pēc tam mēs to sadalām projektos, produktos vai tehnoloÄ£iju komplektā, ievietojam komandās un ievieÅ”am. Vai esat izveidojis produktu iekŔēji un nolēmis Å”ajā produktā izmantot mikropakalpojumus? Mēs sakām: "Tagad mantotajām sistēmām, kas mums bija, vai priekŔējās lÄ«nijas sistēmām ir jāpārslēdzas uz Å”iem mikropakalpojumiem." Arhitekti saka: ā€œTātad: tehnoloÄ£iskajā atpalicÄ«bā priekŔējās lÄ«nijas produktos - pāreja uz mikropakalpojumiem. Iet". Un produktu speciālisti vai uzņēmumu Ä«paÅ”nieki saprot, cik liela jauda ir atvēlēta, kad tas tiks darÄ«ts un kāpēc.

Diskusijas beigas, bet ne visas

Tika organizēta konference mailto:CLOUD Mail.ru mākoņa risinājumi.

Veicam arī citus pasākumus - piem. @Kubernetes Meetup, kur mēs vienmēr meklējam lieliskus runātājus:

  • Sekojiet @Kubernetes un citiem @Meetup jaunumiem mÅ«su Telegram kanālā t.me/k8s_mail
  • Vai vēlaties runāt kādā no @Meetups? Atstājiet pieprasÄ«jumu par mcs.mail.ru/speak

Avots: www.habr.com

Pievieno komentāru