Hi!
Nimeni on Mikhail, olen Sportmaster-yhtiön IT-osaston apulaisjohtaja. Haluan jakaa tarinan siitä, kuinka selvisimme pandemian aikana esiin tulleista haasteista.
Uusien realiteettien ensimmäisinä päivinä Sportmasterin tavanomainen offline-kaupankäyntimuoto jäätyi ja verkkokanavamme kuormitus, ensisijaisesti asiakkaan osoitteeseen toimittamisessa, kasvoi 10-kertaiseksi. Muutimme muutamassa viikossa jättimäisen offline-yrityksen online-yritykseksi ja mukautimme palvelun asiakkaidemme tarpeisiin.
Pohjimmiltaan sivutoiminnastamme tuli ydinliiketoimintamme. Jokaisen verkkotilauksen merkitys on kasvanut valtavasti. Oli tarpeen säästää jokainen rupla, jonka asiakas toi yritykselle.
Vastataksemme nopeasti asiakkaiden pyyntöihin avasimme ylimääräisen yhteyskeskuksen yrityksen pääkonttoriin, ja voimme nyt vastaanottaa noin 285 tuhatta puhelua viikossa. Samalla muutimme 270 myymälää uuteen kontaktittomaan ja turvalliseen toimintamuotoon, jonka ansiosta asiakkaat saivat tilauksia ja työntekijät pystyivät säilyttämään työpaikkansa.
Muutosprosessin aikana kohtasimme kaksi pääongelmaa. Ensinnäkin verkkoresursseidemme kuormitus on lisääntynyt merkittävästi (Sergey kertoo, kuinka käsittelimme tämän). Toiseksi harvinaisten (pre-COVID) toimintojen virta on moninkertaistunut, mikä puolestaan vaati suuren määrän nopeaa automatisointia. Tämän ongelman ratkaisemiseksi meidän piti siirtää nopeasti resursseja alueilta, jotka olivat aiemmin tärkeimpiä. Elena kertoo sinulle, kuinka käsitimme tämän.
Online-palvelujen käyttö
Kolesnikov Sergey, joka vastaa verkkokaupan ja mikropalvelujen toiminnasta
Siitä hetkestä lähtien, kun vähittäismyymälämme alkoivat sulkeutua vierailijoilta, aloimme kirjata kasvua mittareissa, kuten käyttäjämäärässä, sovelluksessamme tehtyjen tilausten määrässä ja sovellusten pyyntöjen määrässä.
Tilausten määrä 18. maaliskuuta - 31. maaliskuutaPyyntöjen määrä verkkomaksumikropalveluihinVerkkosivustolla tehtyjen tilausten määrä
Ensimmäisessä kaaviossa näemme, että kasvu oli noin 14-kertainen, toisessa - 4-kertainen. Pidämme sovelluksiemme vasteaikamittaria suuntaa antavimpana.
Tässä kaaviossa näemme rintamien ja sovellusten reaktion, ja itse päätimme, ettemme havainneet kasvua sellaisenaan.
Tämä johtuu ensisijaisesti siitä, että aloitimme valmistelutyöt vuoden 2019 lopussa. Nyt palvelumme on varattu, vikasietoisuus on varmistettu fyysisten palvelimien, virtualisointijärjestelmien, telakoiden ja niissä olevien palveluiden tasolla. Samalla palvelinresurssien kapasiteetti antaa meille mahdollisuuden kestää useita kuormituksia.
Päätyökalu, joka auttoi meitä koko tarinassa, oli valvontajärjestelmämme. Totta, aivan viime aikoihin asti meillä ei ollut yhtä järjestelmää, jonka avulla voisimme kerätä mittareita kaikilla tasoilla fyysisen laitteiston ja laitteiston tasosta liiketoiminnan mittareiden tasoon.
Muodollisesti yhtiössä oli valvontaa, mutta se oli pääsääntöisesti hajallaan ja kuului tiettyjen osastojen vastuualueeseen. Itse asiassa, kun tapaus tapahtui, meillä ei juuri koskaan ollut yhteistä ymmärrystä siitä, mitä tarkalleen tapahtui, ei ollut viestintää, ja usein tämä johti ympyröimiseen etsimään ja eristämään ongelmaa, jotta se voitaisiin korjata.
Jossain vaiheessa ajattelimme ja päätimme, että meillä riittää tämän kestämiseen - tarvitsimme yhtenäisen järjestelmän nähdäksemme kokonaisuuden kokonaisuudessaan. Tärkeimmät pinoamme sisältyvät teknologiat ovat Zabbix hälytys- ja mittaustietojen tallennuskeskuksena, Prometheus sovellusmittareiden keräämiseen ja tallentamiseen, Stack ELK koko valvontajärjestelmän tietojen kirjaamiseen ja tallentamiseen sekä Grafana visualisointiin, Swagger, Docker ja muuta hyödyllistä ja sinulle tuttua asiaa.
Samalla emme käytä vain markkinoilla olevia teknologioita, vaan kehitämme myös omaamme. Teemme esimerkiksi palveluita järjestelmien integroimiseksi toisiinsa, eli jonkinlaisen API:n mittareiden keräämiseen. Lisäksi kehitämme omia valvontajärjestelmiämme – liiketoimintamittareiden tasolla käytämme käyttöliittymätestejä. Ja myös botti Telegramissa, joka ilmoittaa joukkueille.
Pyrimme myös tuomaan seurantajärjestelmän saataville tiimeille, jotta he voivat itsenäisesti tallentaa ja työskennellä mittareiden kanssa, mukaan lukien hälytyksiä joillekin kapeille mittareille, joita ei käytetä laajalti.
Pyrimme koko järjestelmässä proaktiivisuuteen ja tapausten paikallistamiseen mahdollisimman nopeasti. Lisäksi mikropalveluidemme ja -järjestelmiemme määrä on viime aikoina kasvanut merkittävästi ja integraatioiden määrä on kasvanut vastaavasti. Ja osana tapausten diagnosointiprosessin optimointia integrointitasolla kehitämme järjestelmän, jonka avulla voit suorittaa järjestelmien välisiä tarkastuksia ja näyttää tuloksen, jonka avulla voit löytää tärkeimmät tuontiin ja järjestelmien vuorovaikutukseen liittyvät ongelmat. toisiaan.
Käyttöjärjestelmien osalta meillä on toki vielä tilaa kasvaa ja kehittyä, ja sen eteen teemme aktiivisesti töitä. Voit lukea lisää valvontajärjestelmästämme .
Tekniset testit
Orlov Sergey johtaa verkko- ja mobiilikehityksen osaamiskeskusta
Fyysisten myymälöiden sulkemisten alkamisen jälkeen olemme kohdanneet erilaisia haasteita kehityksen näkökulmasta. Ensinnäkin kuormitusaalto sellaisenaan. On selvää, että jos asianmukaisia toimenpiteitä ei ryhdytä, niin kun järjestelmään kohdistuu suuri kuormitus, se voi muuttua kurpitsaksi surullisen pamauksen kanssa tai heikentää suorituskykyä kokonaan tai jopa menettää toiminnallisuutensa.
Toinen hieman vähemmän ilmeinen näkökohta on se, että suuren kuormituksen alaisena olevaa järjestelmää täytyi muuttaa erittäin nopeasti mukautuen liiketoimintaprosessien muutoksiin. Joskus useita kertoja päivässä. Monissa yrityksissä on sääntö, että jos markkinointitoimintaa on paljon, järjestelmään ei tarvitse tehdä muutoksia. Ei ollenkaan, anna sen toimia niin kauan kuin se toimii.
Ja meillä oli pohjimmiltaan loputon Black Friday, jonka aikana oli tarpeen muuttaa järjestelmää. Ja mikä tahansa virhe, ongelma tai vika järjestelmässä olisi erittäin kallista yritykselle.
Tulevaisuudessa sanon, että onnistuimme selviytymään näistä testeistä, kaikki järjestelmät kestivät kuormituksen, skaalautuivat helposti, emmekä kokeneet globaaleja teknisiä vikoja.
Järjestelmässä on neljä pilaria, joiden varassa järjestelmän kyky kestää suuria ylijännitekuormia. Ensimmäinen niistä on seuranta, josta luit juuri edellä. Ilman sisäänrakennettua valvontajärjestelmää on lähes mahdotonta löytää järjestelmän pullonkauloja. Hyvä seurantajärjestelmä on kuin kodin vaatteet; sen tulee olla mukava ja räätälöity sinulle.
Toinen näkökohta on testaus. Otamme tämän asian erittäin vakavasti: kirjoitamme klassisia yksiköitä, integraatiotestejä, kuormitustestejä ja monia muita jokaiselle järjestelmälle. Kirjoitamme myös testausstrategiaa ja samalla yritämme nostaa testauksen tasoa siihen pisteeseen, että emme enää tarvitse manuaalisia tarkastuksia.
Kolmas pilari on CI/CD Pipeline. Sovelluksen rakentamis-, testaus- ja käyttöönottoprosessit tulee automatisoida mahdollisimman pitkälle, eikä manuaalisia toimenpiteitä pitäisi tehdä. CI/CD Pipelinen aihe on melko syvällinen, ja käsittelen sitä vain lyhyesti. On vain syytä mainita, että meillä on CI/CD Pipeline -tarkistuslista, jonka jokainen tuotetiimi käy läpi osaamiskeskusten avulla.
Ja tässä on tarkistuslista
Tällä tavalla saavutetaan monia tavoitteita. Tämä on API-version ja ominaisuuksien vaihto, jolla vältetään julkaisujuna ja saavutetaan erilaisten testien kattavuus sellaisella tasolla, että testaus on täysin automatisoitua, käyttöönotot ovat saumattomia ja niin edelleen.
Neljäs pilari on arkkitehtoniset periaatteet ja tekniset ratkaisut. Arkkitehtuurista voidaan puhua paljon pitkään, mutta haluan korostaa paria periaatetta, joihin haluaisin keskittyä.
Ensin sinun on valittava erikoistyökalut tiettyihin tehtäviin. Kyllä, se kuulostaa itsestään selvältä, ja on selvää, että naulat tulee lyödä vasaralla ja rannekellot purkaa erityisillä ruuvimeisselillä. Mutta meidän aikakaudellamme monet työkalut pyrkivät universaalisointiin kattaakseen suurimman osan käyttäjistä: tietokannat, välimuistit, puitteet ja muut. Jos otat esimerkiksi MongoDB-tietokannan, se toimii usean asiakirjan tapahtumien kanssa ja Oracle-tietokanta toimii jsonin kanssa. Ja näyttää siltä, että kaikkea voidaan käyttää kaikkeen. Mutta jos kannatamme tuottavuutta, meidän on ymmärrettävä selvästi kunkin työkalun vahvuudet ja heikkoudet ja käytettävä niitä, joita tarvitsemme luokkamme tehtäviin.
Toiseksi järjestelmiä suunniteltaessa jokainen monimutkaisuuden lisäys on perusteltava. Tämä on pidettävä jatkuvasti mielessä, matalan kytkennän periaate on kaikkien tiedossa. Mielestäni sitä tulisi soveltaa tietyn palvelun tasolla ja koko järjestelmän tasolla ja arkkitehtuurimaiseman tasolla. Tärkeää on myös mahdollisuus skaalata jokainen järjestelmäkomponentti vaakasuunnassa kuormitusreitin varrella. Jos sinulla on tämä kyky, skaalaus ei ole vaikeaa.
Teknisistä ratkaisuista puheen ollen pyysimme tuotetiimejä valmistelemaan tuoreita suosituksia, ideoita ja ratkaisuja, jotka he toteuttivat valmistautuessaan seuraavaan työtaakka-aaltoon.
Keshi
On välttämätöntä lähestyä tietoisesti paikallisten ja hajautettujen välimuistien valintaa. Joskus on järkevää käyttää molempia saman järjestelmän sisällä.. Meillä on esimerkiksi järjestelmiä, joissa osa tiedoista on olennaisesti esittelyvälimuistia, eli päivityslähde sijaitsee itse järjestelmän takana, eivätkä järjestelmät muutu. tämä data. Tätä lähestymistapaa varten käytämme paikallista kofeiinivälimuistia.
Ja on tietoja, joita järjestelmä muuttaa aktiivisesti toiminnan aikana, ja täällä käytämme jo hajautettua välimuistia Hazelcastin kanssa. Tämän lähestymistavan avulla voimme käyttää hajautetun välimuistin etuja siellä, missä niitä todella tarvitaan, ja minimoida Hazelcast-klusteridatan kierrättämisen palvelukustannukset siellä, missä voimme tehdä ilman sitä. Olemme kirjoittaneet paljon välimuistista. и .
Lisäksi serialisoinnin vaihtaminen Kryoon Hazelcastissa antoi meille hyvän sysäyksen. Ja siirtyminen ReplicatedMapista IMap + Near Cacheen Hazelcastissa antoi meille mahdollisuuden minimoida tietojen liikkumisen klusterin poikki.
Pieni neuvo: massavälimuistin mitätöinnin tapauksessa taktiikkaa lämmittää toinen välimuisti ja sitten vaihtaa siihen voidaan joskus soveltaa. Näyttäisi siltä, että tällä lähestymistavalla meidän pitäisi saada kaksinkertainen muistinkulutus, mutta käytännössä niissä järjestelmissä, joissa tätä harjoitettiin, muistin kulutus väheni.
Reaktiivinen pino
Käytämme reaktiivista pinoa melko monissa järjestelmissä. Meidän tapauksessamme tämä on Webflux tai Kotlin korutiinien kanssa. Reaktiivinen pino on erityisen hyvä siellä, missä odotamme hitaita syöttö-lähtötoimintoja. Esimerkiksi kutsut hidastaviin palveluihin, työskentely tiedostojärjestelmän tai tallennusjärjestelmien kanssa.
Tärkein periaate on välttää puheluiden estämistä. Reaktiivisissa kehyksissä on pieni määrä reaaliaikaisia palvelusäikeitä käynnissä konepellin alla. Jos annamme itsellemme huolimattomasti tehdä suoran estopuhelun, kuten JDBC-ohjainpuhelun, järjestelmä yksinkertaisesti pysähtyy.
Yritä muuttaa virheet omaksi ajonaikaiseksi poikkeukseksi. Todellinen ohjelman suoritusvirta siirtyy reaktiivisiin kehyksiin, ja koodin suorittamisesta tulee epälineaarista. Tämän seurauksena on erittäin vaikeaa diagnosoida ongelmia pinojälkien avulla. Ja ratkaisu tähän olisi luoda selkeät, objektiiviset ajonaikaiset poikkeukset jokaiselle virheelle.
Elasticsearch
Kun käytät Elasticsearchia, älä valitse käyttämättömiä tietoja. Tämä on periaatteessa myös hyvin yksinkertainen neuvo, mutta useimmiten tämä unohdetaan. Jos sinun on valittava yli 10 tuhatta tietuetta kerralla, sinun on käytettävä Scrollia. Analogiaa käyttääkseni se on vähän kuin kohdistin relaatiotietokannassa.
Älä käytä jälkisuodatinta, ellei se ole välttämätöntä. Kun päänäytteessä on paljon dataa, tämä toiminto kuormittaa tietokantaa suuresti.
Käytä tarvittaessa joukkotoimintoja.
API
Kun suunnittelet API:ta, sisällytä vaatimukset siirrettävien tietojen minimoimiseksi. Tämä pätee erityisesti rintaman yhteydessä: juuri tässä risteyksessä menemme datakeskustemme kanavien ulkopuolelle ja työstämme jo kanavaa, joka yhdistää meidät asiakkaaseen. Jos siinä on pieninkin ongelma, liian suuri liikenne aiheuttaa negatiivisen käyttökokemuksen.
Ja lopuksi, älä heitä ulos koko joukkoa tietoja, vaan ole selkeä kuluttajien ja toimittajien välisestä sopimuksesta.
Organisaation muutos
Eroshkina Elena, IT-osaston apulaisjohtaja
Sillä hetkellä, kun karanteeni koitui ja tarve nostaa verkkokehityksen vauhtia jyrkästi ja ottaa käyttöön monikanavaiset palvelut, olimme jo organisaatiomuutosprosessissa.
Osa rakenteestamme siirrettiin työhön tuotelähestymistavan periaatteiden ja käytäntöjen mukaisesti. On muodostettu tiimejä, jotka vastaavat nyt kunkin tuotteen toiminnasta ja kehittämisestä. Tällaisten ryhmien työntekijät ovat 100-prosenttisesti mukana ja organisoivat työnsä Scrumilla tai Kanbanilla sen mukaan, mikä heille on parempi, käyttöönottoputkiston perustaminen, teknisten käytäntöjen käyttöönotto, laadunvarmistuskäytännöt ja paljon muuta.
Onneksi suurin osa tuotetiimeistämme oli verkko- ja monikanavaisten palvelujen alueella. Tämän ansiosta pystyimme siirtymään etätyötilaan mahdollisimman lyhyessä ajassa (vakavasti, kirjaimellisesti kahdessa päivässä) tehokkuuden menettämättä. Räätälöidyn prosessin ansiosta pystyimme nopeasti sopeutumaan uusiin työolosuhteisiin ja ylläpitämään uusien toimintojen toimitustahtia melko korkealla.
Lisäksi meillä on tarve vahvistaa niitä tiimejä, jotka ovat verkkoliiketoiminnan eturintamassa. Sillä hetkellä kävi selväksi, että voimme tehdä tämän vain käyttämällä sisäisiä resursseja. Ja noin 50 ihmistä kahdessa viikossa vaihtoi alaa, jolla he työskentelivät aiemmin, ja ryhtyivät työskentelemään heille uuden tuotteen parissa.
Tämä ei vaatinut erityisiä johtamisponnisteluja, sillä oman prosessimme organisoinnin, tuotteen teknisen parantamisen ja laadunvarmistuskäytäntöjen ohella opetamme tiimimme itseorganisoitumaan – hallitsemaan omaa tuotantoprosessiaan ilman hallinnollisia resursseja.
Pystyimme keskittämään johtamisresurssimme juuri sinne, missä sitä sillä hetkellä tarvittiin - koordinointiin yhdessä liiketoiminnan kanssa: Mikä on asiakkaallemme juuri nyt tärkeää, mitkä toiminnot tulisi ottaa käyttöön ensin, mitä pitää tehdä suorituskyvyn parantamiseksi toimittaa ja käsitellä tilauksia. Kaikki tämä ja selkeä roolimalli mahdollistivat tänä aikana tuotannon arvovirroihimme lataamisen sillä, mikä on todella tärkeää ja tarpeellista.
On selvää, että etätyöllä ja nopealla muutosvauhdilla, kun liiketoiminnan indikaattorit riippuvat kaikkien osallistumisesta, ei voi luottaa vain sisäisiin tunteisiin sarjasta ”Onko meillä kaikki hyvin? Kyllä näyttää hyvältä." Tuotantoprosessin objektiivisia mittareita tarvitaan. Meillä on näitä, ne ovat kaikkien tuotetiimien mittareista kiinnostuneiden saatavilla. Ensinnäkin tiimi itse, liiketoiminta, alihankkijat ja johto.
Kahden viikon välein jokaisen tiimin kanssa pidetään status, jossa mittarit analysoidaan 10 minuutin ajan, kartoitetaan tuotantoprosessin pullonkaulat ja kehitetään yhteinen ratkaisu: mitä voidaan tehdä näiden pullonkaulojen poistamiseksi. Täällä voit kysyä heti apua johdolta, jos jokin havaittu ongelma on tiimien vaikutusalueen ulkopuolella tai vastaavien jo törmänneiden kollegoiden asiantuntemusta.
Ymmärrämme kuitenkin, että kiihdyttääksemme useita kertoja (ja tämä on juuri se tavoite, jonka asetamme itsellemme), meidän on silti opittava paljon ja otettava se käyttöön päivittäisessä työssämme. Tällä hetkellä jatkamme tuotelähestymistapamme skaalaamista muihin tiimeihin ja uusiin tuotteisiin. Tätä varten meidän oli hallittava meille uusi muoto - metodologien verkkokoulu.
Metodologit, ihmiset, jotka auttavat tiimejä rakentamaan prosessia, luomaan viestintää ja parantamaan työn tehokkuutta, ovat pohjimmiltaan muutoksen tekijöitä. Tällä hetkellä ensimmäisen kohorttimme valmistuneet työskentelevät tiimien kanssa ja auttavat heitä menestymään.
Uskon, että nykyinen tilanne avaa meille mahdollisuuksia ja näkymiä, joita emme ehkä itse ole vielä täysin tietoisia. Mutta nyt saamamme kokemukset ja käytännöt vahvistavat, että olemme valinneet oikean kehityspolun, emme missaa näitä uusia mahdollisuuksia tulevaisuudessa ja pystymme vastaamaan yhtä tehokkaasti Sportmasterin kohtaamiin haasteisiin.
Tulokset
Tänä vaikeana aikana olemme muotoilleet ohjelmistokehityksen pääperiaatteet, jotka mielestäni tulevat koskemaan jokaista tätä asiaa käsittelevää yritystä.
Ihmiset. Tähän kaikki perustuu. Työntekijöiden tulee nauttia työstään ja ymmärtää yrityksen tavoitteet ja tuotteiden tavoitteet. Ja tietysti he voisivat kehittyä ammatillisesti.
Технология. Yrityksen on omaksuttava kypsä lähestymistapa työskentelyyn teknologiapinon kanssa ja rakentaa osaamista siellä, missä sitä todella tarvitaan. Se kuulostaa hyvin yksinkertaiselta ja ilmeiseltä. Ja hyvin usein huomiotta.
prosessit. Tärkeää on organisoida tuotetiimien ja osaamiskeskusten työ kunnolla, luoda vuorovaikutusta yrityksen kanssa voidakseen toimia sen kanssa kumppanina.
Yleisesti ottaen selvisimme pitkälti näin. Aikamme pääteesi vahvistui jälleen kerran, kova napsahdus otsassa
Vaikka sinulla olisi valtava offline-liiketoiminta, jolla on monia kauppoja ja joukko kaupunkeja, joissa toimit, kehitä online-liiketoimintaasi. Tämä ei ole vain lisämyyntikanava tai kaunis sovellus, jonka kautta voit myös ostaa jotain (ja myös siksi, että kilpailijoilla on myös kauniita). Tämä ei ole joka tapauksessa vararengas, joka auttaa sinua selviytymään myrskystä.
Tämä on ehdottoman välttämätöntä. Mihin ei vain sinun on valmistauduttava teknisten kykyjesi ja infrastruktuurisi, vaan myös henkilöstösi ja prosessisi. Loppujen lopuksi voit ostaa nopeasti lisää muistia, tilaa, ottaa käyttöön uusia esiintymiä jne. muutamassa tunnissa. Mutta ihmisten ja prosessien on valmistauduttava tähän etukäteen.
Lähde: will.com