Как «Самокат» переехал на новые ИТ-системы и сократил базу данных в 10 раз

«Самокат» — это 785,5 тыс. заказов в день и 129 городов России. За такой масштаб отвечает не только логистика, но и ИТ-инфраструктура, которая должна работать без сбоев. Когда бизнес вырос из старой системы, компания решилась на смелый шаг: одновременно заменить и ERP, и базу данных. Итог — объем базы сократился в 10 раз, а бизнес не остановился ни на минуту. Разбираем, как им это удалось.

#Почему «Самокат» решился на двойную миграцию

Изначально сервис работал на «1С:Управление торговлей» («1С:УТ»), но с ростом числа заказов функционала стало не хватать. Потребовалась более мощная система — 1С:ERP, которая закрывает все аспекты управления крупным предприятием. Параллельно встал вопрос о замене СУБД MS SQL — она не справлялась с нагрузками.

Вместо того чтобы делать два последовательных перехода, команда Ecom.tech (технологическое подразделение «Самоката») решила объединить их. Как объяснил руководитель департамента разработки и эксплуатации учетных систем Сергей Сковпин, это требовало больше ресурсов, но экономило время. После анализа рынка выбор пал на Postgres Pro Enterprise от компании Postgres Professional.

«Возникла идея осуществить оба перехода одновременно. Конечно, это требовало больше ресурсов, но занимало значительно меньше времени, чем внедрение одного проекта за другим».

#Главные сложности: 120 ТБ данных и ноль секунд простоя

Масштаб задачи впечатляет: на момент миграции база занимала 120 ТБ сжатых данных, а ежедневно в ней фиксировалось около 6 млн интеграционных событий. Система работала круглосуточно, без выходных, и остановить её даже на минуту было невозможно — это парализовало бы доставку.

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

• Синхронизация в реальном времени — изменения в старой системе мгновенно отражались в новой.
• Тестирование на реальных нагрузках — можно было проверять работу без риска для бизнеса.
• Поэтапный запуск — функции включались постепенно, с демонстрацией и отладкой.
• Быстрый откат — при обнаружении проблемы возвращались к стабильной версии.
• Обучение пользователей — сотрудники осваивали новую систему ещё до официального перехода.

#Ключевой момент — обмен данными, а не перенос

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

«Важно было не просто перенести данные, а обеспечить непрерывность бизнес-процессов. Мы выстраивали обмен так, чтобы любые изменения в старой системе сразу отражались в новой», — рассказывает Сергей Сковпин.

Для этого использовалось внутреннее решение по событийной интеграции. Оно позволило перейти от работы с отдельными объектами к сквозным бизнес-событиям — это сделало переход более гибким и управляемым.

#Как работает событийная интеграция

Вместо того чтобы синхронизировать каждую таблицу или документ, система отслеживает значимые события: создание заказа, изменение статуса, движение товара. Каждое событие автоматически передаётся в новую систему, и обе базы остаются консистентными.

#Трудности, с которыми столкнулась команда

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

Двойная разработка оказалась самой болезненной: новые функции приходилось создавать и в «1С:УТ», и в 1С:ERP одновременно. Это увеличивало нагрузку на команду. Новый стек — Postgres Pro и сопутствующие инструменты — тоже требовал времени на освоение. Но проект был растянут во времени, и сотрудники успевали учиться на практике.

#Что помогло пройти миграцию без сбоев

Команда выделяет несколько факторов, которые стали решающими:

1. Сильная внутренняя экспертиза — технические специалисты быстро решали сложные архитектурные задачи.
2. Договорённости с бизнесом — заранее согласовали, что на время разработки процессы замедлятся, это сняло давление по срокам.
3. Развитие многопоточности — инструменты позволяли видеть, где накапливается очередь, и увеличивать число обработчиков.
4. Работа с реальными данными — скрытые ошибки выявлялись сразу, а не на тестовых стендах.
5. Поддержка вендора — команда Postgres Professional оперативно реагировала на инциденты, вплоть до совместных видеозвонков и разбора дампов.

«При таких больших объёмах данных критически важна поддержка вендора. В нашем проекте команда Postgres Professional показала высокий профессионализм и быстрое реагирование», — отмечает Сергей Сковпин.

#Результаты: база меньше в 10 раз, запас производительности

Переход прошёл настолько гладко, что финал выглядел буднично: в пятницу сотрудники работали в «1С:УТ», а в понедельник утром просто открыли компьютеры и оказались в 1С:ERP. Ничего не упало и не затормозило.

Эффект от новой СУБД превзошёл ожидания:

• Объём базы данных сократился в 10 раз — с 120 ТБ до 12 ТБ.
• Потребление оперативной памяти снизилось в 3–4 раза.
• Нагрузка на процессор упала в 3 раза.

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

#Что это значит для селлеров

Опыт «Самоката» — это не только история про ИТ-гигантов. Для селлеров на маркетплейсах, которые работают с Wildberries, Ozon или Яндекс Маркет, практические уроки:

• Если ваш бизнес нельзя останавливать, стройте новую систему параллельно старой.
• Фокусируйтесь на качестве обмена данными, а не на механическом переносе.
• Работайте с реальными данными — это выявляет ошибки, которые не видны на тестах.
• Выбирайте вендоров, готовых оперативно подключаться к решению проблем.

«Мир меняют команды. Какой бы необъёмной и сложной ни казалась задача на старте, подходящая команда сможет её решить».

Для любого бизнеса, который планирует масштабирование, миграция на новые системы — это не риск, а возможность. Главное — подойти к ней с умом и не бояться сложных задач.