25. aprila smo v skupini Mail.ru imeli konferenco o oblakih in okoli - . Nekaj poudarkov:
- Glavni — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center in Yandex.Cloud so spregovorili o posebnostih našega trga v oblaku in njihovih storitvah;
- Kolegi iz Bitrix24 so povedali, kako so ;
- Za zanimivost so poskrbeli Leroy Merlin, Otkritie, Burger King in Schneider Electric — kakšne naloge IT postavlja njihovo podjetje in katere tehnologije, vključno s tistimi v oblaku, se jim zdijo najbolj obetavne.
Ogledate si lahko vse videe s konference mailto:CLOUD , tukaj pa si lahko preberete, kako je potekala razprava o mikrostoritvah. Alexander Deulin, vodja centra za raziskave in razvoj poslovnih sistemov MegaFon, in Sergey Sergeev, direktor informacijske tehnologije skupine M.Video-Eldorado, sta delila svoje uspešne primere, kako se znebiti monolitov. Razpravljali smo tudi o sorodnih vprašanjih IT strategije, procesov in celo kadrov.
Panelisti
- Sergej Sergejev, CIO skupine "M.Video-Eldorado";
- Aleksander Deulin, vodja centra za raziskave in razvoj poslovnih sistemov MegaFon;
- Moderator — Dmitrij Lazarenko, vodja smeri PaaS Mail.ru rešitve v oblaku.
Po nagovoru Aleksandra Deulina Pri razpravi se mu pridružita Sergey Sergeev iz M.Video-Eldorado in moderator razprave Dmitry Lazarenko, Mail.ru Cloud Solutions.
Spodaj smo za vas pripravili transkript razprave, lahko pa si ogledate tudi video:
Prehod na mikrostoritve je odgovor na potrebe trga
Dmitrij:
Ali ste imeli kakšno uspešno izkušnjo s prehodom na mikrostoritve? In na splošno: kje vidite največjo poslovno korist od uporabe mikrostoritev oziroma prehoda z monolitov na mikrostoritve?
Sergej:
Pri prehodu na mikrostoritve smo že nekaj naredili in ta pristop uporabljamo že več kot tri leta. Prva potreba, ki je upravičila potrebo po mikrostoritvah, je bila neskončna integracija različnih front-end produktov z zaledno pisarno. In vsakič, ko smo bili prisiljeni v dodatno integracijo in razvoj, implementacijo lastnih pravil za delovanje te ali one storitve.
Na neki točki smo ugotovili, da moramo pospešiti delovanje naših sistemov in izhod funkcionalnosti. V tistem trenutku so na trgu že obstajali koncepti, kot so mikrostoritve in mikrostoritveni pristop, in odločili smo se, da ga preizkusimo. To se je začelo leta 2016. Nato je bila postavljena platforma in prvih 10 storitev je izvajala posebna ekipa.
Ena prvih storitev, ki je bila najbolj obremenjena, je bila storitev izračuna cen. Vsakič, ko pridete na kateri koli kanal, v skupino podjetij M.Video-Eldorado, naj bo to spletno mesto ali maloprodajna trgovina, tam izberete izdelek, vidite ceno na spletnem mestu ali v »Košarici«, se stroški samodejno izračunana z eno službo. Zakaj je to potrebno: pred tem je imel vsak sistem svoja načela za delo s promocijami - s popusti in tako naprej. Naša zaledna pisarna skrbi za določanje cen, funkcija popustov je implementirana v drug sistem. To je bilo treba centralizirati in ustvariti edinstveno, ločljivo storitev v obliki poslovnega procesa, ki bi nam to omogočil implementacijo. Približno tako smo začeli.
Vrednost prvih rezultatov je bila zelo velika. Prvič, lahko smo ustvarili ločljive entitete, ki nam omogočajo ločeno in združeno delo. Drugič, znižali smo stroške lastništva v smislu integracije z več sistemi.
V zadnjih treh letih smo dodali tri frontline sisteme. Težko jih je bilo vzdrževati z enako količino sredstev, ki si jih je podjetje lahko privoščilo. Zato se je pojavila naloga iskanja novih prodajnih mest, ki se odzivajo na trg po hitrosti, po notranjih stroških in učinkovitosti.
Kako izmeriti uspešnost prehoda na mikrostoritve
Dmitrij:
Kako se določi uspeh pri prehodu na mikrostoritve? Kaj je bilo »prej« v vsakem podjetju? S kakšno metriko ste ugotavljali uspešnost prehoda in kdo jo je pravzaprav določal?
Sergej:
Najprej se je rodil v IT kot omogočevalec - "odklepanje" novih zmogljivosti. Vse smo morali narediti hitreje za razmeroma enak denar in tako odgovoriti na izzive trga. Zdaj se uspeh izraža v številu storitev, ki jih ponovno uporabljajo različni sistemi, poenotenju procesov med seboj. Zdaj je, toda v tistem trenutku je bila to priložnost, da ustvarimo platformo in potrdimo hipotezo, da lahko to storimo, bo dalo učinek in izračunalo poslovni primer.
Aleksander:
Uspeh je bolj notranji občutek. Posel vedno želi več in globina našega zaostanka je dokaz uspeha. Tako se mi zdi.
Sergej:
Ja se strinjam. V treh letih imamo že več kot dvesto storitev in zaostankov. Potreba po virih znotraj ekipe samo narašča – za 30 % letno. To se dogaja, ker so ljudje čutili: hitreje je, drugače je, obstajajo različne tehnologije, vse to se razvija.
Mikrostoritve bodo prišle, a jedro bo ostalo
Dmitrij:
Je kot neskončen proces, kjer vlagaš v razvoj. Je prehod na mikrostoritve za podjetja že končan ali ne?
Sergej:
Zelo enostavno je odgovoriti. Kaj menite: menjava telefonov je neskončen proces? Tudi sami kupujemo telefone vsako leto. In tukaj je: dokler bo potrebna hitrost, prilagajanje trgu, bodo potrebne nekatere spremembe. To ne pomeni, da opuščamo standardne stvari.
Ne moremo pa pokriti in predelati vsega naenkrat. Imamo podedovane, standardne integracijske storitve, ki so obstajale prej: poslovna vodila in tako naprej. Vendar so zaostanki in obstaja tudi potreba. Število mobilnih aplikacij in njihove funkcionalnosti narašča. Hkrati nihče ne pravi, da vam bodo dali 30% več denarja. Se pravi, na eni strani so vedno potrebe, na drugi pa iskanje učinkovitosti.
Dmitrij:
Življenje je v dobri formi. (smeh)
Aleksander:
Na splošno ja. Nimamo revolucionarnih pristopov k odstranitvi jedra iz pokrajine. Poteka sistematično delo za razgradnjo sistemov, tako da so bolj skladni z arhitekturo mikrostoritev, da se zmanjša vpliv sistemov drug na drugega.
Vendar nameravamo obdržati osrednji del, saj bo v krajini operaterja vedno nekaj platform, ki jih kupujemo. Ponovno potrebujemo zdravo ravnovesje: ne smemo hiteti z izrezovanjem jedra. Sisteme postavimo enega poleg drugega in zdaj se je izkazalo, da smo že na vrhu mnogih ključnih delov. Nadalje z razvojem funkcionalnosti ustvarjamo potrebne predstavitve za vse kanale, ki delujejo z našimi komunikacijskimi storitvami.
Kako podjetjem prodati mikrostoritve
Dmitrij:
Zanima me tudi - za tiste, ki še niste prestopili, pa nameravate: kako enostavno je bilo to idejo prodati poslu in je bila to avantura, investicijski projekt? Ali pa je bila to zavestna strategija: zdaj gremo na mikrostoritve in to je to, nič nas ne bo ustavilo. Kako je bilo tebi?
Sergej:
Nismo prodajali pristopa, ampak poslovno korist. Prišlo je do težave v poslu in poskušali smo jo rešiti. Takrat se je izrazilo v tem, da so različni kanali uporabljali različna načela za izračun cen - ločeno za promocije, za promocije itd. Bilo je težko vzdrževati, pojavljale so se napake, prisluhnili smo pritožbam strank. Se pravi, prodajali smo rešitev problema, vendar smo prišli z dejstvom, da potrebujemo denar za ustvarjanje platforme. In na primeru prve faze investicije so prikazali poslovni primer: kako jo bomo naprej povrnili in kaj nam bo to omogočilo.
Dmitrij:
Ste nekako zabeležili čas prve etape?
Sergej:
Ja seveda. Za izdelavo jedra kot platforme in testiranje pilota smo namenili 6 mesecev. V tem času smo poskušali ustvariti platformo, na kateri bi drsal pilot. Potem je bila hipoteza potrjena in ker deluje, pomeni, da lahko nadaljujemo. Začeli so razmnoževati in krepiti ekipo – preselili so jo v ločeno divizijo, ki počne prav to.
Sledi sistematično delo, ki temelji na poslovnih potrebah, priložnostih, razpoložljivosti virov in vsem, kar je trenutno v delu.
Dmitrij:
V REDU. Aleksander, kaj praviš?
Aleksander:
Naše mikrostoritve so se rodile iz "morske pene" - zaradi varčevanja z viri, zaradi nekaj ostankov v obliki strežniških zmogljivosti in prerazporeditve sil znotraj ekipe. Na začetku tega projekta nismo prodali podjetjem. To je bil projekt, kjer sva oba raziskovala in se ustrezno razvijala. Začeli smo v začetku leta 2018 in to smer preprosto z zanosom razvijali. Prodaja se je šele začela in smo v procesu.
Dmitrij:
Se zgodi, da vam podjetje omogoči, da delate takšne stvari kot Google - en prost dan v tednu? Imate takšno usmeritev?
Aleksander:
Hkrati z raziskovanjem smo se ukvarjali tudi s poslovnimi problemi, zato so vse naše mikrostoritve rešitve poslovnih problemov. Samo na začetku smo gradili mikrostoritve, ki so pokrivale majhen del baze naročnikov, zdaj pa smo prisotni v skoraj vseh vodilnih izdelkih.
In materialni vpliv je že jasen – že nas je mogoče prešteti, oceniti hitrost lansiranja izdelkov in izgubljeni prihodek, če bi šli po stari poti. Na tem gradimo primer.
Mikrostoritve: hype ali nujnost?
Dmitrij:
Številke so številke. In prihodki ali prihranjeni denar so zelo pomembni. Kaj pa če pogledaš z druge strani? Zdi se, da so mikrostoritve trend, hype in mnoga podjetja to zlorabljajo? Kako jasno razlikujete med tem, kar počnete, in tem, kar ne prevajate v mikrostoritve? Če ste zapuščina zdaj, ali boste imeli zapuščino čez 5 let? Kakšna bo starost informacijskih sistemov, ki delujejo v M.Video-Eldorado in MegaFon čez 5 let? Bodo deset let, petnajst let stari informacijski sistemi ali bo to nova generacija? Kako ti vidiš to?
Sergej:
Zdi se mi, da je težko razmišljati zelo daleč. Če pogledamo nazaj, kdo si je predstavljal, da se bo tehnološki trg razvijal tako, vključno s strojnim učenjem in identifikacijo uporabnikov po obrazu? Toda če pogledate prihodnja leta, se mi zdi, da osrednji sistemi, podjetniški sistemi razreda ERP v podjetjih - delujejo že precej dolgo.
Naša podjetja so skupaj stara 25 let, s klasičnim ERP zelo globoko v sistemski krajini. Jasno je, da nekaj kosov vzamemo od tam in jih poskušamo združiti v mikrostoritve, vendar bo jedro ostalo. Zdaj si težko predstavljam, da bomo tam zamenjali vse jedrne sisteme in hitro prešli na drugo, svetlo stran novih sistemov.
Sem zagovornik tega, da je vse, kar je bližje naročniku in potrošniku, največja poslovna korist in vrednost, kjer je prilagodljivost in osredotočenost na hitrost, na spremembe, na “poskusi, prekliči, ponovno uporabi, naredi nekaj drugega”. potrebno «—tukaj se bo pokrajina spremenila. In izdelki v škatli ne sodijo prav dobro tja. Vsaj mi tega ne vidimo. Tam so potrebne najlažje, najenostavnejše rešitve.
Vidimo ta razvoj:
- temeljni informacijski sistemi (večinoma zaledni uradi);
- srednji sloji v obliki mikrostoritev povezujejo jedro, združujejo, ustvarjajo predpomnilnik ipd.;
- front-line sistemi so namenjeni potrošniku;
- integracijska plast, ki je na splošno integrirana v trge, druge sisteme in ekosisteme. Ta plast je čim lažja, preprosta in vsebuje minimalno poslovno logiko.
A hkrati sem zagovornik tega, da se stara načela še naprej uporabljajo, če so pravilno uporabljena.
Recimo, da imate klasičen podjetniški sistem. Nahaja se v pokrajini enega prodajalca in je sestavljen iz dveh modulov, ki delujeta drug z drugim. Obstaja tudi standardni integracijski vmesnik. Zakaj bi to ponovili in tja pripeljali mikroservis?
Ko pa je v zaledni pisarni 5 modulov, iz katerih se informacije zbirajo v poslovni proces, ki ga nato uporablja 8-10 front-line sistemov, je korist takoj opazna. Iz petih zalednih sistemov ustvarite storitev, izolirano, ki je osredotočena na poslovni proces. Naredite storitev tehnološko napredno – tako da predpomni podatke in je tolerantna na napake ter deluje tudi z dokumenti ali poslovnimi subjekti. In integrirate ga po enotnem principu z vsemi izdelki prve linije. Preklicali so izdelek front-line - preprosto so izklopili integracijo. Jutri morate napisati mobilno aplikacijo ali narediti majhno spletno stran in samo en del spraviti v funkcionalnost - vse je preprosto: sestavili ste ga kot konstruktor. Vidim več razvoja v tej smeri – vsaj pri nas.
Aleksander:
Sergej je v celoti opisal naš pristop, hvala. Povedal bom le, kam zagotovo ne bomo šli - v bistvo, na temo spletnega obračunavanja. To pomeni, da bo ocena in zaračunavanje dejansko ostala "velika" mlatilnica, ki bo zanesljivo odpisala denar. In ta sistem bodo še naprej certificirali naši regulativni organi. Vse ostalo, kar gleda na stranke, so seveda mikrostoritve.
Dmitrij:
Tukaj je certificiranje ena zgodba. Verjetno več podpore. Če porabite malo za podporo ali sistem ne potrebuje podpore in sprememb, je bolje, da se ga ne dotikate. Razumen kompromis.
Kako razviti zanesljive mikrostoritve
Dmitrij:
Globa. Ampak vseeno me zanima. Zdaj pripovedujete zgodbo o uspehu: vse je bilo v redu, prešli smo na mikrostoritve, zagovarjali idejo pri podjetju in vse se je izšlo. Slišal pa sem še druge zgodbe.
Pred nekaj leti je švicarsko podjetje, ki je dve leti vlagalo v razvoj nove mikrostoritvene platforme za banke, na koncu zaprlo projekt. Popolnoma propadel. Porabljenih je bilo veliko milijonov švicarskih frankov, a na koncu je bila ekipa razpršena - ni se izšlo.
Ste imeli podobne zgodbe? So bile ali so kakšne težave? Na primer, vzdrževanje mikrostoritev in spremljanje je tudi glavobol v operativnih dejavnostih podjetja. Navsezadnje se število komponent poveča več desetkrat. Kako gledate na to, ali so bili pri nas neuspešni primeri naložb? In kaj lahko svetujete ljudem, da ne bodo naleteli na takšne težave?
Aleksander:
Neuspešni primeri so vključevali podjetja, ki so spreminjala prednostne naloge in odpovedovala projekte. Ko je podjetje na dobri stopnji pripravljenosti (pravzaprav je MVP pripravljen), je podjetje reklo: "Imamo nove prednostne naloge, prehajamo na drug projekt in tega zapiramo."
Pri mikrostoritvah nismo imeli globalnih napak. Mirno spimo, imamo 24/7 dežurno izmeno, ki servisira celoten BSS [sistem za podporo poslovanju].
In še nekaj - mikrostoritve oddajamo po pravilih, ki veljajo za škatlaste produkte. Ključ do uspeha je, da morate najprej zbrati ekipo, ki bo v celoti pripravila mikrostoritev za produkcijo. Sama razvitost je pogojno 40-odstotna. Ostalo je analitika, metodologija DevSecOps, prave integracije in prava arhitektura. Posebno pozornost namenjamo načelom gradnje varnih aplikacij. Predstavniki informacijske varnosti sodelujejo pri vsakem projektu tako v fazi načrtovanja arhitekture kot v procesu izvedbe. Upravljajo tudi sisteme za analizo kode za ranljivosti.
Recimo, da uvedemo naše storitve brez stanja – imamo jih v Kubernetesu. To vsem omogoča miren spanec zaradi samodejnega skaliranja in samodejnega dvigovanja storitev, dežurna izmena pa pobira incidente.
V celotnem obstoju naših mikrostoritev sta bila le en ali dva incidenta, ki sta dosegla našo linijo. Zdaj ni nobenih težav z delovanjem. Seveda nimamo 200, ampak približno 50 mikrostoritev, vendar se uporabljajo v vodilnih izdelkih. Če jim ne bi uspelo, bi bili mi prvi, ki bi izvedeli za to.
Mikrostoritve in HR
Sergej:
Glede premestitve v podporo se strinjam s kolegom - da je treba delo pravilno organizirati. Povedal pa vam bom o težavah, ki seveda obstajajo.
Prvič, tehnologija je nova. To je v dobrem smislu hype in najti strokovnjaka, ki bo to razumel in lahko ustvaril, je velik izziv. Tekmovanje za vire je noro, zato so strokovnjaki zlata vredni.
Drugič, z ustvarjanjem določenih pokrajin in naraščajočim številom storitev je treba nenehno reševati problem ponovne uporabe. Kot radi počnejo razvijalci: "Napišimo zdaj tukaj veliko zanimivih stvari ..." Zaradi tega sistem raste in izgublja svojo učinkovitost v smislu denarja, stroškov lastništva itd. To pomeni, da je treba ponovno uporabo vključiti v sistemsko arhitekturo, jo vključiti v načrt uvajanja storitev in prenos dediščine v novo arhitekturo.
Druga težava – čeprav je to po svoje dobro – je notranja konkurenca. "Oh, tukaj so se pojavili novi modni fantje, govorijo nov jezik." Ljudje smo seveda različni. Obstajajo tisti, ki so navajeni pisanja v Javi, in tisti, ki pišejo in uporabljajo Docker in Kubernetes. To so popolnoma različni ljudje, različno govorijo, uporabljajo različne izraze in se včasih ne razumejo. Sposobnost ali nezmožnost deljenja prakse, deljenja znanja v tem smislu je tudi problem.
No, povečanje virov. »Super, gremo! In zdaj želimo hitreje, več. Kaj, ne moreš? Ali ni mogoče v enem letu dostaviti dvakrat več? In zakaj?" Takšne rastne bolečine so verjetno standardne za marsikaj, marsikateri pristop in čutiš jih.
Glede spremljanja. Zdi se mi, da se storitve ali industrijska orodja za spremljanje že učijo ali so sposobna delati z Dockerjem in Kubernetesom v drugačnem, nestandardnem načinu. Da na primer ne boste imeli 500 Java strojev, pod katerimi vse to teče, se namreč agregira. Toda tem izdelkom še manjka zrelosti, skozi to morajo iti. Tema je res nova, razvijala se bo še naprej.
Dmitrij:
Ja, zelo zanimivo. In to velja za HR. Morda sta se vaš kadrovski proces in kadrovska blagovna znamka v teh 3 letih nekoliko spremenila. Začeli ste zaposlovati druge ljudi z različnimi kompetencami. In verjetno obstajajo tako prednosti kot slabosti. Prej sta bila blockchain in podatkovna znanost priljubljena, strokovnjaki zanju pa so bili vredni milijone. Zdaj stroški padajo, trg postaja zasičen, podoben trend je tudi pri mikrostoritvah.
Sergej:
Da, absolutno.
Aleksander:
HR postavlja vprašanje: "Kje je vaš roza samorog med zadnjim in sprednjim delom?" HR ne razume, kaj je mikrostoritev. Povedali smo jim skrivnost in povedali, da je zaledje naredilo vse in ni samoroga. Toda HR se spreminja, hitro se uči in zaposluje ljudi z osnovnim IT znanjem.
Razvoj mikrostoritev
Dmitrij:
Če pogledate ciljno arhitekturo, so mikrostoritve videti kot taka pošast. Vaša pot je trajala več let. Drugi imajo eno leto, tretji tri leta. Ste predvideli vse težave, ciljno arhitekturo, se je kaj spremenilo? Na primer, v primeru mikrostoritev se zdaj znova pojavljajo prehodi in storitvena omrežja. Ste jih uporabljali na začetku ali ste spremenili samo arhitekturo? Imate takšne izzive?
Sergej:
Prepisali smo že več komunikacijskih protokolov. Najprej je bil en protokol, zdaj smo prešli na drugega. Povečujemo varnost in zanesljivost. Začeli smo s podjetniškimi tehnologijami - Oracle, Web Logic. Zdaj se odmikamo od tehnoloških podjetniških produktov v mikrostoritvah in prehajamo na odprtokodne oziroma popolnoma odprte tehnologije. Opustimo baze podatkov in se premaknemo k temu, kar v tem modelu za nas deluje bolj učinkovito. Tehnologije Oracle ne potrebujemo več.
Začeli smo preprosto kot storitev, ne da bi razmišljali o tem, koliko potrebujemo predpomnilnik, kaj bi počeli, ko ne bi bilo povezave z mikrostoritvijo, pa bi bili potrebni podatki itd. Zdaj razvijamo platformo, da bi lahko opisali arhitekturo ne v jeziku storitev, ampak v poslovnem jeziku, dvignite poslovno logiko na višjo raven, ko začnemo govoriti z besedami. Zdaj smo se naučili govoriti s črkami, naslednja stopnja pa je, ko bodo storitve zbrane v nekakšen agregat, ko je to že beseda - na primer celotna kartica izdelka. Sestavljen je iz mikrostoritev, vendar je API zgrajen na tem.
Varnost je zelo pomembna. Takoj, ko začneš biti dostopen in imaš storitev, prek katere lahko dobiš marsikaj zanimivega, in to zelo hitro, v delčku sekunde, se pojavi želja, da bi to dobil na ne najbolj varen način. Da bi se temu izognili, smo morali spremeniti pristope k testiranju in spremljanju. Spremeniti smo morali ekipo, strukturo upravljanja dostave, CI/CD.
To je evolucija – tako kot pri telefonih, le da veliko hitreje: najprej so bili telefoni na tipke, nato so se pojavili pametni telefoni. Izdelek so preoblikovali in preoblikovali, ker je imel trg drugačne potrebe. Tako se razvijamo: prvi razred, deseti razred, delo.
Iterativno se na leto nekaj postavi z vidika tehnologije, nekaj drugega z vidika zaostankov in potreb. Povezujemo eno stvar z drugo. Ekipa porabi 20 % za tehnični dolg in tehnično podporo za ekipo, 80 % za poslovni subjekt. In premikamo se z razumevanjem, zakaj to počnemo, zakaj delamo te tehnološke izboljšave, do česa bodo pripeljale. Kot to.
Dmitrij:
Kul. Kaj je v Megafonu?
Aleksander:
Glavni izziv, ko smo prišli do mikrostoritev, je bil, da ne zapademo v kaos. Arhitekturni biro MegaFon se nam je takoj pridružil, postal celo pobudnik in gonilnik - zdaj imamo zelo močno arhitekturo. Njegova naloga je bila razumeti, h kateremu ciljnemu modelu gremo in katere tehnologije je treba preizkusiti. Z arhitekturo smo te pilote izvedli sami.
Naslednje vprašanje je bilo: "Kako potem vse to izkoristiti?" In še: “Kako zagotoviti transparentno interakcijo med mikrostoritvami?” Na zadnje vprašanje nam je pomagal odgovoriti servisni mesh. Pilotirali smo Istio in rezultati so nam bili všeč. Zdaj smo v fazi uvajanja v proizvodne cone. Imamo pozitiven odnos do vseh izzivov – tega, da je treba nenehno spreminjati sklad, se učiti česa novega. Zanima nas razvoj, ne izkoriščanje starih rešitev.
Dmitrij:
Zlate besede! Takšni izzivi držijo ekipo in posel na trnih ter ustvarjajo prihodnost. GDPR je ustanovil glavne uradnike za varstvo podatkov, trenutni izzivi pa ustvarjajo glavne uradnike za mikrostoritve in arhitekturo. In ugaja.
Veliko sva razpravljala. Glavna stvar je, da vam dobra zasnova mikrostoritev in same arhitekture omogoča, da se izognete številnim napakam. Seveda je proces iterativen in evolucijski, vendar je prihodnost.
Hvala vsem udeležencem, hvala Sergeju in Aleksandru!
Vprašanja iz publike
Vprašanje iz publike (1):
Sergej, kako se je spremenilo vodenje IT v vašem podjetju? Razumem, da je upravljanje z njim precej jasen in logičen postopek, ko obstaja velik sklad več sistemov. Kako ste obnovili upravljanje IT komponente, potem ko je bilo v tako kratkem času integrirano zelo veliko mikrostoritev?
Sergej:
Strinjam se s kolegom, da je arhitektura zelo pomembna kot gonilo sprememb. Začeli smo z arhitekturnim oddelkom. Arhitekti so hkrati lastniki razporeditve funkcionalnosti in zahtev, kako se bo prikazala v krajini. Torej delujejo tudi kot koordinatorji teh sprememb. Posledično je prišlo do posebnih sprememb v določenem procesu dostave, ko smo ustvarili platformo CI/CD.
Toda standard, osnovna načela razvoja, poslovne analize, testiranja in razvoja niso bila preklicana. Samo dodali smo hitrost. Prej je cikel trajal toliko, namestitev v testnih okoljih je trajala veliko več. Zdaj podjetja vidijo korist in pravijo: "Zakaj ne bi mogli storiti enako drugje?"
To je v dobrem smislu kot injekcija v obliki cepiva, ki je pokazala: lahko tako, lahko pa drugače. Seveda je problem v kadrih, v kompetencah, v znanju, v odporu.
Vprašanje iz publike (2):
Kritiki arhitekture mikrostoritev pravijo, da sta testiranje in razvoj težavna. To je logično, kjer se stvari zapletejo. S kakšnimi izzivi se je soočila vaša ekipa in kako ste jih premagali? Vprašanje za vse.
Aleksander:
Pri prehodu z mikrostoritev na platformo se pojavljajo težave, ki pa so rešljive.
Na primer, izdelujemo produkt, ki je sestavljen iz 5-7 mikrostoritev. Zagotoviti moramo integracijske teste za celoten sklad mikrostoritev, da damo zeleno luč za prehod v glavno vejo. Ta naloga za nas ni bila nova: v BSS smo se s tem ukvarjali že dolgo, ko nam je prodajalec dobavil že poslane rešitve.
In naš problem je le v majhni ekipi. En QA inženir je potreben za en pogojni izdelek. In tako pošljemo izdelek 5-7 mikrostoritev, od katerih lahko 2-3 razvijejo tretje osebe. Na primer, imamo izdelek, pri razvoju katerega sodelujeta naš prodajalec plačilnega sistema, Mail.ru Group in MegaFon R&D. To moramo pokriti s testi, preden ga pošljemo v proizvodnjo. Inženir QA je na tem izdelku delal mesec in pol, ostala ekipa pa je ostala brez njegove podpore.
To zapletenost povzroča le skaliranje. Zavedamo se, da mikrostoritve ne morejo obstajati v vakuumu; absolutna izolacija ne obstaja. Pri zamenjavi ene storitve se vedno trudimo ohraniti pogodbo API. Če se kaj spremeni pod pokrovom, sprednji servis ostane. Če so spremembe usodne, pride do nekakšne arhitekturne preobrazbe in preidemo na popolnoma drug podatkovni metamodel, ki je popolnoma nekompatibilen – šele takrat govorimo o pojavu specifikacije API storitve v2. Podpiramo prvo in drugo različico hkrati in ko vsi potrošniki preidejo na drugo različico, prvo enostavno zapremo.
Sergej:
Želim dodati. Glede zapletov se popolnoma strinjam - zgodijo se. Pokrajina postaja vse bolj zapletena, režijski stroški pa naraščajo, zlasti za testiranje. Kako ravnati s tem: preklopite na avtomatizirano testiranje. Da, morali boste dodatno investirati v pisanje samodejnih testov in testov enot. Da se razvijalci ne bi mogli zavezati, ne da bi opravili preizkus, niso mogli spremeniti kode. Tako, da tudi tipka ne deluje brez autotest, unit test.
Pomembno je ohraniti prejšnjo funkcionalnost, to pa je dodaten strošek. Če tehnologijo prepišete v drug protokol, jo prepišete, dokler vsega popolnoma ne zaprete.
Včasih namenoma ne izvajamo testiranja od konca do konca, ker ne želimo ustaviti razvoja, čeprav imamo tudi eno stvar za drugo. Pokrajina je zelo velika, kompleksna, sistemov je veliko. Včasih so samo škrbine - ja, znižaš varnostno mejo, pojavi se več tveganj. Toda hkrati sprostite zalogo.
Aleksander:
Da, samodejni testi in testi enot vam omogočajo ustvarjanje visokokakovostne storitve. Smo za cevovod, ki ga ni mogoče prenesti brez enotnih in integracijskih testov. Emulatorje in komercialne sisteme moramo pogosto vleči v testna območja in razvojna okolja, saj vseh sistemov ni mogoče postaviti v testna območja. Poleg tega se ne samo zmočijo - ustvarimo popoln odziv sistema. To je resen del dela z mikrostoritvami in vanj tudi vlagamo. Brez tega bo nastal kaos.
Vprašanje iz publike (3):
Kolikor razumem, so mikrostoritve sprva zrasle iz ločene ekipe in zdaj obstajajo v tem modelu. Kakšne so njegove prednosti in slabosti?
Imamo pač podobno zgodbo: nastala je nekakšna tovarna mikrostoritev. Sedaj smo konceptualno prišli do točke, da ta pristop širimo na proizvodnjo po tokovih in po sistemih. Z drugimi besedami, odmikamo se od centraliziranega razvoja mikrostoritev, mikrostoritvenih modelov in se približujemo sistemom.
Temu primerno gre naše delovanje tudi v sisteme, torej to temo decentraliziramo. Kakšen je vaš pristop in kakšna je vaša ciljna zgodba?
Aleksander:
Kar iz ust ste izpustili ime »tovarna mikrostoritev« – tudi mi se želimo povečati. Prvič, zdaj imamo res eno ekipo. Vsem razvojnim ekipam, ki jih ima MegaFon, želimo omogočiti delo v skupnem ekosistemu. Ne želimo popolnoma prevzeti vseh razvojnih funkcij, ki jih imamo zdaj. Lokalna naloga je skalirati, globalna naloga pa je voditi razvoj do vseh ekip v plasti mikrostoritve.
Sergej:
Povedal vam bom pot, ki smo jo prehodili. Začeli smo res delovati kot ena ekipa, zdaj pa nismo sami. Sem zagovornik naslednjega: mora biti lastnik procesa. Nekdo mora razumeti, upravljati, nadzorovati in graditi proces razvoja mikrostoritev. Imeti mora lastna sredstva in se ukvarjati z upravljanjem z njimi.
Ti viri, ki poznajo tehnologije, posebnosti in razumejo, kako zgraditi mikrostoritve, se lahko nahajajo v produktnih skupinah. Imamo mešanico, v kateri so ljudje s platforme mikrostoritev v produktni skupini, ki izdeluje mobilno aplikacijo. So tam, vendar delajo po procesu oddelka za upravljanje platforme mikrostoritev s svojim vodjo razvoja. Znotraj te divizije obstaja posebna ekipa, ki se ukvarja s tehnologijo. To pomeni, da med seboj zmešamo skupen nabor virov in jih razdelimo ter damo ekipam.
Hkrati pa proces ostaja splošen, nadzorovan, poteka po splošnih tehnoloških principih, s testiranjem enot in tako naprej - vse, kar je nadgrajeno. Obstajajo lahko stolpci v obliki virov, zbranih iz različnih oddelkov produktnega pristopa.
Aleksander:
Sergey, ti si dejansko lastnik procesa, kajne? Ali so zaostanki opravil deljeni? Kdo je odgovoren za njegovo distribucijo?
Sergej:
Poglejte: tukaj je spet mešanica. Obstaja zaostanek, ki nastaja na podlagi tehnoloških izboljšav – to je ena zgodba. Obstajajo zaostanki, ki so oblikovani iz projektov, in obstajajo zaostanki iz izdelkov. Toda zaporedje uvedbe v vsak storitveni izdelek ali ustvarjanje te storitve razvije strokovnjak za izdelke. Ni ga na direktoratu za informatiko, iz njega so ga posebej odstranili. Toda moji ljudje zagotovo delajo po istem postopku.
Lastnik zaostanka v različnih smereh - zaostanka sprememb - bodo različni ljudje. Povezava tehnoloških storitev, njihov organizacijski princip - vse to bo v IT. Sem lastnik platforme in tudi virov. Na vrhu je tisto, kar zadeva zaostanke in funkcionalne spremembe ter arhitekturo v tem smislu.
Recimo, da podjetje reče: "Želimo to funkcijo, želimo ustvariti nov izdelek - predelati posojilo." Odgovorimo: "Da, ponovili bomo." Arhitekti pravijo: "Pomislimo: kje v posojilu bomo zapisali mikrostoritve in kako bomo to naredili?" Nato ga razdelimo na projekte, izdelke ali tehnološki sklop, razdelimo v ekipe in implementiramo. Ali ste interno ustvarili izdelek in se odločili za uporabo mikrostoritev v tem izdelku? Pravimo: "Zdaj morajo podedovani sistemi, ki smo jih imeli, ali prvi sistemi, preklopiti na te mikrostoritve." Arhitekti pravijo: »Torej: v tehnološkem zaostanku znotraj izdelkov prve linije - prehod na mikrostoritve. Pojdi". In strokovnjaki za izdelke ali lastniki podjetij razumejo, koliko zmogljivosti je dodeljenih, kdaj bo to opravljeno in zakaj.
Konec razprave, vendar ne vse
Organizirana je bila konferenca mailto:CLOUD .
Delamo tudi druge dogodke – npr. @Kubernetes srečanje, kjer vedno iščemo odlične govorce:
- Spremljajte @Kubernetes in druge novice @Meetup na našem kanalu Telegram
- Vas zanima govor na enem od srečanj @Meetups? Pustite zahtevo za
Vir: www.habr.com