Ahoj!
Jmenuji se Michail, jsem zástupcem ředitele IT ve společnosti Sportmaster. Chci se podělit o příběh, jak jsme se vypořádali s výzvami, které se objevily během pandemie.
V prvních dnech nové reality obvyklý offline obchodní formát Sportmaster zamrzl a zatížení našeho online kanálu, především z hlediska doručení na adresu klienta, se zvýšilo 10krát. Během několika týdnů jsme přeměnili gigantický offline byznys na online a přizpůsobili službu potřebám našich klientů.
V podstatě to, co bylo v podstatě naší vedlejší činností, se stalo naší hlavní činností. Význam každé online objednávky extrémně vzrostl. Bylo potřeba šetřit každý rubl, který klient do firmy přinesl.
Abychom mohli rychle reagovat na požadavky zákazníků, otevřeli jsme další kontaktní centrum v hlavním sídle společnosti a nyní můžeme přijímat asi 285 tisíc hovorů týdně. Zároveň jsme přesunuli 270 prodejen do nového bezkontaktního a bezpečného provozního formátu, který umožnil zákazníkům přijímat objednávky a zaměstnancům udržet si práci.
Během transformačního procesu jsme narazili na dva hlavní problémy. Za prvé, zatížení našich online zdrojů se výrazně zvýšilo (Sergey vám řekne, jak jsme se s tím vypořádali). Za druhé, tok vzácných (před COVID) operací se mnohonásobně zvýšil, což zase vyžadovalo velké množství rychlé automatizace. Abychom tento problém vyřešili, museli jsme rychle přesunout zdroje z oblastí, které byly dříve hlavní. Elena vám řekne, jak jsme se s tím vypořádali.
Provozování online služeb
Kolesnikov Sergey, zodpovědný za provoz internetového obchodu a mikroslužeb
Od chvíle, kdy se naše maloobchodní prodejny začaly zavírat návštěvníkům, jsme začali zaznamenávat nárůst metrik, jako je počet uživatelů, počet objednávek zadaných v naší aplikaci a počet požadavků na aplikace.
Počet objednávek od 18. března do 31. březnaPočet požadavků na online platební mikroslužbyPočet objednávek zadaných na webu
V prvním grafu vidíme, že nárůst byl přibližně 14krát, ve druhém - 4krát. Metriku doby odezvy našich aplikací považujeme za nejvíce orientační.
V tomto grafu vidíme odezvu front a aplikací a sami jsme určili, že jsme žádný růst jako takový nezaznamenali.
Je to dáno především tím, že jsme na konci roku 2019 zahájili přípravné práce. Nyní jsou naše služby vyhrazeny, odolnost proti chybám je zajištěna na úrovni fyzických serverů, virtualizačních systémů, dockerů a služeb v nich. Kapacita našich serverových zdrojů nám zároveň umožňuje vydržet vícenásobné zatížení.
Hlavním nástrojem, který nám v celém tomto příběhu pomohl, byl náš monitorovací systém. Pravda, až donedávna jsme neměli jediný systém, který by nám umožňoval shromažďovat metriky na všech úrovních, od úrovně fyzického vybavení a hardwaru až po úroveň obchodních metrik.
Formálně ve firmě monitoring probíhal, ale zpravidla byl rozptýlený a byl v oblasti odpovědnosti konkrétních oddělení. Ve skutečnosti, když došlo k incidentu, téměř nikdy jsme neměli společnou představu o tom, co se přesně stalo, neexistovala žádná komunikace a často to vedlo k běhání v kruzích, abychom našli a izolovali problém, aby mohl být vyřešen.
V určitém okamžiku jsme si řekli a rozhodli, že už toho máme dost – potřebujeme jednotný systém, abychom viděli celý obraz v plném rozsahu. Hlavní technologie, které jsou součástí našeho stacku, jsou Zabbix jako centrum pro ukládání výstrah a metrik, Prometheus pro sběr a ukládání metrik aplikací, Stack ELK pro protokolování a ukládání dat z celého monitorovacího systému, stejně jako Grafana pro vizualizaci, Swagger, Docker a další užitečné a věci, které jsou vám známé.
Využíváme přitom nejen technologie dostupné na trhu, ale vyvíjíme i některé vlastní. Děláme například služby pro integraci systémů mezi sebou, tedy nějaké API pro sběr metrik. Plus pracujeme na vlastních monitorovacích systémech – na úrovni obchodních metrik využíváme UI testy. A také robot v Telegramu, který informuje týmy.
Snažíme se také zpřístupnit monitorovací systém týmům, aby si mohly své metriky samostatně ukládat a pracovat s nimi, včetně nastavení upozornění na některé úzké metriky, které se příliš nepoužívají.
V celém systému se snažíme o proaktivitu a co nejrychlejší lokalizaci incidentů. V poslední době navíc výrazně vzrostl počet našich mikroslužeb a systémů a odpovídajícím způsobem vzrostl i počet integrací. A v rámci optimalizace procesu diagnostiky incidentů na úrovni integrace vyvíjíme systém, který umožňuje provádět mezisystémové kontroly a zobrazovat výsledek, což umožňuje najít hlavní problémy spojené s importy a interakcí systémů s navzájem.
Samozřejmě máme stále prostor pro růst a rozvoj, co se týče operačních systémů, a na tom aktivně pracujeme. Můžete si přečíst více o našem monitorovacím systému .
Technické zkoušky
Orlov Sergey, vede kompetenční centrum pro webový a mobilní vývoj
Od začátku uzavírání kamenných obchodů jsme čelili různým výzvám z hlediska vývoje. V první řadě zátěžový ráz jako takový. Je jasné, že pokud nebudou přijata příslušná opatření, pak se při vysoké zátěži systému může se smutným třeskem proměnit v dýni, nebo zcela degradovat výkon, či dokonce ztratit funkčnost.
Druhým aspektem, o něco méně zřejmým, je, že systém pod vysokou zátěží bylo nutné velmi rychle změnit a přizpůsobit se změnám v obchodních procesech. Někdy i několikrát za den. Mnoho firem má pravidlo, že pokud je hodně marketingových aktivit, není potřeba v systému provádět žádné změny. Vůbec žádný, ať to funguje, dokud to jde.
A měli jsme v podstatě nekonečný Black Friday, během kterého bylo nutné změnit systém. A jakákoliv chyba, problém nebo selhání v systému by bylo pro podnik velmi nákladné.
Při pohledu do budoucna řeknu, že se nám tyto testy podařilo zvládnout, všechny systémy vydržely zátěž, byly snadno škálovatelné a nezaznamenali jsme žádné globální technické poruchy.
Existují čtyři pilíře, na kterých spočívá schopnost systému odolat vysokému nárazovému zatížení. První z nich je monitoring, o kterém jste se dočetli těsně výše. Bez vestavěného monitorovacího systému je téměř nemožné najít úzká místa systému. Dobrý monitorovací systém je jako domácí oblečení, měl by být pohodlný a šitý na míru vám.
Druhým aspektem je testování. Tento bod bereme velmi vážně: pro každý systém píšeme klasické jednotky, integrační testy, zátěžové testy a mnoho dalších. Píšeme také testovací strategii a zároveň se snažíme zvýšit úroveň testování do té míry, že již nepotřebujeme ruční kontroly.
Třetím pilířem je CI/CD Pipeline. Procesy vytváření, testování a nasazování aplikace by měly být co nejvíce automatizovány, neměly by docházet k ručním zásahům. Téma CI/CD Pipeline je poměrně hluboké a dotknu se ho jen krátce. Za zmínku stojí pouze to, že máme kontrolní seznam CI/CD Pipeline, kterým prochází každý produktový tým s pomocí kompetenčních center.
A tady je kontrolní seznam
Tímto způsobem je dosaženo mnoha cílů. Jedná se o verzování API a přepínání funkcí, abyste se vyhnuli vydávání a dosahování pokrytí různých testů na takové úrovni, že testování je plně automatizované, nasazení je bezproblémové a tak dále.
Čtvrtým pilířem jsou architektonické principy a technická řešení. O architektuře můžeme mluvit hodně dlouho, ale chci zdůraznit pár principů, na které bych se rád zaměřil.
Nejprve si musíte vybrat specializované nástroje pro konkrétní úkoly. Ano, zní to jako samozřejmost a je jasné, že hřebíky se mají zatloukat kladivem a náramkové hodinky rozebírat speciálními šroubováky. Ale v naší době se mnoho nástrojů snaží o univerzalizaci, aby pokryly maximální segment uživatelů: databáze, cache, frameworky a ostatní. Pokud například vezmete databázi MongoDB, funguje s transakcemi s více dokumenty a databáze Oracle pracuje s json. A zdálo by se, že všechno se dá použít na všechno. Pokud ale stojíme za produktivitou, pak musíme jasně pochopit silné a slabé stránky každého nástroje a použít ty, které potřebujeme pro naši třídu úkolů.
Za druhé, při navrhování systémů musí být každé zvýšení složitosti odůvodněno. To musíme mít neustále na paměti, princip nízké vazby zná každý. Domnívám se, že by měl být aplikován na úrovni konkrétní služby, na úrovni celého systému a na úrovni architektonické krajiny. Důležitá je také schopnost horizontálně škálovat každou komponentu systému podél dráhy zatížení. Pokud máte tuto schopnost, škálování nebude obtížné.
Když už mluvíme o technických řešeních, požádali jsme produktové týmy, aby připravily nový soubor doporučení, nápadů a řešení, které implementovaly v rámci přípravy na další vlnu zátěže.
Keshi
K výběru lokálních a distribuovaných keší je potřeba přistupovat vědomě. Někdy má smysl používat oba v rámci jednoho systému. Například máme systémy, ve kterých jsou některá data v podstatě ukázkovou mezipamětí, to znamená, že zdroj aktualizací je umístěn za systémem samotným a systémy se nemění tyto údaje. Pro tento přístup používáme místní Caffeine Cache.
A jsou data, která systém během provozu aktivně mění, a zde již využíváme distribuovanou cache s Hazelcastem. Tento přístup nám umožňuje využívat výhody distribuované mezipaměti tam, kde jsou skutečně potřeba, a minimalizovat servisní náklady na cirkulaci dat clusteru Hazelcast tam, kde se bez nich obejdeme. O keškách jsme toho napsali hodně. и .
Kromě toho nám změna serializátoru na Kryo v Hazelcast poskytla dobrou podporu. A přechod z ReplicatedMap na IMap + Near Cache v Hazelcast nám umožnil minimalizovat přesun dat napříč clusterem.
Malá rada: v případě hromadného znehodnocení cache se občas hodí taktika zahřátí druhé cache a následného přepnutí na ni. Zdálo by se, že s tímto přístupem bychom měli získat dvojnásobnou spotřebu paměti, ale v praxi v systémech, kde se to praktikovalo, spotřeba paměti klesla.
Reaktivní zásobník
Reaktivní zásobník používáme v poměrně velkém počtu systémů. V našem případě se jedná o Webflux nebo Kotlin s corutinami. Reaktivní zásobník je zvláště dobrý tam, kde očekáváme pomalé vstupně-výstupní operace. Například volání pomalých služeb, práce se souborovým systémem nebo úložnými systémy.
Nejdůležitější zásadou je vyhnout se blokování hovorů. Reaktivní rámce mají pod kapotou malý počet podprocesů živých služeb. Pokud si neopatrně dovolíme provést přímé blokovací volání, jako je volání ovladače JDBC, systém se jednoduše zastaví.
Pokuste se proměnit chyby ve vlastní výjimku za běhu. Vlastní tok provádění programu se posouvá do reaktivních rámců a provádění kódu se stává nelineární. V důsledku toho je velmi obtížné diagnostikovat problémy pomocí trasování zásobníku. A řešením by zde bylo vytvořit jasné, objektivní výjimky pro každou chybu.
Elastickýsearch
Při použití Elasticsearch nevybírejte nepoužívaná data. To je v zásadě také velmi jednoduchá rada, ale nejčastěji se na to zapomíná. Pokud potřebujete vybrat více než 10 tisíc záznamů najednou, musíte použít Scroll. Abychom použili analogii, je to trochu jako kurzor v relační databázi.
Pokud to není nutné, nepoužívejte postfiltr. S velkými daty v hlavním vzorku tato operace značně zatěžuje databázi.
V případě potřeby použijte hromadné operace.
API
Při návrhu API zahrňte požadavky na minimalizaci přenášených dat. To platí zejména v souvislosti s frontou: právě na tomto místě překračujeme kanály našich datových center a již pracujeme na kanálu, který nás spojuje s klientem. Pokud má sebemenší problém, příliš velký provoz způsobuje negativní uživatelský dojem.
A nakonec nevyhazujte spoustu údajů, ujasněte si smlouvu mezi spotřebiteli a dodavateli.
Organizační transformace
Eroshkina Elena, zástupkyně ředitele pro IT
V okamžiku, kdy nastala karanténa a vyvstala potřeba prudce zrychlit tempo online vývoje a zavést omnichannel služby, jsme již byli v procesu organizační transformace.
Část naší struktury byla převedena do práce podle zásad a praktik produktového přístupu. Byly vytvořeny týmy, které jsou nyní odpovědné za provoz a vývoj každého produktu. Zaměstnanci v takových týmech jsou 100% zapojeni a strukturují svou práci pomocí Scrumu nebo Kanbanu, v závislosti na tom, co je pro ně výhodnější, nastavují postup nasazení, implementují technické postupy, postupy pro zajištění kvality a mnoho dalšího.
Naštěstí většina našich produktových týmů byla v oblasti online a omnichannel služeb. To nám umožnilo přejít do režimu práce na dálku v co nejkratším čase (vážně, doslova za dva dny) bez ztráty efektivity. Přizpůsobený proces nám umožnil rychle se přizpůsobit novým pracovním podmínkám a udržet poměrně vysoké tempo dodávání nových funkcí.
Navíc potřebujeme posílit ty týmy, které jsou na hranici online podnikání. V tu chvíli bylo jasné, že to můžeme udělat pouze s využitím interních zdrojů. A asi 50 lidí během dvou týdnů změnilo oblast, kde předtím pracovali, a zapojilo se do práce na produktu, který pro ně byl nový.
To nevyžadovalo žádné zvláštní úsilí managementu, protože spolu s organizováním vlastního procesu, technickým zlepšováním produktu a postupy zajišťování kvality učíme naše týmy samoorganizovat se – řídit svůj vlastní výrobní proces bez zapojení administrativních zdrojů.
Byli jsme schopni zaměřit naše manažerské zdroje přesně tam, kde to bylo v danou chvíli potřeba – na koordinaci společně s obchodem: Co je pro našeho klienta právě teď důležité, jakou funkcionalitu bychom měli implementovat jako první, co je třeba udělat pro zvýšení naší propustnosti doručovat a vyřizovat objednávky. To vše a jasný vzor umožnily během tohoto období nabít naše výrobní hodnotové toky tím, co je skutečně důležité a nezbytné.
Je jasné, že při práci na dálku a vysokém tempu změn, kdy obchodní ukazatele závisí na účasti všech, nelze spoléhat pouze na vnitřní pocity ze série „Jde nám všechno dobře? Ano, vypadá to dobře." Jsou zapotřebí objektivní metriky výrobního procesu. Ty máme, jsou dostupné každému, koho zajímají metriky produktových týmů. V první řadě samotný tým, obchod, subdodavatelé a management.
Jednou za dva týdny se s každým týmem zjišťuje status, kde se 10 minut analyzují metriky, identifikují se úzká místa ve výrobním procesu a vyvine se společné řešení: co lze udělat pro odstranění těchto úzkých míst. Zde můžete okamžitě požádat o pomoc vedení, pokud je jakýkoli identifikovaný problém mimo zónu vlivu týmů nebo odbornosti kolegů, kteří se s podobným problémem již mohli setkat.
Chápeme však, že abychom se vícenásobně zrychlili (a to je přesně cíl, který jsme si stanovili), musíme se ještě hodně učit a implementovat to do naší každodenní práce. Právě teď pokračujeme v rozšiřování našeho produktového přístupu na další týmy a nové produkty. K tomu jsme museli zvládnout pro nás nový formát – online školu metodiků.
Metodologové, lidé, kteří pomáhají týmům budovat proces, navazovat komunikaci a zlepšovat efektivitu práce, jsou v podstatě činiteli změny. Právě teď absolventi naší první kohorty pracují s týmy a pomáhají jim stát se úspěšnými.
Myslím, že současná situace nám otevírá možnosti a vyhlídky, které si možná sami ještě plně neuvědomujeme. Zkušenosti a praxe, které nyní získáváme, ale potvrzují, že jsme zvolili správnou cestu rozvoje, tyto nové příležitosti si v budoucnu nenecháme ujít a budeme schopni stejně efektivně reagovat na výzvy, kterým bude Sportmaster čelit.
Závěry
V této těžké době jsme formulovali hlavní principy, na kterých stojí vývoj softwaru, které, myslím, budou relevantní pro každou společnost, která se tím zabývá.
lidé. Na tom vše spočívá. Zaměstnance musí práce bavit a musí rozumět cílům společnosti a cílům produktů, na kterých pracují. A samozřejmě se mohli profesně rozvíjet.
Технология. Je nutné, aby firma zaujala vyzrálý přístup k práci se svým technologickým stackem a vybudovala si kompetence tam, kde je to skutečně potřeba. Zní to velmi jednoduše a jasně. A velmi často ignorován.
Procesy. Je důležité správně zorganizovat práci produktových týmů a kompetenčních center, navázat interakci s podnikem, aby s ním mohl spolupracovat jako partner.
Obecně vzato, takhle jsme přežili. Hlavní teze naší doby se opět potvrdila, a to zvučným kliknutím na čelo
I když jste obrovský offline podnik s mnoha obchody a spoustou měst, kde působíte, rozvíjejte své online podnikání. Nejde jen o doplňkový prodejní kanál nebo krásnou aplikaci, přes kterou si také můžete něco koupit (a také proto, že konkurenti to mají také krásné). Toto není rezervní pneumatika pro každý případ, která vám pomůže přečkat bouři.
To je absolutní nutnost. Na což musí být připraveny nejen vaše technické možnosti a infrastruktura, ale také vaši lidé a procesy. Koneckonců, můžete rychle koupit další paměť, prostor, nasadit nové instance atd. během pár hodin. Na to je ale potřeba lidi a procesy připravit předem.
Zdroj: www.habr.com