Lep pozdrav!
Moje ime je Mikhail, sem namestnik direktorja IT v podjetju Sportmaster. Želim deliti zgodbo o tem, kako smo se soočili z izzivi, ki so se pojavili med pandemijo.
V prvih dneh novih realnosti je običajna oblika trgovanja brez povezave Sportmaster zamrznila, obremenitev našega spletnega kanala, predvsem v smislu dostave na naslov stranke, pa se je povečala za 10-krat. V samo nekaj tednih smo velikansko offline poslovanje preoblikovali v spletno in storitev prilagodili potrebam naših strank.
V bistvu je tisto, kar je bilo v bistvu naša stranska dejavnost, postalo naša osnovna dejavnost. Pomen vsakega spletnega naročila se je izjemno povečal. Prihraniti je bilo treba vsak rubelj, ki ga je stranka prinesla podjetju.
Za hitro odzivanje na zahteve strank smo odprli dodatni kontaktni center na sedežu družbe, ki sedaj lahko sprejme približno 285 tisoč klicev na teden. Hkrati smo 270 trgovin prestavili na novo brezstično in varno obliko poslovanja, kar je strankam omogočilo sprejemanje naročil, zaposlenim pa ohranitev delovnih mest.
Med procesom transformacije smo naleteli na dve glavni težavi. Prvič, obremenitev naših spletnih virov se je znatno povečala (Sergey vam bo povedal, kako smo se s tem spopadli). Drugič, pretok redkih (pred COVID) operacij se je večkrat povečal, kar je posledično zahtevalo veliko količino hitre avtomatizacije. Da bi rešili to težavo, smo morali hitro prenesti sredstva s področij, ki so bila prej glavna. Elena vam bo povedala, kako smo se tega lotili.
Delovanje spletnih storitev
Kolesnikov Sergey, odgovoren za delovanje spletne trgovine in mikrostoritev
Od trenutka, ko so se naše maloprodajne trgovine začele zapirati za obiskovalce, smo začeli beležiti porast metrik, kot so število uporabnikov, število oddanih naročil v naši aplikaciji in število povpraševanj po aplikacijah.
Število naročil od 18. do 31Število zahtevkov za spletne plačilne mikrostoritveŠtevilo naročil, oddanih na spletni strani
V prvem grafu vidimo, da je bilo povečanje približno 14-krat, v drugem - 4-krat. Menimo, da je metrika odzivnega časa naših aplikacij najbolj indikativna.
V tem grafu vidimo odziv front in aplikacij, sami pa smo ugotovili, da rasti kot take nismo opazili.
To je predvsem posledica dejstva, da smo s pripravljalnimi deli pričeli konec leta 2019. Zdaj so naše storitve rezervirane, toleranca napak je zagotovljena na nivoju fizičnih strežnikov, virtualizacijskih sistemov, dockerjev in storitev v njih. Hkrati nam zmogljivost naših strežniških virov omogoča, da prenesemo več obremenitev.
Glavno orodje, ki nam je pomagalo pri vsej tej zgodbi, je bil naš nadzorni sistem. Res je, do nedavnega nismo imeli enotnega sistema, ki bi omogočal zbiranje metrik na vseh ravneh, od nivoja fizične opreme in strojne opreme do nivoja poslovnih metrik.
Formalno je nadzor v podjetju obstajal, vendar je bil praviloma razpršen in je bil v pristojnosti določenih oddelkov. Pravzaprav, ko se je zgodil incident, skoraj nikoli nismo imeli skupnega razumevanja, kaj se je točno zgodilo, ni bilo komunikacije in pogosto je to vodilo v tekanje v krogih, da bi našli in osamili težavo, da bi jo lahko odpravili.
V nekem trenutku smo pomislili in se odločili, da imamo dovolj tega prenašanja - potrebujemo enoten sistem, da bi videli celotno sliko v celoti. Glavne tehnologije, ki so vključene v naš sklad, so Zabbix kot center za opozarjanje in shranjevanje metrik, Prometheus za zbiranje in shranjevanje metrik aplikacij, Stack ELK za beleženje in shranjevanje podatkov iz celotnega nadzornega sistema, pa tudi Grafana za vizualizacijo, Swagger, Docker in druge koristne stvari, ki so vam znane.
Pri tem ne uporabljamo samo tehnologij, ki so na voljo na trgu, ampak razvijamo tudi nekaj lastnih. Izdelujemo na primer storitve za medsebojno integracijo sistemov, torej nekakšen API za zbiranje metrik. Poleg tega delamo na lastnih sistemih za spremljanje - na ravni poslovnih metrik uporabljamo teste uporabniškega vmesnika. In tudi bot v Telegramu za obveščanje ekip.
Prav tako poskušamo narediti nadzorni sistem dostopen ekipam, tako da lahko neodvisno shranjujejo in delajo s svojimi meritvami, vključno z nastavitvijo opozoril za nekatere ozke meritve, ki se ne uporabljajo široko.
V celotnem sistemu stremimo k proaktivnosti in čim hitrejši lokalizaciji incidentov. Poleg tega se je v zadnjem času močno povečalo število naših mikrostoritev in sistemov, temu primerno pa je naraslo tudi število integracij. In kot del optimizacije procesa diagnosticiranja incidentov na ravni integracije razvijamo sistem, ki vam omogoča izvajanje medsistemskih preverjanj in prikaz rezultatov, kar vam omogoča, da najdete glavne težave, povezane z uvozi in interakcijo sistemov z drug drugega.
Seveda pa imamo še prostor za rast in razvoj glede operacijskih sistemov in na tem aktivno delamo. Več o našem sistemu spremljanja lahko preberete .
Tehnični testi
Orlov Sergey, vodi kompetenčni center za spletni in mobilni razvoj
Od začetka zapiranja fizičnih trgovin smo se z razvojnega vidika soočali z različnimi izzivi. Prvič, val obremenitve kot tak. Jasno je, da če se ne sprejmejo ustrezni ukrepi, se lahko ob visoki obremenitvi sistema spremeni v bučo z žalostnim pokom ali popolnoma zmanjša zmogljivost ali celo izgubi svojo funkcionalnost.
Drugi vidik, nekoliko manj očiten, pa je, da je bilo treba sistem pod velikimi obremenitvami zelo hitro spreminjati in se prilagajati spremembam v poslovnih procesih. Včasih večkrat na dan. Veliko podjetij ima pravilo, da če je trženjskih aktivnosti veliko, ni treba spreminjati sistema. Nikakršne, naj dela, dokler deluje.
In v bistvu smo imeli neskončen črni petek, med katerim je bilo treba spremeniti sistem. Vsaka napaka, težava ali napaka v sistemu bi bila za podjetje zelo draga.
Če pogledam naprej, bom rekel, da smo se uspeli spopasti s temi testi, vsi sistemi so zdržali obremenitev, jih je bilo enostavno prilagoditi in nismo doživeli nobenih globalnih tehničnih napak.
Obstajajo štirje stebri, na katerih sloni sposobnost sistema, da prenese visoke udarne obremenitve. Prvi med njimi je spremljanje, o katerem ste prebrali tik zgoraj. Brez vgrajenega nadzornega sistema je skoraj nemogoče najti sistemska ozka grla. Dober nadzorni sistem je kot domača obleka, mora biti udoben in prilagojen vam.
Drugi vidik je testiranje. To točko jemljemo zelo resno: za vsak sistem pišemo klasične enote, integracijske teste, obremenitvene teste in številne druge. Pišemo tudi strategijo testiranja, hkrati pa skušamo povečati nivo testiranja do te mere, da ročnih preverjanj ne potrebujemo več.
Tretji steber je CI/CD Pipeline. Postopki gradnje, testiranja in uvajanja aplikacije morajo biti čim bolj avtomatizirani; ne sme biti nobenih ročnih posegov. Tema CI/CD Pipeline je precej globoka in se je bom dotaknil le na kratko. Omeniti velja le, da imamo kontrolni seznam CI/CD Pipeline, skozi katerega gre vsaka produktna ekipa s pomočjo kompetenčnih centrov.
In tukaj je kontrolni seznam
Na ta način se doseže veliko ciljev. To je različica API-ja in preklapljanje funkcij, da se izognete nizu izdaj in dosežete pokritost različnih testov na taki ravni, da je testiranje popolnoma avtomatizirano, uvedbe brezhibne itd.
Četrti steber so arhitekturni principi in tehnične rešitve. O arhitekturi lahko govorimo veliko časa, vendar želim poudariti nekaj principov, na katere bi se rad osredotočil.
Najprej morate izbrati specializirana orodja za določene naloge. Da, sliši se očitno in jasno je, da je treba žeblje zabijati s kladivom, ročne ure pa razstavljati s posebnimi izvijači. Toda v naši dobi si mnoga orodja prizadevajo za univerzalizacijo, da bi pokrila največji segment uporabnikov: baze podatkov, predpomnilnike, okvire in ostalo. Na primer, če vzamete bazo podatkov MongoDB, deluje s transakcijami z več dokumenti, baza podatkov Oracle pa deluje z json. In zdi se, da je vse mogoče uporabiti za vse. Toda če se zavzemamo za produktivnost, potem moramo jasno razumeti prednosti in slabosti vsakega orodja in uporabiti tista, ki jih potrebujemo za svoj razred nalog.
Drugič, pri načrtovanju sistemov je treba vsako povečanje kompleksnosti utemeljiti. To moramo stalno imeti v mislih, načelo nizkega povezovanja je znano vsem. Menim, da bi ga bilo treba uporabiti na ravni posamezne storitve, na ravni celotnega sistema in na ravni arhitekturne krajine. Pomembna je tudi možnost vodoravnega skaliranja vsake komponente sistema vzdolž poti obremenitve. Če imate to sposobnost, skaliranje ne bo težko.
Ko smo že pri tehničnih rešitvah, smo prosili produktne ekipe, da pripravijo svež nabor priporočil, idej in rešitev, ki so jih implementirali v pripravah na naslednji val delovne obremenitve.
Keshi
Zavestno je treba pristopiti k izbiri lokalnih in porazdeljenih predpomnilnikov. Včasih je smiselno uporabiti oboje znotraj istega sistema.Imamo na primer sisteme, v katerih so nekateri podatki v bistvu predpomnilnik, kar pomeni, da se vir posodobitev nahaja za samim sistemom in sistemi se ne spreminjajo. te podatke. Za ta pristop uporabljamo lokalni predpomnilnik kofeina.
In obstajajo podatki, ki jih sistem aktivno spreminja med delovanjem, in tukaj že uporabljamo porazdeljeni predpomnilnik s Hazelcastom. Ta pristop nam omogoča, da uporabimo prednosti porazdeljenega predpomnilnika, kjer so resnično potrebne, in zmanjšamo stroške storitev kroženja podatkov gruče Hazelcast, kjer lahko brez njih. O predpomnilnikih smo že veliko pisali. и .
Poleg tega nam je sprememba serializatorja v Kryo v Hazelcastu dala dober zagon. In prehod z ReplicatedMap na IMap + Near Cache v Hazelcastu nam je omogočil, da smo čim bolj zmanjšali pretok podatkov po gruči.
Majhen nasvet: v primeru množične razveljavitve predpomnilnika je včasih uporabna taktika segrevanja drugega predpomnilnika in nato preklopa nanj. Zdi se, da bi morali s tem pristopom dobiti dvojno porabo pomnilnika, vendar se je v praksi v tistih sistemih, kjer se je to izvajalo, poraba pomnilnika zmanjšala.
Reaktivni sklad
Reaktivni sklad uporabljamo v precej velikem številu sistemov. V našem primeru je to Webflux ali Kotlin s korutinami. Reaktivni sklad je še posebej dober tam, kjer pričakujemo počasne vhodno-izhodne operacije. Na primer klici počasnih storitev, delo z datotečnim sistemom ali sistemi za shranjevanje.
Najpomembnejše načelo je izogibanje blokiranju klicev. Reaktivna ogrodja imajo pod pokrovom majhno število aktivnih niti storitev. Če si neprevidno dovolimo, da izvedemo neposreden blokirajoči klic, kot je klic gonilnika JDBC, se bo sistem preprosto ustavil.
Poskusite spremeniti napake v lastno izjemo med izvajanjem. Dejanski tok izvajanja programa se premakne v reaktivna ogrodja in izvajanje kode postane nelinearno. Posledično je zelo težko diagnosticirati težave z uporabo sledi skladov. In rešitev tukaj bi bila ustvariti jasne, objektivne izjeme med izvajanjem za vsako napako.
Elastično iskanje
Ko uporabljate Elasticsearch, ne izberite neuporabljenih podatkov. To je načeloma tudi zelo preprost nasvet, a največkrat se na to pozabi. Če morate hkrati izbrati več kot 10 tisoč zapisov, morate uporabiti Scroll. Če uporabimo analogijo, je to nekoliko podobno kazalcu v relacijski bazi podatkov.
Ne uporabljajte postfiltra, razen če je to potrebno. Z velikimi podatki v glavnem vzorcu ta operacija močno obremeni bazo podatkov.
Uporabite množične operacije, kjer je to primerno.
API
Pri načrtovanju API-ja vključite zahteve za zmanjšanje prenesenih podatkov. To še posebej velja v povezavi s fronto: na tem stičišču presegamo kanale naših podatkovnih centrov in že delamo na kanalu, ki nas povezuje s stranko. Če ima najmanjšo težavo, prevelik promet povzroči negativno uporabniško izkušnjo.
In končno, ne vrzite celega kupa podatkov, bodite jasni glede pogodbe med potrošniki in dobavitelji.
Organizacijska transformacija
Eroshkina Elena, namestnica direktorja za IT
V trenutku, ko je nastopila karantena in potreba po strmem pospeševanju spletnega razvoja ter uvedbi večkanalnih storitev, smo bili že v procesu organizacijske transformacije.
Del naše strukture smo prenesli na delo po načelih in praksah produktnega pristopa. Oblikovane so ekipe, ki sedaj skrbijo za delovanje in razvoj posameznega produkta. Zaposleni v takšnih ekipah so 100-odstotno vključeni in strukturirajo svoje delo z uporabo Scrum ali Kanban, odvisno od tega, kaj jim je ljubše, vzpostavijo cevovod za uvajanje, izvajajo tehnične prakse, prakse zagotavljanja kakovosti in še veliko več.
Na srečo je bila večina naših produktnih ekip na področju spletnih in večkanalnih storitev. To nam je omogočilo, da smo v najkrajšem možnem času (resno, dobesedno v dveh dneh) preklopili na način dela na daljavo brez izgube učinkovitosti. Prilagojen proces nam je omogočil hitro prilagajanje novim delovnim razmeram in ohranjanje dokaj visokega tempa zagotavljanja novih funkcionalnosti.
Poleg tega moramo okrepiti tiste ekipe, ki so na meji spletnega poslovanja. V tistem trenutku je postalo jasno, da lahko to storimo le z notranjimi viri. Približno 50 ljudi je v dveh tednih zamenjalo področje, kjer so prej delali, in se vključilo v delo na zanje novega produkta.
To ni zahtevalo posebnih vodstvenih naporov, saj poleg organizacije lastnega procesa, tehničnega izboljševanja produkta in praks zagotavljanja kakovosti naše ekipe učimo samoorganiziranosti – vodenja lastnega proizvodnega procesa brez vključevanja administrativnih virov.
Naše upravljavske vire smo lahko usmerili točno tam, kjer je bilo v tistem trenutku potrebno – na usklajevanje s podjetjem: kaj je trenutno pomembno za našo stranko, katere funkcionalnosti je treba najprej implementirati, kaj je treba storiti, da povečamo našo prepustnost. za dostavo in obdelavo naročil. Vse to in jasen vzornik sta v tem obdobju omogočila, da smo proizvodne tokove vrednosti naložili s tistim, kar je res pomembno in potrebno.
Jasno je, da se pri delu na daljavo in visokem tempu sprememb, ko so poslovni kazalniki odvisni od sodelovanja vseh, ne gre zanašati le na interne občutke iz serije »Je pri nas vse v redu? Da, zdi se dobro." Potrebne so objektivne metrike proizvodnega procesa. Te imamo, na voljo so vsem, ki jih zanimajo metrike produktnih timov. Najprej sama ekipa, posel, podizvajalci in vodstvo.
Enkrat na dva tedna se z vsako ekipo izvede status, kjer se 10 minut analizirajo metrike, identificirajo ozka grla v proizvodnem procesu in razvije skupna rešitev: kaj je mogoče storiti za odpravo teh ozkih grl. Tukaj lahko nemudoma zaprosite za pomoč vodstvo, če je kakršna koli ugotovljena težava zunaj območja vpliva ekip, ali strokovno znanje sodelavcev, ki so se morda že srečali s podobno težavo.
Zavedamo pa se, da se moramo za večkratno pospešitev (in prav to je cilj, ki smo si ga zadali) še veliko naučiti in to implementirati v vsakodnevno delo. Trenutno še naprej širimo naš pristop k izdelku na druge ekipe in nove izdelke. Za to smo morali obvladati za nas novo obliko - spletno šolo metodikov.
Metodologi, ljudje, ki timom pomagajo zgraditi proces, vzpostaviti komunikacijo in izboljšati učinkovitost dela, so v bistvu nosilci sprememb. Prav zdaj diplomanti naše prve skupine delajo z ekipami in jim pomagajo postati uspešni.
Mislim, da nam trenutne razmere odpirajo priložnosti in obete, ki se jih morda sami še premalo zavedamo. A izkušnje in praksa, ki si jih nabiramo prav zdaj, potrjujejo, da smo izbrali pravo pot razvoja, novih priložnosti ne bomo zamudili tudi v prihodnje in se bomo lahko enako učinkovito odzvali na izzive, s katerimi se bo Sportmaster soočal.
Ugotovitve
V tem težkem času smo oblikovali glavna načela, na katerih temelji razvoj programske opreme, ki bodo po mojem mnenju pomembna za vsako podjetje, ki se s tem ukvarja.
Ljudje. Na tem vse sloni. Zaposleni morajo uživati v svojem delu in razumeti cilje podjetja ter cilje izdelkov, ki jih delajo. In seveda bi se lahko poklicno razvijali.
Технология. Nujno je, da podjetje zrelo pristopi k delu s svojim tehnološkim skladom in gradi kompetence tam, kjer je to res potrebno. Sliši se zelo preprosto in očitno. In zelo pogosto prezrt.
Procesi. Pomembno je pravilno organizirati delo produktnih timov in kompetenčnih centrov, vzpostaviti interakcijo s podjetjem, da bi z njim sodelovali kot partner.
Na splošno smo približno tako preživeli. Glavna teza našega časa se je znova potrdila, z odmevnim klikom na čelo
Tudi če ste ogromno offline podjetje s številnimi trgovinami in kupom mest, kjer poslujete, razvijajte svoje spletno poslovanje. To ni le dodaten prodajni kanal ali lepa aplikacija, preko katere lahko tudi kaj kupiš (pa tudi zato, ker imajo lepe tudi konkurenti). To ni rezervna guma za vsak primer, ki bi vam pomagala prebroditi nevihto.
To je absolutna nuja. Na kar morajo biti pripravljene ne le vaše tehnične zmogljivosti in infrastruktura, ampak tudi vaši ljudje in procesi. Navsezadnje lahko v nekaj urah hitro kupite dodaten pomnilnik, prostor, namestite nove primerke itd. A ljudi in procese je treba na to pripraviti vnaprej.
Vir: www.habr.com