Ahoj!
Volám sa Michail, som zástupcom riaditeľa IT v spoločnosti Sportmaster. Chcem sa podeliť o príbeh, ako sme sa vysporiadali s výzvami, ktoré vznikli počas pandémie.
V prvých dňoch novej reality zamrzol zvyčajný offline obchodný formát Sportmaster a zaťaženie nášho online kanála, predovšetkým z hľadiska doručenia na adresu klienta, sa zvýšilo 10-krát. Len za pár týždňov sme premenili gigantický offline biznis na online a prispôsobili službu potrebám našich klientov.
V podstate to, čo bolo v podstate našou vedľajšou činnosťou, sa stalo našou hlavnou činnosťou. Význam každej online objednávky extrémne vzrástol. Bolo treba šetriť každý rubeľ, ktorý klient do firmy priniesol.
Aby sme mohli rýchlo reagovať na požiadavky zákazníkov, otvorili sme ďalšie kontaktné centrum v hlavnom sídle spoločnosti a teraz môžeme prijať približne 285 tisíc hovorov týždenne. Zároveň sme presunuli 270 predajní do nového bezkontaktného a bezpečného prevádzkového formátu, ktorý umožnil zákazníkom prijímať objednávky a zamestnancom udržať si prácu.
Počas transformačného procesu sme narazili na dva hlavné problémy. Po prvé, zaťaženie našich online zdrojov sa výrazne zvýšilo (Sergey vám povie, ako sme sa s tým vysporiadali). Po druhé, tok zriedkavých operácií (pred ochorením COVID) sa mnohonásobne zvýšil, čo si zase vyžadovalo veľké množstvo rýchlej automatizácie. Aby sme tento problém vyriešili, museli sme rýchlo presunúť zdroje z oblastí, ktoré boli predtým hlavné. Elena vám povie, ako sme sa s tým vysporiadali.
Prevádzkovanie online služieb
Kolesnikov Sergey, zodpovedný za prevádzku internetového obchodu a mikroslužieb
Od momentu, keď sa naše maloobchodné predajne začali zatvárať pre návštevníkov, sme začali zaznamenávať nárast metrík, ako je počet používateľov, počet objednávok zadaných v našej aplikácii a počet žiadostí do aplikácií.
Počet objednávok od 18. marca do 31. marcaPočet žiadostí o online platobné mikroslužbyPočet objednávok zadaných na webovej stránke
V prvom grafe vidíme, že nárast bol približne 14-násobný, v druhom - 4-násobný. Metriku doby odozvy našich aplikácií považujeme za najviac orientačnú.
V tomto grafe vidíme odozvu frontov a aplikácií a sami sme zistili, že sme nezaznamenali žiadny rast ako taký.
Je to spôsobené predovšetkým tým, že prípravné práce sme začali koncom roka 2019. Teraz sú naše služby rezervované, odolnosť voči chybám je zabezpečená na úrovni fyzických serverov, virtualizačných systémov, dockerov a služieb v nich. Kapacita našich serverových zdrojov nám zároveň umožňuje vydržať viacnásobné zaťaženie.
Hlavným nástrojom, ktorý nám v celom tomto príbehu pomohol, bol náš monitorovací systém. Pravda, donedávna sme nemali jediný systém, ktorý by nám umožňoval zbierať metriky na všetkých úrovniach, od úrovne fyzického vybavenia a hardvéru až po úroveň obchodných metrík.
Formálne bol v spoločnosti monitoring, ale spravidla bol rozptýlený a bol v oblasti zodpovednosti konkrétnych oddelení. V skutočnosti, keď došlo k incidentu, takmer nikdy sme nemali spoločné chápanie toho, čo sa presne stalo, neexistovala žiadna komunikácia a často to viedlo k behaniu v kruhoch s cieľom nájsť a izolovať problém, aby sa dal vyriešiť.
V určitom momente sme si mysleli a rozhodli sme sa, že už toho máme dosť – potrebujeme jednotný systém, aby sme videli celý obraz. Hlavnými technológiami, ktoré sú súčasťou nášho zásobníka, sú Zabbix ako centrum na ukladanie upozornení a metrík, Prometheus na zhromažďovanie a ukladanie metrík aplikácií, Stack ELK na zaznamenávanie a ukladanie údajov z celého monitorovacieho systému, ako aj Grafana na vizualizáciu, Swagger, Docker a ďalšie užitočné veci a veci, ktoré poznáte.
Zároveň využívame nielen technológie dostupné na trhu, ale vyvíjame aj niektoré vlastné. Robíme napríklad služby na vzájomnú integráciu systémov, teda nejaké API na zbieranie metrík. Plus pracujeme na vlastných monitorovacích systémoch – na úrovni biznis metrík používame UI testy. A tiež robot v telegrame, ktorý informuje tímy.
Snažíme sa tiež sprístupniť monitorovací systém tímom, aby si mohli samostatne ukladať svoje metriky a pracovať s nimi, vrátane nastavenia upozornení na niektoré úzke metriky, ktoré nie sú široko používané.
V celom systéme sa snažíme o proaktivitu a čo najrýchlejšiu lokalizáciu incidentov. Okrem toho počet našich mikroslužieb a systémov v poslednej dobe výrazne vzrástol a zodpovedajúcim spôsobom vzrástol aj počet integrácií. A v rámci optimalizácie procesu diagnostiky incidentov na úrovni integrácie vyvíjame systém, ktorý vám umožní vykonávať medzisystémové kontroly a zobraziť výsledok, čo vám umožní nájsť hlavné problémy spojené s importom a interakciou systémov s navzájom.
Samozrejme, stále máme priestor na rast a rozvoj, čo sa týka operačných systémov, a na tom aktívne pracujeme. Môžete si prečítať viac o našom monitorovacom systéme .
Technické skúšky
Orlov Sergey, vedie kompetenčné centrum pre webový a mobilný vývoj
Od začiatku zatvárania fyzických obchodov sme čelili rôznym výzvam z hľadiska vývoja. V prvom rade záťažový ráz ako taký. Je jasné, že ak sa neprijmú vhodné opatrenia, tak pri vysokej záťaži systému sa môže so smutným treskom zmeniť na tekvicu, alebo úplne degradovať výkon, či dokonca stratiť funkčnosť.
Druhým aspektom, o niečo menej zrejmým, je, že systém pod vysokým zaťažením sa musel veľmi rýchlo zmeniť a prispôsobiť sa zmenám v podnikových procesoch. Niekedy aj niekoľkokrát za deň. Veľa firiem má pravidlo, že ak je veľa marketingových aktivít, nie je potrebné robiť v systéme žiadne zmeny. Vôbec žiadne, nech to funguje, kým to funguje.
A mali sme v podstate nekonečný Black Friday, počas ktorého bolo potrebné zmeniť systém. A každá chyba, problém alebo porucha v systéme by bola pre podnik veľmi drahá.
Pri pohľade do budúcnosti poviem, že sa nám tieto testy podarilo zvládnuť, všetky systémy vydržali záťaž, boli ľahko škálovateľné a nezaznamenali sme žiadne globálne technické poruchy.
Existujú štyri piliere, na ktorých spočíva schopnosť systému odolávať vysokým nárazovým zaťaženiam. Prvým z nich je monitoring, o ktorom ste sa dočítali hneď vyššie. Bez zabudovaného monitorovacieho systému je takmer nemožné nájsť systémové úzke miesta. Dobrý monitorovací systém je ako domáce oblečenie; mal by byť pohodlný a prispôsobený vám.
Druhým aspektom je testovanie. Tento bod berieme veľmi vážne: pre každý systém píšeme klasické jednotky, integračné testy, záťažové testy a mnohé ďalšie. Píšeme aj stratégiu testovania a zároveň sa snažíme zvýšiť úroveň testovania do tej miery, že už nepotrebujeme manuálne kontroly.
Tretím pilierom je CI/CD Pipeline. Procesy vytvárania, testovania a nasadzovania aplikácie by mali byť čo najviac automatizované, nemali by dochádzať k manuálnym zásahom. Téma CI/CD Pipeline je pomerne hlboká a dotknem sa jej len krátko. Za zmienku stojí len to, že máme kontrolný zoznam CI/CD Pipeline, ktorým každý produktový tím prechádza s pomocou kompetenčných centier.
A tu je kontrolný zoznam
Týmto spôsobom sa dosiahne veľa cieľov. Ide o vytváranie verzií API a prepínanie funkcií, aby sa predišlo vypúšťaniu a dosahovanie pokrytia rôznych testov na takej úrovni, že testovanie je plne automatizované, nasadenia sú bezproblémové atď.
Štvrtým pilierom sú architektonické princípy a technické riešenia. O architektúre sa môžeme dlho rozprávať, no chcem zdôrazniť pár princípov, na ktoré by som sa chcel zamerať.
Najprv si musíte vybrať špecializované nástroje pre konkrétne úlohy. Áno, znie to ako samozrejmosť a je jasné, že klince treba zatĺkať kladivom a náramkové hodinky rozoberať špeciálnymi skrutkovačmi. Ale v našej dobe sa veľa nástrojov snaží o univerzalizáciu, aby pokryli maximálny segment používateľov: databázy, vyrovnávacie pamäte, rámce a ostatné. Napríklad, ak si vezmete databázu MongoDB, funguje s transakciami viacerých dokumentov a databáza Oracle pracuje s json. A zdalo by sa, že všetko sa dá použiť na všetko. Ak však stojíme za produktivitou, potom musíme jasne pochopiť silné a slabé stránky každého nástroja a použiť tie, ktoré potrebujeme pre našu triedu úloh.
Po druhé, pri navrhovaní systémov musí byť každé zvýšenie zložitosti odôvodnené. Toto musíme mať neustále na pamäti, princíp nízkej väzby pozná každý. Domnievam sa, že by sa mala uplatňovať na úrovni konkrétnej služby, na úrovni celého systému a na úrovni architektonickej krajiny. Dôležitá je aj schopnosť horizontálne škálovať každý komponent systému pozdĺž dráhy zaťaženia. Ak máte túto schopnosť, škálovanie nebude ťažké.
Keď už hovoríme o technických riešeniach, požiadali sme produktové tímy, aby pripravili nový súbor odporúčaní, nápadov a riešení, ktoré implementovali v rámci prípravy na ďalšiu vlnu pracovného zaťaženia.
Keshi
Je potrebné vedome pristupovať k výberu lokálnych a distribuovaných kešiek. Niekedy má zmysel použiť oboje v rámci toho istého systému. Napríklad máme systémy, v ktorých sú niektoré údaje v podstate ukážkovou vyrovnávacou pamäťou, to znamená, že zdroj aktualizácií sa nachádza za samotným systémom a systémy sa nemenia tieto údaje. Na tento prístup používame lokálnu kofeínovú vyrovnávaciu pamäť.
A existujú údaje, ktoré systém počas prevádzky aktívne mení, a tu už používame distribuovanú vyrovnávaciu pamäť s Hazelcastom. Tento prístup nám umožňuje využívať výhody distribuovanej vyrovnávacej pamäte tam, kde sú skutočne potrebné, a minimalizovať servisné náklady na cirkuláciu údajov klastra Hazelcast tam, kde sa bez nich zaobídeme. O keškách sme toho napísali veľa. и .
Okrem toho, zmena serializátora na Kryo v Hazelcast nám dala dobrý impulz. A prechod z ReplicatedMap na IMap + Near Cache v Hazelcast nám umožnil minimalizovať pohyb údajov v klastri.
Malá rada: v prípade hromadného znehodnotenia vyrovnávacej pamäte sa niekedy hodí taktika zahriatia druhej vyrovnávacej pamäte a následného prechodu na ňu. Zdalo by sa, že s týmto prístupom by sme mali získať dvojnásobnú spotrebu pamäte, ale v praxi v tých systémoch, kde sa to praktizovalo, spotreba pamäte klesla.
Reaktívny zásobník
Reaktívny zásobník používame v pomerne veľkom počte systémov. V našom prípade ide o Webflux alebo Kotlin s korutínmi. Reaktívny zásobník je dobrý najmä tam, kde očakávame pomalé vstupno-výstupné operácie. Napríklad volania na pomalé služby, práca so súborovým systémom alebo úložnými systémami.
Najdôležitejšou zásadou je vyhnúť sa blokovaniu hovorov. Reaktívne rámce majú pod kapotou malý počet aktívnych vlákien služieb. Ak si nedbanlivo dovolíme uskutočniť priamy blokovací hovor, ako napríklad volanie ovládača JDBC, systém sa jednoducho zastaví.
Pokúste sa premeniť chyby na vlastnú výnimku pri spustení. Skutočný tok vykonávania programu sa presúva do reaktívnych rámcov a vykonávanie kódu sa stáva nelineárnym. V dôsledku toho je veľmi ťažké diagnostikovať problémy pomocou stôp zásobníka. Riešením by tu bolo vytvoriť jasné, objektívne výnimky pre každú chybu.
ElasticSearch
Pri používaní Elasticsearch nevyberajte nepoužívané údaje. Toto je v zásade tiež veľmi jednoduchá rada, ale najčastejšie sa na to zabúda. Ak potrebujete vybrať viac ako 10 tisíc záznamov naraz, musíte použiť Scroll. Ak chcete použiť analógiu, je to trochu ako kurzor v relačnej databáze.
Nepoužívajte postfilter, pokiaľ to nie je nevyhnutné. S veľkými údajmi v hlavnej vzorke táto operácia značne zaťažuje databázu.
V prípade potreby použite hromadné operácie.
API
Pri navrhovaní API zahrňte požiadavky na minimalizáciu prenášaných údajov. Platí to najmä v súvislosti s frontom: práve na tomto uzle ideme za kanály našich dátových centier a už pracujeme na kanáli, ktorý nás spája s klientom. Ak má najmenší problém, príliš veľká návštevnosť spôsobuje negatívnu používateľskú skúsenosť.
A nakoniec, nevyhadzujte veľa údajov, vyjasnite si zmluvu medzi spotrebiteľmi a dodávateľmi.
Organizačná transformácia
Eroshkina Elena, zástupkyňa riaditeľa pre IT
V momente, keď nastala karanténa a vznikla potreba prudko zrýchliť tempo online rozvoja a zaviesť omnichannel služby, sme už boli v procese organizačnej transformácie.
Časť našej štruktúry bola prenesená do práce podľa princípov a praktík produktového prístupu. Boli vytvorené tímy, ktoré sú teraz zodpovedné za prevádzku a vývoj každého produktu. Zamestnanci v takýchto tímoch sú 100% zapojení a štruktúrujú svoju prácu pomocou Scrumu alebo Kanbanu, v závislosti od toho, čo je pre nich vhodnejšie, nastavujú nasadzovací kanál, implementujú technické postupy, postupy zabezpečenia kvality a mnoho ďalších.
Našťastie väčšina našich produktových tímov bola v oblasti online a omnichannel služieb. To nám umožnilo prejsť do režimu práce na diaľku v čo najkratšom čase (vážne, doslova za dva dni) bez straty efektivity. Prispôsobený proces nám umožnil rýchlo sa prispôsobiť novým pracovným podmienkam a udržať pomerne vysoké tempo dodávania nových funkcií.
Okrem toho potrebujeme posilniť tie tímy, ktoré sú na hranici online podnikania. V tom momente bolo jasné, že to dokážeme len s využitím interných zdrojov. A asi 50 ľudí za dva týždne zmenilo oblasť, kde predtým pracovali a zapojili sa do práce na produkte, ktorý bol pre nich nový.
Nevyžadovalo si to žiadne špeciálne manažérske úsilie, pretože spolu s organizáciou vlastného procesu, technickým zdokonaľovaním produktu a postupmi zabezpečenia kvality učíme naše tímy samoorganizovať sa – riadiť svoj vlastný výrobný proces bez zapojenia administratívnych zdrojov.
Boli sme schopní zamerať naše manažérske zdroje presne tam, kde to bolo v danom momente potrebné – na koordináciu spolu s biznisom: Čo je pre nášho klienta práve teraz dôležité, akú funkcionalitu treba implementovať ako prvú, čo treba urobiť, aby sme zvýšili našu priepustnosť doručovať a spracovávať objednávky. To všetko a jasný vzor umožnili počas tohto obdobia naplniť naše výrobné hodnotové toky tým, čo je skutočne dôležité a potrebné.
Je jasné, že pri práci na diaľku a vysokom tempe zmien, keď obchodné ukazovatele závisia od účasti všetkých, sa nemôžete spoliehať len na vnútorné pocity zo série „Ide nám všetko dobre? Áno, vyzerá to dobre." Sú potrebné objektívne metriky výrobného procesu. Tie máme, sú dostupné každému, koho zaujímajú metriky produktových tímov. V prvom rade samotný tím, obchod, subdodávatelia a manažment.
Raz za dva týždne sa s každým tímom zisťuje status, kde sa 10 minút analyzujú metriky, identifikujú sa úzke miesta vo výrobnom procese a vyvinie sa spoločné riešenie: čo možno urobiť na odstránenie týchto prekážok. Tu môžete okamžite požiadať o pomoc vedenie, ak je akýkoľvek zistený problém mimo zóny vplyvu tímov alebo odbornosti kolegov, ktorí sa už s podobným problémom mohli stretnúť.
Chápeme však, že na to, aby sme sa viacnásobne zrýchlili (a to je presne cieľ, ktorý sme si stanovili), sa musíme ešte veľa naučiť a implementovať to do našej každodennej práce. Práve teraz pokračujeme v rozširovaní nášho produktového prístupu na iné tímy a nové produkty. Na to sme museli zvládnuť pre nás nový formát – online školu metodikov.
Metodológovia, ľudia, ktorí pomáhajú tímom vybudovať proces, nadviazať komunikáciu a zlepšiť efektivitu práce, sú v podstate agentmi zmeny. Práve teraz absolventi našej prvej kohorty pracujú s tímami a pomáhajú im stať sa úspešnými.
Myslím si, že súčasná situácia nám otvára možnosti a perspektívy, ktoré si možno my sami ešte úplne neuvedomujeme. Ale skúsenosti a prax, ktoré práve teraz získavame, nás utvrdzujú v tom, že sme si zvolili správnu cestu rozvoja, tieto nové príležitosti si nenecháme ujsť ani v budúcnosti a budeme vedieť rovnako efektívne reagovať na výzvy, ktorým bude Sportmaster čeliť.
Závery
V tejto ťažkej dobe sme sformulovali hlavné princípy, na ktorých stojí vývoj softvéru, ktoré, myslím, budú relevantné pre každú spoločnosť, ktorá sa tým zaoberá.
Ľudia. Na tomto všetko spočíva. Zamestnancov musí práca baviť a musia rozumieť cieľom spoločnosti a cieľom produktov, na ktorých pracujú. A, samozrejme, mohli sa profesionálne rozvíjať.
Технология. Je potrebné, aby spoločnosť dospela k práci so svojim technologickým zásobníkom a vybudovala si kompetencie tam, kde je to skutočne potrebné. Znie to veľmi jednoducho a jasne. A veľmi často ignorované.
procesy. Je dôležité správne zorganizovať prácu produktových tímov a kompetenčných centier, nadviazať interakciu s podnikom, aby ste s ním mohli spolupracovať ako s partnerom.
Vo všeobecnosti sme takto prežili. Hlavná téza našej doby sa opäť raz potvrdila ráznym kliknutím na čelo
Aj keď ste obrovský offline podnik s mnohými obchodmi a množstvom miest, kde pôsobíte, rozvíjajte svoje online podnikanie. Nie je to len doplnkový predajný kanál alebo krásna aplikácia, cez ktorú si môžete aj niečo kúpiť (a aj preto, že konkurenti ich majú tiež krásne). Toto nie je rezervná pneumatika pre každý prípad, ktorá vám pomôže prekonať búrku.
To je absolútna nevyhnutnosť. Na čo musia byť pripravené nielen vaše technické možnosti a infraštruktúra, ale aj vaši ľudia a procesy. Koniec koncov, za pár hodín môžete rýchlo kúpiť ďalšiu pamäť, priestor, nasadiť nové inštancie atď. Na to však treba ľudí a procesy pripraviť vopred.
Zdroj: hab.com