Какво ни помогна бързо да се адаптираме към онлайн търговията в новите условия

Привет!

Казвам се Михаил, аз съм заместник-директор ИТ във фирма Спортмастер. Искам да споделя историята за това как се справихме с предизвикателствата, възникнали по време на пандемията.

В първите дни на новите реалности обичайният офлайн търговски формат на Sportmaster замръзна и натоварването на нашия онлайн канал, предимно по отношение на доставката до адреса на клиента, се увеличи 10 пъти. Само за няколко седмици трансформирахме гигантски офлайн бизнес в онлайн и адаптирахме услугата към нуждите на нашите клиенти.

По принцип това, което по същество беше наша странична дейност, се превърна в наш основен бизнес. Значението на всяка онлайн поръчка се увеличи изключително много. Беше необходимо да се спести всяка рубла, която клиентът донесе на компанията. 

За да отговорим бързо на заявките на клиентите, открихме допълнителен контактен център в централния офис на компанията, който вече може да приема около 285 хиляди обаждания седмично. В същото време преместихме 270 магазина в нов безконтактен и безопасен формат на работа, което позволи на клиентите да получават поръчки, а на служителите да запазят работните си места.

По време на процеса на трансформация се натъкнахме на два основни проблема. Първо, натоварването на нашите онлайн ресурси значително се увеличи (Сергей ще ви каже как се справихме с това). Второ, потокът от редки (преди COVID) операции се е увеличил многократно, което от своя страна изисква голямо количество бърза автоматизация. За да разрешим този проблем, трябваше бързо да прехвърлим ресурси от области, които преди бяха основните. Елена ще ви каже как се справихме с това.

Операция на онлайн услуги

Колесников Сергей, отговарящ за работата на онлайн магазина и микроуслугите

От момента, в който нашите магазини за търговия на дребно започнаха да се затварят за посетители, ние започнахме да регистрираме увеличение на показателите като броя на потребителите, броя на поръчките, направени в нашето приложение и броя на заявките към приложенията. 

Брой поръчки от 18 март до 31 мартБрой заявки към микроуслуги за онлайн плащанеБрой поръчки, направени на уебсайта

На първата графика виждаме, че увеличението е приблизително 14 пъти, на втората - 4 пъти. Смятаме, че метриката за време за реакция на нашите приложения е най-показателна. 

В тази графика виждаме реакцията на фронтовете и приложенията и за себе си установихме, че не забелязваме никакъв растеж като такъв.

Това се дължи преди всичко на факта, че започнахме подготвителна работа в края на 2019 г. Сега нашите услуги са запазени, толерантността към грешки е осигурена на ниво физически сървъри, системи за виртуализация, докери и услуги в тях. В същото време капацитетът на нашите сървърни ресурси ни позволява да издържаме на множество натоварвания.

Основният инструмент, който ни помогна в цялата тази история, беше нашата система за мониторинг. Вярно е, че доскоро нямахме нито една система, която да ни позволи да събираме показатели на всички нива, от нивото на физическо оборудване и хардуер до нивото на бизнес показатели. 

Формално в компанията е имало наблюдение, но по правило то е разпръснато и е в зоната на отговорност на отделни отдели. Всъщност, когато се случи инцидент, почти никога не сме имали общо разбиране какво точно се е случило, нямаше комуникация и често това водеше до тичане в кръг, за да намерим и изолираме проблема, за да може да бъде отстранен.

По някое време се замислихме и решихме, че ни стига да търпим това – нужна ни е единна система, за да видим цялостната картина. Основните технологии, които са включени в нашия стек, са Zabbix като център за предупреждение и съхранение на метрики, Prometheus за събиране и съхраняване на метрики на приложения, Stack ELK за регистриране и съхраняване на данни от цялата система за наблюдение, както и Grafana за визуализация, Swagger, Docker и други полезни неща, които са ви познати.

В същото време ние използваме не само наличните на пазара технологии, но и разработваме някои свои. Например, ние правим услуги за интегриране на системи помежду си, тоест някакъв вид API за събиране на показатели. Освен това работим върху нашите собствени системи за наблюдение - на ниво бизнес показатели използваме UI тестове. А също и бот в Telegram за уведомяване на екипи.

Също така се опитваме да направим системата за мониторинг достъпна за екипите, така че те да могат независимо да съхраняват и работят с техните показатели, включително настройване на предупреждения за някои тесни показатели, които не се използват широко. 

В цялата система се стремим към проактивност и възможно най-бързо локализиране на инциденти. В допълнение, броят на нашите микроуслуги и системи нарасна значително напоследък и съответно броят на интеграциите нарасна. И като част от оптимизирането на процеса на диагностициране на инциденти на ниво интеграция, ние разработваме система, която ви позволява да провеждате междусистемни проверки и да показвате резултата, което ви позволява да намерите основните проблеми, свързани с импортирането и взаимодействието на системите с взаимно. 

Разбира се, все още имаме място за растеж и развитие по отношение на операционните системи и работим активно върху това. Можете да прочетете повече за нашата система за мониторинг тук. 

Технически тестове 

Сергей Орлов, ръководи центъра за компетентност за уеб и мобилно развитие

Откакто започна затварянето на физическите магазини, се сблъскахме с различни предизвикателства от гледна точка на развитието. На първо място, скокът на натоварването като такъв. Ясно е, че ако не се вземат подходящи мерки, тогава когато се приложи голямо натоварване към системата, тя може да се превърне в тиква с тъжен взрив или напълно да влоши производителността си или дори да загуби своята функционалност.

Вторият аспект, малко по-малко очевиден, е, че системата под голямо натоварване трябваше да се промени много бързо, адаптирайки се към промените в бизнес процесите. Понякога по няколко пъти на ден. Много компании имат правило, че ако има много маркетингова дейност, не е необходимо да се правят промени в системата. Никакви, нека работи, докато работи.

И по същество имахме безкраен Черен петък, по време на който беше необходимо да променим системата. И всяка грешка, проблем или повреда в системата ще струва много скъпо на бизнеса.

Гледайки напред, ще кажа, че успяхме да се справим с тези тестове, всички системи издържаха на натоварването, бяха лесно мащабирани и не изпитахме никакви глобални технически повреди.

Има четири стълба, на които се крепи способността на системата да издържа на високи натоварвания от удар. Първият от тях е мониторингът, за който прочетохте малко по-горе. Без вградена система за наблюдение е почти невъзможно да се намерят тесни места в системата. Добрата система за наблюдение е като домашно облекло, тя трябва да е удобна и съобразена с вас.

Вторият аспект е тестването. Ние приемаме тази точка много сериозно: ние пишем класически модули, интеграционни тестове, тестове за натоварване и много други за всяка система. Ние също така пишем стратегия за тестване и в същото време се опитваме да повишим нивото на тестване до такава степен, че вече да не се нуждаем от ръчни проверки.

Третият стълб е CI/CD Pipeline. Процесите на изграждане, тестване и внедряване на приложение трябва да бъдат автоматизирани, доколкото е възможно; не трябва да има ръчна намеса. Темата за CI/CD Pipeline е доста дълбока и ще я засегна само накратко. Струва си да споменем само, че имаме контролен списък за CI/CD Pipeline, през който преминава всеки продуктов екип с помощта на центрове за компетентност.

А ето и контролния списък

По този начин се постигат много цели. Това е API версия и превключване на функции, за да се избегне влакът за освобождаване и да се постигне покритие на различни тестове на такова ниво, че тестването да е напълно автоматизирано, внедряването да е безпроблемно и т.н.

Четвъртият стълб са архитектурните принципи и техническите решения. Можем да говорим много за архитектурата дълго време, но искам да подчертая няколко принципа, върху които бих искал да се съсредоточа.

Първо, трябва да изберете специализирани инструменти за конкретни задачи. Да, звучи очевидно и е ясно, че гвоздеите трябва да се забиват с чук, а ръчните часовници да се разглобяват със специални отвертки. Но в нашата епоха много инструменти се стремят към универсализация, за да покрият максималния сегмент от потребители: бази данни, кешове, рамки и останалото. Например, ако вземете базата данни MongoDB, тя работи с транзакции с множество документи, а базата данни Oracle работи с json. И изглежда, че всичко може да се използва за всичко. Но ако подкрепяме производителността, тогава трябва ясно да разберем силните и слабите страни на всеки инструмент и да използваме онези, от които се нуждаем за нашия клас задачи. 

На второ място, когато се проектират системи, всяко увеличаване на сложността трябва да бъде обосновано. Трябва постоянно да имаме предвид това; принципът на ниското свързване е известен на всички. Смятам, че трябва да се прилага и на ниво конкретна услуга, и на ниво цялостна система, и на ниво архитектурен пейзаж. Способността за хоризонтално мащабиране на всеки системен компонент по пътя на натоварване също е важна. Ако имате тази способност, мащабирането няма да е трудно.

Говорейки за технически решения, помолихме продуктовите екипи да подготвят нов набор от препоръки, идеи и решения, които те внедриха в подготовка за следващата вълна на натоварване.

Кеши

Необходимо е съзнателно да се подхожда към избора на локални и разпределени кешове. Понякога има смисъл да се използват и двете в рамките на една и съща система.Например, имаме системи, в които някои от данните са по същество витринен кеш, тоест източникът на актуализации се намира зад самата система и системите не се променят тези данни. За този подход използваме местен Caffeine Cache. 

И има данни, че системата активно се променя по време на работа и тук вече използваме разпределен кеш с Hazelcast. Този подход ни позволява да използваме предимствата на разпределения кеш, където те наистина са необходими, и да минимизираме разходите за обслужване на циркулиращите данни на клъстера Hazelcast, където можем да се справим без него. Писали сме много за кешовете. тук и тук.

В допълнение, промяната на сериализатора на Kryo в Hazelcast ни даде добър тласък. И преходът от ReplicatedMap към IMap + Near Cache в Hazelcast ни позволи да минимизираме движението на данни в клъстера. 

Малък съвет: в случай на масова невалидност на кеша, понякога е приложима тактиката за загряване на втория кеш и след това превключване към него. Изглежда, че с този подход трябва да получим двойно потребление на памет, но на практика в онези системи, където това се практикува, потреблението на памет намалява.

Реактивен стек

Използваме реактивния стек в доста голям брой системи. В нашия случай това е Webflux или Kotlin със съпрограмми. Реактивният стек е особено добър там, където очакваме бавни входно-изходни операции. Например повиквания към бавни услуги, работа с файловата система или системите за съхранение.

Най-важният принцип е да избягвате блокиране на повиквания. Реактивните рамки имат малък брой нишки на живи услуги, работещи под капака. Ако небрежно си позволим да направим директно блокиращо повикване, като повикване на JDBC драйвер, системата просто ще спре. 

Опитайте се да превърнете грешките във свое собствено изключение по време на изпълнение. Действителният поток на изпълнение на програмата се измества към реактивни рамки и изпълнението на кода става нелинейно. В резултат на това е много трудно да се диагностицират проблеми с помощта на проследяване на стека. И решението тук би било да се създадат ясни, обективни изключения по време на изпълнение за всяка грешка.

Elasticsearch

Когато използвате Elasticsearch, не избирайте неизползвани данни. Това по принцип също е много прост съвет, но най-често това е, което се забравя. Ако трябва да изберете повече от 10 хиляди записа наведнъж, трябва да използвате Превъртане. Ако използваме аналогия, това е малко като курсор в релационна база данни. 

Не използвайте постфилтър, освен ако не е необходимо. При големи данни в основната извадка тази операция натоварва значително базата данни. 

Използвайте групови операции, където е приложимо.

API

Когато проектирате API, включете изисквания за минимизиране на предаваните данни. Това е особено вярно във връзка с фронта: именно на това кръстовище излизаме отвъд каналите на нашите центрове за данни и вече работим върху канала, който ни свързва с клиента. Ако има и най-малък проблем, твърде много трафик причинява отрицателно потребителско изживяване.

И накрая, не изхвърляйте цял куп данни, бъдете ясни относно договора между потребители и доставчици.

Организационна трансформация

Ерошкина Елена, заместник-директор по ИТ

В момента, в който настъпи карантина и възникна необходимостта от рязко увеличаване на темпото на онлайн развитие и въвеждане на omnichannel услуги, ние вече бяхме в процес на организационна трансформация. 

Част от нашата структура беше прехвърлена да работи по принципите и практиките на продуктовия подход. Сформирани са екипи, които вече отговарят за работата и развитието на всеки продукт. Служителите в такива екипи са 100% включени и структурират работата си с помощта на Scrum или Kanban, в зависимост от това, което е за предпочитане за тях, като създават конвейер за внедряване, прилагат технически практики, практики за осигуряване на качество и много други.

За късмет по-голямата част от нашите продуктови екипи бяха в областта на онлайн и омниканални услуги. Това ни позволи да преминем към дистанционен режим на работа в най-кратки срокове (сериозно, буквално за два дни) без загуба на ефективност. Персонализираният процес ни позволи бързо да се адаптираме към новите условия на работа и да поддържаме доста висок темп на доставка на нова функционалност.

Освен това имаме нужда да подсилим тези екипи, които са на границата на онлайн бизнеса. В този момент стана ясно, че можем да направим това само с вътрешни ресурси. И около 50 души за две седмици промениха областта, в която са работили преди, и се включиха в работата по продукт, който беше нов за тях. 

Това не изискваше специални управленски усилия, тъй като наред с организирането на собствен процес, техническото усъвършенстване на продукта и практиките за осигуряване на качеството, ние учим нашите екипи да се самоорганизират - да управляват собствения си производствен процес, без да ангажираме административен ресурс.

Успяхме да съсредоточим нашите управленски ресурси точно там, където беше необходимо в този момент - върху координирането заедно с бизнеса: какво е важно за нашия клиент в момента, коя функционалност трябва да бъде внедрена първо, какво трябва да се направи, за да увеличим пропускателната способност за доставка и обработка на поръчки. Всичко това и ясният модел за подражание направиха възможно през този период да заредим нашите производствени потоци от стойност с това, което е наистина важно и необходимо. 

Ясно е, че при дистанционна работа и висок темп на промяна, когато бизнес показателите зависят от участието на всички, не можете да разчитате само на вътрешни усещания от поредицата „Всичко върви ли добре при нас? Да, изглежда добре." Необходими са обективни показатели на производствения процес. Имаме такива, достъпни са за всеки, който се интересува от показателите на продуктовите екипи. На първо място, самият екип, бизнесът, подизпълнителите и мениджмънтът.

Веднъж на всеки две седмици се провежда статус с всеки екип, където се анализират показателите за 10 минути, идентифицират се тесните места в производствения процес и се разработва съвместно решение: какво може да се направи, за да се премахнат тези тесни места. Тук можете незабавно да поискате помощ от ръководството, ако някой идентифициран проблем е извън зоната на влияние на екипите, или експертизата на колеги, които може вече да са се сблъскали с подобен проблем.

Ние обаче разбираме, че за да се ускорим многократно (и точно това е целта, която си поставяме), все още трябва да научим много и да го приложим в ежедневната си работа. Точно сега ние продължаваме да мащабираме нашия продуктов подход към други екипи и нови продукти. За да направим това, трябваше да овладеем нов за нас формат - онлайн училище за методисти.

Методолозите, хората, които помагат на екипите да изградят процес, да установят комуникации и да подобрят ефективността на работата, са по същество агенти на промяната. В момента възпитаниците на нашата първа група работят с екипи и им помагат да станат успешни. 

Мисля, че сегашната ситуация разкрива пред нас възможности и перспективи, които може би самите ние все още не осъзнаваме напълно. Но опитът и практиката, които натрупваме в момента, потвърждават, че сме избрали правилния път на развитие, няма да пропуснем тези нови възможности в бъдеще и ще можем да отговорим също толкова ефективно на предизвикателствата, пред които ще се изправи Sportmaster.

Данни

В този труден момент ние формулирахме основните принципи, на които се основава разработката на софтуер, които смятам, че ще бъдат актуални за всяка компания, която се занимава с това.

Хора. На това почива всичко. Служителите трябва да се наслаждават на работата си и да разбират целите на компанията и целите на продуктите, върху които работят. И, разбира се, те биха могли да се развиват професионално. 

Технология. Необходимо е компанията да възприеме зрял подход към работата със своя технологичен стек и да изгради компетенции там, където наистина е необходимо. Звучи много просто и очевидно. И много често пренебрегвани.

процеси. Важно е правилно да се организира работата на продуктовите екипи и центровете за компетентност, да се установи взаимодействие с бизнеса, за да се работи с него като партньор.

Общо взето така оцеляхме. Основната теза на нашето време беше потвърдена за пореден път, със звънко щракане на челото

Дори ако сте огромен офлайн бизнес с много магазини и куп градове, в които оперирате, развивайте своя онлайн бизнес. Това не е просто допълнителен канал за продажби или красиво приложение, чрез което можете също да купите нещо (а също и защото конкурентите също имат красиви). Това не е резервна гума за всеки случай, която да ви помогне да преодолеете бурята.

Това е абсолютна необходимост. За което трябва да са подготвени не само вашите технически възможности и инфраструктура, но и вашите хора и процеси. В края на краищата можете бързо да закупите допълнителна памет, пространство, да внедрите нови копия и т.н. за няколко часа. Но хората и процесите трябва да бъдат предварително подготвени за това.

Източник: www.habr.com