Маркетплейс Flowwow: спасение бизнеса в условиях IT-санкций

В 2014 году маркетплейс Flowwow начинал как агрегатор по продаже цветов, но сейчас с площадкой сотрудничают более 6 тысяч продавцов, продающих товары более 20 разных категорий в 950 городах. И как любой маркетплейс, Flowwow – это IT-бизнес, работа которого зависит от множества сервисов, предоставляемых международными IT-компаниями. В феврале 2022 года компания столкнулась с кризисом: из России ушли крупнейшие платежные системы, многие IT-сервисы прекратили работать с российскими пользователями, в работах геокарт стали происходить сбои… О том, как компания сумела спасти свою IT-архитектуру и добиться устойчивости, в этой статье рассказывает Дмитрий Шестернин, технический директор маркетплейса локальных брендов Flowwow.

Шаг 1. Оценить обстановку

Международные компании, сервисами которых мы пользовались каждый день, по-разному отреагировали на произошедшие в феврале события.

Многие из них полностью прекратили сотрудничать с российскими пользователями и компаниями, вплоть до блокировки по IP-адресам. Такой путь избрали Apple, Booking.com и Airbnb, Citrix и еще многие.

Другие – пока лишь ограничили свое присутствие. Cloud-платформа Google (не путать с Google Russia, которая объявила себя банкротом) отказалась от поддержки клиентов (ею мы, к счастью, не пользовались), но продолжила предоставлять основные платные сервисы.

Наконец, часть западных компаний, предоставляющих важные IT-сервисы, осталась работать на прежних условиях. В их числе – Amazon AWS, на чьих серверах развернута часть нашей платформы, и GitHub – вебсервис, где мы ведем разработку. Последний в настоящий момент закрыл аккаунты для российских компаний, попавших под санкции, но не прекратил работу с другими.

Независимо от сценария взаимодействия, решительно у всех компаний возникли трудности с оплатой международных сервисов – независимо от степени лояльности их производителей. Поиск альтернативных способов оплаты каждого сервиса – неотъемлемая часть работы любой российской компании в 2022 году.  

Фото: Ukki Studio/shutterstock

Шаг 2. Оценка рисков и алгоритм действий

Мы составили перечень всех зарубежных сервисов, с которыми работаем, и проранжировали их с точки зрения критичности для бизнеса; уход одного сервиса может вызвать у нас временный дискомфорт, уход другого – парализовать всю работу бизнеса.

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

1. Заботимся о безопасности текущих данных, делаем бэкапы.

2. Рассматриваем альтернативные сервисы, анализируем, выбираем подходящий.

3. Готовимся к интеграции.

4. Тестируем (на небольшой территории, на части процессов и т.д.), следим за работой нового сервиса.

5. Если все устраивает, масштабируем на всю систему.

Желательно на последних этапах так продумать архитектуру проекта, чтобы одна интеграция открывала пути для последующих: то есть сейчас вы выбираете один сервис, с которым будете работать, но в следующий момент сможете легко переключить на другой, третий и т.д. Ниже покажем, как мы это сделали. 

Шаг 3. Защититься от самых серьезных рисков

Риск 1: отключение платформы

Несмотря на то что Аmazon остался в России, находиться на его серверах может быть очень рискованно для компании, предоставляющей сервис на территории России и имеющей доход в рублях.

Решение: в феврале мы сразу сделали бэкап всех данных платформы на российское облачное решение. Затем за несколько месяцев развернули полноценную боевую схему на «Яндекс.Облаке». Основная нагрузка легла на нашу команду DevOps: пришлось оставить ранее намеченный план и срочно заняться спасением наших данных.

Этапы:

1. К 15 марта запустили полноценный сервис с минимальной нагрузкой (не более 10% мощности) и в течение двух месяцев изучали, как ведет себя облачный провайдер, чтобы отследить на боевом трафике сетевые задержки и падения.

2. К июню перевели весь трафик русскоязычных пользователей (из России и стран СНГ) на обслуживание серверов через «Яндекс.Облако».

Риск 2: сбой работы географических карт

Работа Flowwow остро заточена на геоинформацию. Это ядро нашего сервиса: поиск магазинов, находящихся поблизости от получателя, плюс работа нашей курьерской доставки. 

Google-карты составляли около 50% всех наших расходов на сторонние сервисы (а когда в марте доллар вырос в несколько раз, траты стали еще более значительными).

Решение: планомерно перенесли систему для всех русскоязычных пользователей с Google Maps на «Яндекс.Карты» – на сайте, в клиентских приложениях, в панели администраторов, в приложениях для магазинов и курьеров.

Этапы:

1. Анализ альтернативного сервиса: мы установили «Яндекс.Карты» для тестовой локации, убедились, что у «Яндекса» есть все нужные нам опции.

2. Подготовка переноса на бэке.

3. Перенос каждого фронтенда, использующего карточный слой, с последующим исправлением багов.

Вынужденный переход на другое гео подарил нам несколько приятных эффектов. Во-первых – сокращение расходов на Google Maps в пять раз. Во-вторых – карты «Яндекса» для России более точные, с лучшей детализацией, чем Google.

В результате наши пользователи за рубежом продолжили спокойно пользоваться Google Maps, а все пользователи из России безболезненно переехали на «Яндекс.Карты».

Риск 3: падение конверсии из-за отключения удобных платежных систем

До февраля мы развивали свой сервис так, чтобы клиенты могли оплачивать заказы через Google Pay и Apple Pay, и очень радовались, когда доля платежей через эти сервисы росла.

В апреле клиенты нашей платформы потеряли возможность пользоваться самым удобным и привычным способом оплаты. Это нас не парализовало, но сильно ударило по показателям продаж.

Решение. Мы рассмотрели все доступные на данный момент системы платежей на российском рынке, быстро провели интеграцию с Yandex Pay, затем SberPay. Как и в случае с картами, мы попутно подготовили инфраструктуру к тому, чтобы в нее можно было легко интегрировать любую платежную систему. Здесь не могу не поблагодарить наших партнеров из CloudPayments, которые в период максимальной неопределенности действовали гибко, переключались с одного банка на другой, чтобы не допускать просадок по оплатам на сервисе.

Шаг 4. Продумать отходные пути для инфраструктурных рисков

Итак, избавившись от главных рисков, мы исключили сценарий, при котором наша платформа будет парализована из-за ухода международного IT-сервиса. Остались другие, менее серьезные риски, но все же важные для жизнедеятельности бизнеса:

1. GitHub. Сохранили все репозитории с кодом на сервера на территории РФ и наши локальные компьютеры, рассмотрели альтернативные решения для хранения кода, выбрали в качестве альтернативы self-hosted Gitlab, продумали алгоритм его подключения.

2. Atlassian (инструменты Jira и Confluence). Забэкапили у себя на локальных серверах все архивы (мы и так регулярно это делаем). Рассмотрели альтернативные self-hosted решения, нашли компанию, которая ранее выносила документацию и задачи на связке Redmine и Wiki. Теперь мы знаем, у кого просить помощи в случае форс-мажора. Также, для страховки, купили годовую лицензию на Jira: в цивилизованном мире финансовые договоренности пока еще работают.

3. SLACK. Выгрузили архивом 25 гигабайт данных переписки в SLACK, примерили альтернативы (наиболее подходящие – self-hosted RetailRocket и MasterMost). В ходе работы выяснили, что наши внутренние интеграции в SLACK устарели, и оперативно подготовили структуру для новых интеграций.  

Что в итоге?

Пока этот год для многих из нас (и для меня тоже) – один из самых сложных и интересных за всю жизнь и карьеру. Как инженеры мы сталкиваемся с сильными вызовами и невероятно интересными задачами.

Бизнес Flowwow мог пошатнуться – но вместо этого вся его система стала более прочной, глобальной и универсальной. Мы научились не быть привязанными к одному решению, провайдеру, дата-центру: мы стали более гибкими и независимыми от частных решений.

Мой главный совет коллегам, которые сейчас сталкиваются с теми же трудностями, что и мы: на время откажитесь от перфекционизма. Идеальных цифровых продуктов для бизнеса и раньше не было, и теперь не стоит рассчитывать на то, что вы их найдете. Но давайте обратимся к принципу Парето: если найденная вами альтернатива привычному сервису решает 80% ваших задач при помощи 20% функционала – это уже хороший результат.

Retail.ru