Kio helpis nin rapide adaptiĝi al interreta komerco en la novaj kondiĉoj

Saluton!

Mi nomiĝas Miĥail, mi estas la vicdirektoro de IT ĉe la kompanio Sportmaster. Mi volas konigi la rakonton pri kiel ni traktis la defiojn, kiuj aperis dum la pandemio.

En la unuaj tagoj de la novaj realaĵoj, la kutima eksterreta komerca formato de Sportmaster frostiĝis, kaj la ŝarĝo sur nia interreta kanalo, ĉefe laŭ livero al la adreso de la kliento, pliiĝis 10 fojojn. En nur kelkaj semajnoj, ni transformis gigantan eksterreta komercon en interretan kaj adaptis la servon al la bezonoj de niaj klientoj.

Esence, kio esence estis nia flanka operacio fariĝis nia kerna komerco. La graveco de ĉiu interreta mendo ege pliiĝis. Necesis ŝpari ĉiun rublon, kiun la kliento alportis al la kompanio. 

Por rapide respondi al klientpetoj, ni malfermis plian kontaktcentron ĉe la ĉefa oficejo de la kompanio, kaj nun povas ricevi ĉirkaŭ 285 mil vokojn semajne. Samtempe, ni movis 270 vendejojn al nova senkontakta kaj sekura operacia formato, kiu permesis al klientoj ricevi mendojn kaj dungitoj konservi siajn laborpostenojn.

Dum la transforma procezo, ni renkontis du ĉefajn problemojn. Unue, la ŝarĝo de niaj interretaj rimedoj signife pliiĝis (Sergey rakontos al vi kiel ni traktis ĉi tion). Due, la fluo de maloftaj (antaŭ COVID) operacioj multfoje pliiĝis, kio siavice postulis grandan kvanton da rapida aŭtomatigo. Por solvi ĉi tiun problemon, ni devis rapide translokigi rimedojn de areoj, kiuj antaŭe estis la ĉefaj. Elena rakontos al vi kiel ni traktis ĉi tion.

Funkciado de interretaj servoj

Kolesnikov Sergey, respondeca pri la funkciado de la reta vendejo kaj mikroservoj

De la momento, kiam niaj podetalaj vendejoj komencis fermiĝi al vizitantoj, ni komencis registri pliiĝon de mezuroj kiel la nombro da uzantoj, la nombro da mendoj faritaj en nia aplikaĵo kaj la nombro da petoj al aplikoj. 

Nombro de mendoj de la 18-a de marto ĝis la 31-a de martoNombro da petoj al interreta pagmikroservojNombro de mendoj faritaj en la retejo

En la unua grafikaĵo ni vidas, ke la kresko estis proksimume 14 fojojn, en la dua - 4 fojojn. Ni konsideras la respondtempan metrikon de niaj aplikoj kiel la plej indika. 

En ĉi tiu grafikaĵo ni vidas la respondon de frontoj kaj aplikoj, kaj por ni mem ni determinis, ke ni ne rimarkis ajnan kreskon kiel tia.

Ĉi tio estas ĉefe pro la fakto, ke ni komencis preparajn laborojn fine de 2019. Nun niaj servoj estas rezervitaj, toleremo al misfunkciadoj estas certigita je la nivelo de fizikaj serviloj, virtualigaj sistemoj, dockers kaj servoj en ili. Samtempe, la kapablo de niaj servilaj rimedoj permesas al ni elteni plurajn ŝarĝojn.

La ĉefa ilo, kiu helpis nin en ĉi tiu tuta historio, estis nia monitora sistemo. Vere, ĝis antaŭ nelonge ni ne havis ununuran sistemon, kiu permesus al ni kolekti metrikojn ĉe ĉiuj tavoloj, de la nivelo de fizika ekipaĵo kaj aparataro ĝis la nivelo de komercaj metrikoj. 

Formale, estis monitorado en la kompanio, sed kutime ĝi estis disigita kaj estis en la areo de respondeco de specifaj fakoj. Fakte, kiam okazis okazaĵo, ni preskaŭ neniam havis komunan komprenon pri tio, kio ĝuste okazis, ne estis komunikado, kaj ofte tio kondukis al kuri en rondoj por trovi kaj izoli la problemon por ke ĝi estu riparita.

Iam ni pensis kaj decidis, ke ni sufiĉe elteni tion - ni bezonis unuecan sistemon por vidi la tutan bildon plene. La ĉefaj teknologioj, kiuj estas inkluzivitaj en nia stako, estas Zabbix kiel atentiga kaj metrika stokadocentro, Prometheus por kolekti kaj stoki aplikajn metrikojn, Stack ELK por registri kaj stoki datumojn de la tuta monitora sistemo, kaj Grafana por bildigo, Swagger, Docker. kaj aliaj utilaj kaj aferoj, kiuj estas konataj al vi.

Samtempe ni uzas ne nur teknologiojn disponeblajn sur la merkato, sed ankaŭ disvolvas iujn niajn proprajn. Ekzemple, ni faras servojn por integri sistemojn unu kun la alia, tio estas, ia API por kolekti metrikojn. Krome ni laboras pri niaj propraj monitoraj sistemoj - je la nivelo de komercaj metrikoj ni uzas UI-testojn. Kaj ankaŭ bot en Telegramo por sciigi teamojn.

Ni ankaŭ provas igi la monitoran sistemon alirebla por teamoj por ke ili povu sendepende stoki kaj labori kun siaj metrikoj, inkluzive de agordo de atentigoj por kelkaj mallarĝaj metrikoj kiuj ne estas vaste uzataj. 

Ĉie en la sistemo, ni strebas por proaktiveco kaj lokalizado de okazaĵoj kiel eble plej rapide. Krome, la nombro da niaj mikroservoj kaj sistemoj signife kreskis lastatempe, kaj la nombro da integriĝoj sekve kreskis. Kaj kiel parto de optimumigo de la procezo de diagnozo de incidentoj ĉe la integriga nivelo, ni disvolvas sistemon, kiu ebligas al vi fari transsistemajn kontrolojn kaj montri la rezulton, kio ebligas al vi trovi la ĉefajn problemojn asociitajn kun importado kaj interago de sistemoj kun unu la alian. 

Kompreneble, ni ankoraŭ havas lokon por kreski kaj disvolvi rilate al operaciumoj, kaj ni aktive laboras pri tio. Vi povas legi pli pri nia monitora sistemo tie. 

Teknikaj provoj 

Orlov Sergey, gvidas la kompetentecan centron por reto kaj movebla evoluo

De kiam la fizikaj vendejfermoj komenciĝis, ni alfrontis diversajn defiojn de evolua perspektivo. Antaŭ ĉio, la ŝarĝo pliiĝo kiel tia. Estas klare, ke se taŭgaj mezuroj ne estas prenitaj, tiam kiam alta ŝarĝo estas aplikata al la sistemo, ĝi povas iĝi kukurbo kun malĝoja eksplodo, aŭ tute malboniĝi en rendimento, aŭ eĉ perdi sian funkcion.

La dua aspekto, iom malpli evidenta, estas, ke la sistemo sub alta ŝarĝo devis esti ŝanĝita tre rapide, adaptiĝante al ŝanĝoj en komercaj procezoj. Kelkfoje plurfoje tage. Multaj kompanioj havas regulon, ke se estas multe da merkata agado, ne necesas fari ajnajn ŝanĝojn al la sistemo. Tute neniu, lasu ĝin funkcii tiel longe kiel ĝi funkcias.

Kaj ni esence havis senfinan Nigran Vendredon, dum kiu necesis ŝanĝi la sistemon. Kaj ajna eraro, problemo aŭ malsukceso en la sistemo estus tre multekosta por la komerco.

Rigardante antaŭen, mi diros, ke ni sukcesis trakti ĉi tiujn provojn, ĉiuj sistemoj eltenis la ŝarĝon, estis facile skalitaj, kaj ni ne spertis tutmondajn teknikajn fiaskojn.

Estas kvar kolonoj sur kiuj la kapablo de la sistemo elteni altajn ŝprucŝarĝojn ripozas. La unua el ili estas monitorado, pri kiu vi legis ĝuste supre. Sen enkonstruita monitora sistemo, estas preskaŭ neeble trovi sistemajn proplempunktojn. Bona monitora sistemo estas kiel hejma vesto; ĝi devus esti komforta kaj adaptita al vi.

La dua aspekto estas testado. Ni prenas ĉi tiun punkton tre serioze: ni skribas klasikajn unuojn, integrigajn testojn, ŝarĝajn provojn kaj multajn aliajn por ĉiu sistemo. Ni ankaŭ skribas testan strategion, kaj samtempe provas pliigi la nivelon de testado ĝis la punkto, ke ni ne plu bezonas manajn kontrolojn.

La tria kolono estas CI/CD Pipeline. La procezoj de konstruado, testado kaj deplojado de aplikaĵo devas esti aŭtomatigitaj kiel eble plej multe; ne devus ekzisti mana interveno. La temo de CI/CD Pipeline estas sufiĉe profunda, kaj mi nur mallonge tuŝos ĝin. Estas nur menciinde, ke ni havas CI/CD Pipeline-kontrolliston, kiun ĉiu produktteamo trapasas helpe de kompetentecaj centroj.

Kaj jen la kontrola listo

Tiel, multaj celoj estas atingitaj. Ĉi tio estas API-versiado kaj funkcio baskulo por eviti la eldontrajnon, kaj atingi kovradon de diversaj testoj je tia nivelo, ke testado estas plene aŭtomatigita, deplojoj estas senjuntaj, ktp.

La kvara kolono estas arkitekturaj principoj kaj teknikaj solvoj. Ni povas multe paroli pri arkitekturo dum longa tempo, sed mi volas emfazi kelkajn principojn, pri kiuj mi ŝatus koncentriĝi.

Unue, vi devas elekti specialajn ilojn por specifaj taskoj. Jes, ĝi sonas evidente, kaj estas klare, ke najloj devas esti enŝovataj per martelo, kaj brakhorloĝoj devas esti malmuntitaj per specialaj ŝraŭbiloj. Sed en nia epoko, multaj iloj strebas al universaligo por kovri la maksimuman segmenton de uzantoj: datumbazoj, kaŝmemoroj, kadroj kaj la ceteraj. Ekzemple, se vi prenas la MongoDB-datumbazon, ĝi funkcias kun multdokumentaj transakcioj, kaj la Oracle-datumbazo funkcias kun json. Kaj ŝajnus, ke ĉio povas esti uzata por ĉio. Sed se ni staras por produktiveco, tiam ni devas klare kompreni la fortojn kaj malfortojn de ĉiu ilo kaj uzi tiujn, kiujn ni bezonas por nia klaso de taskoj. 

Due, dum desegnado de sistemoj, ĉiu pliiĝo en komplekseco devas esti pravigita. Ni devas konstante konservi ĉi tion en menso; la principo de malalta kunigo estas konata de ĉiuj. Mi kredas, ke ĝi devus esti aplikata je la nivelo de specifa servo, kaj je la nivelo de la tuta sistemo, kaj je la nivelo de la arkitektura pejzaĝo. La kapablo horizontale grimpi ĉiun sistemkomponenton laŭ la ŝarĝpado ankaŭ estas grava. Se vi havas ĉi tiun kapablon, grimpi ne estos malfacila.

Parolante pri teknikaj solvoj, ni petis produktteamojn prepari freŝan aron da rekomendoj, ideoj kaj solvoj, kiujn ili efektivigis en preparo por la sekva ondo de laborŝarĝo.

Keshi

Necesas konscie alproksimiĝi al la elekto de lokaj kaj distribuitaj kaŝmemoroj. Kelkfoje estas senco uzi ambaŭ ene de la sama sistemo.Ekzemple, ni havas sistemojn en kiuj iuj el la datumoj esence estas montrofenestro, tio estas, la fonto de ĝisdatigoj situas malantaŭ la sistemo mem, kaj la sistemoj ne ŝanĝiĝas. ĉi tiuj datumoj. Por ĉi tiu aliro ni uzas lokan Kafeina Cache. 

Kaj estas datumoj, ke la sistemo aktive ŝanĝas dum operacio, kaj ĉi tie ni jam uzas distribuitan kaŝmemoron kun Hazelcast. Ĉi tiu aliro permesas al ni uzi la avantaĝojn de distribuita kaŝmemoro kie ili vere bezonas, kaj minimumigi la servokostojn de cirkulado de Hazelcast-grupo-datumoj kie ni povas malhavi ĝin. Ni skribis multon pri kaŝmemoroj. tie и tie.

Krome, ŝanĝi la seriigilon al Kryo en Hazelcast donis al ni bonan akcelon. Kaj la transiro de ReplicatedMap al IMap + Near Cache en Hazelcast permesis al ni minimumigi la movadon de datumoj tra la areto. 

Eta konsilo: en kazo de amasa kaŝmemoro nevalidiĝo, foje aplikeblas la taktiko varmigi la duan kaŝmemoron kaj poste ŝanĝi al ĝi. Ŝajnus, ke kun ĉi tiu aliro ni devus ricevi duoblan memorkonsumon, sed praktike, en tiuj sistemoj kie tio estis praktikata, memorkonsumo malpliiĝis.

Reaktiva stako

Ni uzas la reaktivan stakon en sufiĉe granda nombro da sistemoj. En nia kazo, ĉi tio estas Webflux aŭ Kotlin kun korutinoj. La reaktiva stako estas precipe bona, kie ni atendas malrapidajn enig-eligajn operaciojn. Ekzemple, vokoj al malrapidaj servoj, laborante kun la dosiersistemo aŭ stokadsistemoj.

La plej grava principo estas eviti blokadon de vokoj. Reaktivaj kadroj havas malgrandan nombron da vivservaj fadenoj kurantaj sub la kapuĉo. Se ni senzorge permesas al ni fari rektan blokantan vokon, kiel JDBC-ŝoforvokon, la sistemo simple haltos. 

Provu transformi erarojn en vian propran rultempan escepton. La fakta fluo de programekzekuto ŝanĝiĝas al reaktivaj kadroj, kaj kodekzekuto iĝas nelinia. Kiel rezulto, estas tre malfacile diagnozi problemojn uzante stakspurojn. Kaj la solvo ĉi tie estus krei klarajn, objektivajn rultempajn esceptojn por ĉiu eraro.

Elasta esploro

Kiam vi uzas Elasticsearch, ne elektu neuzatajn datumojn. Ĉi tio principe ankaŭ estas tre simpla konsilo, sed plej ofte tio estas forgesita. Se vi bezonas elekti pli ol 10 mil rekordojn samtempe, vi devas uzi Scroll. Por uzi analogion, ĝi estas iom kiel kursoro en rilata datumbazo. 

Ne uzu postfiltrilon krom se necese. Kun grandaj datumoj en la ĉefa specimeno, ĉi tiu operacio tre ŝarĝas la datumbazon. 

Uzu pograndajn operaciojn kie aplikeble.

API

Dum desegnado de API, inkludu postulojn por minimumigi transdonitajn datumojn. Ĉi tio estas precipe vera lige kun la fronto: estas ĉe ĉi tiu krucvojo, ke ni preterpasas la kanalojn de niaj datumcentroj kaj jam laboras pri la kanalo konektanta nin kun la kliento. Se ĝi havas la plej etan problemon, tro da trafiko kaŭzas negativan sperton de uzanto.

Kaj finfine, ne forĵetu tutan aron da datumoj, estu klara pri la kontrakto inter konsumantoj kaj provizantoj.

Organiza transformo

Eroshkina Elena, vicdirektoro por IT

En la momento, kiam okazis kvaranteno, kaj ekestis la bezono akre pliigi la ritmon de interreta disvolviĝo kaj enkonduki omnikajnajn servojn, ni jam estis en la procezo de organiza transformo. 

Parto de nia strukturo estis transdonita al laboro laŭ la principoj kaj praktikoj de la produkta aliro. Formiĝis teamoj, kiuj nun respondecas pri la funkciado kaj evoluo de ĉiu produkto. Dungitoj en tiaj teamoj estas 100% implikitaj kaj strukturas sian laboron uzante Scrum aŭ Kanban, depende de tio, kio estas preferinda al ili, starigante disfaldan dukton, efektivigante teknikajn praktikojn, kvalitajn praktikojn kaj multe pli.

Por sorto, la plej granda parto de niaj produktteamoj estis en la areo de interretaj kaj omnikanaj servoj. Ĉi tio permesis al ni ŝanĝi al fora laborreĝimo en la plej mallonga ebla tempo (serioze, laŭvorte en du tagoj) sen perdo de efikeco. La personecigita procezo permesis al ni rapide adaptiĝi al novaj laborkondiĉoj kaj konservi sufiĉe altan rapidecon de liverado de novaj funkcioj.

Krome, ni bezonas plifortigi tiujn teamojn, kiuj estas ĉe la limo de interreta komerco. En tiu momento evidentiĝis, ke ni povas fari tion nur per internaj rimedoj. Kaj ĉirkaŭ 50 homoj en du semajnoj ŝanĝis la areon kie ili laboris antaŭe kaj okupiĝis pri laborado pri produkto kiu estis nova por ili. 

Ĉi tio ne postulis specialajn administradajn klopodojn, ĉar kune kun organizado de nia propra procezo, teknika plibonigo de la produkto kaj praktikoj pri kvalito-certigo, ni instruas niajn teamojn memorganizi - administri sian propran produktadprocezon sen impliki administrajn rimedojn.

Ni povis enfokusigi niajn administrajn rimedojn ĝuste kie ĝi estis bezonata en tiu momento - pri kunordigo kune kun la komerco: Kio estas grava por nia kliento nun, kia funkcieco devus esti efektivigita unue, kio devas esti farita por pliigi nian traigan kapablon. liveri kaj procesi mendojn. Ĉio ĉi kaj klara rolmodelo ebligis dum ĉi tiu periodo ŝarĝi niajn produktadajn valorfluojn per kio estas vere grava kaj necesa. 

Estas klare, ke kun fora laboro kaj alta ritmo de ŝanĝo, kiam komercaj indikiloj dependas de ĉies partopreno, vi ne povas fidi nur al internaj sentoj de la serio "Ĉu ĉio iras bone ĉe ni? Jes, ĝi ŝajnas bona.” Objektivaj metrikoj de la produktada procezo estas necesaj. Ni havas ĉi tiujn, ili disponeblas por ĉiuj, kiuj interesiĝas pri la metrikoj de produktaj teamoj. Antaŭ ĉio, la teamo mem, la komerco, subkontraktistoj kaj administrado.

Unufoje ĉiujn du semajnojn, statuso estas tenita kun ĉiu teamo, kie metrikoj estas analizitaj dum 10 minutoj, botelkoloj en la produktadprocezo estas identigitaj, kaj komuna solvo estas evoluigita: kion oni povas fari por forigi ĉi tiujn botelpunktojn. Ĉi tie vi povas tuj peti helpon de administrado se iu identigita problemo estas ekster la influzono de la teamoj, aŭ la kompetenteco de kolegoj, kiuj eble jam renkontis similan problemon.

Tamen ni komprenas, ke por plurfoje akceli (kaj ĝuste ĉi tio estas la celo, kiun ni fiksis al ni mem), ni ankoraŭ bezonas multon lerni kaj efektivigi ĝin en nia ĉiutaga laboro. Ĝuste nun ni daŭre skalas nian produktan aliron al aliaj teamoj kaj novaj produktoj. Por fari tion, ni devis regi novan formaton por ni - interretan lernejon de metodikistoj.

Metodologoj, homoj, kiuj helpas teamojn konstrui procezon, establi komunikadojn kaj plibonigi laborefikecon, estas esence agentoj de ŝanĝo. Ĝuste nun, diplomiĝintoj de nia unua kohorto laboras kun teamoj kaj helpas ilin sukcesi. 

Mi pensas, ke la nuna situacio malfermas al ni ŝancojn kaj perspektivojn, pri kiuj eble ni mem ankoraŭ ne plene konscias. Sed la sperto kaj praktiko, kiujn ni akiras nun, konfirmas, ke ni elektis la ĝustan vojon de evoluo, ni ne maltrafos ĉi tiujn novajn ŝancojn en la estonteco kaj povos respondi same efike al la defioj, kiujn Sportmaster alfrontos.

trovoj

Dum ĉi tiu malfacila tempo, ni formulis la ĉefajn principojn, sur kiuj baziĝas programaro-disvolviĝo, kiuj, mi pensas, estos gravaj por ĉiu kompanio, kiu traktas ĉi tion.

personoj. Jen sur kio ĉio ripozas. Dungitoj devas ĝui sian laboron kaj kompreni la celojn de la kompanio kaj la celojn de la produktoj, pri kiuj ili laboras. Kaj, kompreneble, ili povus disvolvi profesie. 

Teknologio. Estas necese, ke la kompanio prenu maturan aliron por labori kun sia teknologia stako kaj konstrui kompetentecojn kie ĝi vere bezonas. Ĝi sonas tre simpla kaj evidenta. Kaj tre ofte ignorita.

Procezoj. Gravas taŭge organizi la laboron de produktteamoj kaj kompetentecaj centroj, establi interagadon kun la komerco por labori kun ĝi kiel partnero.

Ĝenerale, tiel ni travivis. La ĉefa tezo de nia tempo denove estis konfirmita, per sonora klako sur la frunto

Eĉ se vi estas grandega eksterreta komerco kun multaj vendejoj kaj amaso da urboj, kie vi funkcias, disvolvu vian interretan komercon. Ĉi tio ne estas nur plia venda kanalo aŭ bela aplikaĵo per kiu vi ankaŭ povas aĉeti ion (kaj ankaŭ ĉar konkurantoj ankaŭ havas belajn). Ĉi tio ne estas ĉiaokaze rezerva pneŭo por helpi vin elteni la ŝtormon.

Ĉi tio estas absoluta neceso. Por kio ne nur viaj teknikaj kapabloj kaj infrastrukturo devas esti pretaj, sed ankaŭ viaj homoj kaj procezoj. Post ĉio, vi povas rapide aĉeti plian memoron, spacon, disfaldi novajn okazojn ktp. en kelkaj horoj. Sed homoj kaj procezoj devas esti pretaj por ĉi tio anticipe.

fonto: www.habr.com