Tere!
Minu nimi on Mihhail, olen ettevõtte Sportmaster IT asedirektor. Tahan jagada lugu sellest, kuidas tulime toime pandeemia ajal tekkinud väljakutsetega.
Uue reaalsuse esimestel päevadel külmus tavaline Sportmasteri võrguühenduseta kauplemisvorming ja meie veebikanali koormus, eelkõige kliendi aadressile tarnimise osas, kasvas 10 korda. Vaid mõne nädalaga muutsime hiiglasliku võrguühenduseta ettevõtte veebipõhiseks ja kohandasime teenust oma klientide vajadustega.
Põhimõtteliselt sai meie põhitegevusest see, mis oli sisuliselt meie kõrvaltegevus. Iga veebitellimuse tähtsus on tohutult kasvanud. Säästa oli vaja iga rubla, mille klient firmasse tõi.
Kliendipäringutele kiireks vastamiseks avasime ettevõtte peakontoris täiendava kontaktkeskuse, millega saame nüüd vastu võtta umbes 285 tuhat kõnet nädalas. Samal ajal kolisime 270 kauplust uude kontaktivabale ja turvalisele töövormingule, mis võimaldas klientidel tellimusi vastu võtta ja töötajatel töökohti säilitada.
Ümberkujundamise käigus puutusime kokku kahe peamise probleemiga. Esiteks on meie veebiressursside koormus märkimisväärselt suurenenud (Sergei räägib teile, kuidas me sellega hakkama saime). Teiseks on haruldaste (COVID-eelsete) toimingute voog kordades kasvanud, mis omakorda nõudis suurt kiiret automatiseerimist. Selle probleemi lahendamiseks pidime kiiresti üle kandma ressursse valdkondadest, mis olid varem peamised. Elena räägib teile, kuidas me sellega hakkama saime.
Sidusteenuste kasutamine
Kolesnikov Sergei, vastutab veebipoe ja mikroteenuste toimimise eest
Alates hetkest, kui meie jaekauplused hakkasid külastajatele sulgema, hakkasime registreerima selliste näitajate kasvu nagu kasutajate arv, meie rakenduses tehtud tellimuste arv ja rakenduste päringute arv.
Tellimuste arv 18. märtsist 31. märtsiniVeebimaksete mikroteenuste taotluste arvVeebilehel tehtud tellimuste arv
Esimesel graafikul näeme, et kasv oli ligikaudu 14 korda, teisel - 4 korda. Peame oma rakenduste reageerimisaja mõõdikut kõige indikatiivsemaks.
Sellel graafikul näeme rinnete ja rakenduste vastust ning tegime enda jaoks kindlaks, et me ei märganud kasvu kui sellist.
Selle põhjuseks on eelkõige asjaolu, et alustasime ettevalmistustöödega 2019. aasta lõpus. Nüüd on meie teenused reserveeritud, tõrketaluvus on tagatud füüsiliste serverite, virtualiseerimissüsteemide, dokkerite ja neis olevate teenuste tasemel. Samas võimaldab meie serveriressursside võimsus taluda mitut koormust.
Peamine tööriist, mis meid kogu selle loo juures aitas, oli meie seiresüsteem. Tõsi, veel üsna hiljuti polnud meil ühtset süsteemi, mis võimaldaks koguda mõõdikuid kõigil kihtidel, alates füüsilise varustuse ja riistvara tasemest kuni ärimõõdikute tasemeni.
Formaalselt oli ettevõttes järelevalve, kuid reeglina oli see hajutatud ja kuulus konkreetsete osakondade vastutusalasse. Tegelikult, kui juhtus juhtum, ei olnud meil peaaegu kunagi ühtset arusaama sellest, mis täpselt juhtus, puudus suhtlus ja sageli põhjustas see ringi jooksmise, et probleem leida ja isoleerida, et seda saaks parandada.
Mingil hetkel mõtlesime ja otsustasime, et meil on selle talumisest küllalt – vajame ühtset süsteemi, et näha tervikpilti täies mahus. Peamised meie virnas sisalduvad tehnoloogiad on Zabbix hoiatus- ja mõõdikute salvestuskeskusena, Prometheus rakenduste mõõdikute kogumiseks ja salvestamiseks, Stack ELK kogu seiresüsteemi andmete logimiseks ja salvestamiseks, samuti Grafana visualiseerimiseks, Swagger, Docker ja muud kasulikku ja teile tuttavat.
Samal ajal ei kasuta me mitte ainult turul saadaolevaid tehnoloogiaid, vaid arendame ka mõnda enda oma. Näiteks teeme teenuseid süsteemide omavaheliseks integreerimiseks ehk mingi API mõõdikute kogumiseks. Lisaks töötame oma seiresüsteemide kallal – ärimõõdikute tasemel kasutame kasutajaliidese teste. Ja ka bot Telegramis, et meeskondi teavitada.
Samuti püüame teha seiresüsteemi juurdepääsetavaks meeskondadele, et nad saaksid iseseisvalt oma mõõdikuid salvestada ja nendega töötada, sealhulgas seadistada hoiatusi mõne kitsa mõõdiku kohta, mida laialdaselt ei kasutata.
Kogu süsteemis püüdleme proaktiivsuse ja juhtumite võimalikult kiire lokaliseerimise poole. Lisaks on viimasel ajal oluliselt kasvanud meie mikroteenuste ja süsteemide arv ning vastavalt kasvanud ka integratsioonide arv. Integratsioonitasemel intsidentide diagnoosimise protsessi optimeerimise osana töötame välja süsteemi, mis võimaldab teil läbi viia süsteemiüleseid kontrolle ja kuvada tulemust, mis võimaldab teil leida peamised probleemid, mis on seotud impordi ja süsteemide interaktsiooniga. üksteist.
Muidugi on meil operatsioonisüsteemide osas veel ruumi kasvada ja areneda ning me tegeleme sellega aktiivselt. Lisateavet meie seiresüsteemi kohta saate lugeda .
Tehnilised testid
Orlov Sergey juhib veebi- ja mobiiliarenduse kompetentsikeskust
Alates füüsiliste poodide sulgemiste algusest oleme arengu vaatenurgast silmitsi seisnud erinevate väljakutsetega. Esiteks koormuse tõus kui selline. On selge, et kui asjakohaseid meetmeid ei võeta, võib see süsteemi suure koormuse korral muutuda kurva pauguga kõrvitsaks või jõudluses täielikult halveneda või isegi oma funktsionaalsuse kaotada.
Teine, veidi vähem ilmne aspekt on see, et suure koormuse all olevat süsteemi tuli väga kiiresti muuta, kohanedes äriprotsesside muutustega. Mõnikord mitu korda päevas. Paljudes ettevõtetes kehtib reegel, et kui turundustegevust on palju, siis pole vaja süsteemis muudatusi teha. Üldse mitte ühtegi, las töötab nii kaua, kuni töötab.
Ja meil oli sisuliselt lõputu must reede, mille jooksul oli vaja süsteemi muuta. Ja mis tahes viga, probleem või rike süsteemis oleks ettevõttele väga kulukas.
Tulevikku vaadates ütlen, et saime nende testidega hakkama, kõik süsteemid pidasid koormust vastu, olid kergesti skaleeritavad ja globaalseid tehnilisi rikkeid meil ei esinenud.
Seal on neli tugisammast, millel toetub süsteemi võime taluda suuri liigkoormusi. Esimene neist on monitooring, mille kohta lugesite ülalt. Ilma sisseehitatud seiresüsteemita on peaaegu võimatu leida süsteemi kitsaskohti. Hea jälgimissüsteem on nagu koduriided; see peaks olema mugav ja teie jaoks kohandatud.
Teine aspekt on testimine. Võtame seda punkti väga tõsiselt: kirjutame iga süsteemi jaoks klassikalised ühikud, integratsioonitestid, koormustestid ja palju muud. Kirjutame ka testimisstrateegiat ja samal ajal proovime tõsta testimise taset nii kaugele, et me ei vaja enam käsitsi kontrollimist.
Kolmas sammas on CI/CD Pipeline. Rakenduse loomise, testimise ja juurutamise protsessid tuleks võimalikult palju automatiseerida, käsitsi sekkumist ei tohiks teha. CI/CD Pipeline'i teema on üsna sügav ja puudutan seda vaid põgusalt. Tasub vaid mainida, et meil on CI/CD Pipeline'i kontrollnimekiri, mille iga tootetiim kompetentsikeskuste abiga läbib.
Ja siin on kontrollnimekiri
Nii saavutatakse palju eesmärke. See on API versioonide ja funktsioonide lüliti, et vältida väljalaskerongi ning saavutada erinevate testide katvus sellisel tasemel, et testimine on täielikult automatiseeritud, juurutamine sujuv ja nii edasi.
Neljas sammas on arhitektuursed põhimõtted ja tehnilised lahendused. Arhitektuurist võib rääkida palju pikalt, kuid tahan rõhutada paari põhimõtet, millele tahaksin keskenduda.
Esiteks peate konkreetsete ülesannete jaoks valima spetsiaalsed tööriistad. Jah, see kõlab ilmselgelt ja on selge, et naelad tuleks lüüa haamriga ja käekellad lahti võtta spetsiaalsete kruvikeerajatega. Kuid meie ajastul püüdlevad paljud tööriistad universaalsuse poole, et katta kasutajate maksimaalne segment: andmebaasid, vahemälud, raamistikud ja muu. Näiteks kui võtate MongoDB andmebaasi, töötab see mitme dokumendiga tehingutega ja Oracle'i andmebaas töötab jsoniga. Ja tundub, et kõike saab kasutada kõige jaoks. Aga kui me seisame tootlikkuse eest, siis peame selgelt mõistma iga tööriista tugevaid ja nõrku külgi ning kasutama neid, mida oma ülesannete klassis vajame.
Teiseks, süsteemide projekteerimisel peab iga keerukuse suurenemine olema põhjendatud. Peame seda pidevalt meeles pidama, madala sidumise põhimõte on kõigile teada. Usun, et seda tuleks rakendada konkreetse teenuse tasandil ja kogu süsteemi tasandil ning arhitektuurse maastiku tasandil. Oluline on ka võimalus horisontaalselt skaleerida iga süsteemi komponenti piki koormusteed. Kui teil on see võime, pole skaleerimine keeruline.
Tehnilistest lahendustest rääkides palusime tootemeeskondadel koostada värske komplekti soovitusi, ideid ja lahendusi, mida nad järgmiseks töökoormuse laineks valmistudes ellu viisid.
Keshi
Kohaliku ja hajutatud vahemälu valikule tuleb teadlikult läheneda. Mõnikord on mõttekas kasutada mõlemat sama süsteemi sees.Näiteks on meil süsteeme, kus osa andmetest on sisuliselt esitletud vahemälu ehk uuenduste allikas asub süsteemi enda taga ja süsteemid ei muutu. need andmed. Selle lähenemisviisi jaoks kasutame kohalikku kofeiini vahemälu.
Ja on andmeid, mida süsteem töötamise ajal aktiivselt muutub, ja siin kasutame juba Hazelcastiga hajutatud vahemälu. See lähenemisviis võimaldab meil kasutada hajutatud vahemälu eeliseid seal, kus neid tõesti vaja on, ja minimeerida Hazelcasti klastri andmete levitamise teenusekulusid seal, kus saame ilma selleta hakkama. Oleme vahemäludest palju kirjutanud. и .
Lisaks andis meile korraliku tõuke serialiseerija vahetamine Kryo vastu Hazelcastis. Ja üleminek ReplicatedMapilt IMap + Near Cache'ile Hazelcastis võimaldas meil minimeerida andmete liikumist klastri vahel.
Väike nõuanne: massvahemälu kehtetuks tunnistamise korral on mõnikord rakendatav taktika soojendada teine vahemälu ja seejärel sellele üle minna. Näib, et selle lähenemisviisiga peaksime saama kahekordse mälutarbimise, kuid praktikas nendes süsteemides, kus seda praktiseeriti, mälutarbimine vähenes.
Reaktiivne virn
Me kasutame reaktiivset pinu üsna paljudes süsteemides. Meie puhul on selleks Webflux või Kotlin koos korutiinidega. Reaktiivne pinu on eriti hea seal, kus eeldame aeglaseid sisend-väljundoperatsioone. Näiteks kõned aeglastele teenustele, töö failisüsteemi või salvestussüsteemidega.
Kõige olulisem põhimõte on vältida kõnede blokeerimist. Reaktiivsetel raamistikel on katte all väike arv reaalajas teenuselõime. Kui lubame endale ettevaatamatult teha otsese blokeeriva kõne, näiteks JDBC draiveri kõne, siis süsteem lihtsalt seiskub.
Proovige muuta vead oma käitusaja erandiks. Programmi täitmise tegelik voog nihkub reaktiivsetele raamistikele ja koodi täitmine muutub mittelineaarseks. Seetõttu on virnajälgede abil probleeme väga raske diagnoosida. Ja siin oleks lahendus luua iga vea jaoks selged objektiivsed käitusaja erandid.
Elasticsearch
Elasticsearchi kasutamisel ärge valige kasutamata andmeid. See on põhimõtteliselt ka väga lihtne nõuanne, kuid enamasti unustatakse see ära. Kui teil on vaja korraga valida rohkem kui 10 tuhat kirjet, peate kasutama Scrolli. Kui kasutada analoogiat, siis see on natuke nagu kursor relatsiooniandmebaasis.
Ärge kasutage järelfiltrit, kui see pole vajalik. Kui põhivalimis on palju andmeid, koormab see toiming andmebaasi oluliselt.
Kasutage vajaduse korral hulgioperatsioone.
API
API kavandamisel lisage edastatavate andmete minimeerimise nõuded. Seda eriti seoses esiosaga: just sellel ristmikul läheme oma andmekeskuste kanalitest kaugemale ja töötame juba kanali kallal, mis meid kliendiga ühendaks. Kui sellel on vähimgi probleem, põhjustab liiga suur liiklus negatiivse kasutajakogemuse.
Ja lõpuks, ärge visake välja tervet hunnikut andmeid, olge tarbijate ja tarnijate vahelise lepingu osas selge.
Organisatsiooniline ümberkujundamine
Eroshkina Jelena, IT asedirektor
Sel hetkel, kui tuli karantiin ja tekkis vajadus veebiarenduse tempot järsult tõsta ja omnikanaliteenuseid kasutusele võtta, oli meil juba käimas organisatsiooniline ümberkujundamine.
Osa meie struktuurist viidi tööle tootepõhise lähenemise põhimõtete ja tavade järgi. Moodustatud on meeskonnad, kes nüüd vastutavad iga toote toimimise ja arendamise eest. Sellistes meeskondades töötavad töötajad on 100% kaasatud ja struktureerivad oma tööd Scrumi või Kanbani abil, olenevalt sellest, mis neile eelistatakse, juurutustorustiku seadistamist, tehniliste tavade rakendamist, kvaliteedi tagamise tavasid ja palju muud.
Õnneks oli suurem osa meie tootetiimidest võrgu- ja mitmekanaliliste teenuste valdkonnas. See võimaldas meil lülituda kaugtöörežiimile võimalikult lühikese aja jooksul (tõsiselt, sõna otseses mõttes kahe päevaga) ilma tõhusust kaotamata. Kohandatud protsess võimaldas meil kiiresti kohaneda uute töötingimustega ja säilitada uute funktsioonide tarnimise üsna kõrge tempo.
Lisaks peame tugevdama neid meeskondi, kes on veebiäri eesliinil. Sel hetkel sai selgeks, et saame seda teha vaid sisemisi ressursse kasutades. Ja umbes 50 inimest vahetasid kahe nädala jooksul valdkonda, kus nad varem töötasid, ja osalesid nende jaoks uue toote kallal.
See ei nõudnud erilisi juhtimispingutusi, sest koos oma protsessi korraldamise, toote tehnilise täiustamise ja kvaliteedi tagamise praktikatega õpetame oma meeskondi ise organiseeruma – juhtima oma tootmisprotsessi ilma haldusressursse kaasamata.
Suutsime suunata oma juhtimisressursid täpselt sinna, kus seda sel hetkel vaja oli – koostööle äritegevusega: Mis on meie kliendi jaoks praegu oluline, mis funktsionaalsust tuleks esmalt juurutada, mida on vaja teha läbilaskevõime suurendamiseks. tellimuste kohaletoimetamiseks ja töötlemiseks. Kõik see ja selge eeskuju võimaldas sellel perioodil laadida oma toodangu väärtusvoogusid sellega, mis on tõeliselt oluline ja vajalik.
Selge on see, et kaugtöö ja kiire muutuste tempo juures, kui ärinäitajad sõltuvad kõigi osalusest, ei saa loota ainult sisetundele sarjast “Kas meil läheb kõik hästi? Jah, see tundub hea olevat." Vaja on tootmisprotsessi objektiivseid mõõdikuid. Meil on need olemas, need on kättesaadavad kõigile, kes on huvitatud tootemeeskondade mõõdikutest. Esiteks meeskond ise, äri, alltöövõtjad ja juhtkond.
Kord kahe nädala jooksul tehakse iga meeskonnaga staatus, kus 10 minuti jooksul analüüsitakse mõõdikuid, tehakse kindlaks tootmisprotsessi kitsaskohad ning töötatakse välja ühine lahendus: mida teha nende kitsaskohtade kõrvaldamiseks. Siin saate koheselt abi küsida juhtkonnalt, kui mõni tuvastatud probleem jääb väljapoole meeskondade mõjutsooni või kolleegide asjatundlikkust, kes on sarnase probleemiga juba kokku puutunud.
Küll aga mõistame, et mitmekordseks kiirendamiseks (ja see on just see eesmärk, mille me endale seame), peame siiski palju õppima ja seda oma igapäevatöös rakendama. Praegu jätkame oma tootepõhise lähenemisviisi laiendamist teistele meeskondadele ja uutele toodetele. Selleks pidime meisterdama meie jaoks uue formaadi – metoodikute veebikooli.
Metoodikud, inimesed, kes aitavad meeskondadel protsessi üles ehitada, kommunikatsiooni luua ja töö tõhusust parandada, on sisuliselt muutuste agensid. Praegu töötavad meie esimese rühma lõpetajad meeskondadega ja aitavad neil edukaks saada.
Arvan, et praegune olukord avab meile võimalusi ja väljavaateid, mida me ise võib-olla veel lõpuni ei teadvusta. Kuid kogemused ja praktika, mida me praegu omandame, kinnitavad, et oleme valinud õige arengutee, me ei jäta neid uusi võimalusi ka tulevikus kasutamata ning suudame sama tõhusalt vastata ka Sportmasteri ees seisvatele väljakutsetele.
Järeldused
Sel raskel ajal oleme sõnastanud põhiprintsiibid, millele tarkvaraarendus tugineb, mis minu arvates on aktuaalsed igale sellega tegelevale ettevõttele.
Inimesed. Sellel kõik toetubki. Töötajad peavad oma tööd nautima ning mõistma ettevõtte eesmärke ja nende toodete eesmärke, millega nad töötavad. Ja loomulikult võiksid nad professionaalselt areneda.
Технология. Ettevõte peab oma tehnoloogiavirnaga töötama küpselt lähenema ja arendama kompetentse seal, kus seda tõesti vaja on. See kõlab väga lihtsalt ja ilmselgelt. Ja väga sageli ignoreeritakse.
Protsessid. Oluline on korrektselt korraldada tootemeeskondade ja kompetentsikeskuste tööd, luua suhtlust ettevõttega, et sellega partnerina koostööd teha.
Üldiselt niimoodi me ellu jäime. Meie aja põhitees sai järjekordse kinnituse, kõlava klõpsuga otsmikul
Isegi kui teil on suur võrguühenduseta ettevõte, millel on palju poode ja palju linnu, kus tegutsete, arendage oma veebiäri. See pole lihtsalt lisamüügikanal või ilus rakendus, mille kaudu saab ka midagi osta (ja ka sellepärast, et konkurentidel on ka ilusaid). See ei ole igaks juhuks mõeldud varurehv, mis aitab teil tormist üle elada.
See on absoluutne vajadus. Milleks ei pea olema valmis mitte ainult oma tehnilised võimalused ja infrastruktuur, vaid ka oma inimesed ja protsessid. Paari tunniga saab ju kiirelt juurde osta mälu, ruumi, juurutada uusi eksemplare jne. Aga inimesed ja protsessid peavad selleks eelnevalt valmis olema.
Allikas: www.habr.com