Hi!
A nevem Mikhail, a Sportmaster cég IT igazgatóhelyettese vagyok. Szeretném megosztani a történetet arról, hogyan kezeltük a világjárvány során felmerült kihívásokat.
Az új realitások első napjaiban a Sportmaster szokásos offline kereskedési formátuma lefagyott, és online csatornánk terhelése, elsősorban az ügyfél címére történő szállítás tekintetében, tízszeresére nőtt. Néhány hét alatt egy gigantikus offline vállalkozást online üzletté alakítottunk, és ügyfeleink igényeihez igazítottuk a szolgáltatást.
Alapvetően a melléküzemünk lett az alaptevékenységünk. Minden online rendelés jelentősége rendkívül megnőtt. Minden rubelt meg kellett menteni, amit az ügyfél hozott a cégnek.
Az ügyfelek kéréseinek gyors megválaszolása érdekében további kapcsolattartó központot nyitottunk a cég központi irodájában, amely immár mintegy 285 ezer hívást fogadhat hetente. Ezzel egyidejűleg 270 üzletet költöztettünk át egy új érintésmentes és biztonságos működési formára, amely lehetővé tette a vásárlók számára a megrendelések fogadását, az alkalmazottak pedig a munkahelyük megtartását.
Az átalakulás során két fő problémával találkoztunk. Először is, jelentősen megnőtt az online forrásaink terhelése (Szergej elmondja, hogyan kezeltük ezt). Másodszor, a ritka (COVID előtti) műveletek áramlása sokszorosára nőtt, ami viszont nagy mennyiségű gyors automatizálást igényelt. A probléma megoldásához gyorsan át kellett mozgatnunk az erőforrásokat olyan területekről, amelyek korábban a fő területek voltak. Elena elmondja, hogyan kezeltük ezt.
Online szolgáltatások működtetése
Kolesnikov Sergey, az online áruház működéséért és a mikroszolgáltatásokért felelős
Attól a pillanattól kezdve, hogy kiskereskedelmi üzleteink bezártak a látogatók előtt, növekedést kezdtünk el olyan mutatókban, mint a felhasználók száma, az alkalmazásunkban leadott rendelések száma és az alkalmazásokhoz érkezett kérések száma.
Megrendelések száma március 18-tól március 31-igAz online fizetési mikroszolgáltatásokhoz intézett kérések számaA weboldalon leadott rendelések száma
Az első grafikonon azt látjuk, hogy a növekedés körülbelül 14-szeres volt, a másodikban - 4-szeres. Alkalmazásaink válaszidő-mutatóját tartjuk a leginkább tájékoztatónak.
Ezen a grafikonon a frontok és az alkalmazások reakcióit látjuk, és magunk határoztuk meg, hogy nem vettünk észre semmiféle növekedést.
Ez elsősorban annak köszönhető, hogy 2019 végén megkezdtük az előkészítő munkát. Jelenleg szolgáltatásaink le vannak foglalva, a hibatűrés a fizikai szerverek, virtualizációs rendszerek, dockerek és az azokban lévő szolgáltatások szintjén biztosított. Szerver erőforrásaink kapacitása ugyanakkor lehetővé teszi, hogy többszörös terhelést is elviseljünk.
A fő eszköz, amely segített ebben az egész történetben, a megfigyelő rendszerünk volt. Igaz, egészen a közelmúltig nem volt egyetlen olyan rendszerünk sem, amely lehetővé tette volna a mérőszámok gyűjtését minden szinten, a fizikai felszereltség és hardver szintjétől az üzleti mérőszámok szintjéig.
Formálisan a cégnél volt megfigyelés, de rendszerint szétszórt volt, és az egyes részlegek felelősségi körébe tartozott. Valójában, amikor egy incidens megtörtént, szinte soha nem értettük meg, hogy pontosan mi is történt, nem volt kommunikáció, és ez gyakran ahhoz vezetett, hogy körbefutottunk, hogy megtaláljuk és elkülönítsük a problémát, hogy megoldható legyen.
Valamikor úgy gondoltuk, és úgy döntöttünk, hogy elég volt ezt elviselni – egységes rendszerre van szükség, hogy a teljes képet teljes egészében láthassuk. A veremünkben szereplő főbb technológiák a Zabbix mint riasztási és mérőszámtároló központ, a Prometheus az alkalmazási metrikák összegyűjtésére és tárolására, a Stack ELK a teljes megfigyelőrendszer adatainak naplózására és tárolására, valamint a Grafana a megjelenítéshez, a Swagger, a Docker és egyéb hasznos és ismerős dolgok.
Ugyanakkor nemcsak a piacon elérhető technológiákat használjuk, hanem saját magunkat is fejlesztjük. Például rendszereket egymással integráló szolgáltatásokat készítünk, vagyis valamilyen API-t a mérőszámok gyűjtésére. Emellett saját felügyeleti rendszereinken is dolgozunk – az üzleti mérőszámok szintjén UI teszteket használunk. És egy bot is a Telegramban, amely értesíti a csapatokat.
Arra is törekszünk, hogy a felügyeleti rendszert elérhetővé tegyük a csapatok számára, hogy önállóan tárolhassák és dolgozhassanak mérőszámaikkal, beleértve a riasztások beállítását néhány szűk, nem széles körben használt mérőszámra.
Az egész rendszerben proaktivitásra és az események mielőbbi lokalizálására törekszünk. Emellett az utóbbi időben jelentősen megnőtt mikroszolgáltatásaink és rendszereink száma, ennek megfelelően nőtt az integrációk száma is. Az incidensek integrációs szintű diagnosztizálási folyamatának optimalizálása részeként egy olyan rendszert fejlesztünk, amely lehetővé teszi a rendszerek közötti ellenőrzések elvégzését és az eredmény megjelenítését, amely lehetővé teszi az importálással és a rendszerek interakciójával kapcsolatos főbb problémák megtalálását. egymás.
Természetesen még van hova fejlődnünk és fejlődnünk az operációs rendszerek terén, és ezen aktívan dolgozunk. Bővebben felügyeleti rendszerünkről olvashat .
Műszaki vizsgálatok
Orlov Sergey, a webes és mobilfejlesztési kompetenciaközpont vezetője
A fizikai üzletek bezárása óta számos fejlesztési kihívással nézünk szembe. Először is a terhelési hullám, mint olyan. Nyilvánvaló, hogy ha nem tesznek megfelelő intézkedéseket, akkor a rendszer nagy terhelése esetén szomorú robajjal tökké változhat, vagy teljesen leromlik a teljesítmény, vagy akár elveszítheti funkcionalitását.
A második, kicsit kevésbé nyilvánvaló szempont, hogy a nagy terhelés alatt álló rendszert nagyon gyorsan kellett változtatni, alkalmazkodva az üzleti folyamatok változásaihoz. Néha naponta többször is. Sok cégnél van egy szabály, hogy ha sok a marketing tevékenység, akkor nem kell változtatásokat végrehajtani a rendszeren. Egyáltalán nincs, addig működjön, amíg működik.
És lényegében egy végtelen Black Friday volt, ami alatt rendszerváltásra volt szükség. És a rendszer bármilyen hibája, probléma vagy meghibásodása nagyon költséges lenne a vállalkozás számára.
A jövőre nézve azt mondom, hogy sikerült megbirkózni ezekkel a tesztekkel, minden rendszer bírta a terhelést, könnyen skálázható volt, és nem tapasztaltunk globális műszaki hibát.
Négy pilléren nyugszik a rendszer azon képessége, hogy ellenálljon a nagy túlfeszültségnek. Az első ezek közül a monitorozás, amelyről fentebb olvashat. Beépített felügyeleti rendszer nélkül szinte lehetetlen megtalálni a rendszer szűk keresztmetszeteit. A jó megfigyelőrendszer olyan, mint az otthoni ruha: kényelmesnek és személyre szabottnak kell lennie.
A második szempont a tesztelés. Ezt nagyon komolyan vesszük: klasszikus egységeket, integrációs teszteket, terhelési teszteket és még sok mást írunk minden rendszerhez. Tesztelési stratégiát is írunk, és ezzel párhuzamosan igyekszünk a tesztelés szintjét odáig emelni, hogy többé ne legyen szükségünk kézi ellenőrzésekre.
A harmadik pillér a CI/CD Pipeline. Az alkalmazások felépítésének, tesztelésének és telepítésének folyamatait a lehető legnagyobb mértékben automatizálni kell, nem szabad kézi beavatkozást végezni. A CI/CD Pipeline témája meglehetősen mély, és csak röviden érintem. Csak annyit érdemes megemlíteni, hogy van egy CI/CD Pipeline ellenőrzőlistánk, amelyet minden termékcsapat átvesz a kompetenciaközpontok segítségével.
És itt az ellenőrző lista
Ily módon számos cél megvalósul. Ez egy API-verzió és funkcióváltás, amellyel elkerülhető a kiadási sorozat, és a különböző tesztek olyan szintű lefedettsége érhető el, hogy a tesztelés teljesen automatizált, a telepítések zökkenőmentesek és így tovább.
A negyedik pillér az építészeti elvek és műszaki megoldások. Az építészetről még sokáig beszélhetünk, de szeretnék egy-két alapelvet kiemelni, amelyekre szeretnék összpontosítani.
Először is speciális eszközöket kell választania bizonyos feladatokhoz. Igen, nyilvánvalóan hangzik, és egyértelmű, hogy a szögeket kalapáccsal kell beverni, a karórákat pedig speciális csavarhúzókkal kell szétszedni. De korunkban sok eszköz törekszik az univerzalizálásra, hogy a felhasználók maximális szegmensét lefedje: adatbázisok, gyorsítótárak, keretrendszerek és a többi. Például, ha a MongoDB adatbázist vesszük, az több dokumentumból álló tranzakciókkal működik, az Oracle adatbázis pedig a json-val. És úgy tűnik, hogy mindent mindenre fel lehet használni. De ha a termelékenység mellett állunk, akkor világosan meg kell értenünk az egyes eszközök erősségeit és gyengeségeit, és használnunk kell azokat, amelyekre szükségünk van a feladatosztályunkhoz.
Másodszor, a rendszerek tervezésekor a bonyolultság minden növekedését indokolni kell. Ezt folyamatosan szem előtt kell tartanunk, az alacsony csatolás elve mindenki számára ismert. Úgy gondolom, hogy ezt egy konkrét szolgáltatás szintjén kell alkalmazni, és az egész rendszer szintjén, illetve az építészeti táj szintjén. Az is fontos, hogy az egyes rendszerelemeket a terhelési útvonal mentén vízszintesen lehessen skálázni. Ha rendelkezik ezzel a képességgel, a méretezés nem lesz nehéz.
A technikai megoldások apropóján megkértük a termékcsapatokat, hogy készítsenek új ajánlásokat, ötleteket és megoldásokat, amelyeket a következő terhelési hullámra való felkészülés során valósítottak meg.
Keshi
Tudatosan kell megközelíteni a helyi és elosztott gyorsítótárak kiválasztását. Néha érdemes mindkettőt ugyanazon a rendszeren belül használni. Például vannak olyan rendszereink, amelyekben az adatok egy része lényegében egy gyorsítótár, vagyis a frissítések forrása maga a rendszer mögött található, és a rendszerek nem változnak ezt az adatot. Ehhez a megközelítéshez a helyi koffein gyorsítótárat használjuk.
És vannak olyan adatok, amelyeket a rendszer működés közben aktívan változtat, és itt már elosztott gyorsítótárat használunk a Hazelcasttal. Ez a megközelítés lehetővé teszi számunkra, hogy ott használjuk ki az elosztott gyorsítótár előnyeit, ahol valóban szükség van rájuk, és minimalizáljuk a Hazelcast-fürtadatok köröztetésének szolgáltatási költségeit ott, ahol nélkülözhetjük. Sokat írtunk a gyorsítótárakról. и .
Ezen kívül a Hazelcastban a szerializáló Kryo-ra cserélése jó lökést adott nekünk. A ReplicatedMapről az IMap + Near Cache-re való áttérés a Hazelcastban lehetővé tette számunkra, hogy minimalizáljuk az adatok mozgását a fürtön keresztül.
Egy kis tanács: tömeges gyorsítótár érvénytelenítése esetén esetenként alkalmazható az a taktika, hogy a második gyorsítótárat bemelegítjük, majd átváltunk rá. Úgy tűnik, hogy ezzel a megközelítéssel dupla memóriafelhasználást kell kapnunk, de a gyakorlatban azokban a rendszerekben, ahol ezt gyakorolták, a memóriafogyasztás csökkent.
Reaktív verem
Nagyon sok rendszerben használjuk a reaktív veremet. Esetünkben ez Webflux vagy Kotlin korutinokkal. A reaktív verem különösen jó ott, ahol lassú bemeneti-kimeneti műveletekre számítunk. Például lassú szolgáltatások hívása, a fájlrendszerrel vagy tárolórendszerekkel való munka.
A legfontosabb elv a hívások blokkolásának elkerülése. A reaktív keretrendszerek burkolata alatt néhány élő szolgáltatási szál fut. Ha hanyagul megengedjük magunknak egy közvetlen blokkoló hívást, például egy JDBC illesztőprogram hívást, a rendszer egyszerűen leáll.
Próbálja meg a hibákat saját futásidejű kivételekké alakítani. A programvégrehajtás tényleges folyamata reaktív keretrendszerekre tolódik el, és a kódvégrehajtás nemlineárissá válik. Ennek eredményeként nagyon nehéz diagnosztizálni a problémákat a veremnyomok segítségével. A megoldás pedig az lenne, ha minden hibához egyértelmű, objektív futásidejű kivételeket hozunk létre.
Elasticsearch
Az Elasticsearch használatakor ne válasszon fel nem használt adatokat. Ez is elvileg nagyon egyszerű tanács, de legtöbbször ezt felejtik el. Ha egyszerre több mint 10 ezer rekordot kell kiválasztania, akkor a Scrollt kell használnia. Ha egy analógiával élünk, ez egy kicsit olyan, mint egy kurzor egy relációs adatbázisban.
Ne használjon utószűrőt, hacsak nem szükséges. Ha nagy adat van a főmintában, ez a művelet nagymértékben terheli az adatbázist.
Adott esetben használjon tömeges műveleteket.
API
API tervezésekor vegye figyelembe a továbbított adatok minimalizálására vonatkozó követelményeket. Különösen igaz ez a front kapcsán: ezen a csomóponton lépünk túl adatközpontjaink csatornáin, és már dolgozunk azon a csatornán, amely összeköt minket az ügyféllel. Ha a legkisebb probléma is fennáll, a túl nagy forgalom negatív felhasználói élményt okoz.
És végül, ne dobjon ki egy csomó adatot, legyen tisztában a fogyasztók és a szállítók közötti szerződéssel.
Szervezeti átalakulás
Eroshkina Elena, informatikai igazgatóhelyettes
Abban a pillanatban, amikor beköszöntött a karantén, és felmerült az igény az online fejlesztés ütemének erőteljes növelésére és az omnichannel szolgáltatások bevezetésére, már a szervezeti átalakítás folyamatában voltunk.
Struktúránk egy része a termékszemléletű elvek és gyakorlatok szerint került át a munkába. Csapatok alakultak, amelyek ma már az egyes termékek működéséért és fejlesztéséért felelősek. Az ilyen csapatok alkalmazottai 100%-ban részt vesznek, és a Scrum vagy a Kanban segítségével strukturálják munkájukat, attól függően, hogy melyiket részesítik előnyben: telepítési folyamat felállítása, műszaki gyakorlatok megvalósítása, minőségbiztosítási gyakorlatok és még sok más.
Szerencsére termékcsapatunk nagy része az online és az omnichannel szolgáltatások területén tevékenykedett. Ez lehetővé tette számunkra, hogy a lehető legrövidebb időn belül (komolyan, szó szerint két nap alatt) a hatékonyság elvesztése nélkül váltsunk távoli munkamódra. A testre szabott folyamat lehetővé tette számunkra, hogy gyorsan alkalmazkodjunk az új munkakörülményekhez, és fenntartsuk az új funkciók meglehetősen magas ütemét.
Emellett meg kell erősítenünk azokat a csapatokat, amelyek az online üzlet élvonalában vannak. Abban a pillanatban világossá vált, hogy ezt csak belső erőforrások felhasználásával tudjuk megtenni. Két hét alatt körülbelül 50 ember változtatta meg azt a területet, ahol korábban dolgozott, és egy számukra új terméken dolgozott.
Ez nem igényelt különösebb vezetési erőfeszítést, hiszen saját folyamatszervezéssel, a termék műszaki fejlesztésével, minőségbiztosítási gyakorlattal együtt megtanítjuk csapatainkat az önszerveződésre - saját gyártási folyamat irányítására adminisztratív erőforrások bevonása nélkül.
Menedzsment erőforrásainkat pontosan oda tudtuk összpontosítani, ahol az adott pillanatban szükség volt rá - az üzlettel való közös koordinációra: Mi a fontos ügyfelünk számára jelenleg, milyen funkcionalitást kell először bevezetni, mit kell tenni az áteresztőképességünk növelése érdekében a rendelések kiszállítására és feldolgozására. Mindez és egy világos példakép lehetővé tette ebben az időszakban, hogy termelési értékfolyamainkat azzal töltsük fel, ami igazán fontos és szükséges.
Nyilvánvaló, hogy a távmunka és a nagy ütemű változás mellett, amikor az üzleti mutatók mindenki részvételétől függenek, nem lehet csak a belső érzésekre hagyatkozni a „Nálunk minden rendben van? Igen, jónak tűnik.” A gyártási folyamat objektív mérőszámaira van szükség. Ezek megvannak, bárki számára elérhetőek, akit érdekelnek a termékcsapatok mutatói. Mindenekelőtt maga a csapat, az üzlet, az alvállalkozók és a menedzsment.
Kéthetente minden csapattal státuszt tartanak, ahol 10 percig elemzik a mutatókat, azonosítják a gyártási folyamat szűk keresztmetszeteit, és közös megoldást dolgoznak ki: mit lehet tenni a szűk keresztmetszetek megszüntetése érdekében. Itt azonnal kérheti a vezetőség segítségét, ha a feltárt probléma kívül esik a csapatok hatásterületén, vagy olyan kollégák szakértelmét, akik esetleg már találkoztak hasonló problémával.
Azonban megértjük, hogy a többszörös gyorsuláshoz (és pontosan ezt a célt tűztük ki magunk elé), még sokat kell tanulnunk, és ezt be is kell ültetni a mindennapi munkánkba. Jelenleg folytatjuk termékmegközelítésünk kiterjesztését más csapatokra és új termékekre. Ehhez egy új formátumot kellett elsajátítanunk - egy online módszertani iskolát.
A módszertanosok, az emberek, akik segítik a csapatokat egy folyamat felépítésében, a kommunikáció kialakításában és a munka hatékonyságának javításában, alapvetően a változás előmozdítói. Jelenleg az első kohorszunkban végzett hallgatók csapatokkal dolgoznak, és segítenek nekik sikeres lenni.
Úgy gondolom, hogy a jelenlegi helyzet olyan lehetőségeket és távlatokat nyit meg előttünk, amelyekkel talán mi magunk még nem vagyunk teljesen tisztában. A most megszerzett tapasztalatok és gyakorlat azonban megerősíti, hogy a fejlődés helyes útját választottuk, a jövőben sem hagyjuk ki ezeket az új lehetőségeket, és ugyanolyan hatékonyan tudunk majd válaszolni a Sportmaster előtt álló kihívásokra.
Álláspontja
Ebben a nehéz időszakban megfogalmaztuk azokat a főbb alapelveket, amelyeken a szoftverfejlesztés nyugszik, ami szerintem minden ezzel foglalkozó cég számára aktuális lesz.
Emberek. Ezen múlik minden. Az alkalmazottaknak élvezniük kell a munkájukat, és meg kell érteniük a vállalat céljait és a termékek céljait, amelyeken dolgoznak. És persze szakmailag is fejlődhettek.
Технология. Szükséges, hogy a vállalat érett megközelítést alkalmazzon a technológiai köteggel való munkához, és ott építsen ki kompetenciákat, ahol valóban szükség van rá. Nagyon egyszerűen és nyilvánvalóan hangzik. És nagyon gyakran figyelmen kívül hagyják.
A folyamatok. Fontos a termékcsapatok és a kompetenciaközpontok munkájának megfelelő megszervezése, a vállalkozással való interakció kialakítása, hogy partnerként működhessen együtt vele.
Általában véve nagyjából így éltük túl. Korunk fő tézise ismét beigazolódott, hangos kattanással a homlokon
Még akkor is fejlessze online üzletét, ha Ön egy hatalmas offline vállalkozás, sok üzlettel és egy csomó várossal, ahol működik. Ez nem csak egy további értékesítési csatorna vagy egy gyönyörű alkalmazás, amelyen keresztül vásárolhat is valamit (és azért is, mert a versenytársaknak is vannak szépei). Ez nem minden esetre egy pótkerék, amely segít átvészelni a vihart.
Ez feltétlenül szükséges. Amire nem csak a technikai adottságait és infrastruktúráját kell felkészíteni, hanem az embereit és folyamatait is. Végül is gyorsan vásárolhat további memóriát, helyet, telepíthet új példányokat stb., néhány óra alatt. De erre előre fel kell készülni az embereknek és a folyamatoknak.
Forrás: will.com