Каршеринг: журнал поездок и штрафов, который нельзя потерять при смене вендора

MAATRIX

Региональный каршеринг работает на чужой платформе: аренда авто через приложение вендора, телематика вендора, база поездок — тоже у вендора. Пока всё стабильно, это удобно. Но в момент спора с клиентом по поводу штрафа или ДТП выясняется, что журнал поездок нужен вчера, а выгрузить его из чужой системы — отдельный квест с обращением в поддержку и ожиданием ответа. А если вы вообще решите сменить платформу, потому что тарифы выросли или функциональность не устраивает — есть риск, что часть истории поездок и штрафов просто не переедет с вами. Разберём, почему этот журнал критичен именно как юридический актив, и как забрать его под свой контроль на собственном сервере, не разрывая интеграцию с текущей платформой.

Почему журнал поездок — это не лог, а доказательная база

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

То же самое с ДТП, угоном топлива, спорами о повреждениях кузова при возврате. Фотофиксация до и после поездки, GPS-трек, время открытия и закрытия дверей, показания одометра — весь этот набор нужно хранить не «пока не кончится место на диске вендора», а годами, потому что срок исковой давности по гражданским делам — три года, а для дел с ГИБДД документы могут запрашивать спустя месяцы после самого события. Если платформа-вендор урезает историю до 90 или 180 дней (а многие так и делают, чтобы не раздувать свою инфраструктуру), у оператора физически нет данных для защиты своей позиции в споре, который случился полгода назад.

Отдельная тонкость — это ещё и персональные данные клиентов (паспорт, права, платёжные реквизиты, история перемещений), а обработка геолокации и биометрии (если у вас есть фотофиксация лица при получении машины) требует соблюдения 152-ФЗ. Если оператор не понимает, где физически лежит база с этими данными и кто к ней имеет доступ — это тоже риск, отдельный от рисков потери самих поездок. У нас в блоге есть отдельный разбор, где законно хранить сервер с персональными данными, если у вас уже встаёт вопрос с проверяющими.

Как устроена типичная связка «платформа вендора + бортовое оборудование»

Стандартная схема небольшого регионального каршеринга выглядит так: в машину ставится бортовой модуль (иммобилайзер + GPS-трекер + иногда камера салона), он передаёт телематику на сервер вендора платформы. Приложение для клиентов, биллинг, начисление штрафов за нарушение зон парковки или курение в салоне, интеграция со страховой — тоже на стороне вендора. Оператор каршеринга видит красивую админку, но данные физически лежат на инфраструктуре поставщика ПО, зачастую вообще без возможности прямого доступа к базе — только через API платформы или ручной экспорт CSV раз в месяц.

Проблема вылезает в трёх ситуациях. Первая — вендор поднимает цену подписки (для небольшого парка в 20-40 машин ежемесячный платёж за платформу часто оказывается заметной статьёй расходов, и рост на 30-50% — это уже повод искать альтернативу). Вторая — у вендора меняется продуктовая политика, платформу закрывают или сливают с другой (SaaS-рынок каршеринговых решений у нас ещё молодой, консолидация вполне реальна). Третья — просто хочется гибкости: свой скоринг клиентов, свои правила начисления штрафов, интеграция с локальной страховой, которых в стандартной платформе нет.

Во всех трёх случаях оператор оказывается перед фактом: чтобы уйти к другому поставщику или на своё решение, надо забрать историю. И тут выясняется, что экспорт в лучшем случае даёт таблицу поездок без фотографий осмотра, без полного трека GPS, без переписки с клиентом по спорной ситуации. В худшем — техподдержка отвечает через две недели и присылает частичный дамп. Это не злой умысел вендора, а естественное следствие того, что чужая платформа не обязана хранить ваши архивные данные вечно и бесплатно — у неё свои лимиты хранения и свой SLA на выгрузку.

Что значит «данные принадлежат вам напрямую»

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

Технически это означает три вещи. Во-первых, отдельный VPS или выделенный сервер под СУБД — обычно достаточно PostgreSQL, он спокойно тянет и реляционные данные (клиенты, договоры, штрафы), и геометки через расширение PostGIS для хранения треков. Установка описана в статье как установить и настроить PostgreSQL на VPS, если у вас такой базы ещё нет. Во-вторых, механизм синхронизации — почти все платформы каршеринга дают вебхуки или REST API, через которые можно забирать события «поездка завершена», «начислен штраф», «зафиксировано нарушение» в реальном времени, а не выгрузкой раз в месяц. В-третьих — регулярный бэкап именно этой базы на отдельное хранилище, потому что смысл всей затеи теряется, если сервер с копией данных сам окажется точкой отказа.

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

Для старта не нужна сложная архитектура — достаточно нормализованной реляционной схемы из пяти-шести таблиц. Условный набросок на PostgreSQL:

CREATE TABLE clients (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    full_name TEXT NOT NULL,
    license_number TEXT,
    phone TEXT,
    created_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE vehicles (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    plate_number TEXT UNIQUE NOT NULL,
    vin TEXT,
    model TEXT
);

CREATE TABLE trips (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    client_id UUID REFERENCES clients(id),
    vehicle_id UUID REFERENCES vehicles(id),
    started_at TIMESTAMPTZ NOT NULL,
    finished_at TIMESTAMPTZ,
    start_odometer INTEGER,
    end_odometer INTEGER,
    source_platform TEXT,      -- через какого вендора прошла поездка
    external_trip_id TEXT      -- id поездки в системе платформы
);

CREATE TABLE trip_locations (
    trip_id UUID REFERENCES trips(id),
    ts TIMESTAMPTZ NOT NULL,
    lat DOUBLE PRECISION,
    lon DOUBLE PRECISION
);

CREATE TABLE fines (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    trip_id UUID REFERENCES trips(id),
    fine_type TEXT,             -- парковка, скорость, эвакуация и т.д.
    amount_kopecks BIGINT,
    issued_at TIMESTAMPTZ,
    document_url TEXT,          -- ссылка на скан постановления, хранится тоже у вас
    status TEXT DEFAULT 'issued'
);

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

Документы (сканы постановлений, фото осмотра при получении и возврате машины) разумно не заливать прямо в базу как BLOB, а держать файлами на том же сервере или в объектном хранилище, а в базе хранить только путь или ссылку — так проще и бэкапить, и масштабировать при росте архива.

Перенос истории со старой платформы

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

Сначала — выгрузка. У большинства платформ каршеринга есть либо REST API с постраничной выдачей поездок, либо кнопка «экспорт в CSV/Excel» в админке. Если API есть — пишется небольшой скрипт (Python с requests или любой язык, которым владеет ваша команда), который постранично забирает все поездки и штрафы за нужный период и складывает их во временные файлы или сразу в staging-таблицу вашей базы.

Дальше — сверка и нормализация. Экспорт из чужой системы почти никогда не совпадает 1:1 со схемой, которую вы спроектировали у себя: другие названия полей, другой формат дат, суммы штрафов иногда в рублях, иногда в копейках. На этом этапе пишется ETL-скрипт, который приводит данные к вашей схеме и проверяет базовые инварианты — не бывает поездки с временем окончания раньше начала, штраф не может ссылаться на несуществующую поездку. Ошибки на этом шаге лучше логировать в отдельную таблицу «требует ручной проверки», а не блокировать весь импорт из-за десятка кривых записей.

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

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

Синхронизация в реальном времени, а не разовый экспорт

Разовый перенос истории решает проблему прошлого, но не проблему будущего — если вы продолжаете работать через ту же платформу вендора (а полностью отказаться от готового решения ради своей системы решаются немногие, это дорого и долго), нужен постоянный канал, по которому новые поездки и штрафы попадают в вашу базу сразу, а не раз в месяц.

Практический вариант — вебхуки. Большинство платформ каршеринга умеют слать POST-запрос на ваш эндпоинт при событии «поездка завершена» или «зафиксирован штраф». На вашем сервере поднимается небольшой сервис (тот же FastAPI или Express), который принимает вебхук, валидирует подпись запроса (у платформы обычно есть HMAC-секрет для этого), и пишет запись в базу. Если вебхуков нет или они ненадёжны (иногда платформа их просто не досылает при сбое на своей стороне) — резервный вариант — периодический опрос API раз в 15-30 минут с догрузкой того, что могло потеряться.

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

Бэкап журнала — отдельный контур защиты

Вся конструкция теряет смысл, если сервер с вашей копией данных сгорает вместе с диском без резервной копии — тогда вы просто перенесли точку отказа из чужой инфраструктуры в свою, ничего не выиграв. Бэкап базы должен идти по классической схеме 3-2-1: минимум одна копия за пределами того же физического сервера.

Для PostgreSQL это либо pg_dump по расписанию через cron с шифрованием архива перед отправкой во внешнее хранилище, либо, если объём данных уже заметный (много треков GPS с высокой детализацией), потоковая репликация на второй сервер плюс отдельные архивные снапшоты раз в сутки. Если у вас уже настроен бэкап с шифрованием для других сервисов — тот же контур разумно переиспользовать и здесь, см. бэкап с шифрованием на VPS. Шифрование архива обязательно, если в базе лежат персональные данные клиентов и сканы документов — иначе утечка резервной копии станет отдельным инцидентом поверх всего остального.

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

Частые вопросы