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

Здравейте!

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

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

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

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

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

Експлоатация на онлайн услуги

Колесников Сергей, отговаря за експлоатацията на интернет магазина и микросервисите

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

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

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

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

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

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

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

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

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

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

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

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

Технически изпитания 

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

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

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

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

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

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

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

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

А ето и чеклистът

По този начин се постигат много цели. Това е версионирането на API, и feature toggle, за да се избегне товарният влак на релизите, и постигане на покритие на различни тестове на такова ниво, че тестването да бъде напълно автоматизирано, разгръщанията да бъдат безшевни и др.

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

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

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

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

Кешове

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

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

Освен това, сменването на сериализатора на Kryo в Hazelcast ни предостави съществено увеличаване. А преходът от ReplicatedMap към IMap + Near Cache в Hazelcast ни позволи да минимизираме движението на данни в клъстера. 

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

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

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

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

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

Elasticsearch

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

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

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

API

При проектиране на API заложете изисквания за минимизиране на предавани данни. Особено актуално е при свързването с фронта: именно на това пресичане излизаме извън каналите на нашите ЦОД и вече работим на канала, свързващ ни с клиента. Ако има най-малките проблеми в него, твърде високият трафик предизвиква негативно потребителско изживяване.

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

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

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

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

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

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

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

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

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

Ясно е, че при дистанционна работа и висок темп на промяна, когато бизнес показателите зависят от участието на всеки, не можем да разчитаме само на вътрешни усещания от типа „Как сме? Май всичко е наред“. Необходими са обективни метрики на производствения процес. Такива разполагаме, те са достъпни за всеки, който се интересува от метриките на продуктовите екипи. Първо за самия екип, бизнеса, свързаните екипи и ръководството.

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

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

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

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

Изводи

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

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

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

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

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

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

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

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