Helló!
A nevem Mihail, az IT igazgatóhelyettese vagyok a Sportmaster cégnél. Szeretnék megosztani egy történetet arról, hogyan birkóztunk meg a járvány alatt felmerült nehézségekkel.
Az új realitások első napjaiban a Sportmaster offline kereskedelmi formátuma leállt, és a hozzáférési online csatornánk terhelése, különösen az ügyfélszállítás terén, tízszeresére nőtt. Pár hét alatt óriási offline üzletünket online-ra alakítottuk, és a szolgáltatást alkalmazkodtattuk ügyfeleink igényeihez.
Röviden, ami lényegében másodlagos tevékenységünk volt, az lett a fő üzletág. Minden egyes online rendelés fontossága drámaian megnőtt. Meg kellett őriznünk minden forintot, amit az ügyfél hozott a cég számára.
Az ügyfélkérések gyors kezelésére egy további kapcsolattartó központot nyitottunk a cég főirodájában, így most heti körülbelül 285 ezer hívást tudunk fogadni. Ugyanakkor 270 boltot átállítottunk az érintkezés nélküli és biztonságos működés új formátumára, ami lehetővé tette az ügyfelek számára a rendeléseik átvételét, a munkatársak számára pedig a munkahelyeik megőrzését.
A transzformáció során két fő problémával találkoztunk. Először is, a terhelés a online erőforrásainkon érzékelhetően megnőtt (erről Szergej mesél majd). Másodszor, a COVID előtt ritka műveletek száma többszörösére emelkedett, ami gyors automatizálást igényelt. E probléma megoldásához gyorsan át kellett irányítanunk erőforrásokat olyan területekről, amelyek korábban fő tevékenységek voltak. Erről Jelena fog beszélni.
Online szolgáltatások üzemeltetése
Szergej Kolesznikov, az internetáruház és mikro-szolgáltatások üzemeltetéséért felelős
Azt követően, hogy a kiskereskedelmi boltjaink zárva tartottak a látogatók előtt, elkezdtük észlelni a felhasználók számának, az alkalmazásunkban leadott rendelések számának és a mikro-szolgáltatásokra irányuló kérelmek számának növekedését.
Rendelések száma március 18. és 31. között
Mikroszolgáltatások online kifizetésére irányuló kérelmek száma
A weboldalon leadott rendelések száma
Az első grafikonon azt látjuk, hogy a növekedés körülbelül 14-szeres, míg a második 4-szeres. A legkifejezőbb mutatónak a válaszidőnk jelzőt tartjuk ebben az alkalmazásainkra.
Ezen a grafikonon a frontok és alkalmazások válaszát látjuk, és számunkra azt állapítottuk meg, hogy igazi növekedést nem tapasztaltunk.
Elsősorban azzal függ össze, hogy 2019 végén elkezdtük az előkészületeket. Jelenleg szolgáltatásaink rezerváltak, a fizikai szerverek, virtualizációs rendszerek és a bennük lévő szolgáltatások szintjén biztosított a hibatűrés. Ezenkívül a szerver erőforrásaink kapacitása lehetővé teszi a többszörös terhelés elviselését.
A legfontosabb eszköz, amely segített nekünk az egész történet során, a saját megfigyelő rendszerünk volt. Igaz, hogy még egészen nemrégiben nem volt egy egységes rendszerünk, amely lehetővé tette volna, hogy metricákat gyűjtsünk minden szinten, a fizikai hardver szintjétől kezdve egészen az üzleti metrikákig.
Formálisan volt megfigyelés a cégnél, de jellemzően szétszórt volt, és az egyes osztályok felelősségi körébe tartozott. Valójában, amikor valamilyen incidens történt, szinte soha nem volt egységes megértésünk arról, mi is történt, nem volt tájékoztatás, és gyakran ez körbe-körbe futáshoz vezetett a probléma felkutatásához és lokalizálásához a későbbi elhárításhoz.
Egy ponton úgy döntöttünk, hogy elegünk van ebből — szükségünk van egy egységes rendszerre, hogy láthassuk az egész képet. A fő technológiák, amelyek a stackünkbe tartoznak, a Zabbix mint riasztó és metrikagyűjtő központ, a Prometheus az alkalmazás metrikák gyűjtésére és tárolására, az ELK stack a logoláshoz és az egész megfigyelő rendszer adatainak tárolásához, valamint a Grafana a vizualizálásért, Swagger, Docker és más hasznos és ismerős eszközök.
Ezen kívül nem csak a piacon elérhető technológiákat használjuk, hanem magunk is fejlesztünk egyet s mást. Például integráló szolgáltatásokat készítünk a rendszerek között, egy API-t a metrikák gyűjtésére. Emellett saját megfigyelő rendszereinken is dolgozunk — az üzleti metrikák szintjén UI-teszteket használunk. Továbbá egy Telegram botot is fejlesztünk a csapatok értesítésére.
Emellett arra törekszünk, hogy a megfigyelő rendszert hozzáférhetővé tegyük a csapatok számára, hogy önállóan tárolhassák metrikáikat és dolgozhassanak velük, beleértve a riasztások beállítását is bizonyos szűk metrikákra, amelyek nem általános alkalmazásnak számítanak.
A rendszer keretein belül célunk a proaktivitás és a lehető leggyorsabb incidenslokalizálás. Emellett a mikroszolgáltatásaink és rendszereink száma az utóbbi időben jelentősen nőtt, ennek megfelelően növekszik az integrációk száma is. Az incidensdiagnosztikai folyamat optimalizálása érdekében olyan rendszert fejlesztünk, amely lehetővé teszi a rendszerek közötti ellenőrzések elvégzését és az eredmények kiértékelését, ami segít feltárni az importokkal és a rendszerek közötti együttműködéssel kapcsolatos alapvető problémákat.
Természetesen még van hova fejlődnünk a rendszerek üzemeltetése terén, és aktívan dolgozunk ezen. A megfigyelő rendszerünkről bővebben olvashatsz itt. .
Műszaki tesztek
Szergej Orlov, a web- és mobilfejlesztési kompetencia központ vezetője
A fizikai bolt bezárását követően különböző kihívásokkal kellett szembenéznünk a fejlesztés szempontjából. Elsősorban a terhelés hirtelen növekedése volt a kihívás. Nyilvánvaló, hogy ha nem teszünk megfelelő intézkedéseket, akkor a rendszer magas terhelés alá helyezve szomorú puffanással tök formájába változhat, vagy teljesen csökkenhet a teljesítménye, vagy akár el is veszítheti működőképességét.
A második, kevésbé nyilvánvaló aspektus az, hogy a rendszert magas terhelés alatt rendkívül 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 nagy marketingaktivitások során nem szabad változtatásokat végrehajtani a rendszerben. Semmilyen változtatást, hagyjuk működni, ha már működik.
Nálunk lényegében végtelen fekete péntek volt, amikor a rendszerünket kellett változtatni. És bármilyen hiba, probléma, zavar a rendszerben nagyon magas költségeket jelentett volna az üzlet számára.
Előrehaladva elmondhatom, hogy sikerült megbirkóznunk ezekkel a kihívásokkal, minden rendszer kibírta a terhelést, könnyen skálázható volt, és nem voltak globális technikai zavaraink.
Négy alapelv létezik, amelyek lehetővé teszik a rendszer számára, hogy ellenálljon a hirtelen megnövekedett terhelésnek. Az első a monitoring, amiről korábban olvastál. A jól felépített monitoring rendszer nélkül szinte lehetetlen azonosítani a rendszer szűk keresztmetszeteit. Egy jó monitoring rendszer olyan, mint a kényelmes otthoni ruha, ami illeszkedik hozzád.
A második aspektus a tesztelés. Ezt a szakaszt nagyon komolyan vesszük: klasszikus egységteszteket, integrációs és terhelési teszteket és sok más tesztet írunk minden rendszer számára. Emellett tesztelési stratégiát is kidolgozunk, célunk, hogy elérjük a tesztelés olyan szintjét, ahol a manuális ellenőrzések már nem szükségesek.
A harmadik alapelv a CI/CD Pipeline. Az alkalmazás összegyűjtésének, tesztelésének és telepítésének folyamatait maximálisan automatizálni kell, nem legyenek manuális beavatkozások. A CI/CD Pipeline témája meglehetősen mély, ezért csak érintően beszélek róla. Megemlítendő, hogy van egy CI/CD Pipeline ellenőrzőlistánk, amely szerint minden termékcsapat a kompetenciaközpontok segítségével dolgozik.
Íme a ellenőrzőlista
Így sok célt elérünk. Ez magában foglalja az API verziózását, a feature toggle-t, hogy elkerüljük a kiadási vonatokat, valamint a különböző tesztelések olyan szintű lefedettségét, hogy a tesztelés teljesen automatizált legyen, a telepítések zökkenőmentesek legyenek, és így tovább.
A negyedik alapelv az architekturális elvek és technikai megoldások. Az architektúráról sokat és hosszan lehet beszélni, de szeretnék hangsúlyozni néhány elvet, amelyekre nagy figyelmet fordítanék.
Először is, speciális eszközöket kell választani a konkrét feladatokhoz. Igen, ez nyilvánvalónak tűnik, és világos, hogy a szögeket kalapáccsal érdemes beverni, míg a karórákat speciális csavarhúzókkal érdemes szétszedni. De a mi korunkban sok eszköz az univerzalizációra törekszik, hogy minél nagyobb felhasználói szegmenst lefedjen: adatbázisok, gyorsítótárak, keretrendszerek és egyebek. Például, ha megnézzük a MongoDB adatbázist, az multifunkciós tranzakciókkal működik, míg az Oracle adatbázis JSON-nal dolgozik. És úgy tűnik, hogy minden bármi számára használható. De ha a teljesítményt tartjuk szem előtt, fontos megérteni az egyes eszközök erősségeit és gyengeségeit, és azokat használni, amelyek a feladatkörünkhöz szükségesek.
Másodszor, a rendszerek tervezésekor minden bonyolultságnövelésnek indokoltnak kell lennie. Folyamatosan észben kell tartanunk ezt, a low coupling elve mind előttünk van. Úgy gondolom, hogy ezt alkalmazni kell a szolgáltatás szintjén, a rendszer szintjén és az architekturális táj szintjén is. Fontos, hogy a rendszer minden komponense képes legyen vízszintes skálázásra a terhelés függvényében. Ha van erre képesség, a skálázás nem jelenthet gondot.
Ha a technikai megoldásokról beszélünk, kérjük, hogy a termékcsapatok készítsenek egy friss javaslatkészletet, ötleteket és megoldásokat, amelyeket a következő terhelési hullámra való felkészülés során valósítottak meg.
Gyorsítótárak
Tudatosan kell megközelíteni a helyi és elosztott gyorsítótárak kiválasztását. Néha érdemes mindkettőt használni egy rendszeren belül. Például vannak olyan rendszereink, ahol az adatok egy része gyakorlatilag vitrin gyorsítótár, azaz a frissítések forrása a rendszeren kívül található, és a rendszer nem változtatja meg ezeket az adatokat. Ebben az esetben helyi Caffeine Cache-t használunk.
Vannak olyan adatok is, amelyeket a rendszer aktívan módosít a munkafolyamat során, itt már elosztott gyorsítótárat alkalmazunk Hazelcast-tel. Ez a megközelítés lehetővé teszi számunkra, hogy kihasználjuk az elosztott gyorsítótár előnyeit ott, ahol valóban szükség van rá, és minimalizáljuk a költségeket a Hazelcast klaszter adataival való műveletek során ott, ahol ezt elkerülhetjük. A gyorsítótárakról sokat írtunk. és .
Továbbá, a Kryo sorosító használatára váltás a Hazelcast-ban jelentős növekedést hozott számunkra. Az áttérés a ReplicatedMap-ről az IMap + Near Cache-re a Hazelcast-ban lehetővé tette a klaszter adatmozgásának minimalizálását.
Egy kis tipp: tömeges gyorsítótár érvénytelenítés esetén néha alkalmazható a második gyorsítótár felmelegítési taktikája, majd a váltás rá. Elsőre úgy tűnhet, hogy ilyen megközelítéssel dupla memóriafogyasztást kellene kapnunk, de a gyakorlatban, azokban a rendszerekben, ahol ezt alkalmazták, a memóriafogyasztás csökkent.
Reaktív verem
Reaktív veremet már viszonylag nagy számú rendszerben használunk. Az esetünkben ez a Webflux vagy a Kotlin coroutines. Különösen jól működik a reaktív verem, ahol lassú bemeneti-kimeneti műveletekre számítunk. Például, lassú szolgáltatások hívása, fájlrendszerrel vagy tárolórendszerekkel való munka esetén.
A legfontosabb elv — kerüljük a blokkoló hívásokat. A reaktív keretrendszerek alatt egy kis számú aktív szolgáltatási szál fut. Ha nem vigyázunk, és engedjük, hogy közvetlen blokkoló hívást végezzünk, például JDBC-illesztőhöz, a rendszer egyszerűen leáll.
Próbálja meg saját runtime exception-öket létrehozni a hibák kezelésére. A program végrehajtási szála a reaktív keretrendszerekhez fordul, a kód végrehajtása nem lineáris. Ennek következményeként nagyon nehéz diagnosztizálni a problémákat a stack trace-ek alapján. A megoldás itt az, hogy minden hiba esetén egyértelmű és objektív runtime exception-öket hozzunk létre.
Elasticsearch
Elasticsearch használata során ne válassza ki a nem használt adatokat. Ez alapvetően egy nagyon egyszerű tanács, de a legtöbbször éppen ezt felejtik el. Ha egy lépésben több mint 10 ezer rekordot kell kiválasztani, a Scroll-t kell használni. Analógiaként ez kissé hasonlít a kurzorra a relációs adatbázisban.
Ne használj postfilter-t szükségtelenül. Nagy adathalmazon ez a művelet nagyon megterheli az adatbázist.
Használja a bulk műveleteket ott, ahol alkalmazható.
API
Az API tervezésekor határozza meg az adatátvitel minimalizálására vonatkozó követelményeket. Ez különösen fontos a front-end-hez való összekapcsolás során: pontosan itt lépünk ki az adatközpontjaink csatornáiból, és már azon a csatornán dolgozunk, amely összeköt minket az ügyféllel. Ha ott a legkisebb problémák merülnek fel, a túl magas forgalom negatív felhasználói élményt okoz.
Végül ne ömleszd rá az összes adatot, légy pontos a szerződésnél a fogyasztók és a szolgáltatók között.
Szervezeti átalakulás
Jelena Eroshkina, IT igazgatóhelyettes
Abban a pillanatban, amikor a karantén bekövetkezett, és sürgősen növelni kellett az online fejlődés ütemét, valamint bevezetni az omnichannel szolgáltatásokat, már folyamatban voltunk az szervezeti átalakuláson.
Struktúránk egy része átállt a termék alapú megközelítések és gyakorlatok szerint való munkavégzésre. Olyan csapatok alakultak, amelyek most felelősek minden egyes termék működéséért és fejlesztéséért. Az ilyen csapatok tagjai teljes mértékben részt vesznek a munkában, és a Scrum vagy Kanban módszertan szerint dolgoznak, attól függően, hogy mi a preferált számukra, beállítják a kiadási folyamatot, bevezetik a technikai gyakorlatokat, a minőségbiztosítási eljárásokat és még sok mást.
Szerencsés véletlen, hogy ezeknek a termékcsapatoknak a legtöbbje éppen az online és omnichannel szolgáltatások területén dolgozott. Ez lehetővé tette számunkra, hogy néhány napon belül (komolyan, szó szerint két nap alatt) áttérjünk a távoli munkavégzésre anélkül, hogy a hatékonyságunk csökkent volna. A beállított folyamat gyors alkalmazkodást tett lehetővé az új munkakörülményekhez, és elég magas ütemben tudtuk biztosítani az új funkciókat.
Továbbá szükségessé vált, hogy erősítsük az online üzlet frontján álló csapatokat. Abban a pillanatban nyilvánvalóvá vált, hogy ezt csak belső forrásokkal tudjuk megtenni. Kb. 50 ember változtatta meg a munkaterületét a két hét alatt, és kapcsolódott be egy számukra új termék fejlesztésébe.
Ehhez nem volt szükség különleges menedzsment erőfeszítésekre, mert a saját folyamataink megszervezése, a termék technikai fejlesztése, valamint a minőségbiztosítási gyakorlat mellett tanítjuk csapatainkat az önszerveződésre — hogy saját termelési folyamatukat irányítsák adminisztratív forrás bevonása nélkül.
Az irányítói erőforrást pontosan ott tudtuk összpontosítani, ahol erre szükség volt abban a pillanatban - az üzlettel való koordinálásra: Mi is fontos most ügyfelünk számára, milyen funkcionalitást kellene elsőként megvalósítani, mit kell tennünk a rendelésfeldolgozási kapacitásunk növeléséhez. Mindez és egy világos szerepminta lehetővé tette számunkra, hogy ebben az időszakban a valóban fontos és szükséges értékteremtési gyártási folyamatainkat terheljük.
Nyilvánvaló, hogy távoli munkavégzés és a gyors változások idején, amikor mindenki részvétele befolyásolja az üzleti mutatókat, nem lehet csupán a belső érzésekre támaszkodni, mint például: „Jól megy minden?” Szükségesek objektív előállítási folyamatmetrikák. Azok rendelkezésre állnak, és bárki hozzáférhet, aki érdeklődik a termékcsapatok metrikái iránt. Elsősorban a csapatnak, az üzletnek, a kapcsolódó területeknek és a vezetőségnek.
Kéthetente minden csapatnál státuszjelentést tartanak, amelynek során 10 perc alatt elemzik a metrikákat, feltárjá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érhetjük a vezetőség segítségét is, ha a felismert probléma a csapatok befolyási körén kívül helyezkedik el, vagy a kollégák szakértelme, akik esetleg már hasonló problémával találkoztak.
Mindazonáltal tisztában vagyunk azzal, hogy a többszörös gyorsítás érdekében (ez pontosan ez a célunk) még sok mindent meg kell tanulnunk és be kell vezetnünk a napi munkánkba. Jelenleg a termékmegközelítés skálázását folytatjuk más csapatokra és új termékekre. Ehhez el kellett sajátítanunk egy új online módszertani iskolai formát.
A módszertani szakemberek, akik segítenek a csapatoknak a folyamat felépítésében, a kommunikációk megteremtésében és a munka hatékonyságának növelésében, lényegében a változás ügynökei. Jelenleg az első osztályunk végzett diákjai dolgoznak a csapatokkal és segítik őket a siker elérésében.
Azt gondolom, hogy a kialakult helyzet olyan lehetőségeket és perspektívákat nyit meg számunkra, amelyeket talán még mi magunk sem tudunk teljesen felmérni. De az a tapasztalat és gyakorlat, amelyet most nyerünk, megerősíti, hogy a fejlődés helyes útját választottuk, nem fogunk elveszíteni ezeket az új lehetőségeket a jövőben, és ugyanolyan hatékonyan tudunk majd reagálni a „Sportmaster” előtt álló kihívásokra.
Következtetések
Ebben a nehéz időszakban megfogalmaztuk azokat a fő elveket, amelyekre a szoftverfejlesztés támaszkodik, és úgy vélem, hogy ezek minden olyan cég számára relevánsak, amely ezzel foglalkozik.
Ember. Ez az alapja mindennek. Az alkalmazottaknak élvezniük kell a munkát, érteniük kell a cég céljait és a termékek céljait, amelyekkel foglalkoznak. És természetesen, folyamatosan fejlődniük kell szakmai szempontból.
Technológia. Fontos, hogy a cég éretten közelítse meg a technológiai stack munkáját és ott növelje a kompetenciáit, ahol ez valóban szükséges. Ez nagyon egyszerűnek és nyilvánvalónak hangzik. És nagyon gyakran figyelmen kívül hagyják.
Folyamatok. Fontos, hogy a termékcsapatok és a kompetencia központok munkáját helyesen építsük fel, és biztosítsuk az üzlettel való együttműködést, hogy partnerré tudjunk válni.
Összességében körülbelül így éltük túl. A modernitás alapvető tézise ismét megerősítést nyert, éles pofonként csattant a homlokon.
Még ha hatalmas offline üzlet is vagy sok bolt és sok városi jelenléttel, fejleszd az online jelenlétedet. Ez nem csupán egy további forgalmazási csatorna vagy egy szép alkalmazás, amelyen keresztül valamit meg lehet vásárolni (és azért is, mert a versenytársaknál is van szép). Ez nem egy pótkerék, ami segít átvészelni a viharokat.
Ez elengedhetetlen szükséglet. Amire nemcsak a technikai kapacitásoknak és infrastruktúrának, hanem az embereknek és a folyamatoknak is fel kell készülniük. Hiszen a memória, a hely, az új instanciák gyors beszerzése és egyéb dolgok néhány óra alatt megvalósíthatók. De az embereket és a folyamatokat előre fel kell készíteni.
Forrás: habr.com
