La 25-an de aprilo, ni ĉe Mail.ru Group okazigis konferencon pri nuboj kaj ĉirkaŭ - . Kelkaj elstaraĵoj:
- La ĉefa — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center kaj Yandex.Cloud parolis pri la specifaĵoj de nia nuba merkato kaj iliaj servoj;
- Kolegoj de Bitrix24 rakontis kiel ili ;
- Leroy Merlin, Otkritie, Burger King kaj Schneider Electric provizis interesa — kiajn taskojn ilia komerco starigas por IT kaj kiajn teknologiojn, inkluzive de nuboj, ili vidas kiel la plej promesplenaj.
Vi povas spekti ĉiujn filmetojn de la konferenco mailto:CLOUD , kaj ĉi tie vi povas legi kiel la diskuto pri mikroservoj iris. Alexander Deulin, estro de la centro de esploro kaj disvolviĝo de komercaj sistemoj MegaFon, kaj Sergey Sergeev, direktoro pri informa teknologio de la grupo M.Video-Eldorado, konigis siajn sukcesajn kazojn pri forigo de monolitoj. Ni ankaŭ diskutis rilatajn aferojn de IT-strategio, procezoj kaj eĉ HR.
Panelistoj
- Sergej Sergeev, Grupo CIO "M.Video-Eldorado";
- Aleksandro Deulin, estro de la centro por esplorado kaj evoluo de komercaj sistemoj MegaFon;
- Moderiganto — Dmitrij Lazarenko, Estro de PaaS-direkto Mail.ru Cloud Solutions.
Post la parolado de Aleksandro Deulin al li aliĝas por diskuto Sergey Sergeev de M.Video-Eldorado kaj diskutmodoro Dmitry Lazarenko, Mail.ru Cloud Solutions.
Ĉi-sube ni pretigis transskribon de la diskuto por vi, sed vi ankaŭ povas spekti la videon:
La transiro al mikroservoj estas respondo al merkataj bezonoj
Dmitrij:
Ĉu vi havis sukcesan sperton migrante al mikroservoj? Kaj ĝenerale: kie vi vidas la plej grandan komercan profiton de uzado de mikroservoj aŭ moviĝado de monolitoj al mikroservoj?
Sergey:
Ni jam venis iun vojon en la transiro al mikroservoj kaj uzis ĉi tiun aliron dum pli ol tri jaroj. La unua bezono, kiu pravigis la bezonon de mikroservoj, estis la senfina integriĝo de diversaj antaŭfinaj produktoj kun la malantaŭa oficejo. Kaj ĉiufoje ni estis devigitaj fari plian integriĝon kaj disvolviĝon, efektivigante niajn proprajn regulojn por la funkciado de tiu aŭ alia servo.
En iu momento, ni rimarkis, ke ni bezonas akceli la funkciadon de niaj sistemoj kaj la eligo de funkcieco. En tiu momento, tiaj konceptoj kiel mikroservoj kaj mikroserva aliro jam ekzistis sur la merkato, kaj ni decidis provi ĝin. Ĉi tio komenciĝis en 2016. Tiam la platformo estis metita kaj la unuaj 10 servoj estis efektivigitaj fare de aparta teamo.
Unu el la unuaj servoj, la plej peze ŝarĝita, estis la prezkalkulservo. Ĉiufoje kiam vi venas al iu ajn kanalo, al la grupo de kompanioj M.Video-Eldorado, ĉu ĝi estas retejo aŭ podetala vendejo, elektu produkton tie, vidu la prezon en la retejo aŭ en la "Corbo", la kosto aŭtomate estas. kalkulita de unu servo. Kial ĉi tio necesas: antaŭ ĉi tio, ĉiu sistemo havis siajn proprajn principojn por labori kun promocioj - kun rabatoj kaj tiel plu. Nia oficejo pritraktas prezojn; rabata funkcio estas efektivigita en alia sistemo. Ĉi tio devis esti centralizita kaj unika, apartigebla servo kreita en formo de komerca procezo, kiu permesus al ni efektivigi ĉi tion. Preskaŭ tiel ni komencis.
La valoro de la unuaj rezultoj estis tre granda. Unue, ni povis krei disigeblajn entojn, kiuj ebligas al ni labori aparte kaj en agregado. Due, ni reduktis la koston de proprieto laŭ integriĝo kun pli da sistemoj.
Dum la lastaj tri jaroj, ni aldonis tri frontliniajn sistemojn. Estis malfacile konservi ilin per la sama kvanto de rimedoj, kiujn la firmao povis pagi. Tial ekestis la tasko serĉi novajn ellasejojn, respondante al la merkato laŭ rapideco, laŭ internaj kostoj kaj efikeco.
Kiel mezuri la sukceson de migrado al mikroservoj
Dmitrij:
Kiel estas determinita sukceso en migrado al mikroservoj? Kio estis la "antaŭe" en ĉiu kompanio? Kian metrikon vi uzis por determini la sukceson de la transiro, kaj kiu fakte determinis ĝin?
Sergey:
Antaŭ ĉio, ĝi naskiĝis ene de IT kiel ebliganto - "malŝlosi" novajn kapablojn. Ni devis fari ĉion pli rapide por relative la sama mono, respondante al merkataj defioj. Nun sukceso esprimas en la nombro da servoj reuzitaj de malsamaj sistemoj, unuiĝo de procezoj inter si. Nun ĝi estas, sed en tiu momento estis ŝanco krei platformon kaj konfirmi la hipotezon, ke ni povas fari ĉi tion, ĝi donos efikon kaj kalkulos la komercan kazon.
Aleksandro:
Sukceso estas prefere interna sento. Komerco ĉiam volas pli, kaj la profundo de nia restaro estas pruvo de sukceso. Tiel ŝajnas al mi.
Sergey:
Jes, mi konsentas. En tri jaroj, ni jam havas pli ol ducent servojn kaj restaron. La bezono de rimedoj ene de la teamo nur kreskas - je 30% ĉiujare. Ĉi tio okazas ĉar homoj sentis: ĝi estas pli rapida, ĝi estas malsama, estas malsamaj teknologioj, ĉio ĉi evoluas.
Mikroservoj venos, sed la kerno restos
Dmitrij:
Ĝi estas kiel senfina procezo, kie vi investas en disvolviĝo. Ĉu la transiro al mikroservoj por komerco jam finiĝis aŭ ne?
Sergey:
Estas tre facile respondi. Kion vi pensas: anstataŭigi telefonojn estas senfina procezo? Ni mem aĉetas telefonojn ĉiujare. Kaj jen: tiel longe kiel necesos rapideco, por adaptiĝo al la merkato, iuj ŝanĝoj estos postulataj. Ĉi tio ne signifas, ke ni forlasas normajn aferojn.
Sed ni ne povas kovri kaj refari ĉion samtempe. Ni havas heredaĵojn, normajn integrigajn servojn, kiuj ekzistis antaŭe: entreprenaj busoj ktp. Sed estas postresto, kaj ankaŭ necesas. La nombro da moveblaj aplikoj kaj ilia funkcieco kreskas. Samtempe, neniu diras, ke vi ricevos 30% pli da mono. Tio estas, ĉiam estas bezonoj unuflanke, kaj serĉado de efikeco aliflanke.
Dmitrij:
La vivo estas en bona formo. (Ridoj)
Aleksandro:
Ĝenerale, jes. Ni ne havas revoluciajn alirojn por forigi la kernan parton de la pejzaĝo. Sistema laboro estas survoje por malkomponi sistemojn tiel ke ili estas pli kongruaj kun mikroserva arkitekturo, por redukti la influon de sistemoj sur unu la alian.
Sed ni planas konservi la kernan parton, ĉar en la pejzaĝo de la funkciigisto ĉiam estos iuj platformoj, kiujn ni aĉetas. Denove, ni bezonas sanan ekvilibron: ni ne rapidu por eltranĉi la kernon. Ni metas la sistemojn unu apud la alia, kaj nun montriĝas, ke ni jam estas super multaj kernaj partoj. Plue, disvolvante la funkciecon, ni kreas la necesajn reprezentojn por ĉiuj kanaloj, kiuj funkcias kun niaj komunikadaj servoj.
Kiel vendi mikroservojn al entreprenoj
Dmitrij:
Mi ankaŭ interesiĝas - por tiuj, kiuj ne ŝanĝis, sed planas: kiom facile estis vendi ĉi tiun ideon al komerco kaj ĉu ĝi estis aventuro, investa projekto? Aŭ ĉu ĝi estis konscia strategio: nun ni iras al mikroservoj kaj jen, nenio haltos nin. Kiel estis por vi?
Sergey:
Ni ne vendis aliron, sed komercan avantaĝon. Estis problemo en komerco, kaj ni provis solvi ĝin. En tiu momento, ĝi esprimiĝis en la fakto, ke malsamaj kanaloj uzis malsamajn principojn por kalkuli prezojn - aparte por promocioj, por promocioj ktp. Ĝi estis malfacile konservi, eraroj okazis, kaj ni aŭskultis klientajn plendojn. Tio estas, ni vendis solvon al problemo, sed ni venis kun la fakto, ke ni bezonis monon por krei platformon. Kaj ili montris komercan kazon uzante la ekzemplon de la unua etapo de investo: kiel ni daŭre regajnos ĝin kaj kion ĉi tio permesos al ni fari.
Dmitrij:
Ĉu vi iel registris la tempon de la unua etapo?
Sergey:
Jes certa. Ni asignis 6 monatojn por krei la kernon kiel platformon kaj testi la piloton. Dum ĉi tiu tempo, ni provis krei platformon sur kiu gliti la piloton. Tiam la hipotezo estis konfirmita, kaj ĉar ĝi funkcias, tio signifas, ke ni povas daŭrigi. Ili komencis reprodukti kaj plifortigi la teamon - ili movis ĝin en apartan dividon kiu faras ĝuste tion.
Poste venas sistema laboro bazita sur komercaj bezonoj, ŝancoj, havebleco de rimedoj kaj ĉio, kio estas nuntempe en la laboroj.
Dmitrij:
BONE. Aleksandro, kion vi diras?
Aleksandro:
Niaj mikroservoj naskiĝis el la "ŝaŭmo de la maro" - pro ŝparado de rimedoj, pro kelkaj restaĵoj en formo de servila kapablo kaj la redistribuo de fortoj ene de la teamo. Komence, ni ne vendis ĉi tiun projekton al komerco. Ĉi tio estis projekto, kie ni ambaŭ esploris kaj disvolviĝis laŭe. Ni komencis komence de 2018 kaj simple disvolvis ĉi tiun direkton kun entuziasmo. Vendoj ĵus komenciĝis kaj ni estas en la procezo.
Dmitrij:
Ĉu okazas, ke komerco permesas al vi fari tiajn aferojn kiel Guglo - en unu libera tago semajne? Ĉu vi havas tian direkton?
Aleksandro:
Samtempe kun esplorado, ni ankaŭ traktis komercajn problemojn, do ĉiuj niaj mikroservoj estas solvoj al komercaj problemoj. Nur komence ni konstruis mikroservojn, kiuj kovris malgrandan parton de la abonantaro, kaj nun ni ĉeestas en preskaŭ ĉiuj ĉefaj produktoj.
Kaj la materiala efiko jam estas klara - ni jam povas esti kalkulitaj, la rapideco de produkto-lanĉoj kaj perditaj enspezoj estas taksataj, se ni estus sekvinta la malnovan vojon. Jen sur kio ni konstruas la kazon.
Mikroservoj: ekzaltiĝo aŭ neceso?
Dmitrij:
Nombroj estas nombroj. Kaj enspezo aŭ mono ŝparita estas tre grava. Kio se vi rigardas la alian flankon? Ŝajnas, ke mikroservoj estas tendenco, hype kaj multaj kompanioj misuzas ĝin? Kiel klare vi diferencas inter tio, kion vi faras kaj ne tradukas al mikroservoj? Se heredaĵo nun, ĉu vi ankoraŭ havos heredaĵon post 5 jaroj? Kiom estos la aĝo de la informsistemoj kiuj funkcias ĉe M.Video-Eldorado kaj MegaFon post 5 jaroj? Ĉu estos dek-jaraj, dekkvinjaraj informsistemoj aŭ ĉu ĝi estos nova generacio? Kiel vi vidas ĉi tion?
Sergey:
Ŝajnas al mi, ke estas malfacile pensi tre malproksime. Se ni retrorigardas, kiu imagis, ke la teknologia merkato disvolviĝus tiel, inkluzive de maŝinlernado kaj identigo de uzantoj laŭvizaĝe? Sed se vi rigardas la venontajn jarojn, ŝajnas al mi, ke kernaj sistemoj, entreprenaj ERP-klasaj sistemoj en kompanioj - ili funkcias sufiĉe longe.
Niaj kompanioj estas kolektive 25 jarojn aĝaj, kun klasika ERP tre profunde en la sistema pejzaĝo. Estas klare, ke ni prenas kelkajn pecojn el tie kaj provas kunigi ilin en mikroservojn, sed la kerno restos. Estas malfacile por mi nun imagi, ke ni anstataŭigos ĉiujn kernsistemojn tie kaj rapide moviĝos al la alia, hela flanko de la novaj sistemoj.
Mi subtenas la fakton, ke ĉio, kio estas pli proksima al la kliento kaj konsumanto, estas kie estas la plej granda komerca profito kaj valoro, kie adaptebleco kaj fokuso pri rapideco, pri ŝanĝo, pri "provi, nuligi, reuzi, fari ion malsaman" estas. bezonis “—tien la pejzaĝo ŝanĝiĝos. Kaj skatolaj produktoj ne tre bone taŭgas tie. Almenaŭ ni ne vidas ĝin. La plej facilaj, plej simplaj solvoj estas bezonataj tie.
Ni vidas ĉi tiun evoluon:
- kernaj informsistemoj (plejparte back office);
- mezaj tavoloj en formo de mikroservoj konektas la kernon, agregas, kreas kaŝmemoron, ktp;
- frontliniaj sistemoj estas celitaj al la konsumanto;
- integriga tavolo kiu estas ĝenerale integra en foirejoj, aliaj sistemoj kaj ekosistemoj. Ĉi tiu tavolo estas kiel eble plej malpeza, simpla, kaj enhavas minimumon de komerca logiko.
Sed samtempe mi subtenas plu uzi la malnovajn principojn, se ili estas taŭge uzataj.
Ni diru, ke vi havas klasikan entreprenan sistemon. Ĝi situas en la pejzaĝo de unu vendisto kaj konsistas el du moduloj, kiuj funkcias inter si. Ekzistas ankaŭ norma integriga interfaco. Kial refari ĝin kaj alporti mikroservon tien?
Sed kiam estas 5 moduloj en la malantaŭa oficejo, el kiuj informoj estas kolektitaj en komercan procezon, kiu tiam estas uzata de 8-10 frontliniaj sistemoj, la avantaĝo estas tuj rimarkebla. Vi prenas el kvin back-officejaj sistemoj kaj kreas servon, izolitan, kiu estas koncentrita al la komerca procezo. Faru la servon teknologie progresinta - por ke ĝi konservu informojn kaj estu tolerema al misfunkciadoj, kaj ankaŭ funkcias kun dokumentoj aŭ komercaj entoj. Kaj vi integras ĝin laŭ ununura principo kun ĉiuj unuaj produktoj. Ili nuligis la unuarangan produkton - ili simple malŝaltis la integriĝon. Morgaŭ vi devas skribi poŝtelefonan aplikaĵon aŭ fari malgrandan retejon kaj meti nur unu parton en funkciojn - ĉio estas simpla: vi kunmetis ĝin kiel konstruisto. Mi vidas pli da evoluo en tiu ĉi direkto – almenaŭ en nia lando.
Aleksandro:
Sergey tute priskribis nian aliron, dankon. Mi nur diros kien ni certe ne iros - al la kerna parto, al la temo de reta fakturado. Tio estas, taksado kaj ŝarĝo restos, fakte, "granda" draŝilo, kiu fidinde forĵetos monon. Kaj ĉi tiu sistemo daŭre estos atestita de niaj reguligaj aŭtoritatoj. Ĉio alia, kio rigardas klientojn, kompreneble, estas mikroservoj.
Dmitrij:
Ĉi tie atestado estas unu rakonto. Verŝajne pli da subteno. Se vi elspezas malmulte por subteno aŭ la sistemo ne postulas subtenon kaj modifon, estas pli bone ne tuŝi ĝin. Racia kompromiso.
Kiel evoluigi fidindajn mikroservojn
Dmitrij:
Bone. Sed mi ankoraŭ interesiĝas. Nun vi rakontas sukcesan historion: ĉio estis bone, ni ŝanĝis al mikroservoj, defendis la ideon al la komerco, kaj ĉio funkciis. Sed mi aŭdis aliajn rakontojn.
Antaŭ kelkaj jaroj, svisa kompanio, kiu investis du jarojn por disvolvi novan mikroservan platformon por bankoj, finfine fermis la projekton. Tute kolapsis. Multaj milionoj da svisaj frankoj estis elspezitaj, kaj finfine la teamo disiĝis - ĝi ne funkciis.
Ĉu vi havis similajn rakontojn? Ĉu estis aŭ estas malfacilaĵoj? Ekzemple, konservado de mikroservoj kaj monitorado ankaŭ estas kapdoloro en la operaciaj agadoj de la kompanio. Post ĉio, la nombro da komponantoj pliiĝas dekfoje. Kiel vi vidas ĝin, ĉu estis malsukcesaj ekzemploj de investoj ĉi tie? Kaj kion vi povas konsili homojn, por ke ili ne renkontu tiajn problemojn?
Aleksandro:
Malsukcesaj ekzemploj inkludis entreprenojn ŝanĝantajn prioritatojn kaj nuligante projektojn. Kiam en bona stadio de preteco (fakte, la MVP estas preta), la komerco diris: "Ni havas novajn prioritatojn, ni iras al alia projekto, kaj ni fermas ĉi tiun."
Ni ne havis tutmondajn fiaskojn kun mikroservoj. Ni dormas trankvile, ni havas 24/7 deĵoran deĵoron kiu servas la tutan BSS [komerca subtena sistemo].
Kaj ankoraŭ unu afero - ni luas mikroservojn laŭ la reguloj, kiuj validas por skatolaj produktoj. La ŝlosilo al sukceso estas, ke vi devas unue kunmeti teamon, kiu plene preparos la mikroservon por produktado. La evoluo mem estas, kondiĉe, 40%. La resto estas analizo, DevSecOps-metodaro, la ĝustaj integriĝoj kaj la ĝusta arkitekturo. Ni donas specialan atenton al la principoj de konstruado de sekuraj aplikoj. Informasekurecreprezentantoj partoprenas en ĉiu projekto kaj en la arkitekturplanadstadio kaj dum la efektivigprocezo. Ili ankaŭ administras sistemojn por analizi kodon por vundeblecoj.
Ni diru, ke ni deplojas niajn sennaciajn servojn - ni havas ilin en Kubernetes. Ĉi tio permesas al ĉiuj dormi trankvile pro aŭtomata skalo kaj aŭtomate altiĝo de servoj, kaj la devoŝanĝo reprenas incidentojn.
En la tuta ekzisto de niaj mikroservoj, estis nur unu aŭ du incidentoj kiuj atingis nian linion. Nun ne estas problemoj kun funkciado. Ni, kompreneble, havas ne 200, sed ĉirkaŭ 50 mikroservojn, sed ili estas uzataj en ĉefaj produktoj. Se ili malsukcesus, ni estus la unuaj kiuj ekscius pri tio.
Mikroservoj kaj HR
Sergey:
Mi konsentas kun mia kolego pri la translokigo al subteno - ke la laboro devas esti ĝuste organizita. Sed mi rakontos al vi pri la problemoj, kiuj kompreneble ekzistas.
Unue, la teknologio estas nova. Ĉi tio estas bona maniero, kaj trovi specialiston, kiu komprenos kaj povas krei ĉi tion, estas granda defio. La konkurado pri rimedoj estas freneza, do spertuloj valoras sian pezon en oro.
Due, kun kreado de certaj pejzaĝoj kaj kreskanta nombro da servoj, la problemo de reuzo devas esti konstante solvita. Kiel programistoj ŝatas fari: "Ni skribu multajn interesajn aferojn ĉi tie nun..." Pro tio, la sistemo kreskas kaj perdas sian efikecon laŭ mono, kosto de posedo ktp. Tio estas, necesas inkluzivi reuzon en la sistema arkitekturo, inkluzivi ĝin en la vojmapon por enkonduki servojn kaj transdoni heredaĵon al nova arkitekturo.
Alia problemo - kvankam tio estas bona siamaniere - estas interna konkurenco. "Ho, novaj modaj uloj aperis ĉi tie, ili parolas novan lingvon." Homoj, kompreneble, estas malsamaj. Estas tiuj, kiuj kutimas skribi en Java, kaj tiuj, kiuj skribas kaj uzas Docker kaj Kubernetes. Ĉi tiuj estas tute malsamaj homoj, ili parolas malsame, uzas malsamajn terminojn kaj foje ne komprenas unu la alian. La kapablo aŭ nekapablo kunhavigi praktikon, scion kundividon, ĉi-sence ankaŭ estas problemo.
Nu, grimpi rimedojn. “Bonege, ni iru! Kaj nun ni volas pli rapide, pli. Kio, vi ne povas? Ĉu ne eblas liveri duoble pli en jaro? Kaj kial?" Tiaj kreskantaj doloroj verŝajne estas normaj por multaj aferoj, multaj aliroj, kaj vi povas senti ilin.
Pri monitorado. Ŝajnas al mi, ke servoj aŭ industriaj monitoraj iloj jam lernas aŭ kapablas labori kun kaj Docker kaj Kubernetes en malsama, ne-norma reĝimo. Por ke, ekzemple, vi ne finiĝu kun 500 Java maŝinoj sub kiuj ĉio ĉi funkcias, nome, ĝi agregas. Sed al ĉi tiuj produktoj ankoraŭ mankas matureco; ili devas travivi ĉi tion. La temo estas vere nova, ĝi daŭre disvolviĝos.
Dmitrij:
Jes, tre interesa. Kaj ĉi tio validas por HR. Eble via HR-procezo kaj HR-marko iom ŝanĝiĝis dum ĉi tiuj 3 jaroj. Vi komencis varbi aliajn homojn kun malsamaj kompetentecoj. Kaj verŝajne estas ambaŭ avantaĝoj kaj malavantaĝoj. Antaŭe, blokĉeno kaj datumscienco estis la furoraĵo, kaj specialistoj en ili valoris milionojn. Nun la kosto falas, la merkato fariĝas saturita, kaj ekzistas simila tendenco en mikroservoj.
Sergey:
Jes, absolute.
Aleksandro:
HR faras la demandon: "Kie estas via rozkolora unikorno inter la backend kaj fasado?" HR ne komprenas kio estas mikroservo. Ni rakontis al ili la sekreton kaj diris al ili, ke la malantaŭo faris ĉion, kaj ne ekzistas unikorno. Sed HR ŝanĝiĝas, lernas rapide kaj varbas homojn, kiuj havas bazajn IT-scion.
La evoluo de mikroservoj
Dmitrij:
Se vi rigardas la celan arkitekturon, mikroservoj aspektas kiel tia monstro. Via vojaĝo daŭris plurajn jarojn. Aliaj havas jaron, aliaj tri jarojn. Ĉu vi antaŭvidis ĉiujn problemojn, la celarkitekturon, ĉu io ŝanĝiĝis? Ekzemple, en la kazo de mikroservoj, enirejoj kaj servaj retoj nun denove aperas. Ĉu vi uzis ilin en la komenco aŭ ĉu vi ŝanĝis la arkitekturon mem? Ĉu vi havas tiajn defiojn?
Sergey:
Ni jam reverkis plurajn komunikprotokolojn. Komence estis unu protokolo, nun ni ŝanĝis al alia. Ni pliigas sekurecon kaj fidindecon. Ni komencis kun entreprenaj teknologioj - Oracle, Web Logic. Nun ni malproksimiĝas de teknologiaj entreprenaj produktoj en mikroservoj kaj moviĝas al malferma fonto aŭ tute malfermaj teknologioj. Ni forlasas datumbazojn kaj moviĝas al tio, kio funkcias pli efike por ni en ĉi tiu modelo. Ni ne plu bezonas Oracle-teknologiojn.
Ni komencis simple kiel servo, sen pensi pri kiom ni bezonis kaŝmemoron, kion ni farus kiam ne estus konekto kun mikroservo, sed necesas datumoj, ktp. Nun ni disvolvas platformon por ke la arkitekturo estu priskribita. ne en la lingvo de servoj, kaj en komerca lingvo, prenu komercan logikon al la sekva nivelo kiam ni komencas paroli per vortoj. Nun ni lernis paroli per literoj, kaj la sekva nivelo estas kiam la servoj estos kolektitaj en ian agregaĵon, kiam ĉi tio jam estas vorto - ekzemple tuta produktkarto. Ĝi estas kunmetita de mikroservoj, sed ĝi estas API konstruita sur ĉi tio.
Sekureco estas tre grava. Tuj kiam vi komencas esti alirebla kaj vi havas servon per kiu vi povas akiri multajn interesajn aferojn, kaj tre rapide, en frakcio de sekundo, tiam estas deziro akiri ĝin en ne la plej sekura maniero. Por foriri de ĉi tio, ni devis ŝanĝi alirojn al testado kaj monitorado. Ni devis ŝanĝi la teamon, la liveran administran strukturon, CI/KD.
Ĉi tio estas evoluo - kiel ĉe telefonoj, nur multe pli rapida: unue estis prembutonaj telefonoj, poste aperis saĝtelefonoj. Ni reverkis kaj restrukturis la produkton ĉar la merkato havis malsaman bezonon. Jen kiel ni evoluas: unua klaso, deka grado, laboro.
Ripete, io estas aranĝita jare el la vidpunkto de teknologio, io alia el la vidpunkto de la restaro kaj bezonoj. Ni ligas unu aferon al alia. La teamo elspezas 20% por teknika ŝuldo kaj teknika subteno por la teamo, 80% por la komerca ento. Kaj ni moviĝas kun kompreno pri kial ni faras ĝin, kial ni faras ĉi tiujn teknologiajn plibonigojn, al kio ili kondukos. Tiel.
Dmitrij:
Cool. Kio estas en MegaFon?
Aleksandro:
La ĉefa defio kiam ni venis al mikroservoj estis ne fali en kaoson. La arkitektura oficejo de MegaFon tuj aliĝis al ni, eĉ fariĝis iniciatinto kaj ŝoforo - nun ni havas tre fortan arkitekturon. Lia tasko estis kompreni kian celmodelon ni iras kaj kiajn teknologiojn devas esti pilotataj. Kun arkitekturo, ni mem kondukis ĉi tiujn pilotojn.
La sekva demando estis: "Do kiel ekspluati ĉion ĉi?" Kaj unu pli: "Kiel certigi travideblan interagadon inter mikroservoj?" Servomaŝo helpis nin respondi la lastan demandon. Ni pilotis Istio kaj ŝatis la rezultojn. Nun ni estas en la stadio de disvolvado en produktajn zonojn. Ni havas pozitivan sintenon al ĉiuj defioj - la fakto, ke ni devas konstante ŝanĝi la stakon, lerni ion novan. Ni interesiĝas pri disvolvi, ne ekspluati malnovajn solvojn.
Dmitrij:
Orvortoj! Tiaj defioj tenas la teamon kaj komercon sur siaj piedfingroj kaj kreas la estontecon. GDPR kreis ĉefajn datumprotektajn oficistojn, kaj nunaj defioj kreas ĉefajn mikroservojn kaj arkitekturoficistojn. Kaj plaĉas.
Ni multe diskutis. La ĉefa afero estas, ke bona dezajno de mikroservoj kaj la arkitekturo mem permesas eviti multajn erarojn. Kompreneble, la procezo estas ripeta kaj evolua, sed ĝi estas la estonteco.
Dankon al ĉiuj partoprenantoj, dankon al Sergej kaj Aleksandro!
Demandoj de la publiko
Demando de la publiko (1):
Sergey, kiel ŝanĝiĝis IT-administrado en via kompanio? Mi komprenas, ke kiam estas granda stako de pluraj sistemoj, kiel ĝi estas administrita estas sufiĉe klara kaj logika procezo. Kiel vi rekonstruis la administradon de la IT-komponento post kiam tre granda nombro da mikroservoj estis integritaj en tiel mallonga tempo?
Sergey:
Mi konsentas kun mia kolego, ke arkitekturo estas tre grava kiel ŝoforo de ŝanĝo. Ni komencis havante arkitekturan dividon. Arkitektoj estas samtempe la posedantoj de la distribuado de funkcieco kaj la postuloj pri kiel ĝi aperos en la pejzaĝo. Do ili ankaŭ rolas kiel kunordigantoj de ĉi tiuj ŝanĝoj. Kiel rezulto, estis specifaj ŝanĝoj al specifa livera procezo kiam ni kreis CI/KD-platformon.
Sed la normaj, bazaj principoj de disvolviĝo, komerca analizo, testado kaj disvolviĝo ne estis nuligitaj. Ni ĵus aldonis rapidon. Antaŭe, la ciklo prenis tiom multe, instalo en testaj medioj prenis multe pli. Nun komerco vidas la avantaĝon kaj diras: "Kial ni ne povas fari la samon en aliaj lokoj?"
Estas kiel, en bona maniero, injekto en formo de vakcino kiu montris: vi povas fari ĝin tiel, sed vi povas fari ĝin alimaniere. Kompreneble, estas problemo en personaro, en kompetentecoj, en scio, en rezisto.
Demando de la publiko (2):
Kritikistoj de mikroserva arkitekturo diras, ke testado kaj evoluo estas malfacilaj. Ĉi tio estas logika kie aferoj komplikiĝas. Kiujn defiojn renkontis via teamo kaj kiel vi venkis ilin? Demando por ĉiuj.
Aleksandro:
Estas malfacilaĵoj dum moviĝado de mikroservoj al platformo, sed ili povas esti solvitaj.
Ekzemple, ni faras produkton kiu konsistas el 5-7 mikroservoj. Ni devas disponigi integrigajn testojn tra la tuta mikroservostako por doni la verdan lumon por moviĝi al la majstra branĉo. Ĉi tiu tasko ne estis nova por ni: ni faris tion delonge ĉe BSS, kiam la vendisto liveris al ni jam senditajn solvojn.
Kaj nia problemo estas nur en la malgranda teamo. Unu QA-inĝeniero estas necesa por unu kondiĉa produkto. Kaj tiel, ni sendas produkton de 5-7 mikroservoj, el kiuj 2-3 povas esti evoluigitaj de triaj partioj. Ekzemple, ni havas produkton en kies evoluo partoprenas nia faktura sistemo-vendisto, Mail.ru Group kaj MegaFon R&D. Ni devas kovri ĉi tion per testoj antaŭ sendi ĝin al produktado. La QA-inĝeniero laboras pri ĉi tiu produkto dum monato kaj duono, kaj la resto de la teamo restas sen lia subteno.
Ĉi tiu komplekseco estas nur kaŭzita de skalo. Ni komprenas, ke mikroservoj ne povas ekzisti en vakuo; absoluta izoliteco ne ekzistas. Ŝanĝante unu servon, ni ĉiam provas konservi la API-kontrakton. Se io ŝanĝiĝas sub la kapuĉo, la antaŭa servo restas. Se la ŝanĝoj estas mortigaj, okazas ia arkitektura transformo kaj ni moviĝas al tute alia datuma metamodelo, kiu estas tute nekongrua - nur tiam ni parolas pri la apero de la v2-servo API-specifo. Ni subtenas la unuan kaj duan versiojn samtempe, kaj post kiam ĉiuj konsumantoj ŝanĝas al la dua versio, ni simple fermas la unuan.
Sergey:
Mi volas aldoni. Mi tute konsentas pri komplikaĵoj - ili okazas. La pejzaĝo fariĝas pli kompleksa, kaj superkostoj pliiĝas, precipe por testado. Kiel trakti ĉi tion: ŝanĝu al aŭtomata testado. Jes, vi devos investi aldone en verkado de aŭtotestoj kaj unuotestoj. Por ke programistoj ne povu kompromiti sen trapasi la teston, ili ne povis ŝanĝi la kodon. Por ke eĉ la prembutono ne funkcias sen aŭtotesto, unutesto.
Gravas konservi la antaŭan funkcion, kaj ĉi tio estas plia superkosto. Se vi reverkas teknologion al alia protokolo, tiam vi reverkas ĝin ĝis vi tute fermos ĉion.
Ni kelkfoje ne intence faras fin-al-finan testadon, ĉar ni ne volas ĉesigi evoluon, kvankam ni ankaŭ havas unu aferon post alia. La pejzaĝo estas tre granda, kompleksa, estas multaj sistemoj. Foje ĝi estas nur stumpoj - jes, vi malaltigas la sekurecan marĝenon, pli da riskoj aperas. Sed samtempe vi liberigas la provizon.
Aleksandro:
Jes, aŭtotestoj kaj unuotestoj permesas vin krei altkvalitan servon. Ni estas por dukto, kiu ne povas esti trapasita sen unuokaj kaj integrigaj testoj. Ni ofte devas treni emulilojn kaj komercajn sistemojn en testajn zonojn kaj evoluajn mediojn, ĉar ne ĉiuj sistemoj povas esti metitaj en testajn zonojn. Plie, ili ne nur malsekiĝas - ni generas plenan respondon de la sistemo. Ĉi tio estas grava parto de laboro kun mikroservoj, kaj ni ankaŭ investas en ĝi. Sen ĉi tio, kaoso okazos.
Demando de la publiko (3):
Laŭ mia kompreno, mikroservoj komence kreskis de aparta teamo kaj nun ekzistas en ĉi tiu modelo. Kio estas ĝiaj avantaĝoj kaj malavantaĝoj?
Ni nur havas similan historion: ekestis ia fabriko de mikroservoj. Nun ni koncipe venis al la punkto, ke ni etendas ĉi tiun aliron al produktado per fluoj kaj per sistemoj. Alivorte, ni malproksimiĝas de la centralizita disvolviĝo de mikroservoj, mikroservomodeloj, kaj iĝas pli proksimaj al sistemoj.
Sekve, nia operacio ankaŭ iras al sistemoj, tio estas, ni malcentralizas ĉi tiun temon. Kio estas via aliro kaj kio estas via celrakonto?
Aleksandro:
Vi faligis la nomon "mikroserva fabriko" tuj el via buŝo - ni ankaŭ volas skali. Unue, ni vere havas unu teamon nun. Ni volas provizi ĉiujn evoluajn teamojn, kiujn MegaFon havas, la ŝancon labori en komuna ekosistemo. Ni ne volas tute transpreni ĉiujn disvolvajn funkciojn, kiujn ni havas nun. La loka tasko estas grimpi, la tutmonda tasko estas gvidi disvolviĝon al ĉiuj teamoj en la mikroserva tavolo.
Sergey:
Mi rakontos al vi la vojon, kiun ni prenis. Ni vere komencis labori kiel unu teamo, sed nun ni ne estas solaj. Mi estas proponanto de la sekvanta: devas esti posedanto de la procezo. Iu bezonas kompreni, administri, kontroli kaj konstrui la disvolvan procezon de mikroservoj. Li devas posedi rimedojn kaj okupiĝi pri resursa administrado.
Ĉi tiuj rimedoj, kiuj konas teknologiojn, specifaĵojn kaj komprenas kiel konstrui mikroservojn, povas troviĝi en produktteamoj. Ni havas miksaĵon, kie homoj de la mikroserva platformo estas en la produktteamo, kiu faras la moveblan aplikaĵon. Ili estas tie, sed ili funkcias laŭ la procezo de la fako pri administrado de mikroservo platformo kun sia disvolva administranto. Ene de ĉi tiu dividado estas aparta teamo, kiu traktas teknologion. Tio estas, ni miksas komunan aron da rimedoj inter ni kaj dividas ilin, donante ilin al teamoj.
Samtempe, la procezo restas ĝenerala, kontrolita, ĝi daŭrigas laŭ ĝeneralaj teknologiaj principoj, kun unuo-testado kaj tiel plu - ĉio, kio estas konstruita sur la supro. Povas ekzisti kolumnoj en la formo de rimedoj kolektitaj de malsamaj fakoj de la produkta aliro.
Aleksandro:
Sergey, vi efektive estas la posedanto de la procezo, ĉu ne? Ĉu la tasko postrestinta estas dividita? Kiu respondecas pri ĝia distribuo?
Sergey:
Rigardu: jen denove la miksaĵo. Estas restaro kiu formiĝas surbaze de teknologiaj plibonigoj - ĉi tio estas unu rakonto. Estas restaro, kiu estas formulita de projektoj, kaj estas postrestanco de produktoj. Sed la sekvenco de enkonduko en ĉiu el la servaj produktoj aŭ la kreado de ĉi tiu servo estas disvolvita de produkta specialisto. Li ne estas en la IT-direktoro; li estis speciale forigita de ĝi. Sed miaj homoj certe laboras laŭ la sama procezo.
La posedanto de la restaro en malsamaj direktoj - la restaro de ŝanĝoj - estos malsamaj homoj. La konekto de teknologiaj servoj, ilia organiza principo - ĉio ĉi estos en IT. Mi posedas ankaŭ la platformon kaj la rimedojn. Ĉe la supro estas kio koncernas la restaron kaj funkciajn ŝanĝojn, kaj la arkitekturon en ĉi tiu senco.
Ni diru, ke komerco diras: "Ni volas ĉi tiun funkcion, ni volas krei novan produkton - refari prunton." Ni respondas: "Jes, ni refaros ĝin." Arkitektoj diras: "Ni pensu: kie en la prunto ni skribos mikroservojn kaj kiel ni faros ĝin?" Poste ni disigas ĝin en projektojn, produktojn aŭ teknologian stakon, metas ĝin en teamojn kaj efektivigas ĝin. Ĉu vi kreis produkton interne kaj decidis uzi mikroservojn en ĉi tiu produkto? Ni diras: "Nun la heredaj sistemoj, kiujn ni havis, aŭ unualiniaj sistemoj, devas ŝanĝi al ĉi tiuj mikroservoj." La arkitektoj diras: "Do: en la teknologia restado ene de la unuaj produktoj - la transiro al mikroservoj. Iru". Kaj produktaj specialistoj aŭ komercaj posedantoj komprenas kiom da kapablo estas asignita, kiam ĝi estos farita kaj kial.
La fino de la diskuto, sed ne ĉio
La konferenco mailto:CLOUD estis organizita .
Ni faras ankaŭ aliajn aranĝojn - ekz. @Kubernetes Meetup, kie ni ĉiam serĉas bonegajn parolantojn:
- Sekvu @Kubernetes kaj aliajn novaĵojn de @Meetup en nia Telegram-kanalo
- Ĉu vi interesas paroli ĉe unu el la @Meetups? Lasu peton por
fonto: www.habr.com